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的这种思路除了比较复杂,总体看来还是挺完美的。