3

我目前正在尝试提高 Web 应用程序的性能。该应用程序的目标是提供(real time) analytics. 我们有一个类似于star schema少量事实表和多维表的数据库模型。数据库MysqlMyIsam引擎一起运行。
Fact 表的大小很容易达到上百万,一些维度表也可以达到上百万。
现在的重点是,如果维度表在事实表上连接并且聚合完成,则选择查询会变得非常慢。听到这个时首先想到的是,为什么不预先计算数据呢?这是不可能的,因为允许用户使用几个可自由定制的过滤器。

所以我需要的是一个适合各种用途的一体化系统;)遗憾的是,它还没有被发明出来。所以我想到了结合两个现有系统的想法。混合 arow orientedcolumn oriented数据库(例如 likeinfinidbinfobright)。保留 mysql MyIsam 解决方案(用于快速插入和基于行的查询)并向其添加面向列的数据库(用于在少数列上进行快速聚合操作)并通过 cronjob 定期(每晚)填充它。问题是当查询当前数据(它必须是实时的)时,因此我可能需要从两个数据库中获取数据,这会使事情变得复杂。

使用 infinidb 进行的第一次测试显示在聚合几列时性能非常好,所以我真的认为这可以帮助我加快应用程序的速度。

所以问题是,这是个好主意吗?有人可能已经这样做了吗?也许有更好的方法来做到这一点。

我还没有面向列的数据库的经验,我也不确定它的架构应该是什么样子。第一次测试显示在相同star schema like结构上的良好性能,而且在结构上也表现出良好的性能big table like

我希望这个问题适合SO。

4

1 回答 1

3

Greenplum是 PostgreSQL 的专有(但大部分是免费的)扩展,支持具有高度可定制压缩的面向列和面向行的表。此外,如果您预计某些部分会经历繁重的事务负载而其他部分不会,您可以在同一个表中混合设置。例如,您可以让最近一年面向行且未压缩,前一年面向列且经过 quicklz 压缩,所有历史年份均面向列且经过 bz2 压缩。

Greenplum 可免费在单个服务器上使用,但如果您需要利用其 MPP 功能(这是它的主要卖点)进行横向扩展,它确实需要花费大量资金,因为它们针对的是大型企业客户。

(免责声明:我专业地与 Greenplum 打过交道,但只是在评估他们购买的软件的情况下。)

至于如何设置模式的问题,在不了解数据细节的情况下很难说太多,但总的来说,拥有压缩的面向列的表应该会让你对模式设计的所有直觉都消失。

特别是,规范化几乎不值得付出努力,有时您可以通过将非规范化到临界滑稽级别的冗余来获得巨大的性能提升。如果数据从未在未压缩状态下进入磁盘,您可能只是不在乎重复每个客户的姓名 40,000 次。Infobright的压缩算法是专门为这类应用程序设计的,最终表格的逻辑大小和物理大小之间的比率为 40 比 1 的情况并不少见。

于 2011-04-15T12:35:11.887 回答