database - 列存储 : Comparing Column Based Databases

Question

我一直在努力使 SQL Server 成为某种东西，坦率地说，它永远不会成为这样的东西。我的分析工作需要一个数据库引擎。数据库需要快速并且不需要典型数据库(SQL Server、Oracle、DB2 等)中的所有日志记录和其他开销。

昨天我听了Michael Stonebraker speak at the Money:Tech conference我一直在想，“我不是真的疯了。有更好的方法!”他谈到使用 column stores而不是面向行的数据库。我去了 column stores 的维基百科页面我看到了一些开源项目(我喜欢)和一些商业/开源项目(我不完全理解)。

我的问题是:在应用分析环境中，不同的基于列的数据库有何不同？我应该怎么想他们？有人对基于多列的系统有实践经验吗？我能否在这些数据库中利用我的 SQL 经验，还是我必须学习一门新语言？

我最终会将数据提取到 R 中进行分析。

编辑:有人要求我澄清我到底想做什么。所以，这是我想做的一个例子:创建一个包含 400 万行和 20 列(5 个维度，15 个事实)的表。创建 5 个聚合表，计算每个事实的最大值、最小值和平均值。将这 5 个聚合连接回起始表。现在计算每行的平均值偏差百分比、最小偏差百分比和最大值偏差百分比，并将其添加到原始表中。该表数据不会每天都有新行，它会被完全替换并重复该过程。如果必须停止该过程，天堂禁止。还有原木……哦，原木! :)

Answer 1

简短的回答是，对于分析数据，列存储往往速度更快，需要的调整更少。

行存储是传统的数据库架构，擅长插入少量行、就地更新行和查询少量行。在行存储中，这些操作可以通过一个或两个磁盘 block I/O 来完成。

分析数据库通常一次加载数千条记录；有时，就像您的情况一样，他们会重新加载所有内容。它们往往是非规范化的，所以有很多列。并且在查询时，他们经常读取表中大部分的行，但只读取其中的少数列。因此，从 I/O 的角度来看，将同一列的值存储在一起是有意义的。

事实证明，这为数据库提供了进行值(value)压缩的巨大机会。例如，如果字符串列的平均长度为 20 个字节，但只有 25 个不同的值，则数据库可以将每个值压缩到大约 5 位。列存储数据库通常可以在不解压缩数据的情况下运行。

在计算机科学中，通常存在 I/O 与 CPU 时间的权衡，但在列存储中，I/O 的改进通常会改善引用的局部性，减少缓存分页事件，并允许更大的压缩因子，从而使 CPU 也获得 yield 。

列存储数据库还倾向于具有其他面向分析的功能，如位图索引(另一种情况，其中更好的组织允许更好的压缩，减少 I/O，并允许更高效的 CPU 算法)、分区和物化 View .

另一个因素是是否使用大规模并行 (MMP) 数据库。有 MMP 行存储和列存储数据库。 MMP 数据库可以扩展到数百或数千个节点，并允许您存储大量数据，但有时会做出妥协，例如较弱的事务概念或不完全是 SQL 的查询语言。

我建议您尝试一下 LucidDB。 (免责声明:我是 LucidDB 的贡献者。)它是开源列存储数据库，针对分析应用程序进行了优化，还具有位图索引等其他功能。它目前仅在一个节点上运行，但可以有效地利用多个内核，并且可以毫不费力地处理合理的数据量。