分布式数据库拓扑

SmartEDB扩展模块提供了实现各种分布式数据解决方案的工具。分布式数据库系统允许应用程序从本地和远程数据库访问数据。分布式数据库管理设计的一般目标是：

• 提供数据的高可用性

• 提供数据和数据管理解决方案的可靠性

• 提供功能和可扩展性

• 适应现有环境并提供节省成本的解决方案

“分布式数据库”和“分布式处理”这两个术语密切相关，但含义不同。分布式数据库是分布式系统中的一组数据库，对于应用程序来说看起来像一个单一的数据库。分布式处理解决方案将其任务分布在网络中的不同计算机之间。在数据库系统和应用程序的上下文中，这意味着数据库任务分布在集群中的两个或多个节点之间，这些节点协作以维护单个逻辑数据库实例。

同样，“分布式数据库系统”和“数据库复制”这两个术语相关，但不同。在“纯”（即未复制）分布式数据库中，系统管理所有数据库对象的单个副本，并且给定的数据库对象仅存在于一个数据库实例中。通常，分布式数据库应用程序使用分布式事务来访问本地和远程数据，并实时修改全局数据库。术语“复制”是指在属于分布式系统的多个数据库实例中复制和维护数据库对象的操作。虽然复制依赖于分布式数据库技术，但数据库复制提供了纯分布式数据库环境中不可能实现的好处。

复制用于提高本地数据库性能（SmartEDB集群）或提高数据库的可用性（SmartEDB高可用性）。例如，在 SmartEDB集群中，集群节点上的每个进程都与本地数据库一起工作，以最大限度地减少网络流量并实现最高性能。使用 SmartEDB高可用性，如果主服务器出现故障，备用系统可以继续运行。

分布式数据库解决方案

SmartEDB 扩展模块提供了三种分布式数据库解决方案架构：

高可用性

SmartEDB高可用性的目的是保持关键任务系统的可用性。为实现这一目标，主数据库实例被复制（分布）到一个或多个备用实例，通常在不同的物理设备上。在 SmartEDB高可用性的使用中，使用数据库的进程也有主实例和备用实例。如果承载主数据库的设备出现故障，主副本任务会启动故障转移过程（成为主实例），并使所有其他副本任务恢复正常处理。

SmartEDB高可用性提供了一种“主从”架构，其中主应用程序具有读写能力，副本应用程序具有只读能力。因此，只有主数据库实例可以被修改，但所有事务都被复制到数据库的从（只读）副本。有多种通信渠道可用，复制可以是同步的或异步的。SmartEDB高可用性提供了极快的故障转移，在承载原始主数据库实例的节点出现意外故障时，副本应用程序接管成为主实例。（请参考 SmartEDB高可用性用户指南以获取更多详细信息。）

集群

SmartEDB集群的目的是为在单个逻辑数据库上协同工作的一组设备提供可扩展性。与高可用性不同，集群中的每个节点对于其他每个节点都是对等的，即不存在主备关系。SmartEDB集群与 SmartEDB高可用性的共同点是物理数据库被复制（分布）到集群中的每个节点，但仍然表示单个逻辑数据库。因为每个节点都有其自己的数据库副本，所以读请求（查询）执行得非常快，因为不涉及网络通信。然而，插入、更新和删除操作必须复制到集群中的每个节点，这导致这些操作与针对单个（非分布式）本地数据库的操作相比要慢。但是，总的来说，集群中所有节点上的插入、更新和删除操作的总和可能超过任何单个节点的性能。例如，集群中的一个节点可能仅以独立节点速度的 40％运行，但三个以理论最大值 40％运行的节点将超过单个节点。这一点，再加上查询始终是本地的这一事实，为通过添加具有成本效益的商品硬件来扩展处理创建了一个平台。然而，可扩展性受到复制的限制，因为向集群中的 2、3、4 等节点复制会为读写事务引入递增的延迟。

SmartEDB集群提供了一种“节点到节点”的复制架构，其中集群中的所有节点都是对等的，例如，每个节点都可以执行读写和只读操作；只读事务始终是本地的（无网络访问，因此非常快），而读写事务默认由 SmartEDB集群运行时分布到集群中的所有节点。集群实现使用可配置的超时和保持活动消息自动控制节点的可用性。有多种方法可以提高 SmartEDB集群的可扩展性，例如使用“本地表”或分散/收集 API 代替自动（默认）复制。（请参考 SmartEDB集群用户指南以获取更多详细信息。）

分片和分布式查询处理

SmartEDB高可用性和 SmartEDB集群提供了基于复制的分布式处理解决方案，而通过 SmartEDB SQL的 DistributedSql 引擎支持数据分布。

分布式数据库通常通过“分片”（又名水平分区）来实现。在过去几年中，由于在线服务提供商、软件即服务（SaaS）公司、社交网络网站、资本市场应用等服务的业务应用数据库的交易量和规模的巨大增长，数据库分片的概念越来越受欢迎。

分片可以简单地定义为将数据库“无共享”地水平分区为多个较小的数据库实例，这些实例共同构成一个逻辑数据库。推动分片需求的原因是，随着数据库的大小和事务量呈线性增长，响应时间往往呈对数增长。分布式查询由于在每个分片上执行并行执行，因此允许更快的处理。

众所周知，数据库性能会随着数据库大小的增加而下降。这在很大程度上是由于诸如 B 树等索引结构的大小（深度）增加。当数据库存在于旋转磁盘上时，机械因素会加剧这个问题（当数据库占用更多磁盘时，等待磁盘旋转或磁盘磁头移动到正确磁道的“旋转等待时间”更长）。将一个逻辑数据库分区为，例如，五个物理数据库意味着每个物理数据库的大小仅为如果它作为单个物理数据库存在时的 20％。因此，索引结构更浅，旋转磁盘几何形状的影响（如果有的话）得到缓解。此外，不是由单个数据库服务器为单个物理数据库提供查询执行，我们可以允许（例如，再次）五个服务器进程提供查询执行。这称为分布式查询处理，对于数据库客户端应用程序是透明的。客户端应用程序只需打开逻辑数据库，数据库配置（在 JSON 文档中描述）确定数据库的物理构成（即逻辑和物理是否意味着相同的东西，或者逻辑数据库是否由 2、5 或 100 个物理分区等组成等）。一旦连接，客户端应用程序以正常方式开始/提交/中止其事务和查询。如果数据库进行了物理分区，SmartEDB SQL查询引擎会代表客户端应用程序负责分布查询，并收集（附加）每个分区的结果集，以向客户端应用程序呈现单个（逻辑）视图。

分片和 SmartEDB高可用性可以结合使用。在这种配置中，单个逻辑数据库被水平分区为两个或更多物理数据库实例。每个分片（物理数据库实例）然后有一个主服务器和副本服务器进程，如果原始主服务器意外终止，副本可以提升为主服务器。通过这种方式，我们可以保留单个逻辑数据库的可用性，否则如果处理分片的任何服务器出现故障，这是不可能的。（请参考 SmartEDB SQL用户指南以获取更多详细信息。）