五分钟DBA：浅谈伪分布式数据库架构

五分钟DBA：浅谈伪分布式数据库架构

【IT168 技术】12月25日消息，2010互联网行业技术研讨峰会今日在上海华东理工大学召开。本次峰会以“互联网行业应用最佳实践”为主题，定位于互联网架构设计、应用开发、应用运维管理，同时，峰会邀请了来自盛大、阿里巴巴、五分钟等互联网企业的多位嘉宾演讲，他们将同大家一起探讨数据库技术在互联网领域的深入应用。

以下是上海五分钟网络科技有限公司金官丁主题为“浅谈伪分布式数据库架构”的演讲全文：

接下来我们马上会看一下分布式数据库一个最独特的架构图。但是看之前，这四个是核心，是四个模块的核心，我们把四个名词解释一下，什么叫局部数据库管理系统，什么是GDBMS，什么是全局数据字典，什么是通信管理。什么是局部数据库管理系统，建立和管理局部数据库，提供场地自治能力，执行局部应用及全部查询的子查询。GDBMS就是提供分布透明性，协调全局事务执行，协调各局部DBMS完成全局应用，保证数据库全局一致性。全局数据字典就是存放全局概念模式、分片模式、分布模式的定义以及各模式之间影象的定义，存放有关用户存取权限的定义，保证全局用户的权限和数据库的安全。通信管理就是实现分布式数据库各场地之间消息和数据传递。

我们看一下结构，这是腹部市数据库最复杂的结构，每个场地，每个节点都有一个全局数据字典和全局数据库管理系统，但真实的产品当中都不会使用这种方式，为什么成本太高了，最关键的还不是成本，最关键的是开放难度。实现难度，维护那块东西。特别是数据的一致性，如何管理。但是有一个好处，任何一个全局管理系统数据库死了，没关系，任何场地都是一样的，相当于都是三头六臂，砍掉一双手还有一双手。

刚刚说的数据结构等等的东西定义的。然后说的伪分布式，就是不是分布式，只是一个名字，千万不要像迷恋NoSQL一样迷恋伪分布式这个名字，都是一样的。伪分布式我简单的理解就是多个集中式数据库加上数据库自身复制，再加上开发的软件加上其他的东西，什么是其他的东西，就是可有可无的，但是有会带来一些好处。

分布式数据库的优点蛮多的，罗列一下四点。一个是数据独立性，就包括逻辑独立性跟武力独立性，这两个东西是集中数据库里面才有的，分布式独立性是跟集中数据库没有的。如果我分布在不同的结点，如果一个分片存的东西越多，存复制的份数越多，你会增加什么后果，跟带来什么优点?第一个数据一次性控制就难度加大了，第二点数据的存储容量这块又会上去了，好处是什么呢?我查询的时候特别快。理由很简单，本来这个可以在A上，现在查B，我不用从A到B上面，B上面可以直接读到这份数据，这就是好处，所以有好处也有坏处。然后全局的一致性跟可串行性和可恢复性。

另外是商业产品的费用比较高，为什么呢?如果后面是柜子存储的话，价格还会是另外一个价格卖给你。然后硬件设备也不用好一点的，一般是存储，也会有廉价IBM的。查询性为什么会下降呢?如果我数据存在不同的节点，我查到C节点，我要在B节点，刚好没有这个数据怎么办呢?是不是要拉过来，所以这样的性能有所下降。

另外一个如果我们不买商业产品，我们自己开发，这个难度太大了，技术复杂度很高。第二个你没办法那么多措施，这是一个很浩大的工程。还是有很多等待它需要完善的地方。而且大数据量的情况下并不适合用，是适合用一些并不是很大量的数据，是高可用性，不是超大规模的数据。而且它的结点是有限制的。

