Answers:
面向列的数据库(=列数据存储)将表的数据逐列存储在磁盘上,而面向行的数据库则逐行存储表的数据。
与面向行的数据库相比,使用面向列的数据库有两个主要优点。第一个优点与万一我们仅对某些功能执行操作时需要读取的数据量有关。考虑一个简单的查询:
SELECT correlation(feature2, feature5)
FROM records
传统的执行者会读取整个表(即所有功能):
相反,使用基于列的方法,我们只需要阅读感兴趣的列:
第二个优点(对于大型数据库也非常重要)是基于列的存储可实现更好的压缩,因为一个特定列中的数据确实比所有列中的数据均质。
面向列的方法的主要缺点是操纵(查找,更新或删除)整个给定的行效率很低。但是,这种情况很少发生在用于分析(“仓库”)的数据库中,这意味着大多数操作是只读的,很少读取同一表中的许多属性,而写操作只是追加操作。
某些RDMS提供面向列的存储引擎选项。例如,PostgreSQL本身没有选择以基于列的方式存储表,但是Greenplum创建了一个封闭源代码(DBMS2,2009)。有趣的是,Greenplum还在开源库中支持可扩展的数据库内分析MADlib(Hellerstein等,2012),这绝非偶然。最近,致力于高速分析数据库的初创公司CitusDB发布了自己的PostgreSQL CSTORE开源列式商店扩展(Miller,2014年)。Google的大规模机器学习系统Sibyl也使用面向列的数据格式(Chandra等,2010)。这种趋势反映出人们对面向列的用于大型分析的存储越来越感兴趣。Stonebraker等。(2005年)进一步讨论了面向列的DBMS的优点。
两个具体的用例:如何存储大多数用于大规模机器学习的数据集?
(大多数答案来自BeatDB的附录C:BeatDB:一种从大量信号数据集中揭示显着性的端到端方法。Franck Dernoncourt,SM,论文,EECS的MIT系)
这要看是什么你做什么。
列存储具有两个主要优点:
但是它们也有缺点:
列式存储在OLAP(又称“愚蠢的分析”)(Michael Stonebraker)中很受欢迎,当然对于预处理,您可能确实有兴趣丢弃整列(但是您首先需要具有结构化数据-不在列式中存储JSON)格式)。因为柱状布局非常适合例如计算您上周售出的苹果数量。
对于许多科学/数据科学用例,阵列数据库似乎是必经之路(当然,还有非结构化输入数据)。例如SciDB和RasDaMan。
在许多情况下(例如深度学习),矩阵和数组是您需要的数据类型,而不是列。当然,MapReduce等在预处理中仍然有用。甚至列数据(但数组数据库通常也支持类似列的压缩)。
我没有使用过列式数据库,但是我使用了一种称为Parquet的开源列式文件格式,我认为好处可能是相同的-当您只需要查询大型数据库的一小部分时,数据处理速度就更快列数。我有一个查询,它在大约50 TB的Avro文件(面向行的文件格式)上运行,其中有673列,在140节点Hadoop集群上花费了大约一个半小时。使用Parquet,相同的查询花费了大约22分钟,因为我只需要5列。
如果您的列数很少或使用的列数很大,那么我认为列式数据库与面向行的数据库不会有太大的区别,因为您仍然必须基本上扫描所有数据。我相信列式数据库分别存储列,而面向行的数据库则分别存储行。只要您能够从磁盘读取较少的数据,查询就会更快。
此链接说明了更多详细信息。
注意:这是我的问题,我真的很感谢这里的精彩回答,这有助于我理解这一概念。
因此,我将以我理解的方式来解释该概念:
通常,数据库中的数据以以下格式存储在内存中:
考虑以下数据:
X1 X2
1 0.7091409 -1.4061361
2 -1.1334614 -0.1973846
3 2.3343391 -0.4385071
在基于关系行的存储中,它的存储方式如下:
1, 0.7091409, -1.4061361, 2, -1.1334614, -0.1973846, 3, 2.3343391, -0.4385071
以行的形式。
在柱状存储中,它将像这样存储:
1, 2, 3, 0.7091409 ,-1.1334614, 2.3343391, -1.4061361, -0.1973846, -0.4385071
以列的形式。
那么这是什么意思?
这意味着在基于行的列存储中,插入(和更新)和删除操作很快,因为它只是删除了后几个值或前几个值。但是,在列式存储中并非如此,因为需要删除每个块存储中的值。
但是,当需要列聚合和操作时,由于列存储按列存储,所以列存储在基于行的对应存储上具有优势,因此,访问单个列非常容易。