列存储:比较基于列的数据库

我一直在努力使SQL Server成为一种东西,坦率地说,它永远不会.我需要一个数据库引擎来进行分析工作.数据库需要快速,不需要在典型数据库(SQL Server,Oracle,DB2等)中找到的所有日志记录和其他开销.

昨天我听了Michael Stonebraker在Money:Tech会议上发言,我一直在想,"我真的不是很疯狂.有更好的方法!" 他谈到使用列存储而不是面向行的数据库.我去了维基百科页面上的列商店,我看到了一些开源项目(我喜欢)和一些商业/开源项目(我不太了解).

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

我最终将数据拉入R进行分析.

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

简短的回答是,对于分析数据,列存储将更快,需要更少的调整.

行存储是传统的数据库体系结构,可以很好地插入少量行,更新行,并查询少量行.在行存储中,可以使用一个或两个磁盘块I/O完成这些操作.

分析数据库通常一次加载数千条记录; 有时,就像你的情况一样,他们会重新加载一切.它们往往是非规范化的,所以有很多列.在查询时,他们经常读取表中的大部分行,但只读取这些列中的一小部分.因此,从I/O的角度来看,将同一列的值存储在一起是有意义的.

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

通常在计算机科学中存在I/O与CPU时间的权衡,但在列存储中,I/O改进通常会改善引用的局部性,减少缓存分页活动,并允许更大的压缩因子,从而CPU也会增加.

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

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

我建议您尝试一下LucidDB.(免责声明:我是LucidDB的提交者.)它是开源列存储数据库,针对分析应用程序进行了优化,还具有其他功能,如位图索引.它目前只在一个节点上运行,但有效地利用了几个核心,并且可以轻松处理合理数量的数据.