伪分布式数据库我接下来就吹一下伪分布式数据库的优点，缺点有会提一下。伪分布式的优点就是提供了内饰分布式数据库的数据库透明性。解决集中式数据库的扩展局限性，也就是说垂直扩展的情况下，通过这个规模提出他的能力，达不到这个应用的情况下，形成一个局限性了。还有就是能够提高数据的性能，因为我把很多数据拆到很多不同的数据上面了，把数据都拆散了，我现在PC机又不错了，可用性又得到保障。我可以做一个自动的切换，可靠性也有了，这个可用性跟可靠性是不太一样的意思。可靠性是那个数据来的，可用性是没有节点那一块的，计算方法也不一样的。

实现技术也不难，有很多思路都有现成的，开发成本也不高。而且我拆分了数据库之后，对这个数据库的维护成本还是可控的。可以用一些自动化的东西，使成本控制在更低的一个角度。缺点也是有的，第一个，不支持分布式事务，那这样就没办法了。所以只能牺牲一些一致性。还有就是通过一些设计，一些场景，有些场景不需要这么高数据的一致性。还有就是数据拆分之后出现一些数据合并的难度也很简单。像ICS网站，我跟好友的关系。还有就是查询，我的分布在不同的结点上，我就改写成多条，发给多个节定上执行掉，把这个结果反回来之后再合并，再反馈应用。这样的话数据合并这块也增加了难度，有些应用要通过技巧弥补这个缺点。

这是罗列了一下伪分布式数据库的运用场景，我特别推荐前四个，第一种类型电子商务平台，还有SNS的平台，还有IM即时通信这块，还有电子邮箱，日志跟SNS游戏，这个东西有点一般是写为主，其实IM也是写为主，但还是不一样。另外还有一个查询量比较少。游戏行业还有一个特点就是来的也快，去的也可能比较快，来的时候可能跟猛兽一样，一天加了几十万用户不知道怎么加的。我就担心这个就有点麻烦了，而且用户数不是我可控的，没办法。电子商务平台也一样，B2C还稍微好一点，如果是B2C电子商务平台的话就麻烦了。像淘宝的收藏家，这些东西不要求那么多，然后又特别大，这个时候就可以用到伪分布式存储。像阿里巴巴产品的信息，我根据不想那么多，但明天早上就会更新，游戏行业叫外挂。这个时候要把这个压力分散，这个东西就惯用了。

什么场景下比较适合呢?我大致准备了三点，一个是大数据容量。什么意思?就是几百个G。至少上百个G才可以考虑是一个大容量。这时候会导致它的垂直升级扩展寿险，这种情况后面是一个浅，还有一种高并发型事务，就是这个事务时间性很高，但又是可以拆散到各个数据库完成的事务，比如我修改我个人的信息就可以拆散做。还有数据的中心远远大于读。SNS游戏我有一个结果，读写的比例是7：1到8：1的东西。当然日志是不算。

数据更新量很大的情况下可以考虑。伪分布式数据库的架构罗列在这两种东西，可能大家都会用到的一些模块，一个是前端通信模块，跟伪分布式的中间件通过通过什么完成?像SNS游戏的话，还有统计领域，我建议大家要JSON。JSON也有它的优点，我可以让前面的人关注它业务怎么开发，不关注后面是怎么写的，没关系，我不需要关心。后端一般是采用MySQL自己的通信，当然也有其他的。当然我推荐大家可以考虑MySQL的，当然看什么开发语言。通用也有通用的好处。

命令行管理接口，就是我可以把我的盘切换掉另外一个机器，命令就会看他看的是不是主机，如果是就会换掉另外一个去，然后我做完了以后就告诉他我已经好了，其实不用告诉他，卸载里面他自己会去检测，但你也可以再发一条命令。

