Bigtable不是column store(列存储) ！

最新推荐文章于 2024-05-07 15:20:47 发布

iteye_11067

最新推荐文章于 2024-05-07 15:20:47 发布

阅读量140

点赞数

文章标签：大数据数据库数据结构与算法

本文探讨了列存储(columnstore)的基本概念及其相对于行存储的优势，特别是在OLAP操作中的表现。同时，文章对比分析了Bigtable/HBase等系统，并解释为何它们不能简单地归类为列存储。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

题外话，今天无意中查看以前写的blog，发现好多blog的呈现只有一堆乱码，正文不见了。可是点击编辑正文又出现了... 我这算是给优快云报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。不过，基于我之前的实验和经验，这个系统也不是太稳定。