对数据库架构的再思考

标签: 随笔文章 | 发表时间:2013-04-30 21:57 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
前面在谈PaaS的时候曾经谈到过共享数据库,私有数据库的问题,在这里再谈谈在多业务系统建设过程中的数据架构模式问题。首先来看下传统的数据交换解决方案如下图:



业务场景为单独构建的四个业务系统,在四个业务系统中SID数据为需要跨四个应用交互和共享的数据。传统的做法则是对四个应用存在的SID库数据进行数据集成和交换,则后续的每一个业务系统中都有全部的共享基础数据,任何一个应用的SID库数据需要通过数据交换和集成同步四份。在这种情况下:

优点:应用开发建设简单,完全本地数据操作和事务处理
缺点:数据同步多份,数据同步的时效性问题,数据本身在同步过程中产生的不一致问题


为了解决共享数据同步多份引起的数据不一致问题,我们考虑对共享数据进行集中处理,建立统一的SID共享数据库,即所有的共享数据只保留一份数据拷贝。共享数据以数据服务的方式向外提供能力,如下图:



在这种情况下,四个应用的所有SID共享数据全部集中到SID库,对于每个应用中只保留ADB私有数据,即所有的共享数据只保留一份数据拷贝,SID库以共享数据服务的方式向外提供服务。

优点:只保留一份数据拷贝,不会有任何数据不一致和数据实时性问题,提供共享数据服务能力可复用
缺点:单个应用开发的复杂度增加,很多问题转换为跨库问题,分布式事务也导致潜在的数据不一致。


我的理解对于第二种模式始终是一种理想情况下的考虑,由于为了保证共享数据的全集中,而带来的大量的跨库分布式事务问题,往往得不偿失。在以上两点思考的基础上考虑一种可折衷的模式,即如下图:



在该模式下,数据的共享数据保留两份,即首先是原有的数据产生源头应用中保留一份,同时在SID共享数据库保留一份。原有应用中的数据负责数据的源头管理和维护,SID库仅仅负责数据读操作,将数据查询和读的能力形成可共享的数据服务朝外部其它应用提供。其它应用访问非本应用产生的共享数据时候,都需要通过数据服务查询SID库的数据。在这种模式下:

优点:应用开发建设简单,完全本地数据操作和事务处理。对于读操作存在少量的跨库操作,但是不存在分布式事务处理和一致性保持的问题。
缺点:数据有两份考虑,可能存在数据的不一致性,但是当前技术可以较好的解决掉。


在这种模式下可以看到和传统的MySQL数据库的读写分离思路相当类似。SID库仅仅是一个读库,供所有的应用读,同时为了包括性能读库本身可以扩展为多个读库集群。进行CUD操作的写库还是在原有应用中,可以大量的避免分布式事务的处理问题。

在这种模式下的实时性和一致性也较容易保持,例如对于本地应用库中的SID数据可以采用类似读写分离集群中的BinLog日志复制技术,这样可以基本保证SID库的准实时性。虽然不是完全高度实时和一致,但是由于是数据读,本身问题不大。

在这个问题考虑清楚后,接下来才是考虑对于单个应用本身的存储和并发量是否单个数据库节点能够支撑的问题,对于这点的考虑又存在单个应用本身的分布式数据库集群架构的考虑。这个在下篇进行思考。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [数据库 架构 思考] 推荐:

对数据库架构的再思考

- - 人月神话的BLOG
前面在谈PaaS的时候曾经谈到过共享数据库,私有数据库的问题,在这里再谈谈在多业务系统建设过程中的数据架构模式问题. 首先来看下传统的数据交换解决方案如下图:. 业务场景为单独构建的四个业务系统,在四个业务系统中SID数据为需要跨四个应用交互和共享的数据. 传统的做法则是对四个应用存在的SID库数据进行数据集成和交换,则后续的每一个业务系统中都有全部的共享基础数据,任何一个应用的SID库数据需要通过数据交换和集成同步四份.

Memcache架构新思考

- - ITeye博客
2011年初Marc Kwiatkowski通过[email protected]介绍了Facebook的Memcache架构,现在重新审视这个架构,仍有很多方面在业界保持先进性. 作为weibo内部数据处理量最大,对数据延迟最敏感的部门,基于本厂2年多来对mc的使用心得,我在本文总结对MC架构的一些新思考.