我这里写的是两个机房，成为服务的公司没有电器没有概念就是一个网络的机房，只是一个北方一个南方，目前北方是先读分离再读写，同时两边进行，我这边可能超前了一点。中间就有很多好处，它有两根光的，每根都是1个G的，如果用1G的带宽把用户的访问请求发过来肯定核算。如果我把这些数据同步的通过这1G的光发过去就可行了。因为上市公司很多时候要异地机房，没有的话就会限制。这个模式就是中间件前面就是应用服务起，最下面是一个数据库继承的模式，我们每一组数据库都是双组复制，而且现在5.5可以异步也可以实时同步了。

我跟大家解释一下，怎样走过去，其实队列发过数据过去，比如我得到一个请求，除了本机的机房数据，同时发到我的一个队列，告诉队列你再把这个数据作为一个模式发到另外一个机房去。这样的话我就可以解决两个机房同步，而且我不需要增加额外的开发。而且中间件还可以做到一些高可用性。

然后比如我叫A名字，这个名字一进来之后，这个表的名字就会出现。也有数据库的名字，比如我们会叫某某某下划线1，或者是下划线2，第二个就是数据库路由表的方式，这就有很好的方式了。我不关心是多少，我一个库、两个库就够了。当我发现今天十几万，明天又十几万我觉得这靠普了，或者我再加一个机器，就写进去了，在写的过程当中，我们一般会等到零写慢了以后，再进一步分发。新用户写慢了一百万了，我这个数据就轮流写，A写一下B写一下，这样就有很多好处，一个游戏靠普了，才可以这样用，还有一点游戏都有它的寿命周期，像尤其的话一般SNS的游戏1、2年，那我怎么把这个用户处理呢?我又不能抛弃，就合并掉。然后这两个表我就不具体揭示了，我解释一下第二张表里面UID、DDIB里面的，为什么再加个72345的东西，因为SNS我们自己没有平台的，我们都做第三方平台的。怎么办，别人传给我的ID都不会让你知道他有多少用户、多少安装量。如果他告诉你，你就可以猜出他们有多少用户。

人人一开始给你1开始，后面就15位到30位不等。***也是很长的，你都猜不出来的，怎么办呢?我管你是什么东西，我只要做MD5操作，这样就有好处了。游戏了用过这个操作的，从第三方网站跳到游戏之后就不再用第三方的ID做用户的转换、用户的交换就可以用自己的ID了。包括物品的ID等等的东西，每个用户只有这一个有这个东西，我某某开头的，也是个好处。这就是生成器的设计，就是说我要实现MySQL自身增长的效果，还有我之前的增长有全局的唯一性，还有支持数据库给予的射精拆分，就是每个数据库里面永不了，还要再分表。时候可能很大，为什么要再拆分一下呢?这个就提到5.5，我一直提到他提到变更表的时候，不要锁表，也就不要堵住中心。我们测了一下还是会，虽然有提高，改变了以前很傻的模式。现在不会复制了，现在就是增加数据。但还是会锁表。那我怎么办，总不能老停机，这样损失的是钱，老板肯定不高兴。所以这时候我们就拆分一下，拆分成小表，我执行的操作就是10秒钟之内搞定的，这多快。然后数据库表这块，一个是表名称，然后还有我分表分多少个，如果分一个就写一，我们是这么设计的，你们可以自己控制。开始值一个是布长。

我怎么办呢?我起来先读一万个ID出去，用完再启一次，这块就是好处。换了这个程序的更换。两个模式都好用，通用型，不要把以前写的不好的，都想搬上来，这个不合适，会有很多问题，所以大家一定要控制这块。不是说简单应该说简洁是最好的。存储设计的时候就要考虑这些东西，这块就要先考虑到，如果考虑这些东西开发成本就降低了。比如我做SNS游戏就有一个，再也不要关心我的数据怎么分的，怎么存的。我只关心我的业务逻辑就够了，中间一定要记住千万不要跑业务逻辑，一跑就要上当了，就永无安宁了。这个一定要抵制，一定要坚持底线。所以这个大家控制的好，对公司长远的发展有一些好处，但这些东西也给公司带来成本，但也要慎用。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。