Bigtable不是column store(列存储) !
2011-02-28 23:59
363 查看
题外话,今天无意中查看以前写的blog,发现好多blog的呈现只有一堆乱码,正文不见了。可是点击编辑正文又出现了... 我这算是给CSDN报bug了。
最近看了好些文章,将bigtable/hbase等归入column store(列存储)。甚至,将column store做为了NOSQL的一部分。这样的观点是不对的。
首先需要解释一下什么是column store。举个简单例子(现摘自wiki,我是懒人...):
这是database中的一张table。对于传统的DBMS,它在Disk上大概是这样排列数据的:
1 Smith Joe 40000 ;
2 Jones Mary 50000 ;
3 Johnson Cathy 44000 ;
table中的每一行(即每一条记录)在Disk上是紧密排列的,也就是raw-oriented store。一般最常用的Database,比如MySQL,Oracle等等,都属于此类。
而colum store则不同,它在Disk是这样的:
1,2,3;
Smith,Jones,Johnson;
Joe,Mary,Cathy;
40000,50000,44000;
它将table中的每一列的数据项放在了一起。(必须得说,这只是一个基本的概念,实际中的colum store会更复杂一些)
早期的Database主要为满足OLTP的需求,大部分的操作都是插入删除,raw store自然成为最舒服的方案,因为采用raw store可以很容易的找到一个记录所包含的所有数据。但是,在当前海量数据的情况下,OLAP的需求越来越大,相当多复杂的查询,column store在这种情况下就很有优势,原因大致有二(自己总结的,可能不全面):
一,很多的查询往往只是针对一个table表的某几列,但如果用row store,不可避免的需要扫描所有的数据(如果不用index的话,实际中,你也不可能对所有column建index);而采用column store,只需要访问对应的column包含的数据;
二,相同的column的数据一般都是相同的数据结构,把它们放在一起,压缩比会大大提高。也许你会说,现在Disk很便宜。但是,压缩率高的一个更大的好处在于每次IO可以从Disk读取更多的数据,相对的,你可以认为是提高了Disk的IO,这对于Database可是至关重要的;
解释完了column store,再回头来看Bigtable/Hbase,你就会发现它们完全是两码事。我很奇怪为什么Bigtable会被认为是column store,也许是因为它有一个“column family”的原因,也许是因为在paper中它提及自己受到了column store的影响“Bigtable locality groups realize similar compression and disk read performance benefits observed for other systems that organize data on disk using column-based rather than row-based storage”。但这并不能说明Bigtable就是按照column的顺序将数据写入到的Disk。
在前面的column store在Disk上如何排列数据例子中,数据并没有被标示属于table中的哪一行,这是因为根据数据项在每一个column中的顺序我们就能知道它处于table中哪一行。比如Joe,它位于自己column的第一项,所以,它属于table的第一行。而Bigtable所强调的应用场景是有大量稀疏数据的,而稀疏数据如果按照column store的方式排列,将会产生大量的Null值。所以,Bigtable中的column family只是在Data Model层面上的一个概念,和column store完全不同。
另外,column store强调的是数据在Disk上以column的方式组织。但是,它并不限定上层的Data Model的形式,所以,以column store来判定该系统不属于relational database是完全没有依据的。讽刺的是,大部分column store提供的接口其实都是SQL,都支持ACID,都属于relational database,而不是NOSQL。
Reference:
[1] Wiki: Column-oriented DBMS
[2] Distinguishing Two Major Types of Column-Stores
Abadi的这篇blog论述得更为详细,此外,他将Bigtable这类的系统称呼为column-family store。我觉着这个称谓更贴切些。
[3] C-Store: A Column Oriented DBMS
这是最有名的一个column store系统,Bigtable也相当程度借鉴了它的思想。可惜的是,它的源代码版本太低了,基本上跑不起来。另外一个开源的column store系统就是MonetDB,它是一个完整的系统,接口是SQL。不过,基于我之前的实验和经验,这个系统也不是太稳定。
最近看了好些文章,将bigtable/hbase等归入column store(列存储)。甚至,将column store做为了NOSQL的一部分。这样的观点是不对的。
首先需要解释一下什么是column store。举个简单例子(现摘自wiki,我是懒人...):
这是database中的一张table。对于传统的DBMS,它在Disk上大概是这样排列数据的:
1 Smith Joe 40000 ;
2 Jones Mary 50000 ;
3 Johnson Cathy 44000 ;
table中的每一行(即每一条记录)在Disk上是紧密排列的,也就是raw-oriented store。一般最常用的Database,比如MySQL,Oracle等等,都属于此类。
而colum store则不同,它在Disk是这样的:
1,2,3;
Smith,Jones,Johnson;
Joe,Mary,Cathy;
40000,50000,44000;
它将table中的每一列的数据项放在了一起。(必须得说,这只是一个基本的概念,实际中的colum store会更复杂一些)
早期的Database主要为满足OLTP的需求,大部分的操作都是插入删除,raw store自然成为最舒服的方案,因为采用raw store可以很容易的找到一个记录所包含的所有数据。但是,在当前海量数据的情况下,OLAP的需求越来越大,相当多复杂的查询,column store在这种情况下就很有优势,原因大致有二(自己总结的,可能不全面):
一,很多的查询往往只是针对一个table表的某几列,但如果用row store,不可避免的需要扫描所有的数据(如果不用index的话,实际中,你也不可能对所有column建index);而采用column store,只需要访问对应的column包含的数据;
二,相同的column的数据一般都是相同的数据结构,把它们放在一起,压缩比会大大提高。也许你会说,现在Disk很便宜。但是,压缩率高的一个更大的好处在于每次IO可以从Disk读取更多的数据,相对的,你可以认为是提高了Disk的IO,这对于Database可是至关重要的;
解释完了column store,再回头来看Bigtable/Hbase,你就会发现它们完全是两码事。我很奇怪为什么Bigtable会被认为是column store,也许是因为它有一个“column family”的原因,也许是因为在paper中它提及自己受到了column store的影响“Bigtable locality groups realize similar compression and disk read performance benefits observed for other systems that organize data on disk using column-based rather than row-based storage”。但这并不能说明Bigtable就是按照column的顺序将数据写入到的Disk。
在前面的column store在Disk上如何排列数据例子中,数据并没有被标示属于table中的哪一行,这是因为根据数据项在每一个column中的顺序我们就能知道它处于table中哪一行。比如Joe,它位于自己column的第一项,所以,它属于table的第一行。而Bigtable所强调的应用场景是有大量稀疏数据的,而稀疏数据如果按照column store的方式排列,将会产生大量的Null值。所以,Bigtable中的column family只是在Data Model层面上的一个概念,和column store完全不同。
另外,column store强调的是数据在Disk上以column的方式组织。但是,它并不限定上层的Data Model的形式,所以,以column store来判定该系统不属于relational database是完全没有依据的。讽刺的是,大部分column store提供的接口其实都是SQL,都支持ACID,都属于relational database,而不是NOSQL。
Reference:
[1] Wiki: Column-oriented DBMS
[2] Distinguishing Two Major Types of Column-Stores
Abadi的这篇blog论述得更为详细,此外,他将Bigtable这类的系统称呼为column-family store。我觉着这个称谓更贴切些。
[3] C-Store: A Column Oriented DBMS
这是最有名的一个column store系统,Bigtable也相当程度借鉴了它的思想。可惜的是,它的源代码版本太低了,基本上跑不起来。另外一个开源的column store系统就是MonetDB,它是一个完整的系统,接口是SQL。不过,基于我之前的实验和经验,这个系统也不是太稳定。
相关文章推荐
- 温习SQL Server 列存储索引 Column Store Index
- SQL Server ->> ColumnStore Index(列存储索引)
- SAP HANA 列存储(SAP HANA Column Store)
- oracle 12c (内存列存储)IM column store
- SQL Server 2012中的ColumnStore Index尝试
- 浅谈MSSQL2012中的列存储索引(columnstore indexes)
- Column store index 列数据如何匹配成行数据?
- C-Store: A Column-oriented DBMS(1)
- 如果使用Ext.form.ComboBox 作为editor,并设置了store,在选择后,在表格单元中显示的是store中的displayfield 而不是valuefield
- 浅述SQL Server的聚焦强制索引查询条件和Columnstore Index
- NoSQL生态系统——类似Bigtable列存储,或者Dynamo的key存储(kv存储如BDB,结构化存储如redis,文档存储如mongoDB)
- Timeout occurred while waiting for latch: class 'COLUMNSTORE_ROWGROUP_COLLECTION'
- What the key facts to choose Row Store and Column Store
- leetcode 168. Excel Sheet Column Title 递归输出,注意倍数是26,不是27
- MariaDB ColumnStore一些限制和BUG总结 推荐
- SQL Server-聚焦强制索引查询条件和Columnstore Index(九)
- SQL Server Column Store Indeses
- SQL SERVER 2012 COLUMNSTORE INDEX - 之一
- 安装MariaDB ColumnStore
- SQL 2014新功能介绍系列8 – 可更新的列存储索引 (Updateable Column Store Indexes)