数据库作为业务的核心，在整个基础软件栈中是非常重要的一环。近几年社区也是新的方案和思想层出不穷，接下来我将总结一下近几年一些主流的开源数据库方案，其背后的设计思想以及适用场景。本人才疏学浅如有遗漏或者错误请见谅。本次分享聚焦于数据库既结构化数据存储OLTP及NoSQL领域，不会涉及OLAP、对象存储、分布式文件系统。
1、开源RDBMS与互联网的崛起
很长时间以来，关系型数据库一直是大公司的专利，市场被Oracle/DB2等企业数据库牢牢把持。但是随着互联网的崛起、开源社区的发展，上世纪九十年代MySQL1.0的发布，标志着关系型数据库的领域社区终于有可选择的方案。
MySQL
第一个介绍的单机RDBMS就是MySQL。相信大多数朋友都已经对MySQL非常熟悉，基本上MySQL的成长史就是互联网的成长史。我接触的第一个MySQL版本是MySQL4.0，到后来的MySQL5.5更是经典——基本所有的互联网公司都在使用。
MySQL也普及了「可插拔」引擎这一概念，针对不同的业务场景选用不同的存储引擎是MySQLtuning的一个重要的方式。比如对于有事务需求的场景使用InnoDB：对于并发读取的场景MyISAM可能比较合适：但是现在我推荐绝大多数情况还是使用InnoDB，毕竟5.6后已经成为了官方的默认引擎。大多数朋友都基本知道什么场景适用MySQL(几乎所有需要持久化结构化数据的场景)，我就不赘述了。
另外值得一提的是MySQL5.6中引入了多线程复制和GTID，使得故障恢复和主从的运维变得比较方便。另外，5.7(目前处于GA版本)是MySQL的一个重大更新，主要是读写性能和复制性能上有了长足的进步(在5.6版本中实现了SCHEMA级别的并行复制，不过意义不大，倒是MariaDB的多线程并行复制大放异彩，有不少人因为这个特性选择MariaDB。MySQL5.7MTS支持两种模式，一种是和5.6一样，另一种则是基于binloggroupcommit实现的多线程复制，也就是MASTER上同时提交的binlog在SLAVE端也可以同时被apply，实现并行复制)。
如果有单机数据库技术选型的朋友，基本上只需要考虑5.7或者MariaDB就好了，而且5.6、5.7由Oracle接手后，性能和稳定性上都有了明显的提升。
PostgreSQL
PostgreSQL的历史也非常悠久，其前身是UCB的Ingres，主持这个项目的MichaelStronebraker于2015年获得图灵奖。后来项目更名为Post-Ingres，项目基于BSDlicense下开源。1995年几个UCB的学生为Post-Ingres开发了SQL的接口，正式发布了PostgreSQL95，随后一步步在开源社区中成长起来。
和MySQL一样，PostgreSQL也是一个单机的关系型数据库，但是与MySQL方便用户过度扩展的SQL文法不一样的是，PostgreSQL的SQL支持非常强大，不管是内置类型、JSON支持、GIS类型以及对于复杂查询的支持，PL/SQL等都比MySQL强大得多。而且从代码质量上来看，PostgreSQL的代码质量是优于MySQL的，另外PostgreSQL的SQL优化器比MySQL强大很多，几乎所有稍微复杂的查询(当然，我没有对比MySQL5.7，也可能这个信息outdated了)PostgreSQL的表现都优于MySQL。
从近几年的趋势上来看，PostgreSQL的势头也很强劲，我认为PostgreSQL的不足之处在于没有MySQL这样强大的社区和群众基础。MySQL经过那么多年的发展，积累了很多的运维工具和最佳实践，但是PostgreSQL作为后起之秀，拥有更优秀的设计和更丰富的功能。PostgreSQL9以后的版本也足够稳定，在做新项目技术选型的时候，是一个很好的选择。另外也有很多新的数据库项目是基于PostgreSQL源码的基础上进行二次开发，比如Greenplum等。
我认为，单机数据库的时代很快就会过去。榨取摩尔定律带来的硬件红利总是有上限的，现代业务的数据规模、流量以及现代的数据科学对于数据库的要求单机已经很难满足。网卡磁盘IO和CPU总有瓶颈，线上敏感的业务系统可能还得承担SPOF(单点故障)的风险，主从复制模型在主挂掉时到底切还是不切？切了以后数据如何恢复？如果只是出现主从机器网络分区问题呢？甚至是监控环境出现网络分区问题呢？这些都是问题。
所以我的观点是，无论单机性能多棒(很多令人乍舌的评测数据都是针对特定场景的优化，另外甚至有些都是本机不走网络，而大多数情况数据库出现的第一个瓶颈其实是网卡和并发连接……)，随着互联网的蓬勃发展，移动互联网的出现使得数据库系统迎来了第一次分布式的洗礼。
2、分布式时代：NoSQL的复兴和模型简化的力量
在介绍NoSQL之前，我想提两个公司，一个是Google，另一个是Amazon。
Google
Google应该是第一个将分布式存储技术应用到大规模生产环境的公司，同时也是在分布式系统上积累最深的公司，可以说目前工业界的分布式系统的工程实践及思想大都来源于Google。比如2003年的GFS开创了分布式文件系统，2006年的Bigtable论文开创了分布式键值系统，直接催生的就是Hadoop的生态：至于2012年发表论文的Spanner和F1更是一个指明未来关系型数据库发展方向的里程碑式的项目，这个我们后续会说。
Amazon
另一个公司是Amazon。2007年发表的Dynamo的论文尝试引入了最终一致性的概念，WRN的模型及向量时钟的应用，同时将一致性HASH、merkletree等当时一些很新潮的技术整合起来，正式标志着NoSQL的诞生——对后来业界的影响也是很大，包括后来的Cassandra、RiakDB、Voldemort等数据库都是基于Dynamo的设计发展起来的。
新思潮
另外这个时期(2006年前后持续至今)一个比较重要的思潮就是数据库(持久化)和缓存开始有明确的分离——我觉得这个趋势是从memcached开始的。随着业务的并发越来越高，对于低延迟的要求也越来越高：另外一个原因是随着内存越来越便宜，基于内存的存储方案渐渐开始普及。当然内存缓存方案也经历了一个从单机到分布式的过程，但是这个过程相比关系型数据库的进化要快得多。
这是因为NoSQL的另外一个重要的标志——数据模型的变化——大多NoSQL都抛弃了关系模型，选择更简单的键值或者文档类型进行存储。数据结构和查询接口都相对简单，没有了SQL的包袱，实现的难度会降低很多。
另外NoSQL的设计几乎都选择牺牲掉复杂SQL的支持及ACID事务换取弹性扩展能力，也是从当时互联网的实际情况出发：业务模型简单、爆发性增长带来的海量并发及数据总量爆炸、历史包袱小、工程师强悍，等。其中最重要的还是业务模型相对简单。
嵌入式存储引擎
在开始介绍具体的开源的完整方案前，我想介绍一下嵌入式存储引擎们。
随着NoSQL的发展，不仅仅缓存和持久化存储开始细分，再往后的存储引擎也开始分化并走上前台。之前很难想象一个存储引擎独立于数据库直接对外提供服务，就像你不会直接拿着InnoDB或者MyISAM甚至一个B-tree出来用一样(当然，bdb这样鼎鼎大名的除外)。人们基于这些开源的存储引擎进行进一步的封装，比如加上网络协议层、加上复制机制等等，一步步构建出完整的风格各异的NoSQL产品。
这里我挑选几个比较著名存储引擎介绍一下。
TC
我最早接触的是TokyoCabinet(TC)。TC相信很多人也都听说过，TC是由日本最大的社交网站Mixi开发并开源的一个混合Key-Value存储引擎，其中包括HASHTable和B+Tree的实现。但是这个引擎的一个缺陷是随着数据量的膨胀，性能的下降会非常明显，而且现在也基本不怎么维护了，所以入坑请慎重。于TC配合使用的TokyoTyrant(TT)是一个网络库，为TC提供网络的接口使其变成一个数据库服务，TT+TC应该是比较早的NoSQL的一个尝试。
LevelDB
在2011年，Google开源了Bigtable的底层存储擎：LevelDB。LevelDB是一个使用C++开发的嵌入式的Key-Value存储引擎，数据结构采用了LSM-Tree，具体LSM-Tree的算法分析可以很容易在网上搜索到，我就不赘述了。其特点是，对于写入极其友好，LSM的设计避免了大量的随机写入：对于特定的读也能达到不错的性能(热数据在内存中)：另外LSM-Tree和B-tree一样是支持有序Scan的：而且LevelDB是出自JeffDean之手，他的事迹做分布式系统的朋友一定都知道，不知道的可以去Google搜一下。
LevelDB拥有极好的写性能，线程安全，BaTChWrite和Snapshot等特性，使其很容易的在上层构建MVCC系统或者事务模型，对于数据库来说非常重要。
另外值得一说的是，Facebook维护了一个活跃的LevelDB的分支，名为RocksDB。RocksDB在LevelDB上做了很多的改进，比如多线程Compactor、分层自定义压缩、多MemTable等。另外RocksDB对外暴露了很多Configration，可以根据不同业务的形态进行调优：同时Facebook在内部正在用RocksDB来实现一个全新的MySQL存储引擎：MyRocks，值得关注。RocksDB的社区响应速度很快也很友好，实际上PingCAP也是RocksDB的社区贡献者。我建议新的项目如果在LevelDB和RocksDB之间纠结的话，请果断选择RocksDB。
B-tree家族
当然，除了LSM-Tree外，B-tree的家族也还是有很多不错的引擎。首先大多数传统的单机数据库的存储引擎都选择了B+Tree，B+Tree对磁盘的读比较友好，第三方存储引擎比较著名的纯B+Tree实现是LMDB。首先LMDB选择在内存映像文件(mmap)实现B+Tree，同时使用了Copy-On-Write实现了MVCC实现并发事务无锁读的能力，对于高并发读的场景比较友好：同时因为使用的是mmap所以拥有跨进程读取的能力。因为我并没有在生产环境中使用过LMDB，所以并不能给出LMDB的一些缺陷，见谅。
混合引擎
还有一部分的存储引擎选择了多种引擎混合，比如最著名的应该是WiredTiger，大概是去年被MongoDB收购，现在成为了MongoDB的默认存储引擎。WiredTiger内部有LSM-Tree和B-tree两种实现提供一套接口，根据业务的情况可自由选择。另外一些特殊数据结构的存储引擎在某些特殊场合下非常抢眼，比如极高压缩比TokuDB，采用了名为分形树的数据结构，在维持一个可接受的读写压力的情况下，能拥有10倍以上的压缩率。
NoSQL
说完了几个比较著名的存储引擎，我们来讲讲比较著名的NoSQL。在我的定义中，NoSQL是NotOnlySQL的缩写，所以可能包含的范围有内存数据库，持久化数据库等。总之就是和单机的关系型数据库不一样的结构化数据存储系统。
我们先从缓存开始。
memcached
前面提到了memcached应该是第一个大规模在业界使用的缓存数据库，memcached的实现极其简单，相当于将内存用作大的HASHTable，只能在上面get/set/计数器等操作，在此之上用libevent封装了一层网络层和文本协议(也有简单的二进制协议)，虽然支持一些CAS的操作，但是总体上来看，还是非常简单的。
但是memcached的内存利用率并不太高，这个因为memcached为了避免频繁申请内存导致的内存碎片的问题，采用了自己实现的slaballocator的方式。即内存的分配都是一块一块的，最终存储在固定长度的chunk上，内存最小的分配单元是chunk，另外libevent的性能也并没有优化到极致，但是不妨碍memcached成为当时的开源缓存事实标准(另外，八卦一下，memcached的作者BradFitzpatrick，现在在Google，大家如果用Golang的话，Go的官方HTTP包就是这哥们写的，是个很高产的工程师)。
Redis
如果我没记错的话，在2009年前后，一位意大利的工程师Antirez，开源了Redis。从此彻底颠覆了缓存的市场，到现在大多数缓存的业务都已用上Redis，memcached基本退出了历史舞台。Redis最大的特点是拥有丰富的数据结构支持，不仅仅是简单的Key-Value，包括队列、集合、SortedSet等等，提供了非常丰富的表达力，而且Redis还提供sub/pub等超出数据库范畴的便捷功能，使得几乎一夜之间大家纷纷投入Redis的怀抱。
Twemproxy
但是随着Redis渐渐的普及，而且越用越狠，另外内存也越来越便宜，人们开始寻求扩展单机Redis的方案，最早的尝试是twitter开源的twemproxy，twemproxy是一个Redis中间件，基本只有最简单的数据路由功能，并没有动态的伸缩能力，但是还是受到了很多公司的追捧，因为确实没方案。随后的RedisCluster也是难产了好久，时隔好几年，中间出了7个RC版本，最后才发布：
2014年底，我们开源了Codis，解决了Redis中间件的数据弹性伸缩问题，目前广泛应用于国内各大互联网公司中，这个在网上也有很多文章介绍，我也就不展开了。所以在缓存上面，开源社区现在倒是非常统一，就是Redis极其周边的扩展方案。
MongoDB
在NoSQL的大家庭中，MongoDB其实是一个异类，大多NoSQL舍弃掉SQL是为了追求更极致的性能和可扩展能力，而MongoDB主动选择了文档作为对外的接口，非常像JSON的格式。Schema-less的特性对于很多轻量级业务和快速变更了互联网业务意义很大，而且MongoDB的易用性很好，基本做到了开箱即用，开发者不需要费心研究数据的表结构，只需要往里存就好了，这确实笼络了一大批开发者。
尽管MongoDB早期的版本各种不稳定，性能也不太好(早期的Mongo并没有存储引擎，直接使用了mmap文件)，集群模式还全是问题(比如至今还未解决的Cluster同步带宽占用过多的问题)，但是因为确实太方便了，在早期的项目快速迭代中，Mongo是一个不错的选择。
但是这也正是它的问题，我不止一次听到当项目变得庞大或者「严肃」的时候，团队最后还是回归了关系型数据库。Anyway，在2014年底MongoDB收购了WiredTiger后，在2.8版本中正式亮相，同时3.0版本后更是作为默认存储引擎提供，性能和稳定性有了非常大的提升。
但是，从另一方面讲，Schema-less到底对软件工程是好事还是坏事这个问题还是有待商榷。我个人是站在Schema这边的，不过在一些小项目或者需要快速开发的项目中使用Mongo确实能提升很多的开发效率，这是毋庸置疑的。
HBase
说到NoSQL不得不提的是HBase，HBase作为Hadoop旗下的重要产品，GoogleBigtable的正统开源实现，是不是有一种钦定的感觉：)。提到HBase就不得不提一下Bigtable，Bigtable是Google内部广泛使用的分布式数据库，接口也不是简单的Key-Value，按照论文的说法叫：multi-dimensionalsortedmap，也就是Value是按照列划分的。Bigtable构建在GFS之上，弥补了分布式文件系统对于海量、小的、结构化数据的插入、更新、随机读请求的缺陷。
HBase就是这么一个系统的实现，底层依赖HDFS。HBase本身并不实际存储数据，持久化的日志和SSTfile(HBase也是LSM-Tree的结构)直接存储在HDFS上，RegionServer(RS)维护了MemTable以提供快速的查询，写入都是写日志，后台进行Compact，避免了直接随机读写HDFS。
数据通过Region在逻辑上进行分割，负载均衡通过调节各个RegionServer负责的Region区间实现。当某Region太大时，这个Region会分裂，后续可能由不同的RS负责，但是前面提到了，HBase本身并不存储数据，这里的Region仅是逻辑上的，数据还是以文件的形式存储在HDFS上，所以HBase并不关心Replication、水平扩展和数据的分布，统统交给HDFS解决。
和Bigtable一样，HBase提供行级的一致性，严格来说在CAP理论中它是一个CP的系统，但遗憾的是并没有更进一步提供ACID的跨行事务。HBase的好处就不用说了，显而易见，通过扩展RS可以几乎线性提升系统的吞吐，及HDFS本身就具有的水平扩展能力。
但是缺点仍然是有的。
首先，Hadoop的软件栈是Java，JVM的GCTuning是一个非常烦人的事情，即使已经调得很好了，平均延迟也得几十毫秒：
另外在架构设计上，HBase本身并不存储数据，所以可能造成客户端请求的RS并不知道数据到底存在哪台HDFSDataNode上，凭空多了一次RPC：
第三，HBase和Bigtable一样，并不支持跨行事务，在Google内部不停的有团队基于Bigtable来做分布式事务的支持，比如MegaStore、Percolator。后来JeffDean有次接受采访也提到非常后悔没有在Bigtable中加入跨行事务，不过还好这个遗憾在Spanner中得到了弥补，这个一会儿说。
总体来说，HBase还是一个非常健壮且久经考验的系统，但是需要你有对于Java和Hadoop比较深入的了解后，才能玩转，这也是Hadoop生态的一个问题，易用性真是不是太好，而且社区演进速度相对缓慢，也是因为历史包袱过重的缘故吧。
Cassandra
提到Cassandra(C*)，虽然也是Dynamo的开源实现，但就没有这种钦定的感觉了。C*确实命途多舛，最早2008由Facebook开发并开源，早期的C*几乎全是bug，Facebook后来索性也不再维护转过头搞HBase去了，一个烂摊子直接丢给社区。还好DataStax把这个项目捡起来商业化，搞了两年，终于渐渐开始流行起来。
C*不能简单的归纳为读快写慢，或者读慢写快，因为采用了qourm的模型，调整复制的副本数以及读的数量，可以达到不同的效果，对于一致性不是特别高的场景，可以选择只从一个节点读取数据，达到最高的读性能。另外C*并不依赖分布式文件系统，数据直接存储在磁盘上，各个存储节点之间自己维护复制关系，减少了一层RPC调用，延迟上对比HBase还是有一定优势的。
不过即使使用qourm的模型也并不代表C*是一个强一致的系统。C*并不帮你解决冲突，即使你W(写的副本数)+R(读请求的副本数)>N(节点总数)，C*也没办法帮你决定哪些副本拥有更新的版本，因为每个数据的版本是一个NTP的时间戳或者客户端自行提供，每台机器可能都有误差，所以有可能并不准确，这也就是为什么C*是一个AP的系统。不过C*一个比较友好的地方是提供了CQL，一个简单的SQL方言，比起HBase在易用性上有明显优势。
即使作为一个AP系统，C*已经挺快了，但是人们追求更高性能的脚步还是不会停止。应该是今年年初，ScyllaDB的发布就是典型的证明，ScyllaDB是一个兼容C*的NoSQL数据库，不一样的是，ScyllaDB完全用C++开发，同时使用了类似DPDK这样的黑科技，具体我就不展开了，有兴趣可以到Scylla的官网去看看。BTW，国内的蘑菇街第一时间使用了ScyllaDB，同时在Scylla的官网上share了他们的方案，性能还是很不错的。
3、中间件与分库分表
NoSQL就先介绍到这里，接下来我想说的是一些在基于单机关系型数据库之上的中间件和分库分表方案。
在这方面确实历史悠久，而且也是没有办法的选择，关系型数据库不比Redis，并不是简单的写一个类似Twemproxy的中间件就搞定了。数据库的中间件需要考虑很多，比如解析SQL，解析出shardingkey，然后根据shardingkey分发请求，再合并：另外数据库有事务，在中间件这层还需要维护Session及事务状态，而且大多数方案并没有办法支持跨shard的事务。
这就不可避免的导致了业务使用起来会比较麻烦，需要重写代码，而且会增加逻辑的复杂度，更别提动态的扩容缩容和自动的故障恢复了。在集群规模越来越大的情况下，运维和DDL的复杂度是指数级上升的。
中间件项目盘点
数据库中间件最早的项目大概是MySQLProxy，用于实现读写分离。后来国人在这个领域有过很多的著名的开源项目，比如阿里的Cobar和DDL(并未完全开源：后来社区基于Cobar改进的MyCAT、360开源的Atlas等，都属于这一类中间件产品：
在中间件这个方案上基本走到头的开源项目应该是YoutubeVitesse。Vitess基本上是一个集大成的中间件产品，内置了热数据缓存、水平动态分片、读写分离等等，但是代价也是整个项目非常复杂，另外文档也不太好。大概1年多以前，我们尝试搭建起完整的Vitess集群，但是并未成功，可见其复杂度。
另外一个值得一提的是Postgres-XC这个项目，Postgres-XC的野心还是很大的，整体的架构有点像早期版本的OceanBase，由一个中央节点来处理协调分布式事务/解决冲突，数据分散在各个存储节点上，应该是目前PostgreSQL社区最好的分布式扩展方案。其他的就不提了。
4、未来在哪里？NewSQL？
一句话，NewSQL是未来。
2012年Google在OSDI上发表了Spanner的论文，2013年在SIGMOD发表了F1的论文。这两篇论文让业界第一次看到了关系模型和NoSQL的扩展性在超庞大集群规模上融合的可能性。在此之前，大家普遍认为这个是不可能的，即使是Google也经历了Megastore这样系统的失败。
Spanner综述
但是Spanner的创新之处在于通过硬件(GPS时钟+原子钟)来解决时钟同步的问题。在分布式系统里，时钟是最让人头痛的问题，刚才提到了C*为什么不是一个强C的系统，正是因为时钟的问题。而Spanner的厉害之处在于即使两个数据中心隔得非常远，不需要有通信(因为通信的代价太大，最快也就是光速)就能保证TrueTimeAPI的时钟误差在一个很小的范围内(10ms)。另外Spanner沿用了很多Bigtable的设计，比如Tablet/Directory等，同时在Replica这层使用Paxos复制，并未完全依赖底层的分布式文件系统。但是Spanner的设计底层仍然沿用了Colossus，不过论文里也说是可以未来改进的点。
Google的内部的数据库存储业务，大多是3～5副本，重要一点的7副本，遍布全球各大洲的数据中心，由于普遍使用了Paxos，延迟是可以缩短到一个可以接受的范围(Google的风格一向是追求吞吐的水平扩展而不是低延迟，从悲观锁的选择也能看得出来，因为跨数据中心复制是必选的，延迟不可能低，对于低延迟的场景，业务层自己解决或者依赖缓存)。
另外由Paxos带来的Auto-Failover能力，更是能让整个集群即使数据中心瘫痪，业务层都是透明无感知的。另外F1构建在Spanner之上，对外提供了更丰富的SQL语法支持，F1更像一个分布式MPPSQL——F1本身并不存储数据，而是将客户端的SQL翻译成类似MapReduce的任务，调用Spanner来完成请求。
其实除了TrueTime整个系统并没有用什么全新的算法，而是近些年分布式系统的技术Spanner和F1的出现标志着第一个NewSQL在生产环境中提供服务。
有以下几个重点：
1.完整的SQL支持，ACID事务：
2.弹性伸缩能力：
3.自动的故障转移和故障恢复，多机房异地灾备。
NewSQL特性确实非常诱人，在Google内部，大量的业务已经从原来的Bigtable切换到Spanner之上。我相信未来几年，整个业界的趋势也是如此，就像当年的Hadoop一样，Google的基础软件的技术趋势是走在社区前面的。
社区反应
Spanner的论文发表之后，当然也有社区的追随者开始实现(比如我们：D)，第一个团队是在纽约的CockrOAchDB。CockroachDB的团队的组成还是非常豪华的，早期团队由是Google的分布式文件系统Colossus团队的成员组成：技术上来说，Cockroach的设计和Spanner很像，不一样的地方是没有选择TrueTime而是HLC(Hybridlogicalclock)，也就是NTP+逻辑时钟来代替TrueTime时间戳：另外Cockroach选用了Raft代替Paxos实现复制和自动容灾，底层存储依赖RocksDB实现，整个项目使用Go语言开发，对外接口选用PostgreSQL的SQL子集。
CockroachDB
CockroachDB的技术选型比较激进，比如依赖了HLC来做事务的时间戳。但是在Spanner的事务模型的CommitWait阶段等待时间的选择，CockroachDB并没有办法做到10ms内的延迟：CockroachDB的CommitWait需要用户自己指定，但是谁能拍胸脯说NTP的时钟误差在多少毫秒内？我个人认为在处理跨洲际机房时钟同步的问题上，基本只有硬件时钟一种办法。HLC是没办法解决的。
另外Cockroach采用了gossip来同步节点信息，当集群变得比较大的时候，gossip心跳会是一个非常大的开销。当然CockroachDB的这些技术选择带来的优势就是非常好的易用性，所有逻辑都在一个binary中，开箱即用，这个是非常大的优点。
TiDB
目前从全球范围来看，另一个在朝着Spanner/F1的开源实现这个目标上走的产品是TiDB(终于谈到我们的产品了)。TiDB本质上是一个更加正统的Spanner和F1实现，并不像CockroachDB那样选择将SQL和Key-Value融合，而是像Spanner和F1一样选择分离，这样分层的思想也是贯穿整个TiDB项目始终的。对于测试、滚动升级以及各层的复杂度控制会比较有优势：另外TiDB选择了MySQL协议和语法的兼容，MySQL社区的ORM框架，运维工具，直接可以应用在TiDB上。
和Spanner一样，TiDB是一个无状态的MPPSQLLayer，整个系统的底层是依赖TiKey-Value来提供分布式存储和分布式事务的支持。TiKey-Value的分布式事务模型采用的是GooglePercolator的模型，但是在此之上做了很多优化。Percolator的优点是去中心化程度非常高，整个集群不需要一个独立的事务管理模块，事务提交状态这些信息其实是均匀分散在系统的各个Key的meta中，整个模型唯一依赖的是一个授时服务器。
在我们的系统上，极限情况这个授时服务器每秒能分配400w以上个单调递增的时间戳，大多数情况基本够用了(毕竟有Google量级的场景并不多见)：同时在TiKey-Value中，这个授时服务本身是高可用的，也不存在单点故障的问题。
TiKey-Value和CockroachDB一样也是选择了Raft作为整个数据库的基础：不一样的是，TiKey-Value整体采用Rust语言开发，作为一个没有GC和Runtime的语言，在性能上可以挖掘的潜力会更大。
关于未来
我觉得未来的数据库会有几个趋势，也是TiDB项目追求的目标：
数据库会随着业务云化，未来一切的业务都会跑在云端，不管是私有云或者公有云，运维团队接触的可能再也不是真实的物理机，而是一个个隔离的容器或者「计算资源」。这对数据库也是一个挑战，因为数据库天生就是有状态的，数据总是要存储在物理的磁盘上，而数据的移动的代价比移动容器的代价可能大很多。
多租户技术会成为标配，一个大数据库承载一切的业务，数据在底层打通，上层通过权限，容器等技术进行隔离：但是数据的打通和扩展会变得异常简单，结合第一点提到的云化，业务层可以再也不用关心物理机的容量和拓扑，只需要认为底层是一个无穷大的数据库平台即可，不用再担心单机容量和负载均衡等问题。
OLAP和OLTP会进一步细分，底层存储也许会共享一套，但是SQL优化器这层的实现一定是千差万别的。对于用户而言，如果能使用同一套标准的语法和规则来进行数据的读写和分析，会有更好的体验。
在未来分布式数据库系统上，主从日志同步这样落后的备份方式会被Multi-Paxos/Raft这样更强的分布式一致性算法替代，人工的数据库运维在管理大规模数据库集群时是不可能的，所有的故障恢复和高可用都会是高度自动化的。
5、答疑环节
问：HANA等内存数据库怎么保证系统掉电而处理结果不丢？传统数据库也用缓存，可是HANA用的内存太大。
黄东旭：没用过HANA，但是直观感觉这类内存数据库的可用性可能通过集中方式保证：
写入会先写WAL：
写入可能会通过主从或者paxos之类的算法做同步和冗余复制还有HANA本身就是内存数据库，会尽可能把数据放到内存里，这样查询才能快呀。
问：对于传统创业公司如何弥补NoSQL的技术短板？快速的引入NoSQL提高效率？
黄东旭：选用NoSQL主要注意两点：
做好业务的调研，估计并发量，数据量，数据的结构看看适不适合：
对各种NoSQL擅长和不擅长的地方都尽可能了解。
不要盲目相信关系型数据库，也不要盲目相信NoSQL，没有银弹的。
问：有多个条件，比如年龄20到30或年龄35到40，并且加入购物车或下单，这种数据怎么存储？
黄东旭：购物车这种场景是典型的OLTP的场景，可以选用关系型数据库MySQLPostgreSQL什么的，如果对于扩展性的数据跨机房有要求的话，可以调研一下NewSQL，比如我们的TiDB。
问：多纬度查询应该选择哪种数据库？
黄东旭：多纬度查询可以说是一个OLAP的场景，可以选用Greenplum或者Vertica之类的分析性数据库。
问：想知道为什么需要这些开源的数据库，既然已经有了MySQL、DB2、Oracle这些成熟的数据库，成本考虑，还是传统数据库满足不了需求？
黄东旭：对，传统数据库的扩展性是有问题的，在海量并发和数据量的场景下很难支持业务。所以可以看到比较大的互联网公司基本都有自己的分布式数据库方案。
问：未来可能不再需要数据仓库吗？
黄东旭：大家可以想想数据仓库的定义，如果是还需要离线的从线上库倒腾数据到数据仓库上，这样很难做到实时查询，而且空间的利用率也低，我认为是目前并没有太好的方案的情况下的折衷……
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：一文掌握所有开源数据库的现状
相关文章
