mysql share nothing_分布式数据库的Share Nothing / Share Disk / Share Storage

在介绍share storage之前，我们首先看下share nothing和share disk。最早期的分布式数据库，整体架构上大致分为share nothing和share disk两类。oracle的RAC集群，是比较典型的share disk模式，而mysql分库分表+大部分NoSQL，是share nothing的代表。

RAC的scale out能力相当有限，要提升存储IO/Volume的能力，必须扩展底层的SAN，而SAN的扩展性比较差，成本也高。当然，RAC的最初目的也只是解决同城双活的高可用问题。

另一方面，来自互联网的海量数据，则催生各种NoSQL存储。NoSQL的设计初衷是把scale out放在第一位，放宽或者放弃事务性的约束，简化数据模型，快速解决数据量爆炸的问题。share nothing的架构自然成为NoSQL的首选。KV存储redis，column family store cassandra，document store ElasticSearch都是这样。

share nothing的架构只解决了扩展性问题，还有一些技术难点不好解决，比如数据复制和一致性。分布式系统的数据一致性是一个很大的话题，本来不打算详细讨论。总体上来说，早期的NoSQL数据复制实现的不那么严谨，一般只追求最终一致性，简单的主从复制，或者Dynamo Style的vector clock算法，让应用自己解决脑裂问题。实现了强一致性数据复制协议的也只有zookeeper或者etcd这种轻量级的分布式存储框架。

众多NoSQL中，BigTable/HBase的比较另类，竟然是share disk而不是share nothing。HBase底层的存储io，比如WAL log跟sst table文件的都是共享的一个分布式文件系统，跨节点的数据复制，通过分布式文件系统HDFS来实现。从工程实现的角度看，HBase的这种设计有不少好处：底层HDFS来做轻量级replication(不需要实现paxos或者raft)，上层只需要保证同一时间点只有一个主节点(region server)写HDFS即可，对外部来说HBase也是一个强一致的存储，支持单记录事务。

NoSQL一般不存在跨sharding的计算，计算层非常简单。而对于NewSQL，或者OLAP的数据仓库而言，要支持跨sharding的操作，要支持SQL的众多语义，计算层会复杂很多。一般来说，从计算层的角度看，必须共享一个底层的分布式存储，才可以支持跨分片的查询。这个共享的分布式存储，如果简单的采用HBase这种share disk的架构，还是存在很多明显的缺点，拿HBase来说：HDFS有自己的Block Allocation算法，HBase有自己的RegionServer Load Balance算法，那么这种两个算法可能会confict，很难保证Region Server的所有数据都在一个物理节点。

HBase的主表数据采用了LSMTree的数据结构。LSMTree经常要做compact，这就意味着compact的时候，数据还需要每个节点间复制写一遍，占用了额外的带宽。

遇到File Block跟Region Server不在一台物理机的情况，总是需要读取一些额外的垃圾数据到Region Server。

如果要支持MVCC，compact的时候又会有额外的垃圾数据占用网络IO。

这些缺点总结一下：HDFS只是一个文件系统，对于上面的计算层是无感知的，会带来很多额外的网络IO的开销。计算存储要分离，同时希望存储必须要增加一些“智能”，减少不必要的网络IO，这就引入了share storage的概念：多个无状态的计算节点，共享一个有状态的分布式存储引擎，这就是所谓的share storage。

打个比方来说：把mysql的innodb做成分布式，就是share storage

把innode的磁盘做成EBS，就是share disk

share disk是硬件加速，实现简单些，share storage实现更复杂

目前的很多NewSQL的设计都采用的share storage的架构，比如Amazon Aurora，cockroachdb/TiDB。OLAP领域，cloudera的kudu就是为SQL计算引擎Impala提供一个shared distributed storage层

以cloudera的kudu为例，kudu显然要比HBase/HDFS作为底层存储引擎要“智能”。比如一个写操作，HDFS/HBase则需要在不同节点间复制多次：一次WAL log，一次SST File，如果需要建物化视图或者二级索引，还需要写多次；而kudu这种架构，只需要一次kudu是只需要raft协议复制一次。

对于share storage vs share disk，阿里的同学也有不同的声音(主要认为网络在OLTP场景下不是瓶颈)：如何评价阿里云新一代关系型数据库 PolarDB？​www.zhihu.com

本文也只是整体架构的角度考虑，工程细节上还有很多地方并没考虑。

最后，夹杂一点私货，前段时间跟小伙伴一起写了个强一致的NoSQL轮子，项目名称elasticell：deepfabric/elasticell​github.commulti raft replication for strong consistency

key range sharding and dynamic scale out

redis compilation to app legacy

search query for full text index

Rocksdb based high performance local storage engine

pass Jepsen test

Thanks TiDB team、RocksDB team、360 nemo team、pilosa team

支持强一致的NoSQL不多。但是支持强一致存储确实能够给应用设计带来很大的简化。

对于一致性的概念，强一致性对于应用的好处，大家可以参考下谷歌的文章https://cloudplatform.googleblog.com/2018/01/why-you-should-pick-strong-consistency-whenever-possible.html​cloudplatform.googleblog.com