数据库架构在美团点评的演变实践

前言

IT时代的缩影基本被CPU、操作系统、数据库这三大核心领域，支撑了半个世纪人类的商业科技文明。本文讲到美团点评数据库的演变，首先从数据库的简史讲起。把数据库划分成三个时代，分别就是关系型数据库时代，NoSQL时代，NewSQL时代。下面分别讲下每个时代数据库发展的诉求和过程。

关系型数据库时代

说到关系型数据库，就要从1970年E.F.Codd的《A Relational Modelof Data forLarge Shared Data Banks》的论文开始讲起。该论文奠定了关系模型的理论基础，Codd的同事DonChamberlin对Codd的论文和关系运算进行转换，发明了简单易用的SQL语言，并且在之后的发展中成为所有关系型数据库的标准。这种高级的非过程化编程接口语言，成为了距离数据库最近的语言，将计算机科学和人类理解认知完美的衔接在了一起。

1970 年关系模型建立之后，IBM公司在SanJose实验室增加了更多的研究人员研究这个项目，这个项目就是著名的System R。该项目结束于1979年，完成了第一个实现SQL的DBMS。

1973年加州大学伯克利分校的Michael Stonebraker
和EugeneWong利用System R已发布的信息开始开发自己的关系数据库系统Ingres。LarryElision和他的同事看到商机，开发出第一个商用大型关系型数据库Oracle（之后将近半个世纪Oracle一直都是关系型数据库的领头羊），之后IBM也推出了DB2、MichaelStonebraker开发了Postgres并放在BSD版权下，后来演变成了Postgres SQL，87年微软和Sybase合作，开发出了MS SQL和Sybase。

到了2000年后，另一款明星产品MySQL由于其自由开放、轻量，被google等互联网公司普遍使用，并逐步进入大家的视野从而火爆起来。



NoSQL异军突起

首先NoSQL是一个比较模糊的概念，而且在不同阶段这解读出来的含义也不一样，网上有一个比较有意思另类解读（下图），不同的解读本身也释放出NoSQL这个技术的螺旋、摇摆的发展态势。在本文里，我们把NoSQL泛指非关系型数据库。

关系数据库很强大，但是它并不能很好的适用所有的应用场景。尤其以社交、搜索为代表的互联网业务产生海量数据时，关系型数据库在扩展性（需要负责技术sharding来实现）、高昂的表变更成本、高并发容量、写入延迟等方面都面对很多挑战。

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。同样NoSQL在海量数据读写性能方面，也优势明显，同时提供了灵活的数据模型。

NoSQL的产品很多，但引领这顾潮流的主要有Amazon的DynamoDB、google的bigtable，后来Facebook开源了Cassandra，以及基于bigtable设计的hadoop Hbase，bigtabl开源实现的Hypertable，以及支持文档事务Mongodb、普遍用于缓存的redis及redis cluster。值得一提的是美团点评内部有一个很优秀存储系统Cellar，兼内存与持久化的分布。

在NoSQL盛行之初，人们似乎能看到了NoSQL取代关系型数据库的时代，可事与愿违，使用NoSQL需要从应用业务去把关系数据库重新实现，而且数据库的功能被向存储方向进一步弱化。这里面的一个代表事件就是DIGG采用Cassanrda遭遇失败，大家重新理解了关系模型的SQL是最方便和数据交互的语言，所以开始妥协，于是大部分NoSQL开始尝试支持关系数据库(这时候主流变成了Not only SQL)。可是就又回到了如果让关系数据库具有扩展性、性能这条老路上来，于是忍了很久的另外一批人就重新站了出来，出现了”No，SQL!“的口号，于是NewSQL又粉墨登场。



NewSQL粉墨登场

NewSQL没有标准定义，作者认为是要满足以下几点：1，可扩展性、高性能；2，具有NoSQL对海量数据的存储能力；3，支持关系型数据库关键特性，比如原子性、一致性、隔离性和持久性等。

分布式关系数据库并不是新的名词，未来某一个阶段分布式数据库也一定会占据数据库的主导位置，这个相信大家不会有太大争议，但问题在于它的实现难度，如果在CAP之间进行平衡和弥补，目前这方面的理论、实践应该说都还在初级阶段。

