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

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/u013054973/article/details/78582284

前言

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 ~

展开阅读全文

没有更多推荐了,返回首页