从Megastore看RDBMS和NOSQL系统结合

RDBMS的优势在于功能，包括事务，强一致性，同时支持随机读和顺序扫描，索引。NOSQL系统的优势在于扩展性和性能。Google的经验告诉我们，系统设计的关键点还是在于可扩展性，依赖于底层GFS+Bigtable提供的无与伦比的可扩展性，Megastore能够在上层不断完善功能，兼具RDBMS和NOSQL系统的优点。

1, 兼顾随机读和顺序扫描。Bigtable底层的存储引擎为MemTable + SSTable构成的Merge-Dump存储引擎，SSTable设计成8K ~ 64K的块，块之间有序，随机读取型应用可以选择较小的块尺寸。和传统关系型数据库的B+树存储引擎不同的是，Merge-Dump存储引擎中的SSTable是只读的，因此可以做得简单有效。之所以能够使用Merge-Dump存储引擎是因为Bigtable把大表分成一个一个100MB~200MB的子表，存储引擎只需要处理百MB级别数据，而关系型数据库的假设是整台机器维护一颗B+树，存储引擎处理的数据规模为百GB级别。

2, 索引层面。Megastore支持两种索引，一种是local index，另外一种是global index。其中local index是单个Entity Group内部的索引，用于OLTP型的随机读取应用。global index是分布式索引，解决类似全文索引，关联推荐这样的问题。由于大多数的访问局限于单个Entity Group内部，local index的效果与RDBMS的单机索引类似，而global index与NOSQL系统的索引方法类似，Megastore的索引同时具有RDBMS和NOSQL系统索引的优点。

3, 事务。Megastore要提供的功能就是在满足事务功能的前提下不牺牲可扩展性和性能。同样是通过划分Entity Group，使得大多数的事务操作局限在Entity Group内部，通过Bigtable的单行事务保证单个Entity Group内部写redo log的原子性，在保证可扩展性和性能的前提下支持事务功能；而跨Entity Group的事务操作很不频繁，通过Two-phase commit协议支持这个功能，即使牺牲一些性能也不至于有太大影响。因此，可以认为Entity Group是RDBMS和NOSQL系统结合的神器。

4, 存储引擎。关系型数据库的存储引擎一般都是基于行的存储引擎，而NOSQL系统往往支持OLAP应用，因此，也会用到列式存储引擎。Bigtable的Locality Group让用户可以通过schema配置数据的行列存储模式。

5, Compaction。Compaction会影响读取类操作的响应时间，因为可能需要读取多个SSTable。然而，Bigtable的Compaction操作基本能够做到自适应。如果Bigtable Tablet Server接收写入的速度太快，单个子表可能同时有多个SSTable，但这样的应用往往都是MapReduce计算型应用，对延时要求不会太高；在线的OLTP应用写入一般比较慢，很少出现一个子表同时有多个SSTable的情况，往往只需要读取一个SSTable，再合并内存表MemTable中的数据即可。

6, MapReduce支持。Megastore基本保留了GFS + Bigtable的全部优点，因此，对分布式计算，比如MapReduce，支持非常友好。

7, OLAP实时计算支持。OLAP单次访问可能需要复杂的计算，比如千万条记录的实时计算，访问延迟要求相对较低，比如3~5秒。OLAP应用的磁盘读取模式一般为顺序扫描，通过分布式方法将数据分散到多机，计算时才能充分发挥多机的集群效应。OLAP实时计算相当于一次在线的MapReduce，可以增加一些协调者节点，将实时计算任务发送到协调者，协调者将任务拆分成不同子表的子任务发送到对应的多台Bigtable Tablet Server。每台Bigtable Tablet Server完成计算后，协调者进行合并汇总，如排序，分组，运算，等等。

总之，通过划分Entity Group，Megastore在单个Entity Group内部的操作能够获取RDBMS的优势，同时又不会对Bigtable原有的性能，可扩展性，支持的操作有所影响。跨Entity Group的操作通过分布式系统中的方法支持，如Two-phase commit, global index，允许牺牲部分性能或者一致性。Google的这种思路除了比较复杂，总体看来还是挺完美的。