正祥的淘宝海量数据库思考分享

- alex zhao - 淘宝核心系统团队博客
正祥(阳振坤老师)最近在个人新浪博客上发表了一系列针对淘宝分布式数据服务系统思考性文章,特此分享. 淘宝海量数据库之一:来自业务的挑战. 淘宝海量数据库之二:一致性选择. 淘宝海量数据库之三:事务的ACID. 淘宝海量数据库之四:系统架构与跨表事务. 淘宝海量数据库之五:数据结构.

数据库设计之外键的思考

- - CSDN博客数据库推荐文章
    关于是否使用外键在业界也没有统一的标准,大家争论的焦点是数据一致性和性能上.     支持使用外键方,强调如果不使用外键,数据一致性无法保证,性能消耗可以忽略.     反对使用外键方,数据一致性可以通过程序保证,性能有大问题,数据维护很麻烦,如果是大系统,整个外键的关系就像编制的一张大网.

对组件化架构的再思考

- - 人月神话的BLOG
原来架构设计比较多关注的是横向的分层,即数据层,逻辑层和UI层. 而组件化架构必须同时关注纵向的隔离和解耦. 在分层和分模块后,每一个业务组件由三层各自存在的部署包组成,包本身是一个包含了技术组件和服务组件的一个结合体. 由数据层,逻辑层,界面层三层的三个业务包可以构成一个完整的具备独立功能的业务组件.

优良的数据库架构--让网站飞起来

- We_Get - 博客园-首页原创精华区
   很少谈架构方面的事情,主要是因为这确实是个对知识面和知识深度要求很高的领域,无论是开发语言的选择、代码的架构,服务器的搭配、网络的架构、数据库的架构还是第三方软件的选用等,每一方面都是个很大的方向,每个方向都值得一个人去研究一辈子;每每看到某某网站的首席架构师之类的人(不过很多是海绵派),总觉得那就是乐于做技术的人的终极目标,总是有种崇拜感.

MySQL云数据库服务的架构探索

- - 博客园_知识库
  MySQL作为一种低成本、高性能、可靠性良好而且开源的数据库产品,在互联网企业中应用非常广泛. 例如,淘宝网就有数千台MySQL服务器. 虽然近两年来NoSQL的发展很快,新产品层出不穷,但在业务中应用NoSQL对开发者来说要求比较高,而MySQL拥有成熟的中间件、运维工具, 已经形成一个良性的生态圈.

[转][转]列式数据库之infobright以及架构

- - heiyeluren的blog(黑夜路人的开源世界)
文章来源:http://www.cnblogs.com/inmanhust/tag/infobright/. 列式数据库之infobright.   年前听过Sybase中国区副总裁的关于列式数据库的讲座之后就一直被列式数据库强大的性能吸引. 最近邂逅了infobright,列式数据库的学习展开了.

分布式MySQL数据库TDSQL架构分析(转)

- - 数据库 - ITeye博客
腾讯计费平台部为了解决基于内存的NoSQL解决方案HOLD平台在应对多种业务接入时的不足,结合团队在MySQL领域多年应用和优化经验,最终在MySQL存储引擎基础上,打造一套分布式SQL系统TDSQL. 腾讯计费平台部托管着公司90%以上的虚拟账户,如QB、Q点、包月服务、游戏的二级账户等,为了保证能顺畅支撑公司各大业务的实时在线交易,并且在各种灾难场景下数据是一致并且可用的,对系统的可用性、一致性切换要求非常高,因此计费团队历来都非常重视高一致性存储系统的建设.

美团数据库高可用架构的演进与设想 -

- -
本文介绍最近几年美团MySQL数据库高可用架构的演进过程,以及我们在开源技术基础上做的一些创新. 同时,也和业界其它方案进行综合对比,了解业界在高可用方面的进展,和未来我们的一些规划和展望. 在2015年之前,美团(点评侧)长期使用MMM(Master-Master replication manager for MySQL)做数据库高可用,积累了比较多的经验,也踩了不少坑,可以说MMM在公司数据库高速发展过程中起到了很大的作用.