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