我目前正在尝试提高Web应用程序的性能。该应用程序的目标是提供(real time) analytics。我们有一个类似于star schema的数据库模型，很少的事实表和许多维度表。数据库正在使用Mysql和MyIsam引擎运行
Fact表的大小可以很容易地进入数百万，而一些维表也可以达到数百万
现在重点是，如果维度表在事实表上加入并且还完成了聚合，则选择查询会变得非常慢。听到这个时首先想到的是，为什么不预先计算数据呢？这是不可能的，因为允许用户使用几个可自由定制的过滤器。
所以我需要的是一个适合各种用途的一体化系统;）可悲的是它还没有发明。所以我想到了结合2个现有系统的想法。混合row oriented和column oriented数据库（例如infinidb或infobright）。保持mysql MyIsam解决方案（用于快速插入和基于行的查询）并向其添加面向列的数据库（用于在几列上进行快速聚合操作）并通过cronjob定期（每晚）填充它。问题是当查询当前数据（它必须是实时）时，因此我可能需要从两个数据库中获取可能使事情复杂化的数据。
使用infinidb进行的首次测试在几列的聚合上表现出非常好的性能，所以我认为这可以帮助我加快应用程序的速度。
所以问题是，这是一个好主意吗？有人可能已经这样做了吗？也许有更好的方法来做到这一点。
我还没有面向列的数据库的经验，我也不确定它的架构应该是什么样子。第一次测试在同一star schema like结构上表现出良好的性能，但在big table like结构中表现良好。
我希望这个问题符合SO。
答案 0 :(得分：3)
Greenplum是PostgreSQL的专有（但大多是免费的）啤酒扩展，支持具有高可定制压缩的面向列和面向行的表。此外，如果您希望某些部分会遇到繁重的事务负载，而其他部分则不会，则可以在同一个表中混合设置。例如，你最近的一年可能是面向行和未压缩的，前一年是面向列的，并且是quicklz-compresed，所有历史年份都是面向列和bz2压缩的。
Greenplum可以在个人服务器上免费使用，但如果你需要扩展其MPP功能（这是它的主要卖点），它确实需要花费大量资金，因为它们的目标是大型企业客户。
（免责声明：我已专业处理Greenplum，但仅限于评估其购买软件的情况。）
至于如何设置架构的问题，在不了解数据细节的情况下很难说很多，但一般来说，压缩的面向列的表应该让你对架构设计的所有直觉都消失了
特别是，规范化几乎不值得付出努力，有时你可以通过非规范化到边缘 - 滑稽的冗余级别来获得性能上的巨大提升。如果数据从未在未压缩状态下访问磁盘，您可能根本不在乎您是否重复每个客户的名称40,000次。 Infobright的压缩算法专门针对这种应用程序而设计，并且在表的逻辑大小和物理大小之间以40：1的比率结束并不罕见。