本文来自twt企业IT社区，作者/赵海。
一、“形散神聚”的分布式数据库
很多人搞研究习惯性先去查一查百度百科，我们也效仿：“分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有DBMS的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。”
接下来，我们再来看看行业内对它的认识，在中国软件测评中心牵头下编制的《分布式数据库发展路径研究》当中描述：“根据目前我国分布式数据库技术现状，我们认为分布式数据库是具备分布式事务处理能力、可平滑扩展、分布于计算机网络且逻辑上统一的数据库，具有分布式事务处理、平滑拓展和物理分布、逻辑统一等特征。”
总结来看，我们认为用“形散神聚”来描述分布式数据库的特征最为贴切。所谓形散是指其表现出来的计算资源、分布空间、互联拓扑等方面的形式，所谓神聚是指其最终在功能层面完成的数据处理能力。
二、分布式数据库的发展历史
我们不谈太远了，从关系数据库开始吧。20世纪70年代，IBM公司研究员E.F.Code首次提出了关系模型，开创了关系型数据库的时代。80年代开始，第一批商业化的关系型数据库开始诞生，例如Oracle、DB2、SQL Server等，90年代，芬兰的一个工程师Michael Widenius推出了至今大小厂都在使用的MySQL，同一时期PostgreSQL也诞生了。2000年后，但是随着数据量的增加，单机的数据库瓶颈已经不能满足大数据量的需求，这时各种分库分表的方案开始涌现。2006年谷歌发了三篇论文，也是被认为的大数据三驾马车“GFS、Big Table、Map-Reduce”。这三篇论文的思想诞生了Hadoop生态，也为分布式数据库做好了铺垫。2012年谷歌又发表了两篇论文，分别是Spanner和F1，为解决分布式数据库的全局事务以及数据上的拆分提供了理论基础。再往后就是国内很多互联网公司的分布式尝试和发展，阿里巴巴、腾讯、百度、字节跳动、美团、滴滴、快手、知乎、58等互联网公司都已经开始使用并且将自己的使用和研发成果形成产品推向市场，到了今天，以金融行业为先头的各行各业的跟进和普遍推广阶段。
三、分布式数据库能解决什么问题？
3.1集中式关系数据库遇到了什么困境？
（一）数据量的处理能力
其实从分布式数据库的发展历史上可以看出，是大数据催生的分布式数据库的诞生和发展。最根本的问题就是数据量的升级导致了传统关系型数据库遇到了巨大的挑战。传统关系型数据库在处理GB、TB量级的数据还是可以应付的，但是一旦到了PB及以上级别的数据处理，就算单机硬件技术如何飞跃发展，单靠单节点的处理能力是无论如何也达不到业务所需要的效率目标的。
（二）业务高并发处理能力
随着互联网的不断发展，从起初的电子商务到现在的各种互联网模式（工业互联网、互联网金融、互联网社交、...），支撑这些业务的数据库必须具备对分散业务请求的高并发处理能力，同时还得保障数据的基本安全属性。这也是坚持CAP理论当中C&A极致的关系型数据库所不具备的特性。
（三）数据及架构的扩展能力
伴随着数据量和业务访问的高并发变化趋势，必然带来的结果就是数据膨胀的速度比以往任何时代都要快，并且还无法准确预测。另外一个结果就是与之相匹配的数据处理能力的提高。但是基于传统集中式架构的数据库产品很难凭借基于点的纵向资源优势来满足现实的需求，这就要求数据库具备从架构上到数据载体上都能扩展横向资源的能力，而且是安全的、简单的、快速的。
（四）数据处理针对突发事件的适应能力
互联网发展到今天，几乎各行各业都为之进行了产业的升级换代，不仅越来越多的业务依托于互联网，而且互联网催生了很多新型的行业和经济。互联网上每天都有有太多的不确定事件发生，以其快速的网络传播效益和影响广度，很可能某些行业的相关业务就会受到其影响，例如明星事件。那么信息系统的承载能力以及数据的处理能力瞬间就会经受前所未有的考验，这就要求数据库同样有很强的适应能力。
（五）数据模型及访问的匹配性
在集中式关系数据库盛世的年代，各行各业对数据的需求基本以结构化二维表形式为主，以少量的非结构化或半结构化数据为辅。但是在今天这个数据飞速发展变化的时代，数据从表示形式、访问特点、存取效率上都发生了巨大的变化。表示形式上，从二维表模型拓展到文档、键值、列式、图等多种类型；访问特点上，出现了只读不写、只写不读等各种特殊业务；存取效率上，出现了各种需要内存级效率的海量检索业务。这就要求根据数据模型及访问特点来匹配正确的数据库类型，而不能再用通用的思维了。
3.2分布式数据库技术为什么能冲出困境？
在分析分布式数据库技术为什么能解决传统关系型数据库解决不了的问题之前，我们需要先明确我们所讲的分布式数据库不是一个或者一类数据库，它应该是具备了“形散神聚”特性的所有数据库的集合。
首先，具备了“形散神聚”特性的数据库产品，它可以将分散的计算资源通过网络聚合到一起，形成一个具备独立数据存储和处理能力的逻辑整体，也就具备了对海量数据的处理能力。
其次，具备了“形散神聚”特性的数据库产品，追求的是CAP理论当中的A&P，降低了对C的期望值。这样放弃强一致性，退而求其次的弱一致性，必然具备将数据的处理由物理上的集中转化为逻辑上的集中的能力，也就具备了高并发的处理能力。
再次，具备了“形散神聚”特性的数据库产品，天然具备很好的扩展性和适应性。因为这种数据库的物理节点本来就是分散的，它是依靠数据库本身的软件机制将其组合到一起形成有机整体。因此，增加减少节点或者容量对于它来讲是一个再正常不过的操作了，只不过需要考虑的是在扩展和变化的过程当中数据量迁移的量级和性能问题。
最后，分布式数据库本身不是一个或者一类产品，在这些产品当中，从数据模型到数据访问特点上都会有很多专注型的数据库产品，比如文档类的MongoDB，比如支持内存访问的Redis，比如支持大数据处理的Hbase。与传统的关系型数据库相比而言，这些分布式数据库其实更专注于某些特殊数据模型或者数据访问场景的数据处理能力，因此从此意义上讲，分布式数据库更适合某些特殊场景下的数据处理，其与特殊场景的匹配性更强。
3.3分布式数据库技术解决不了什么样的问题？
分布式数据库既然有那么多优点，那么它是不是万能的？
首先，从分布式数据库的概念上来讲，它并不聚焦在通用场景，而是聚焦在某些特殊的数据访问场景上，那么拿到通用场景上或者其他与之属性不相匹配的场景上，它必然有很多缺陷。比如数据迁移算法的复杂性和合理性方面、数据模型的不匹配性、数据持久化的缺陷等等。但是就某个特殊场景的技术特性分析来讲，必然能找到更适合的分布式数据库产品。但是就分布式数据库这种“形散神聚”的共性特点来讲，是否有场景必然从分布式数据库当中找不到相应的“菜”呢？
成也萧何败萧何，优势在“形散神聚”上，致命的缺陷也在这个上面。这种特性必然导致它在严格事务性要求的业务场景下不能完成使命。尽管不断有人通过婉转的解决方法来弥补这一点，例如“两阶段事务处理方案”，但是这也是在某些有事务容忍度的业务场景下可以勉强采用。对于事务要求零容忍度的交易类业务场景，还得回到传统的集中式关系型数据库上。
四、企业该如何思考分布式数据库之路？
综上所述，企业在如何选择分布式数据库的技术抉择上，个人觉得应该遵循以下几个原则：
一、以数据业务场景为基点，选择技术路线。
没有哪一种技术路线能绝对代表未来趋势，任何技术路线都是服务于业务场景的需求。因此我们选择技术路线的时候，必然要从分析业务场景的数据模型特点、数据访问特点以及数据存取效率三方面来剖析需求方面的属性，然后再去用这些分析出来的结果去匹配适合的数据库技术路线。
二、不迷信宣传，相信自己的技术分析和测试。
技术路线的把控是一个非常严肃的事情。第三方的评测和厂商宣传结论，但这些只能做参考，暂不提广告效益的影响，就单单选型来讲，别人的选择不一定适合自己企业，就算行业相近也有数据量大小多少以及访问量的区分。所以在广泛参考的基础之上还是要分析和测试。
三、不选最先进，只选最合适。
业务场景对数据库能力要求和侧重点会有千差万别。很难选择一款通用型产品满足全场景，那就需要根据实际情况做有针对性的选择，适合自己场景的数据库产品就是最优的产品。不要认为某个技术特性就是先进的，代表未来发展趋势的。