至于NewSQL的起源，我觉得要从Google说起。2011 年，Google 发表了 Megastore 的论文，Megastore是谷歌一个内部的存储系统，它的底层数据存储依赖Bigtable（基于NoSQL实现），但它实现了类似关系型的数据库模型，不同数据中心之间、分片（Entity Group）之间使用Paxos协议复制，跨分片的事务采用两阶段提交。这种支持事务的存储系统在google内部很受欢迎，但Megastore也有一些噪点，比如延迟比较大，于是google在新的存储文件系统Colossus和新的硬件基础上研发了更大的分布式系统Spanner，它具有可扩展、多版本、全球分布式复制。与Spanner配套，google研发分布式SQL引擎F1，实现F1+Spanner的分布式组合。在Spanner的论文引导下，社区也有开源的实现，其中比较有代表的是CockroachDB和国内人气产品TIDB+TIKV。

分布式的前提需要将存储进行分片，也很自然的引导了计算与存储的分离，在加上GBU的发展，使大家可以将更多的计算下推到存储，并且随着云计算的发展支持，一些大云厂商开始利用自身的硬件优势，开始量身设计新一代云数据库，引导这种潮流的是AWS的Aurora，Aurora使用一个共享存储系统来实现数据库的一致性，依照log is database的理念，最大化的降低了应用的延迟。Aurora后面会单独介绍，和这个比较类似的还有阿里最新公布的polardb，据说华为也在做同样的事情。



美团数据库架构演变
MySQL架构演变

美团的数据库架构是一个比较典型的MySQL+NoSQL演变之路， 最初是简单的M-S架构，读写都在主库上，也是最简单易用的阶段。
 


后来开始按照重要程度、业务归属等维度开始DB拆分，同时进行硬件的升级，主要是SAS->SSD，当然数据库引入了cache，主要是redis和memcache。



我们会对主要的数据库根据真实流量进行压测，来确定拆分的容量尺度。下面用一个案例来说明：左纵坐标是QPS（对应蓝线），表示吞吐量情况；右纵坐标是99%（可配置）的响应时间（对应红线），表示响应时间；横坐标是当前流量的放大倍数，横坐标浅蓝色代表30ms之内的空间（30ms是业务可接受最大的DB响应时间）。通过这个容量图表，我们可以比较清晰的知道数据库当前读流量最大可支持的倍数。



然后开始解决读写分离的问题，最早在引入proxy方案前，我们也短暂使用两个DNS进行分离。



在后来就是分库分表，当年还觉得Sharding是个挺牛的东西，现在看来全是成本和眼泪。



Sharding后，数据的分发和汇总成了问题，当年的解决方案比较现实，是在APP和DB直接加上一层，争论在于这一层更贴近谁？下图是当年做的一些比较。



从DB对应用透明的角度来看，我个人更推荐proxy方案。不过当年在美团内部，两个方案都存在，一段时间内主流的方案还是proxy，后来因为网络单点及链路过多的问题又转向JDBC层。



其实不管是proxy还是JDBC层，成本没有多少变，痛点解决了一部分，也同时引入了一些问题：



举两个例子，比如一个全局ID问题，这个方案在公司内部也经过多次演义，尝试过MySQL自增主键、引入redis序列等，各有各的问题；还有业务多维度、AP业务数据同步，美团内部也是重复做过一些轮子，比如canal、databus、队列方式、pumer等。
美团的NoSQL
美团目前使用比较广泛的是基于tair基础上研发的Cellar，这里我们主要阐述一些基本特性。分布式KV存储系统，底层支持Leverldb、rockdb、mdb、rdb等引擎，各节点直接通过raft进行复制；支持异地容灾、无损数据迁移，元信息存在单独节点，并且通过添加observer的形式实现路由查询能力扩展、客户与中间节点分离。



MySQL与Cellar的主要对比：



最后抛一个问题，如果说MySQL+Cellar≈
美团主流数据库架构，那么头脑风暴一下，MySQL（server层）+Cellar （存储层）≈ ？欢迎大家积极讨论～

欢迎大家加入云计算交流QQ群，群号：469243579 ～