分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有DBMS的一份完整拷贝副本，或者部分拷贝副本
分布式数据库简介
分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有DBMS的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库， 通过网络互相连接共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。
分布式并行数据库通过并行使用多个CPU和磁盘来将诸如装载数据、建立索引、执行查询等操作并行化以提升性能的数据库系统。其中最重要的关键词是并行。
在组成大规模计算机集群的时候，通常有两种特性要考虑：并行和分布式。并行强调多节点同时执行，共同解决一个大问题，通常在严格的高性能网络环境中，有严格的执行要求和反馈时限。或者通过良好的分发极致，分布式并行处理不同的任务，从而达到数据处理高性能的需求。
因为并行数据库的技术特点是为了某类需求设计的，因此它有自己的适用环境。它采用关系理论非常适合结构化数据。非结构化或者某些半结构化数据，当然也可以在其中存和取，但是实际上有很多更好的解决方案可以选择。
并行数据库目前的主要问题来自于它的设计目的，因为要实现完美的并行，因此它大多被设计为计算和存储紧密耦合，这样计算可以控制每行数据的存储位置和每个数据块的存储格式，这样对大型的任务而言提供了很好的性能。
分布式数据库设计理念
分布式数据库核心的理念可以用下面一句话来概括：
“积少成多”让多个“小”的能力协同、汇聚成“大”的能力来解决大问题，是引跑分布式数据库最核心的设计理念。分布式数据库的基本思想是将原来集中式数据库中的数据以及处理能力，分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。
并行数据库主要由执行引擎、存储引擎和管理功能模块组成。 在这里我简单介绍几种常见的多节点数据库架构，有些甚至可以看做是分布式数据库的变种，分布式数据库和我们平时经常提到的数据库集群有些相似的地方，但是不能把它们混淆。为了读者更清楚的理解，我做一些简要说明：
第一类：主从结构数据库
主从架构的数据库目前应用比较广放，其逻辑结构是一个主数据库节点和一个从数据库节点组成。从数据库节点通常可以进行只读访问，通过支撑分析行任务来分担主数据库节点的压力。常见的 DB2、Oracle、MySQL等都有主从架构的功能。
第二类：多计算节点、存储共享架构
这种架构的数据库在计算层面采用多节点的方式，但是存储节点仍然是一个共享架构，所以这种架构的数据库最大的问题在于可扩展性的限制，对于大数据量、高并发的场景很容易触发这种架构的理论缺陷阀值。这种架构最杰出的代表是 Oracle RAC以及 DB2 PureScale等数据库。
第三类：单引擎节点、无数据共享的分布式架构
这种架构的数据库会把所有的数据分布到不同的节点上，通过主引擎节点分发任务到所有计算节点，从属引擎节点作为备用和主引擎节点进行数据同步。代表性产品例如： IBM DB2 DPF、Netezza 等。这些分布式数据库通常应用于OLAP为主的BI分析领域，因为查询性能很强，但是对于OLTP 这些数据库的增、删、改以及对事物的支持能力较弱。
第四类：完全集群化的分布式架构
在这种架构下引擎节点、计算节点以及存储节点都是无中心的分布式架构，这样的中心Master架构在组成大规模集群时优势明显，我认为这是未来最先进的分布式集群架构，这样在提供良好的系统扩展性和高可用的同时，也保持了引擎节点的对等性，整个系统完全没有单点问题。
本文标题中所提到的分布式并行数据库架构，指的就是这里所提到的第三类和第四类数据库架构，它们在市场上都有很多实际的应用项目。
分布式数据库的优势和应用场景
接下来我们简单介绍一下分布式数据库架构的主要特点和主要应用场景，请允许我用引跑科技的分布式数据库产品架构来进行讲解，但是，其原理和其他的率属于第三和第四类分布式数据库原理和特点是一致的的，所以适合的应用场景也有很多重合的地方。
大家可以忽略引跑 DBOne 数据库的名字，下面介绍的特点是很通用的。分布式数据库通常会有以下优势：
- 数据表进行自动分片
- 数据的完整性通过多副本技术实现
- 高可用性通过分布式结构来保证
- 自动的负载均衡
- 水平扩展和压缩
自动数据分片
基于Share Nothing的分布式数据库架构，会对数据进行平均分配，通过数据分片（Sharding）的方式分布在不同数据节点。这样当处理应用对数据的请求时会分布到不同的数据节点并行执行。
自动数据分片原理图
设计良好的分布式数据库系统，会自动根据资源情况进行自动的扩展，把数据和业务负载自动扩展到新加入的物理服务器上。良好的可扩展性也是分布式并行数据库最大的优势。
智能水平扩展
智能水平扩展原理图
智能水平压缩
数据水平压缩是水平扩展的相反操作，用于需要自动或者手动收缩资源的场景。
智能水平压缩原理图
高可用性
分布式数据库通常会配置多个数据副本，例如Replica=2时，会把实际数据在不同的物理节点上存储三份。下面的原理图，展示了当某个服务器出现故障，其他服务器可以自动接管任务负载，并且重新分配数据分片。
高可用性原理图二
自动节点发现和负载均衡
在分布式数据库架构中，动态添加硬件资源，从而避免在繁忙时段服务器的过载是非常重要的功能，这样保证了整体的灵活性和可扩展性大大强于Oracle RAC为代表的传统交易型数据库系统。
下图展示了当服务器出现过载情况时，自动热迁移数据到空闲物理服务器的情景，整个数据迁移粒度可以是：整个应用级、实例级、Shard级别或Shard内部更细粒度迁移。
综合来看，分布式并行数据库在数据处理的高性能、高效的资源利用率、高可用性等方面都有很好的优势。分布式并行处理机制，对于OLAP领域的应用优势非常明显。在OLTP领域分布式并行数据库还刚刚开始显现威力，对于分布式事物的支持能力如何，成为判断分布式并行数据库是否完善的有效评判标准之一。
OLTP领域使用分布式数据库的考虑因素
企业的核心业务系统一般都是OLTP为主的应用场景，在这个领域Oracle一直是市场的领导者，紧随其后的IBM DB2、MS SQL Server等都在这个领域占据重要市场地位。
近年来，随着开源数据库的发展，MySQL、PostgreSQL为主的开源数据库逐步占据了OLTP领域较大一块市场，在市场份额上对传统的交易型数据库厂商造成了冲击。特别是在互联网领域，开源数据库应用非常广泛。但是，在中大型企业及政府机构领域传统交易型数据库三强（Oracle、DB2、SQL Server）仍然占有极大的比重。
随着国产化战略、自主可控需求的发展，以及去“Oracle”浪潮不断的演化，在这些中大型企业中将会逐步使用国内的一些数据库产品，在其中分布式数据库是一个非常重要的方向，只有基于好的分布式架构的数据库才有可能与Oracle RAC进行面对面的直接竞争。
对于企业而言，如果在OLTP应用场景要去Oracle数据库，还是一个比较大的变革，源于Oracle和上层应用的紧密绑定，所以真正要做去“O”的决定，一般需要考虑以下因素：
1. 变革驱动因素
企业的核心交易系统要想去除掉Oracle，要由足够的驱动力。这个驱动力或者是国产化、安全自主可控的国家战略影响，或者是出于降低企业IT成本的需要，无论如何都需要有足够动力让企业决策者去推动替换Oracle数据库的项目。
2. 稳定性因素
OLTP系统通常作为企业核心业务的交易系统，稳定性是第一位的。没有企业愿意在OLTP应用场景中承受稳定性的损失。即使成本或其他因素再有吸引力，如果稳定性不达标，企业和组织机构页不会愿意冒这种风险去做变革。对于分布式并行数据库这种产品来说，把稳定性放在第一位是绝对正确的选择。
3. 迁移复杂度
Oracle在去IOE运动中是最为复杂和困难的，其原因就在于Oracle数据库和上层应用绑定比较紧密，替换数据库需要涉及到应用迁移，这个工作的工作量和时间周期通常较大。
对于上层业务应用来说，如果大量使用Oracle存储过程、自定义函数、触发器等来实现负责的业务逻辑，那么替换Oracle数据库时将会非常耗时，复杂度较高、风险也比较大。
相反，如果业务应用使用Hibernate等比较成熟的开发架构，业务逻辑都封装在应用层，那么这类应用的迁移难度和复杂度就会比较低，这类应用进行数据库迁移会比较容易。
4. 高性能
很多大型的业务应用系统底层的数据库基于Oracle RAC，当数据量增大，SQL查询的业务逻辑很复杂时，这种存储共享的数据库架构会受限于其扩展性的低效率和天花板问题，会出现性能瓶颈。对于并发压力较大、数据量上TB的的业务系统来说，替换Oracle后，需要新的数据库系统能够提供很好的性能支撑。这种情况下，分布式并行数据库基本上成了不二之选。
5.可扩展性
企业核心业务系统通常对可扩展性要求较高，那么作为替换Oracle的新数据系统，在可扩展性方面要有一定的优势。分布式数据库在可扩展性方面通常做的不错，特别是第三类和第四类分布式数据库。
6. 高可用性
高可用性是指一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。在这方面传统的交易型数据库会通过双机热备，多节点等方式来实现。Oracle RAC、DataGuard等都是常见的方式。
而基于分布式并行架构的数据库系统，通常在高可用性方面做的不错，通过多个并行计算、存储节点以及多副本的实现方式，有效的保证了整体系统的高可用性。
7.运维复杂度
企业IT运维是保证IT能力正常支撑企业业务发展的重要流程，在OLTP应用场景中替换原有的数据库，会对企业IT的运维能力造成冲击和挑战，因此，企业在整个去“O”过程中需要有效的评估运维复杂度的变化。新的基于分布式架构的数据库如果能够在用户界面、使用方式、命令、语法等方面和原有的Oracle数据库保持尽可能多的兼容，会有效减少企业对新技术的学习成本，使得运维的复杂度可控。
分布式数据库取代Oracle的常见应用方案
引跑科技DBOne是基于分布式并行数据库架构的，如下图展示的架构图，可以很清楚的看到它是我前面提到的第三类或第四类分布式数据库架构。因为，它的引擎节点可以部署成主备结构或者完全对等的集群结构。
DBOne分布式数据库架构图
DBOne主要包括分布式数据库引擎和分布式数据存储节点。分布式数据库引擎是系统核心，其负责SQL解析、优化、路由、分发、合并等操作，同时将底层的众多存储节点管理起来；分布式存储节点使用引跑自行设计和完全自主可控的单机iDB（Intple DB）关系型数据库产品。用户可灵活构建不同规模的数据库集群，通过将业务数据分片到不同的数据库存储节点中，极大降低了普通数据库面对海量数据时的压力；通过将用户的SQL请求分发到各节点上执行，充分利用各节点的计算资源，从而能够使PC服务器集群达到并超越小型机、中大型机的性能。
下面我以引跑的DBOne分布式并行数据库为例，来介绍一下分布式数据库在取代Oracle的过程中的常见应用场景。
如上图所示，这是一个典型OLTP应用场景中的Oracle架构，多RAC节点的共享存储架构模式，本地一般通过带库进行定期备份。如果替换这样的Oracle数据库，可以采用以下的两种应用方案。
方案一 Fusion混合模式
在这种架构下，原有Oracle数据库和分布式数据库并行运行，通过同步工具进行异步或同步模式的数据同步。把上层应用对数据库的请求进行划分，把少量OLTP以及OLAP业务请求分流到分布式数据库执行。这样对于某些应用迁移复杂度高、风险较大的情况可以灵活进行处理。如果原有的Oracle数据库存在性能问题以及存储扩容的需求，那么可以只在Oracle数据库中保留“热”数据，全量数据放在分布式数据库中，这种模式可以很好的解决用户的这些头疼问题。
这种架构是一种在实际项目中经常用到的模式，对很多企业用户来说，混和模式从各方面来说都更容易接受，尽管它只是一个中间模式，却能通过较小的代价快速解决客户的问题。当然，应用负载的分流复杂性问题也是存在的。
方案二 完全分布式模式
如上图所示，在这种分布式数据库架构模式中，数据完全迁移到新的分布式数据库中，通过两个相对独立的分布式集群来实现本地或者异地的数据库容灾。对于很多新的应用项目这是比较好的实现方式，因为无需考虑上层应用迁移的复杂度和风险问题。从实际市场情况来说，这种新交易型应用项目直接采用分布式数据库是比较常见的的，这种直接去Oracle的方式无论从风险和成本上来说都比较有优势。
大数据应用促进“分布式架构”的繁荣
从实际市场反馈来说，分布式并行数据库要想取代Oracle仍然任重而道远，这其中有很多原因，就像我在第四节提到的那些因素，都制约着国产分布式并行数据库的发展。
好消息是大数据应用的繁荣会促进分布式并行数据库的进步，因为整个大数据应用架构都是以分布式以及并行为核心的。越来越多的企业正在探索和实践大数据项目，随着大数据应用规模不断发展和影响力的扩大，对于分布式并行数据库的发展有极大的促进作用。
我期待有一天能够在不改变任何原有业务逻辑和代码的前提下，实现底层分布式数据库的自由伸缩和扩展。我们会以“高稳定性、可扩展，高性能”为核心理念，改进引跑的分布式并行数据库，最终我们一定能够让它在去Oracle的征途上越走越远。
（责编/钱曙光 qianshg@csdn.net）
作者：张晓东，引跑科技副总裁，IT领域工作15年，曾担任数据库技术专家、IT服务经理、高级云计算架构师、战略部高级总监等职位。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
