为什么同一组件在preview上可以显示，但是在方舟编译器的模拟器上就无法显示？

表格里没有数据，是需要执行其他的控件吗

分类文档链接路标信息cid:link_4特性清单cid:link_1DDM最佳实践cid:link_0原子APIcid:link_2FAQcid:link_3华为云官网服务介绍&操作指导cid:link_5华为云开发者网DDM开放能力cid:link_4

什么是读写分离读写分离是分布式数据库中间件（Distributed Database Middleware，简称DDM）的一项核心功能，可以将只读查询的流量按比例分摊至下挂存储节点的主实例和只读实例，从而减轻主实例的工作负担，保障读写事务的性能。此功能对应用透明，业务代码无需改造，只需要在控制台中设置主实例和只读实例的读权重，即可实现将读流量按照权重分流到主实例和只读实例上。写流量不受影响，默认会分流到主实例上。一般来说该比例的设置需结合业务实际特点以及存储节点实际负载进行设置。只读实例上的数据是从主实例上异步复制而来，所以存在毫秒级的延迟。如果只读查询对数据实时性要求不高（容忍亚秒级可见性延迟）且只读查询的开销较大并对业务核心读写事务有一定影响，设置主实例和只读实例的权重为0:100，即所有只读查询均由只读实例承担，最大程度保证主实例性能。对于其他场景，建议结合实际情况酌情调整。如何设置读写分离1. 登录管理控制台。2. 单击管理控制台左上角的，选择区域。3. 单击左侧的服务列表图标，选择“数据库 > 分布式数据库中间件 DDM”，进入DDM管理控制台。4. 选择目标DDM实例，单击实例名称进入实例基本信息页面。5. 在左侧导航栏选择“DN管理”，进入DN管理页面。图1-1 DN管理6. 设置实例的读写权重。只读实例挂载后默认承载全部可分离的只读请求，如果需要设置实例的读写权重，可参照以下操作来设置。如果需要设置多个实例的读写权重，可单击实例上方的“设置读权重”来进行批量设置。如图1-2所示。在批量设置的弹窗中，“同步”功能可以用来将第一个实例的读权重设置同步到其他的实例上，如图1-3所示。此操作需满足所有实例的只读实例数量一致才可以实行。如果有实例的只读实例数量与其他实例不一致，则无法使用“同步”功能，需手动设置各个实例的读权重，如图1-4所示。图1-2 批量设置读权重图1-3 同步第一个实例的读权重图1-4 手动设置权重如果需要设置单个实例的读写权重，可单击操作栏的“设置读权重”来进行设置。7. 设置读权重命令下发成功提示。

过去十年见证了分布式数据库的崛起不仅通过本地集群来实现负载均衡，并提供高可用性，还具有数据中心内的机架感知等属性。专为云而设计的分布式数据库，可以跨越可用性区域，通过编排技术，支持公有云、私有云、混合云部署。近年来，市面上出现了大量专为分布式数据库部署而设计的新数据库系统，以及在初始设计中添加了分布式架构组件的其他数据库系统。DB-Engines排名前100的数据库DB-Engines是数据库领域的权威排行榜，它保留了所有数据库的流行指数，使用一种算法进行加权，监测诸如网站上的提及次数和谷歌的搜索趋势，Stack Overflow上的讨论或推特中的评论，工作职位要求的技术技能，以及在LinkedIn个人资料中提到这些技术的数量。虽然DB-Engines收集了数百个不同的数据库（截至2022年5月共有394个）。但是本文我们缩小范围，只观察前100名数据库。在很大程度上，反映了市场现状。关系型数据库管理系统（RDBMS），传统的SQL系统，仍然是最大的类别，占列表的47%。另外，列表中有25%是NoSQL系统，涵盖了许多不同类型的数据库，像MongoDB文档数据库、Redis键值系统、ScyllaDB宽列数据库，以及Neo4j图数据库。还有11%的数据库被列为多模型数据库，包括在同一系统中支持SQL和NoSQL的混合数据库，如微软的Cosmos DB或ArangoDB，或者支持多种NoSQL数据模型的数据库，如DynamoDB，它将自己列为NoSQL键值系统和文档存储。最后，还有一些是由各种特殊用途的数据库组成，从搜索引擎到时间序列数据库，以及其他不容易归入简单的“SQL与NoSQL”区域的数据库。但是所有这些数据库都是分布式数据库吗？这个词到底是什么意思？分布式数据库的定义2016年12月14日，ISO/IEC发布了最新版本的数据库语言SQL标准（ISO/IEC9075:2016）。随着时间的推移，如何构建与SQL兼容的分布式RDBMS系统一直在发展。分布式SQL，如PostgreSQL或CockroachDB NewSQL系统。相反，没有ANSI或ISO或IETF或W3C定义什么是NoSQL数据库。每种数据库都使用自己的专有查询语言，比如用于宽列NoSQL数据库的Cassandra查询语言（CQL），用于图形数据库的Gremlin/Tinkerpop查询方法。然而，它们并没有定义数据如何在这些数据库中分布，查询语言也不能解决架构问题。因此，无论是SQL还是NoSQL，对于什么是分布式数据库，并没有标准、协议或共识。因此，我花了一些时间来写下我自己的定义。坦率地说，这更像是一个门外汉的实用主义观点，而不是计算机科学教授的见解。简而言之，你必须决定你如何定义集群，以及如何跨集群分配数据。接下来，你必须确定集群中每个节点的角色。每个节点都是对等的，还是有些节点处于更优越的领导地位，而其他节点则是跟随者。然后，基于这些角色，你如何处理故障转移？最后，你必须在此基础上，弄清楚你如何尽可能均匀和容易地复制和分片数据。而这并不试图做到详尽无遗，你可以添加自己的特定条件。简短的清单：感兴趣的系统考虑到这些，我在前100名数据库中，找到五个示例，看看它们在测量属性时是如何比较的。其中有两个SQL系统和三个NoSQL系统。Postgres和CockroachDB代表最好的分布式SQL。CockroachDB被称为 NewSQL，专为分布式数据库而设计。MongoDB、Redis和ScyllaDB是分布式NoSQL，分别是文档数据库，键值存储，宽列数据库（也被称为键值数据库）。在大多数情况下，适用于ScyllaDB的也同样适用于Apache Cassandra和其他与Cassandra兼容的系统。假定你拥有专业的经验，而且对SQL与NoSQL的区别相对了解。基本上，如果需要一个表JOIN，坚持使用SQL和RDBMS。如果你可以将数据反规范化，那么NoSQL可能是一个很好的选择。我们不打算讨论作为数据结构或查询语言，两者哪个“更好”。而是讨论作为一个分布式数据库，哪个更好。多数据中心集群我们的选项在集群方面是如何比较的？现在，它们都能够进行集群，甚至是多数据中心操作。但是在PostgreSQL、MongoDB和Redis中，它们最初设计于单数据中心本地集群，在多数据中心设计之前就已经成为一种架构要求。Postgres首次发布于1986年，完全早于云计算的概念。后来，它允许在其设计上，纳入这些技术和能力。作为NewSQL革命的一部分，CockroachDB从一开始就考虑到了全球分布。MongoDB是在公有云诞生之初发布的，最开始设计时考虑到了单数据中心集群，但现在已经增加了对许多不同拓扑结构的支持。通过MongoDB Atlas，可以轻松部署到多个地区。Redis，由于其低延迟的设计，通常被部署在单个数据中心，但它具有允许多数据中心部署的企业特性。ScyllaDB，像Cassandra一样，从一开始就考虑到了多数据中心的部署。集群管理如何进行复制和分片，取决于数据库架构的分层或同质化程度。例如，在MongoDB中，有一个主服务器，其余的是主服务器的副本。副本是只读的，你只能对这个数据库的主副本进行写操作，不能直接更新。相反，你写到主数据库，它就会更新副本。所以，节点是异质的，而不是同质的。这有助于在读取繁重的工作负载中分配流量，但在混合或写入工作负载中，对你没有一点好处，主服务器可能会成为一个瓶颈。同样，如果主服务器发生故障会怎样？你将不得不完全停止写操作，直到集群选出一个新的主服务器，并将写操作分流到它上面。相反，如果ScyllaDB或Cassandra，或任何其他无active-active的系统，客户可以从任何节点读取或写入。没有单一的故障点，节点的同质化程度要高得多。而且每个节点都可以更新集群中的任何数据副本。因此，如果你有三个节点，每个节点都会根据其他两个节点的任何写入进行更新。active-active在计算方面本身就比较困难，但是一旦解决了服务器保持彼此同步的问题，就会得到一个可以更好地平衡混合或写入大量工作负载的系统，因为每个节点都可以提供读取或写入服务。那么，我们的各种例子在主复本或active-active对等方面是如何叠加的？CockroachDB和ScyllaDB，以及Cassandra一开始就考虑了active-active的主动式设计。在Postgres中，有一些可选的方法可以做到这一点，但它不是内置的。此外，MongoDB没有正式支持active-active，但是已经有一些人在尝试如何做到这一点了。对于Redis来说，active-active模型在Redis企业中可以通过无冲突复制数据类型（CRDTs）实现。Postgres、MongoDB和Redis都默认使用主副本数据分布模型。复制分布式系统设计也会影响如何跨部署到不同机架或数据中心之间分配数据。例如，给定一个主副本系统，只具有主的数据中心可以为任何写入工作负载服务，其他数据中心只能作为只读副本。在一个支持多数据中心集群的点对点系统中，整个集群中的每个节点都可以接受读或写操作。通过ScyllaDB，你可以决定每个站点有相同或甚至不同的复制因素。这里我展示了在一个数据中心的三个副本，在另一个数据中心有两个副本的可能性。操作可以有不同级别的一致性。你可能在三个节点的数据中心进行本地数据的读或写，需要更新任一数据中心的节点才能成功执行操作。可调整的一致性，结合多数据中心的拓扑感知，为工作负载提供更多的灵活性。拓扑感知本地集群是分布式数据库开始的方式，允许多个系统共享负载。如果想让数据库在多个节点上进行分片，或者通过确保相同的数据在多个节点上可用来实现高可用性，那么这一点非常重要。如果所有节点都安装在同一个机架上，一旦这个机架发生故障，就会很棘手。因此，添加拓扑感知，以便你可以感知同一数据中心内的机架。确保将数据分散在数据中心的多个机架上，从而最大限度地减少电源或连接丢失到一个或另一个机架的中断。有些数据库做的很好，允许在不同的数据中心运行数据库的多个副本，并使用某种跨集群更新机制。每个数据库都是自主运行的，它们的同步机制可以是单向的，一个数据中心更新一个下游的副本，也可以是双向的或多向的。这种地理分布可以通过允许更靠近用户的连接，来减少延迟。跨可用性区域或地区的数据库，还可以确保单个数据中心灾难不会导致数据库的部分或全部丢失。去年我们的一个客户就发生了这种情况，但由于他们部署在三个不同的数据中心，所以数据损失为零。跨集群更新最初是在批量级别上实现的。确保你的数据中心每天至少有一次同步。这并没有持续多久，后面人们开始确保更活跃的事务级更新。如果你在运行强一致性数据库，就会受到基于光速的实时传播延迟的限制。因此，实现最终一致性是为了允许每个操作更新使用多数据中心，同时考虑到在短期内，要使所有数据中心的数据保持一致可能需要时间。那么，在拓扑感知方面，它是如何叠加的？所以，CockroachDB和ScyllaDB也是内置的。从2015年开始，拓扑感知也成为MongoDB的一部分，他们在这方面有着多年的经验。Postgres和Redis最初被设计为单数据中心解决方案，因此处理多数据中心的延迟对两者来说并非易事。现在，你可以添加拓扑感知，就像添加active-active系统功能一样，但它并不是开箱即用的。让我们回顾一下所讨论的内容，分别查看这些数据库的属性。▶︎ PostgreSQLPostgreSQL是世界上最流行的的开源数据库之一，它以可靠性和稳定性而著称,在处理复杂SQL方面也表现出了绝对的优势。然而，Postgres仍在研究其跨集群和多数据中心的集群。由于SQL基于强一致性事务模式，所以它不能很好地跨地域跨集群。在所有相关的数据中心之间，每个查询都将由于长时间的延迟而暂停。此外，Postgres依靠的是主副本模型。集群中的一个节点是领导者，而其他节点是副本。虽然有负载平衡器或active-active插件，但这些也超出了基本的服务范围。最后，Postgres的分片在大多数情况下仍然是手动的，尽管他们在开发自动分片方面取得了进展，但这也超出了基本产品的范围。▶︎ CockroachDBCockroachDB声称自己是“NewSQL”，一个专为分发而设计的SQL数据库。它可以水平扩展，在磁盘、机器、机架，甚至数据中心故障时都能生存下来，做到延迟最小，无需手动干预。值得一提的是，CockroachDB使用Postgres线协议，并大量借鉴了Postgres开创的许多概念，而且并不局限于Postgres的架构。多数据中心集群和点对点的拓扑结构从一开始就被内置。自动分片和数据复制也是如此。它还内置了数据中心感知功能，而且还可以添加机架感知功能。对CockroachDB来说，它要求所有的事务都有很强的一致性，你可以把它看作是一个优点或缺点。既没有最终一致性的灵活性，也没有可调的一致性。这将降低吞吐量，并在任何跨数据中心部署中要求较高的基线延迟。▶︎ MongoDBMongoDB是NoSQL领域的领导者。随着它的发展，大量的分布式数据库功能被添加。现如今，MongoDB能够支持多数据中心集群。在大多数情况下，它仍然遵循主副本模式，也有办法使其成为对等的active-active。▶︎ Redis接下来是Redis，一个旨在作为内存缓存或数据存储的键值存储。Redis的数据全部在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证Redis的数据不会因为故障而丢失，这种机制就是Redis的持久化机制。虽然持久化保存数据，但如果数据集不适合放在RAM中，它就会遭受巨大的性能损失。正因为如此，它在设计时考虑到了本地集群。如果你无法承受5毫秒的等待时间来从SSD上获取数据，您可能更无法等待145毫秒来完成从旧金山到伦敦的网络往返时间。然而，有一些企业特性允许多数据中心的Redis集群。Redis在大多数情况下是以主副本模式运行的。这适用于大量读取的缓存服务器。但这意味着，主节点是数据需要首先写入的地方，然后将这些数据分散到副本，以帮助平衡其缓存负载。有一个企业功能，允许对等的active-active集群。Redis可以自动分片和复制数据，但它的拓扑感知仅限于作为企业功能的机架感知。▶︎ ScyllaDBScyllaDB是按照Apache Cassandra中的分布式数据库模型设计的。因此，它默认是多数据中心集群。它可以自动分片，并且每个操作都有可调整的一致性，如果你想要更强的一致性，它甚至还支持轻量级事务来提供写入的线性化。就拓扑感知而言，ScyllaDB支持机架感知和数据中心意识，甚至支持标记感知和分片感知，不仅知道数据存储在哪个节点上，甚至可以知道与该数据关联的CPU。结论虽然对于什么是分布式数据库，还没有一个行业标准，但是我们可以看到，许多领先的SQL和NoSQL数据库，都在某种程度上支持一组核心功能或属性。其中有些功能是内置的，有些被认为是增值包或第三方选项。在本文分析的五个典型分布式数据库系统中，CockroachDB为SQL数据库提供了最全面的功能和特性，ScyllaDB为NoSQL系统提供了最全面的功能。该分析应被视为某个时间段的调查。鉴于下一个技术周期的需求，每一个数据库系统都在不断发展，这个行业并没有停滞不前。对用户来说，分布式数据库每年都在进步，变得更加灵活、性能更强、更具弹性和可扩展性。来源：今日头条

5月10日，弗若斯特沙利文（Frost & Sullivan，简称“沙利文”）联合头豹研究院发布《2021年中国分布式数据库市场报告》。报告显示，在中国市场，分布式数据库发展正处于“爆发期”。从专利申请的数据角度出发，中国的分布式数据库相关专利申请量从2012年的全球占比22%爬升至2021年的76%，中国已经成为了全球分布式数据库的技术创新中心。通过对2021年数据库市场进行持续跟踪和调研，沙利文指出，数据库作为大多数信息系统的基础设施，向下发挥硬件算力，向上承接上层应用，各式各样的数据库产品分别满足不同的业务需求。数据库的速度、易用性、稳定性、扩展性、成本都对企业的基础业务与增长弹性至关重要。对于数据库行业的发展趋势，沙利文认为，在云上建设数据库服务，设计出以基础云先行，全线适应云特点的云原生数据库尤为重要。腾讯云自主研发了新一代高性能、高可用数据库TDSQL-C，100%兼容MySQL和PostgreSQL，实现超百万级QPS的吞吐能力。展望未来，数据库的发展动力依然来自数据存储规模和性能要求，以及硬件的发展，未来的数据库技术还将满足AI对数据管理的需求。《2021年中国分布式数据库市场报告》 下载  https://www.modb.pro/doc/60894文章来源：https://baijiahao.baidu.com/s?id=1732412452502027034&wfr=spider&for=pc

电脑可以没日没夜地运行，但早先的网站却做不到24*7小时的运营。现在看来我们都不可思议。然而，在互联网出现之前，24*7的高可用性这个提法并不存在。那时我们对可用性是有期待，但我们却压根不会认为这是我们有权要求获得的东西。我们只在需要时使用计算机；更多的时候我们其实本来就不太有机会使用它，自然也很少会让计算机一直开着以便它可以随时响应我们。随着互联网的发展，那些以前在当地时间凌晨 3 点不常见的请求变得越来越多，也让这个时间段在全球各地都变成了黄金营业时间，因此确保计算机能够服务这些请求变得非常重要。然而，许多系统仅依靠一台计算机来处理这些请求——单点故障——我们都知道这是个很糟糕的事实。为了保持正常运行，我们需要在多台可以满足我们需求的计算机之间分配负载。然而，分布式计算有着非常明显的优势：特别是同步和容忍系统内的部分故障（容错）。每一代工程师都在迭代这些解决方案，以满足这个时代的需求。数据库领域是如何引入分布式的，这件事很多人并不清楚前因后果，因为这本身就是一个比其他领域发展缓慢得多的难题。当然，软件在本地数据库中会记录一些分布式计算的结果，但数据库本身的状态只能保存在单台机器上。为什么？因为跨机器的状态复制是非常困难的。在这篇文章中，我们来看看分布式数据库在历史上是如何处理容错的，以及高可用性是什么样子的。另外，我们还会介绍高可用性系统的几种不同类型。高可用性数据库有哪些类型?高可用性数据库一般情况下可分为两类，目前出现了第三类，而且变得越来越普遍：主-从数据库：数据库有一个主节点处理请求，另外一个是热备节点（即从节点），一旦主节点故障后就会投入使用主-主数据库：数据库具有多个主节点，这些节点将数据分片后分别对数据库进行写操作多主数据库：数据库具有至少三个主节点，这些节点都可以对集群中的任何数据执行读写操作而不会产生冲突。什么是主从可用性?主从可用性意味着数据库有一个主节点处理请求，另外一个是热备节点（即从节点），一旦主节点故障后就会投入使用。主从可用性模型基于两节点概念，即一个节点接收所有请求，然后再将数据复制到其追随者。在过去，数据库在单台机器上运行。它只有一个节点，处理所有的读写操作。没有所谓的“部分失败”；数据库不是成功启动就是失败停服。对互联网来说，单节点数据库的完全不可用是一个双重问题；首先，计算机全天候被访问，因此停机更有可能直接影响用户；其次，通过将计算机置于持续的访问请求之下，它们更有可能出现故障。很明显，这个问题的解决方案是使用多台计算机来共同处理请求，这也是分布式数据库起步的契机所在。生活在单节点世界中，最自然的解决方案是继续让单个节点提供读写服务，并将其状态简单地同步到辅助的备份机器上——因此，主从复制诞生了。主从模式是通过即时备份实现高可用性的早期步骤。在主节点发生故障的情况下，您可以简单地将流量引导到从节点，从而将其提升为主节点。只要有可能，您就会用一台新的备份机器替换停机的服务器（并希望主节点在此期间不会出现故障）。首先，从主节点到从节点的复制是一个同步过程，即在从节点确认之前，数据转换并不会被提交。但是，目前还不清楚如果从节点出现故障该怎么办。如果备份系统不可用，整个系统宕机当然没有意义——但是只要使用同步复制，就会发生这种情况。为了进一步提高可用性，可以改为异步复制数据。虽然它的架构看起来是一样的，但它能够处理主节点或从节点的宕机，而不会影响数据库的可用性。虽然异步主从模式是向前迈出的又一步，但仍然存在明显的缺点：当主节点宕机时，任何尚未复制到从节点的数据都可能丢失——即使客户端已经确认了数据完全提交。依靠单台机器来处理流量，仍然受限于单台机器的最大可用资源。对五个 9 的高可用性追求扩展到多台机器随着互联网的普及，业务需求的规模和复杂性都在增长。对于数据库来说，这意味着它们需要能够处理比任何单个节点都多的流量，并且提供“始终在线”的高可用性成为一项任务。鉴于现在大量工程师拥有从事其他分布式技术的经验，很显然，数据库可以超越单节点的主从模式，将数据库分布在多台机器上。分片同样，我们可以从调整现有的系统起步，我们的工程师通过开发分片将主动复制调整为更具可扩展性的架构。在此方案中，您按某个值（例如行数或主键中的唯一值）拆分集群的数据，并将这些段分布在多个实例，每个实例都有一套主从节点。然后，您在由这些实例组成的集群前添加某种路由技术，以将客户端请求引导到正确的实例来处理。分片允许您在将工作负载分配到多台机器上，从而提高吞吐量，并通过容忍更多的部分故障和消除单点故障来创建更大的弹性。尽管有这些好处，但对系统进行分片是复杂的，并且给团队带来了巨大的运维负担。特意对碎片进行的统计可能会变得非常繁琐，以至于路由最终会渗入应用程序的业务逻辑。更糟糕的是，如果您需要修改系统分片的方式（例如模式更改），通常需要明显的（甚至是巨大的）工程量来实现。单节点主从系统也提供了事务支持（即使不是强一致性）。然而，跨分片协调交易的难度是如此的琐碎和复杂，许多分片系统是决定彻底放弃它们的。什么是主主可用性?主主可用性意味着数据库至少有两个主节点，它们对数据进行分片并执行对数据库的写入。主主可用性代表了从主从的演变，通过让集群中的节点提供读写服务，使数据库能够扩展到单台机器之外。考虑到分片数据库难以管理且功能不全，工程师们开始开发至少可以解决其中一个问题的系统。这时候出现的是仍然不支持事务的系统，但管理起来已经非常容易。随着对应用程序正常运行时间的需求不断增加，帮助团队满足其 SLA 的决定是很明智的。这些系统背后的动机是每个实例节点都可以包含集群的部分（或全部）数据，并为其提供读取和写入服务。每当一个节点收到写入请求时，它都会将更改传播到所有其他需要它的副本的节点。为了处理两个节点对同一个键值写入的情况，任何一个节点的转换在提交之前都会被送入冲突解决算法。鉴于每个站点都是“活跃的”，因此被称为主主。因为每台服务器都可以对其所有数据进行读写，所以分片更容易在算法上实现，并使部署更易于管理。在可用性方面，主主非常出色。如果一个节点发生故障，客户端只需重定向到另一个确实包含数据的节点。只要数据的单个副本处于活动状态，就可以为其提供读取和写入服务。虽然这种方案在高可用性方面非常出色，但其设计在一致性和数据正确性方面存在根本性的问题。因为每个实例节点都可以处理键值的写入（在故障转移场景中也是如此），所以它在处理数据时保持数据完全同步是非常困难的。该方案通常是通过冲突解决算法来调解实例之间的冲突，而该算法对如何“消除”不一致性的决策是粗粒度的。由于该解决方案是事后完成的，是在客户端已经收到有关程序的响应之后——并且理论上已经根据该响应执行了其他业务逻辑——主主复制很容易在数据中生成异常。然而，考虑到正常运行时间的溢价，停机成本被认为大于潜在异常的成本，因此主主成为主要的复制类型。大规模正确性共识和多活可用性主主似乎解决了基础设施面临的主要问题——提供高可用性。但它只是通过放弃事务来做到这一点，这使得系统在强一致性需求的满足上并不那么可信。例如，谷歌在其广告业务中使用了一个庞大而复杂的 MySQL 分片系统，该系统严重依赖 SQL 的表达能力来任意查询数据库。因为这些查询通常依赖二级索引来提高性能，所以它们必须与它们所派生的数据保持完全一致。最终，这个系统变得足够大，开始导致分片 MySQL 出现问题，工程师开始设想如何解决这样的问题：既要有大规模可伸缩的系统，又要提供业务所需的强一致性。主主缺乏事务支持意味着它不应该是一个可选项，因此他们不得不设计一些新东西。最终，他们用这样的一个系统解决了问题，这是一个基于共识复制的系统，既能保证一致性，又能提供高可用性。使用共识复制，写入被提议到一个节点，然后被复制到一些其他节点。一旦大多数节点确认写入，就可以提交。共识和高可用性这里的关键概念是，共识复制是介于同步和异步复制之间的一种机制：您可以指定任意数量的节点来进行同步，但这些节点是哪些并不重要。这意味着集群可以容忍少数节点宕机，而不会影响系统的可用性。（处理被关机服务器流量等的注意事项）然而，共识的代价是它需要节点与其他节点进行通信以执行写入。虽然您可以采取一些措施来减少节点之间产生的延迟，例如将它们放在同一个可用区中，但这需要和高可用性一起权衡考虑。例如，如果所有节点都在同一个数据中心，它们之间的通信速度很快，但如果整个数据中心离线，你的服务也不会独活。将您的节点分散到多个数据中心可能会增加写入所需的延迟，但却可以提高你的可用性，就算整个数据中心都离线了，你的应用也仍然在线。什么是多主可用性？多主可用性要求数据库至少具有三个活动节点，每个活动节点都可以对集群中的任何数据进行读写而不产生冲突。CockroachDB 实现了Google Spanner 论文中的大部分内容（但值得注意的是，它不需要原子钟），包括那些超越共识复制之外的特性，这些特性使可用性变得更简单。为了描述其工作原理并将其与主主区分开来，我们创造了术语多主可用性。主主 vs. 多主主主通过允许集群中的任何节点为其键值提供读写服务来实现可用性，但只有在提交写之后才将其接受的更改传播给其他节点。另一方面，多主可用性允许任何节点提供读写服务，但确保大多数副本在写入时保持同步，并且仅提供来自最新版本副本的读取服务。在高可用性方面，主主只需要一个副本即可同时用于读写，而多主则需要大多数副本在线才能达成共识（这仍然允许系统内部出现部分故障）。显然这些数据库在可用性方面的不同表现源于系统在对一致性方面处理的差异。主主数据库在大多数情况下都会努力工作写入数据，但是不能保证客户端现在或将来能够读取到该数据。而多主数据库仅在可以保证以后可以以一致的方式读取数据时才接受写入。回顾与展望在过去的 30 年中，数据库复制和可用性取得了长足的进步，现在已经支持全球范围内部署，感觉就像它们永远不会不受欢迎。该领域的首次尝试通过主从复制奠定了重要的基础，但最终，我们需要更好的可用性和更大的规模。在这个领域，业界发展出了两种主要的数据库类型：其中主从用于满足那些主要关注快速写入的应用程序，而多主则服务于那些对一致性有需要的应用程序。我们都期待有一天，我们可以利用量子纠缠并转向下一代数据库类型：可管理的分布式数据库。原文链接：​​https://www.cockroachlabs.com/blog/brief-history-high-availability/​

分片变更简介分片变更是分布式数据库中间件（Distributed Database Middleware，简称DDM）的一项核心功能，通过增加数据节点数或者增加分片数，提高数据存储能力和并发支持能力。可解决随着业务增长，逻辑库对应的物理存储空间不足问题。分片变更过程对业务秒级影响，可在不影响您业务使用的情况下快速解决业务在快速发展的过程中针对数据库扩展性产生的后顾之忧与运维压力。数据节点也称DN节点，是分布式数据库中间件服务的最小管理单元，表示DDM下关联的RDS for MySQL、GaussDB（for MySQL）两种引擎的实例。本节以RDS for MySQL实例为例说明分片变更的使用方法。本节内容简单介绍一下DDM分片变更三种变更方式的原理，使用场景和操作步骤。变更原理和使用场景分片数不变，增加数据节点数量此种变更方式不改变当前分片数，只增加数据节点数量。将原数据节点的部分分片平移到新增数据节点上，分片数据进行平移，数据相对位置不需要重新分布，所以变更速度为三种变更方式中最快的一种。推荐您优先使用此方式进行分片变更。适用于水平拆分业务后业务规模快速增长的场景，可在业务初期减少成本。也适用于RDS for MySQL实例无法满足存储空间, 读写性能的场景。增加分片数不增加数据节点数量增加分片数不增加数据节点数量。此种情况分片总数、分表总数、分表规则都会发生变化，数据将重新分布到不同的分片中，广播表分片数量增加。适用于单个物理表数据量过大, 查询性能受到限制, 但是整体RDS for MySQL实例可用空间充足的场景。增加分片数也增加数据节点数量既增加分片数也增加数据节点数量。此种情况分片总数、分表总数、分表规则都会发生变化，数据将重新分布到不同的分片中，广播表分片数量增加。适用于RDS for MySQL实例无法满足存储空间, 读写性能，且单个物理表数据量过大, 查询性能受到限制的场景。分片变更操作步骤1.   在分布式数据库中间件服务，实例管理列表页面，选择目标DDM实例，单击实例名称，进入实例基本信息页面。2.   在实例基本信息页面左侧导航栏，选择“逻辑库管理”选项卡，查看DDM实例逻辑库。3.   在逻辑库列表页面，单击“操作”列“分片变更”。     4.   在“分片变更”页面，按需填选对应参数，单击“测试”连接。分片数不变，增加数据节点数量的情况无需修改“变更后逻辑库总分片数”，只增加RDS for MySQL实例。增加分片数不增加数据节点数量的情况下根据业务数据量修改“变更后逻辑库总分片数”，RDS for MySQL实例数无需改动。增加分片数也增加数据节点数量的情况下根据业务数据量修改“变更后逻辑库总分片数”，同时增加RDS for MySQL实例。5.   连接通过后，单击“下一步”，进入预检查页面。6.   检查完成后，单击“开始分片变更”。7.   分片变更任务提交成功，可在“任务中心”查看进度。若切换策略选择了手动切换，需在“任务中心”点击“切换”将路由切换到新的分片上或者数据节点上。若切换策略选择了自动切换，任务将在设置的切换时间内，自动进行切换。8.   分片变更结束后数据将会重新分布，确认完数据无误后可单击“清理”来清除原RDS for MySQL数据库实例的数据。     9.   请仔细阅读弹窗内容，确认任务没有问题后单击“是”进行清理。10.   清理完成。     

近日，Apache ShardingSphere社区与openGauss社区再度展开合作，Apache ShardingSphere + openGauss的分布式解决方案，突破了单机性能瓶颈，使用16台服务器在超过1小时的测试中，得到了平均超过1000万 tpmC 的结果。一、ShardingSphere + openGauss, 达成1000万tpmC在本次测试中，openGauss社区基于标准BenchmarkSQL 5.0 工具，进行本轮 TPC-C 测试。在单机性能方面，openGauss突破了多核CPU的瓶颈，实现两路鲲鹏128核达到150万tpmC，内存优化表（MOT）引擎达到350万 tpmC。但业务场景及用户体验对于性能的追求是无止境的，尤其在如今海量数据的场景下，追求性能极限仍然是每一款数据库的目标。在此情况下，openGauss团队采用了7台机器运行适配了ShardingSphere-JDBC 的BenchmarkSQL测试工具，连接8台openGauss数据库，并部署了1台 ShardingSphere-Proxy用于数据初始化、一致性校验等维护操作。通过数据分片能力，ShardingSphere使总共8000仓数据（超过800GB）被分散在8台 openGauss节点。在完美Sharding的情况下进行持续超过1小时的测试后，得到了平均超过1000 万tpmC的结果，行业同等规模下性能最好。这极大突破了openGauss现有的性能极限，突破了单机性能瓶颈，满足openGauss在海量数据场景下关于性能、可用性以及运维成本这三方面的诉求。两者的结合，正在持续挑战分布式数据库的性能极限。二、ShardingSphere与openGauss的生态合作Apache ShardingSphere社区自2021年起就开始与openGauss社区展开密切合作。随着业务场景的细分以及数据体量的增长，将数据集中存储至单一节点的传统解决方案，已经难以在性能、可用性和运维成本等方面满足业务需求。诚然，数据分片能力能够解决单机数据库在性能、可用性以及单点备份恢复等问题，但也带来了分布式架构较高的系统复杂性。作为Database Plus理念的提出者和实践者，Apache ShardingSphere旨在构建异构数据库上层的标准和生态，以叠加扩展数据分片、弹性伸缩、数据加密等更多计算能力为基础，站在数据库的上层视角来关注数据库之间的协作方式，以能够合理且充分地利用数据库计算与存储能力。目前，Apache ShardingSphere已经形成了微内核 & 可插拔架构模型，并在此基础上持续完善内核及功能层面的能力，为企业及开发者用户提供更多更灵活的解决方案，以满足在不同场景下的特定需求。得益于ShardingSphere可插拔架构的设计理念，在ShardingSphere中实现对 openGauss的支持无须进行额外改造，只需要基于ShardingSphere各个模块所提供的SPI扩展点，增加对应openGauss数据库的实现。在Apache ShardingSphere 5.0.0 版本，已正式完成对openGauss数据库的支持。双方在合作过程中，通过将openGauss强大的单机性能与Apache ShardingSphere生态所提供的分布式能力结合，打造出了适用于高并发OLTP场景的国产分布式数据库解决方案；除功能层面的合作外，ShardingSphere与 openGauss在性能方面不断磨合，充分利用openGauss内核技术的创新，不断地将ShardingSphere与 openGaus 组成的国产分布式数据库解决方案的功能与性能推向极致，此次关于TPC-C的性能测试，就是双方密切合作的一次典型案例。三、使用ShardingSphere打造基于openGauss的分布式数据库解决方案当然，Apache ShardingSphere的能力不仅有数据分片，还有读写分离、数据加密、影子库等功能，在不同的场景下各项功能既可以单独使用，也可以结合使用，用户完全可以按照自己的需求组合ShardingSphere的能力。Apache ShardingSphere目前提供两种接入方式，分别为ShardingSphere-JDBC和ShardingSphere-Proxy。在业务中使用ShardingSphere-JDBC对数据库轻松进行分库分表以及读写分离等透明化操作，来解决其对于“高并发”、“低延迟” 场景的需求。同时在JDBC的基础上，ShardingSphere提供 Proxy端的部署模式，将数据库部分能力和操作部署在Proxy层面，让用户可以像使用原生数据库一样使用Apache ShardingSphere，为用户带来更加优质的使用体验。因此，建议ShardingSphere-JDBC和ShardingSphere-Proxy混合部署使用，这样可以实现维护友好与性能兼顾的平衡。在openGauss的体系中，Apache ShardingSphere能够通过水平拆分以使 openGauss的计算与存储能力实现线性扩展，性能也随着扩展准线性增长，从而有效解决单表数据量膨胀问题；此外结合业务流量，灵活平滑进行数据节点的扩缩容，智能读写分离，实现分布式数据库的自动负载均衡。 四、后续发展 本次Apache ShardingSphere与openGauss两个社区的合作，向外界展示了开源社区之间的合作潜力。随着应用场景的细化以及数据体量的增长，未来对于数据库性能的要求只会更高。此次合作的成功只是双方构筑数据库协作生态的一个开始，相信ShardingSphere与openGauss这种合作模式，一定会有更加广阔的发展空间。关于 Apache ShardingSphereApache ShardingSphere是一款开源分布式数据库生态项目，由 JDBC、Proxy 和 Sidecar（规划中）3款产品组成。其核心采用可插拔架构，通过组件扩展功能。对上以数据库协议及 SQL 方式提供诸多增强功能，包括数据分片、访问路由、数据安全等；对下原生支持多种数据存储引擎。Apache ShardingSphere项目理念，是提供数据库增强计算服务平台，进而围绕其上构建生态。充分利用现有数据库的计算与存储能力，通过插件化方式增强其核心能力，为企业解决在数字化转型中面临的诸多使用难点，为加速数字化应用赋能。关于 TPC-CTPC-C (Transaction Processing Performance Council Benchmark C)用于比较在线事务处理(OLTP)系统性能的基准测试标准规范，由TPC于1992年发布，目前最新的规范为2010年更新的TPC-C v5.11。TPC-C具有多种事务类型、复杂的数据库和整体执行结构。TPC-C涉及五个不同类型和复杂性的并发事务的混合，事务会实时执行或进入队列延迟执行。数据分布在数据库九种类型的表中，表的数据量各不相同。TPC-C以每分钟事务数（tpmC, transactions per minute C）衡量。虽然TPC-C 模拟了批发供应商的业务，但TPC-C并不限于任何特定业务部门的活动，而是代表必须管理、销售或分销产品或服务的任何行业。来源：openGauss

为推进金融科技安全创新发展，金融科技产业联盟积极组织会员单位进行前瞻性研究，汇集研究成果及实践经验，形成《金融科技发展专报》，供监管部门和产业机构参考。当前，金融等重点行业都在进行数字化转型，而分布式数据库作为数据承载工具，为数字化转型提供了有力的支撑。分布式数据库近年来发展迅猛，在产品成熟度上有了很大提升，但在行业应用和生态建设上仍有很多挑战。本文分析了分布式数据库发展情况、分布式数据库应用的主要问题，从行业应用的角度给出了分布式数据库发展的建议。一、发展情况过去三十年，以金融业为代表的核心信息系统架构依托IOE（即IBM、Oracle、EMC）技术，构建了一套集中、专用、封闭的稳态技术体系。但是，随着互联网及云化时代的到来，企业业务架构产生巨大变化，以银行为代表的金融业需加速构建敏态体系，推动底层数据库的分布式改造和互联网金融业务创新。分布式数据库具有满足行业关键应用的高扩展性、高性能、高可用性及软硬件解耦等特性，是金融等重点行业信息系统数字化转型的基石。（一）产品成熟度提升随着分布式数据库在金融等重点行业的不断应用，产品成熟度得到很大提升。一是新技术的不断发展使得分布式数据库在自身固有的优势领域，如扩展性、高可用等方面进一步强化，已有多个应用在重点行业核心业务中落地。二是国产分布式数据库的性能已经实现了与其他商业数据库持平甚至超越，这在多个大型企业机构产品准入测试及业内国际基准测试（如在线交易场景TPCC、在线分析场景TPCH等）中得到充分证明，可对行业核心业务起到重要的支撑作用。三是更多厂商开始提供对主流国产分布式数据库的功能支持，产品的兼容性取得显著进展。管理控制软件、迁移工具等配套设施逐渐完善，极大地降低了数据库的使用门槛和迁移成本。（二）生态逐步完善一是加快推动分布式数据库在重点行业落地，主流分布式数据库厂商纷纷与众多大型银行、企业等开展联合创新活动，取得了许多突破性的成果。以某厂商的分布式数据库为例，在与大型商业银行的联创过程中，已完成10个以上业务系统的分布式数据库替换，覆盖银行A类到C类全场景业务。二是通过一站式的迁移解决方案，实现以较小的业务改造工作量从传统数据库向分布式数据库转型，迁移成本相对较低。而且使用分布式数据库后，业务系统运行稳定，可靠性和扩展性有所增强，从各项指标看，已基本具备承接Oracle及DB2大机下移的能力。三是分布式数据库相关的行业标准和评价体系逐步健全，对产品发展起到较强的规范引领作用。（三）总体发展情况向好当前国产分布式数据库已经渡过了“能用”阶段，正在迈向“好用、易用”阶段。横向来看，我国分布式数据库的发展基本与国际同步，tpcc、sysbench等性能指标和RTO、RPO等可靠性指标甚至具有优势，在应用领域取得些许领先。纵向来看，以金融业为例，分布式数据库应用取得较大进展，不管是在互联网新核心业务，还是传统核心业务中，分布式数据库行业应用落地数量大幅增加，有逐步替代集中式数据库的趋势。二、面临的主要问题（一）主体改造意愿不强，行业实践尚不充分一方面，原有数据库系统改造为分布式数据库，对用户及应用单位提出了较高的要求。改造所面临的成本问题，以及改造完成后分布式运维实施的复杂性，使得部分金融机构对于全面应用分布式还存在有一定的疑虑，主动改造意愿不强。另一方面，分布式数据库在行业典型应用场景中的落地仍处于摸索阶段。由于部分项目中存在一定的需求定制化，应用解决方案与产品的边界不够清晰，产品的规模化复制能力仍有待加强，行业最佳实践相对缺乏。这些因素也影响了金融机构对迁移采用分布式数据库技术的积极性。（二）分布式数据库的生态建设仍需加强生态建设是当前我国基础软件相对薄弱的一环，特别是对基于自研的分布式数据库厂商而言，虽然在实现技术和产品更加自主可控，但在生态建设方面仍需积极应对投入转化慢、门槛高、市场接受程度低等挑战。一方面，部分产品的技术体系相对封闭，用户无法从市场快速获取合格的开发运维人员，导致业务改造及生产运维仍严重依赖原厂，规模化复制效应较差。另一方面，部分产品的开放性仍有待提升，与其他平台数据互联互通的能力不足在客观上造成了业务“上车容易下车难”的现实困境，增加了用户被锁定的风险。（三）可持续发展的盈利模式需进一步探索我国数据库的发展可以追溯到30多年前，在这样一个相对较长的发展周期内，技术和产品都取得了显著进展，但在产业化方面，知识产权的保护不够充分等诸多问题造成部分参与主体的市场化盈利能力较弱，产业整体规模难以做大。分布式数据库虽然已取得了一定进展，但“池子深才能养大鱼”，如何依托当前政策窗口，真正形成可持续发展的商业模式，还需进一步探讨。三、行业的应用建议 尽管存在一些问题，但我们坚信分布式是数据库未来的发展趋势。如果将分布式数据库和单机数据库类比为“高铁”和“轿车”，因两者定位不同，期望“高铁”像“轿车”一样简单易用既不现实也不科学。所以应避免将分布式数据库的应用简单地理解为对单机或者集中式数据库的一对一替换，而要深入考虑如何充分发挥分布式数据库的技术优势。遵循以上思路，我们对于分布式数据库在金融等重点行业的应用提出以下几点建议：（一）通过技术创新和最佳实践，推动行业应用不断深入一方面，要探索利用人工智能等新技术提升产品服务效能。人工智能技术可实现自动数据分区规划、故障自动诊断和自愈、自动负载均衡、面向混合负载的自调优等功能。目前人工智能技术在分布式场景已经有了一些单点突破，但距离全场景落地、实现整体成本的全面降低还有很长的一段路要走，需要继续加以积极的行业引导，推进技术交流和产业落地。另一方面，需充分发挥好示范项目效应。在金融等重点行业典型应用场景如分布式架构设计、多地多中心容灾等，形成最佳解决方案，并在行业推广落地。在此过程中，提炼出更适合分布式数据库的开发、运维、硬件建设等相关要求，研究制定数据库开发、运维、应用方面的标准规范，提高行业的标准化水平，引导各参与主体规范应用分布式数据库，推进行业转型。同时应约束不必要的定制化需求，减少无序竞争，实现技术聚焦。（二）积极推动生态建设，发挥产业引领作用从软件发展历史看，生态建设是基础软件产业化的重要一环。任何一款商业上真正成功的软件产品，无一不是生态建设上获得广泛认可的成功案例。首先，充分发挥产业联盟桥梁纽带作用，推动产业发展。在行业内积极进行资源引流，逐步提升技术营运效率及影响力，搭建高端对话平台，促进分布式数据库应用方、应用开发方及厂商更好地交流，共同面对分布式转型下的业务及技术挑战，推进行业生态繁荣；加强与分布式中间件、分布式服务框架的合作与交流，通过开源、社区等形式建立广泛的赋能体系；鼓励应用软件厂商全面向分布式架构转型，建立相应的培训体系和检测认证体系。其次，完善技术生态，鼓励引入第三方软件垂直提供商。在运维管控、工具端以及解决方案层面实现更多差异化的平台能力，加厚行业整体的技术底盘；鼓励第三方产品服务化和上下游集成，推进各产品的互联互通，打造良好技术生态，促进行业健康发展。再次，建立基础软件开放生态体系，推动开源建设。应鼓励有研发实力的厂商基于国产开源数据库做发行商，有运维能力的厂商基于优质的国产数据库打造适用于自主可控要求的数据库解决方案。数据库厂商和合作伙伴应基于数据库代码开源、产品开放等形式，使数据库产业从封闭商业生态走向产业共赢的开放生态，共同打造开放的数据库生态体系。最后，进一步推进政产学研合作，加强人才储备。明确人才发展战略，梳理多层次行业人才资源地图。加强厂商与各科研院所合作，推进高校在包括数据库在内的基础软件方面专业投入，鼓励有条件的厂商和高校开展课程共建、实践共建，为联合推进分布式数据库关键技术在理论和实践层面的难点问题攻关储备智力资源。（三）全面拥抱云，开展行业可持续发展的尝试与探索数据库上云已逐步成为产业共识。根据Gartner的统计，到2021年，云数据库在整个数据库市场中的占比将首次达到50%；而到2023年，75%的数据库将会跑在云平台之上。发展云数据库，不仅是对技术和产品的重要升级，更是对数据库良性健康发展的商业模式有益探索，对于实现主体可控、支撑行业长期稳定发展具有重要的现实意义。分布式数据库与单机数据库不同，需要更大的集群规模才能实现资源的更有效利用。分布式数据库与云计算是天然伴生关系，通过云化部署，能够帮助分布式数据库扬长避短，充分发挥分布式数据库在扩展性、资源调度方面的灵活性和优势，在提升资源利用效率同时，显著降低运维成本，实现真正业务价值。一是云化基础设施可以通过智能调度、运维系统高效管理更为丰富的应用，并通过多云及边缘计算将应用扩展到多种场景中。二是软硬协同可为应用提供更好的性能，提升应用隔离性等。三是云数据库和云基础设施结合，如利用云基础设施本身的能力实现数据库的跨数据中心访问等，可使存储具备理解、预处理数据库语义的能力。 基于以上，一是建议扩大云数据库在金融行业的应用规模。云数据库已经在互联网、电子政务等各行业得到了广泛应用，在金融行业的应用及推广也在稳步推进中。应引导重点用户单位与厂商尝试在行业落地云数据库及云平台，鼓励技术共创，共同探索基于现代云平台的分布式数据库运维及业务开发体系。二是建议推进行业云发展以提高行业标准化程度。在满足合规营运的前提下，应实现底层基础设施共享，降低中小用户对于分布式数据库的使用门槛和人才需求，减少重复投资，实现集约化营运，充分发挥分布式数据库的规模化优势。厘清各参与主体运营职责与边界，依托业内现有的成熟云平台技术，形成一个或若干个云技术底座，鼓励传统非云数据库厂商根据自身产品技术特点完成与云平台的对接，最终形成行业的云上产品集市，逐步简化并统一运维及交付界面，降低行业应用门槛，提高行业标准化程度。 来源：发展研究部

年少时期，我们有过许多梦，想仗剑天涯，想修种藩篱，想成为建筑大师，想改变世界……无论梦想最终是否如愿，那段独属我们的青春欢乐时光将永远熠熠生辉。今天，有一款面向青少年的游戏创造了很多虚拟世界，来看看有你年少时的梦吗？迷你创想（深圳）科技有限公司（简称：迷你创想）是一家致力于打造优秀的青少年创意实践平台的企业，其倾力打造的《迷你世界》是一款国产沙盒创意平台，主要通过方块组合自由创造等方式，引导用户在平台上创作虚拟作品。用户、开发者和虚拟场景共同构建了活跃的内容生态，而不断完善的低门槛多样化的强大工具，让《迷你世界》里的“虚拟积木”摆脱了现实的种种限制，用户能够实现各种**行空的场景化搭建。稳定性与弹性两手抓，支持大规模全真虚拟互动《迷你世界》自2015年上线至今，单月月活跃用户已突破1亿，影响力巨大。其旗下虚拟偶像“花小楼”发行的单曲，总播放量超过2亿次。迷你云服是支撑《迷你世界》的服务平台，提供更为稳定的联机服务，以增强用户联机的游戏体验。随着用户剧增和访问量的加大，迷你云服在稳定性和弹性扩容方面面临挑战：稳定性：游戏业务对数据库的稳定性要求极高，系统不稳定将直接导致用户流失。弹性扩容：用户数据过百亿，业务高峰期资源要快速下发升配，以保障玩家体验。面对挑战，一场平台升级之旅就此开启。华为云数据库团队围绕客户需求，针对业务特点因地制宜打造了一套合理高效的游戏数据库方案，从部署架构到分布式设计，基于RDS和分布式数据库中间件DDM提供了高性能、稳定可靠、弹性扩容等能力，提升用户联机的游戏体验，为迷你创想1亿+用户畅玩游戏保驾护航。主备架构优化：使用RDS云盘主备实例，该实例经过海量用户生产系统充分验证，在数据库性能和稳定性方面极具优势，可轻松应对海量访问压力。分库分表改造：采用DDM+RDS做分库分表改造，使用hash算法针对用户的唯一键进行业务拆分，由原先的集中式修改为分布式，均衡负载以提升数据库性能。节点快速扩容：针对客户业务场景，提供DDM计算节点快速扩容、RDS节点快速规格变更等能力，解决客户高峰期资源快速下发问题。华为云数据库全力负责《迷你世界》的底层资源保障，实现了2个月内完成游戏内测至上线全流程，提升了业务上线效率；在游戏运行期间，支撑了海量游戏用户同时在线，为花小楼音乐会等高峰场景的稳定运行提供了坚实的保障。创作开发工具便捷化，驱动创新内容生产作为国内TOP1的沙盒创意类游戏，迷你世界拥有的繁荣UGC生态，迷你世界上有7000万开发者每天在不断地创作新内容。相应的，游戏也需要不断给开发者提供各种工具，让开发者们发挥想象，进行场景、人物的创作。 在内容创作方面，迷你世界推出了自定义模型编辑器用来构建3D角色的动作能力，模型编辑器里搭载了华为终端云的AR ENGINE。基于这个编辑器，玩家可以在游戏中对他人的特定动作进行拍摄，将复杂的三维**动作转化成骨骼动态，上传到游戏中映射到游戏角色。游戏角色可以随玩家做出奔跑，跳跃，转身，挥手的动作，虚实结合的同时大大增加了游戏趣味性。那在这其中，AR Engine简化了自定义动作创作，仅用一台华为手机即可完成所有内容创作，创作时间从天级缩短到分钟级，内容创作难度大大降低，引发了虚实角色创作的热潮。海量内容审核智能化，构建健康游戏环境开发者们每天创造了大量的内容，这些内容高效审核是一个很让人头疼的问题。为了确保内容场景的合规性，《迷你世界》每天需要进行大量且细致的内容审核，对审核准确率和实时性要求极高。为此，迷你创想构建了一套严格的内容审核流程，用户上传内容先经本地词库过滤，后续通过华为云AI智能审核与人工复查，极大提高不良内容审核效率和准确率，为平台用户提供健康、清洁的游戏环境。 技术升级促进游戏内容和玩法创新，相信未来，迷你创想将和华为云一起为游戏玩家提供更流畅、有趣的游戏体验，让我们拭目以待！【重磅活动推荐】开年采购享好价！华为云数据库MySQL、GaussDB(for Redis)18元/年限量秒杀，不限新老用户包年3折起。活动期间还有8000元大礼包、满额赠华为笔记本、0门槛抽奖等多重福利！https://activity.huaweicloud.com/dbs_Promotion/index.html

承载着业务快速发展与数据体量激增的重压，数据库在可用性、扩展性、兼容性、稳定性等核心能力上被投注了越来越多的诉求与期望，面对这些由时代赋予数据库厂商和企业用户的新命题，解法显然不止一种，但思路却终归一致——顺势而为，应变而变。由此，近年来，我们看到了分布式架构带来的降本增效、云原生技术带来的弹性便捷，还看到了国产数据库从外围到核心业务系统应用的渐入佳境。这些看得见的变化仅仅只是开端，那些还未企及的变革，我们或许能从华为云数据库服务总经理苏光牛的本次专访中得到启发。专访过程中，苏光牛多次表现出对国产数据库核心技术、用户适配度的信心和肯定，但他同时也指出，展望未来发展，一款真正的企业级分布式数据库，必定要在分布式事务和分布式存储上取得更大的改进和突破，才能从根本上解决用户的核心需求。此外，在国产数据库后续的大浪淘沙中，生态建设及人才培养将是制胜关键，需要持之以恒的投入。而对于企业用户如何应对海量数据挑战，进行数据库改造和国产化替代，苏光牛一语中的，指出大多数企业的担忧并不在于数据库本身，而在于“变化”，担忧作出变化后带来不可预测和不可控制的风险。他建议企业抛开传统思想，用辩证的思维综合衡量规模、成本、效率、安全、运维难度等问题，致力于将更多精力集中在应用和业务当中。以下内容整理自dbaplus社群联合发起人、新炬网络董事/副总经理程永新与华为云数据库服务总经理苏光牛的独家对话，希望能同时给到国产数据库厂商和企业用户更具体、更详实、更适用的数据库应用策略与发展建议。新 创 访 谈受访嘉宾：苏光牛，华为云数据库服务总经理，负责华为云数据库业务的战略制定与发展，负责华为云数据库服务产品与解决方案的研发、运营和运维等。在数据库领域、IT基础设施、虚拟化和底层软件具备丰富的开发经验和团队管理经验，长期负责华为公司IT基础设施的研究与开发、虚拟化、数据库等解决方案的交付。采访者：程永新，dbaplus社群联合发起人，新炬网络董事/副总经理，拥有超过20年IT行业管理经验，计算机本科、工商管理硕士及EMBA。何为真正面向未来的分布式数据库?——分布式事务+分布式存储齐头并进，HTAP是趋势但并非万能程永新：作为一种新兴技术产品，分布式数据库的成熟度还有待提升，很多人依然保持观望态度，尤其是应用于核心系统，对此您有什么建议？苏光牛：从技术角度以及企业发展来看，随着业务的快速发展和数据量的爆发式增长，传统数据库在容量、扩展性、可用性等方面都遇到了巨大的挑战，只有分布式才能解决这些问题，才能满足企业的核心需求。所以在技术层面，分布式数据库是大势所趋，是未来。从产品创新的角度来看，传统数据库以Oracle为代表，在集中式架构上已经做得非常成熟和完善，而基于企业客户当前的真实需求，分布式架构正是时代给予数据库产品的新命题。从商业落地的现状来看，业界要对分布式数据库有信心，要给分布式数据库更多机会。以华为云GaussDB为例，当前已经在1500+政企客户规模商用，其中包括对数据库产品综合能力要求最为严苛的金融行业，GaussDB已经在国有6大行中的4家商用，并且应用在其核心业务系统中。经历更多核心业务系统的打磨，产品能力也将进一步得以完善成熟。程永新：分布式数据库目前有多种技术路线在同步发展，不同人口中的“分布式数据库”可能代表不同的技术栈，主要被归纳为分布式中间件、分布式事务、分布式存储这三大类。您认为未来的趋势是这种多样化持续发展，还是会最终统一为一种形态？或者说怎么才是真正的分布式数据库架构？苏光牛：分布式中间件是介于上层应用和数据库之间的一层架构，或者说更贴近于应用层。实际上，分布式中间件会造成应用复杂度的提升，而通过底层数据库来实现分布式，应用开发者只需要关注数据库提供的API和开放能力，降低了应用的复杂度，企业可以将更多资源投入到应用以及业务本身。我们认为真正的分布式数据库应该是分布式事务与分布式存储的深度融合，这是分布式数据库的典型特征。首先，分布式事务最大的特点就是解决性能问题，分布式数据库要确保高可用必须在分布式事务上进行更多的改进；其次，分布式存储也要重点突破，要做到在存储上具备一定的计算能力，让存储去理解一定的数据结构。华为云GaussDB在分布式事务以及分布式存储层面做了大量优化和创新，在分布式事务层面提升性能和数据一致性；在存储层面充分利用存储的计算能力，创新性地推出了近存储数据处理（NDP, Near Data Processing），并结合并行处理（PQ, Parallel Processing），进一步提升了分布式数据库性能。程永新：不少企业在经历了数据库拆分后，随着对数据一致性和实时性要求的进一步提高，发现对数据库整合的需求越来越强烈，最终又想回到集中式架构的怀抱。您认为企业该如何避免盲目跟风为了拆而拆，重新审视数据库架构选型的合理性？苏光牛：相比较集中式数据库，分布式数据库的扩展性、可靠性、可用性以及灾备能力的增强，可以给企业的运维以及系统设计带来更大的弹性。但这不意味着一个分布式数据库就可以满足企业的所有诉求，而是要从业务、安全、容灾、性能以及运维角度出发，综合考量，选择适合自身业务和应用场景的数据库，设计合适的数据库架构，不能为了拆而拆。程永新：说到合还是分这个话题，不得不提到近年来许多国内外数据库厂商都在聚焦的HTAP，您如何看待这种可同时支持OLTP和OLAP的混合负载能力？会是未来数据库主流发展方向吗？苏光牛：HTAP是未来数据库发展的一个方向，一个数据库同时满足企业对OLTP和OLAP的诉求，保证了查询和分析结果的实时性，更好地支持业务决策的实时性和敏捷性，但是需要注意以下三点：分布式数据库是实现HTAP的最佳方案；HTAP有一定的适用范围，是在TP的基础上增强了其AP能力，支持对查询分析有时效性诉求的业务场景。另外，一个数据库不可能存储企业所有的数据；从企业的业务角度出发，复杂决策需要汇聚不同来源、不同类型的数据在一个集中点，需要通过专业的数据仓库、数据湖或者湖仓一体的方案来构建专业的数据分析系统。数据库迁移的风险防控与选型建议 ——兼容Oracle是个移动靶，还容易把自身产品做成“四不像”程永新：更换数据库存在不少挑战，一是新产品、新架构带来的风险，二是迁移改造中的不确定性，三是产品本身在稳定性上潜在的问题。应对这些情况，有没有较为稳妥的迁移方式？苏光牛：数据库是底层软件，上面是应用和中间件，下面是操作系统和硬件，所以数据库尤其是异构数据库的替换是一个非常复杂的系统性工程，在替换过程中会遇到各种各样的问题，这些问题的解决不是靠某个工具或某个人就能搞定的，比较稳妥的方式是把整个迁移过程细化、分解，针对每个阶段都制定详细的方案并做好验证，能工具化的一定要工具化，因为工具出错的概率比人要低很多，不能工具化的一定要找对应的专家来解决，过程中做好风险管理，及时闭环。为了帮助客户迁移，我们提供了多种工具，比如：数据库迁移工具UGO，实现异构数据库对象和应用迁移，语法的转化率达到90%以上；提供14类核心对象的采集，是当前业界最全的对象采集工具；数据在线迁移工具DRS，能帮助客户实现数据的在线迁移、数据校验；流量回放工具，可实现对源端业务流量抓取，然后在目标端进行回放能力，确保迁移后业务的稳定性和性能。程永新：在不少“去O”项目中，为了尽量减少迁移工作，会选择兼容Oracle语法、甚至存储过程的产品。此类产品确实减少了迁移工作量，但从长远角度来看会是一个很好的选择吗？苏光牛：的确，现在有很多数据库厂商为了减少迁移工作量，主动或被动选择了兼容Oracle这个策略，但显然这不是最好的选择。首先，兼容Oracle是一个移动靶，永远不可能做到100%兼容，因为Oracle本身也在演进；其次，做Oracle兼容很容易把自己的产品做成一个“四不像”，今天兼容Oracle，明天就有可能兼容DB2或SQL Server，这么做反而会牺牲掉自身产品原生设计的优势；另外，Oracle兼容也可能存在法律风险，尤其是兼容Oracle特有的语法，要慎重。程永新：站在用户的角度看，目前各分布式数据库厂商在产品技术实现上存在较大差异，并且没有通用的使用标准，您有什么选型建议？苏光牛：我认为在产品选型时应该考虑以下几个方面：厂商层面：产品是否是长期战略投入以及具备规模商用能力，是否有完整的产业生态、未来人才储备，确保厂商有能力长期服务客户并保证市场人才供给；技术层面：产品的成熟度如何，是否经过核心商业系统对高可靠性、高可用性、安全性的打磨和考验，是否有规模应用案例；外围工具：是否提供数据迁移、容灾备份，以及完善的管理监控工具来帮助客户更好地使用和管理数据库；生态开放：数据库能力开放，客户不被封闭生态所绑定。云化及国产化的势在必行——拥抱云架构，借助国产数据库优势，应变而变才能乘势而上程永新：数据库上云是大势所趋，但鉴于中国国情等特殊原因，金融、电信、政务等行业的数据不可能完全搬到公有云上，混合云将成为中国企业用云的主流模式。然而由于不同的云资源壁垒难以打通，各业务系统架构也缺乏规模效应，会使混合云运维与运营更加复杂，稳定性、数据一致性等问题得不到保障，可有较好的解决方法？苏光牛：数据库上云已经是业界共识，即使客户因为特殊原因无法将业务部署到公有云，最终也会采用混合云或者云化架构。如今，我们面临的是愈加庞大的IT系统场景，如果企业没能及时转变到云架构的设计思路，依然用传统思维去建设和应对大规模复杂IT系统，当遇到机器故障时就很容易酿成事故。混合云或云架构的弹性和易用性给企业运维带来的好处是显而易见的，但既然选择这种特殊方式，就免不了要接受一定的运维成本，但相对于企业自行搭建一套负载均衡等平台，无论是从人员成本、运维成本还是使用难度来说，整体下来其实都比用公有云要高。为了满足不同的客户诉求，华为云数据库以公有云和华为云Stack形式提供服务，客户可以选择适合业务模式的部署形式；而且云上云下版本、技术栈、API保持一致，客户可以在合适的时间在混合云和公有云之间迁移。程永新：圈子里不乏这样一些声音，说目前市面上不少国产数据库都是由MySQL和PostgreSQL魔改而来的，倒不如直接用MySQL或PostgreSQL。对此您有什么看法？苏光牛：这是一个产品应用场景的问题，开源数据库产品和自研产品针对的应用场景和客户诉求是不同的。直接使用开源数据库产品，要求企业自身具备一定的人才储备和技术能力，熟悉产品的使用场景和技术细节，可以在产品出现问题而社区没有修复的情况下，有能力解决问题。开源数据库对于初创期的数据库厂商来说，的确是一个很好的范本和参考对象，但要作为一款企业级数据库推出市面，真正满足企业实际需求，其实需要做很多非功能性的属性，包括性能、可安装、可用性、易用性、安全性等，这些非功能性需求对数据库来说占比非常高，但开源产品是不具备的。在华为云上，我们提供了不同的数据库服务来满足不同应用场景的客户诉求：华为云RDS for MySQL、RDS for PostgreSQL、DDS文档数据库服务（文档类型Mongo），基于开源打造的数据库服务，主要面向数据规模较小、对性能要求不高的业务场景，提供极致性价比的解决方案。华为GaussDB系列，立足创新与自研，一方面拥抱并兼容MySQL等生态，另一方面打造开放的openGauss生态，主要面向政企客户，满足对高性能、高可靠、高安全以及服务能力等方面的诉求。 程永新：如今，数据库国产化替代已不再停留于能不能的问题，而是对谁能交付得更快、投入成本更少、安全性更高的考量。您认为目前国产数据库与Oracle为代表的国外商用数据库还存在哪些差距？接下来国产数据库该如何在技术、生态等层面消除用户的后顾之忧？苏光牛：首先，以Oracle为代表的传统数据库产品，经过多年发展和积累，产品能力完善，生态成熟。与之相比，目前国产数据库在特性上仍然存在不少差距，但在实际的企业使用中，已经足够满足包括接口上、数据迁移上、应用改造上等大多数需求。而且随着业务的增长，企业对数据库的可用性、可靠性、性能以及扩展性提出了新的要求，传统数据库已经无法满足，而云原生、分布式，则更适合企业当下及未来对数据库的诉求，这也是以GaussDB为代表的国产数据库的优势所在。在技术层面，其实国产数据库的性能已不是问题，当然也不能盲目追求性能数字，很多特殊的优化手段在实际应用中根本无法使用，多数企业更多的担忧其实在于变化，担心变化后带来不可预测和不可控制的风险。所以正如我前面所说，业界要给国产数据库更多信心和机会，只有经历过核心系统的不断打磨，才能促进产品技术能力的进一步成熟。在生态层面，以GaussDB为例，我们通过产学研用全面结合，为业界培养未来数据库人才，同时为开发者提供全方位的资源支持，上线GaussDB从初级到专家的培训认证，以及与合作伙伴联合开发解决方案，从全产业链打造生态，确保为用户提供可靠的、持续的服务和支持。以开源打造数据库根技术——开源需要持之以恒的投入，国产数据库亟需人才的培养程永新：开源是近年数据库领域非常火的一个词，2020年华为就开源了openGauss，对于这种投入巨大且短期内较难收益的举措，你们是出于怎样的考量要和开发者、伙伴一起共建openGauss开源社区？苏光牛：华为一直积极参与开源社区，是多个全球顶级开源项目的重要成员，在开源领域贡献排名国内公司第一。说到数据库，华为在2001年就开始做数据库，当时是为了满足运营商业务需求，做的是一个内存数据库。从2011年开始战略投入，荟聚全球7大研究所、1000多名数据库专业人才，结合华为软硬全栈协同方面的优势，先满足华为自身极度复杂业务场景的需求。在当前的大环境下，中国需要发展自己的数据库根技术。基于华为多年参与、支持开源社区的积累，我们将GaussDB单机主备能力开源，与合作伙伴、客户、开发者共建、共享、共治openGauss开源社区，共同促进国内数据库行业的快速发展，打造数据库根技术。程永新：在开源至今一年多的时间里，开源给你们带来了什么？苏光牛：数据库是一个生态型的产品，只有把生态做起来，才能形成共赢的局面。从2020年6月开源到现在，openGauss社区吸引了2500多开发者、30000多用户、20个兴趣小组、6个城市用户组，12家合作伙伴基于openGauss发布了自有品牌数据库，100家头部企业加入社区，我们看到了一个蓬勃发展、越来越活跃的openGauss开源社区。程永新：您如何看待国产数据库相继开源的热潮及未来发展？苏光牛：开源将会促进国产数据库的快速发展，对整个数据库行业以及数据库从业者都是有利的。但是开源需要真正的开源，不是简单的开放代码，而是需要长期的、大量的人员和资源投入，与业界共建社区、不断改进产品。长远来看，只有像华为这样将开源当作业务来做的才得以促进开源的持续发展，获得生态的成功。纵观当下国产数据库百花齐发的态势，未来要想真正将数据库产品做大做强，我认为核心在于人才。因为数据库是一个对工程化要求特别高的东西，对代码精细化程度有非常高的标准，如何把成熟的理论在代码层面实现出来，既满足高可用，又满足高性能，还要满足数据一致性等基本要求，并不是一件简单的事情。所以国产数据库想保持向上的势头，未来发展必须注重数据库内核人才的引入和培养。

分布式数据库中间件（Distributed Database Middleware，简称DDM），是一款分布式关系型数据库中间件。兼容MySQL协议，专注于解决数据库分布式扩展问题，突破传统数据库的容量和性能瓶颈，实现海量数据高并发访问。分库分表是DDM的一个重要特性，依据拆分算法与拆分键将数据分散到多个RDS实例存储，分散风险，影响面降低至1/N，支撑业务爆发式增长。本节内容简单介绍一下如何合理制定分片策略。如何选择拆分算法拆分算法即将逻辑表中数据拆分到多个数据库分片上的算法，DDM支持hash和range两大类拆分算法。hash类：     将数据均匀分布在各个分片。     适用于SQL查询条件使用“=”、“IN”之类运算符相对较多的场景。range类：     将数据表内的记录按照算法元数据的取值范围进行分片存储。     适用于SQL查询条件使用“>”、“<”、“BETWEEN ... AND ...”之类运算符相对较多的场景。拆分算法的使用，需要结合业务查询场景进行评估，以选择合适的拆分算法，提升DDM效率。如何选择拆分键拆分键是在水平拆分逻辑表的过程中，用于生成路由结果的表字段，指定表字段后，可以进一步选择日期函数，也可以手动输入“日期函数(字段名)”，数据表字段必须是日期类型（date、datetime、timestamp），日期函数适用于需要按时间（年、月、日、周及其组合）对数据进行拆分的场景。当数据表之间存在E-R关系时，可以制定相同的分片规则，各数据表分别选择有关联关系的字段作为拆分键，这样各表中有关联关系的数据将会存储在一个分片上，避免数据跨分片JOIN操作。如客户表、订单表与订单明细表，在创建拆分表时，建议都选取客户ID作为拆分键。DDM根据拆分键值与拆分算法计算路由结果，对拆分表的数据进行自动水平拆分，分发到数据分片中。选取拆分算法与拆分键一般遵循以下规则：尽可能使数据均匀分布到各个分片上。该拆分键是最频繁或者最重要的查询条件。优选主键作为拆分键，因为主键作为查询条件时，查询速度最快。拆分算法和拆分健的使用说明与适用场景拆分算法hash类range类拆分键表字段表字段+日期函数表字段表字段+日期函数详细说明根据指定的表字段将数据平均拆分到各个分片上。根据指定的表字段+日期函数将数据平均拆分到各个分片上。表字段必须是日期类型（date、datetime、timestamp）。将数据表内的记录按照算法元数据定义的规则将数据拆分到指定的分片上。根据指定的表字段+日期函数将数据按照算法元数据的规则将数据拆分到各个分片上。表字段必须是日期类型（date、datetime、timestamp）。适用场景适用于需要将数据均匀分布的场景，例如：银行类客户业务应用，业务逻辑主体是客户，可使用客户对应的表字段（例如客户号）作为拆分键，详情参见如下示例。需要按时间（年、月、日、周及其组合）对数据进行拆分的场景，例如：游戏类的应用，可使用玩家对应的表字段（例如玩家注册时间）作为拆分键，按日、月、年等函数分片，方便统计和查询某日、月玩家的操作数据，帮助游戏厂家做大数据分析。适合范围类操作较多的场景，例如：电商类应用，如果业务场景是围绕商家做活动进行，业务逻辑主体是活动日期，可使用活动日期对应的表字段（例如活动名称、日期范围）作为拆分键，方便统计某周期内销量等情况。例如日志分析场景，日志系统中可能包含各类复杂的信息，这时您可以选择时间字段作为拆分键，然后对拆分键使用日期函数拆分。为了方便日志清理和转储，采用range拆分算法，对时间字段用日期函数转换成年，表示按年存储到各个分片上，详情参见如下示例。 

如今，我们正处于数据库从互联网基础软件转变为社会数字化基础软件的时代，在传统集中式数据库已不能满足大规模数据承载需求与高并发处理需求的形势下，基于海量数据场景应用而生的分布式数据库迎来应用热潮。据IDC调研，目前约26.8%的企业级市场用户部署了分布式数据库，超过90%的企业认可分布式数据库部署后的效果。在分布式数据库中，主要有三类解决方案，一类是以中间件+单机数据库为主的分布式数据库，下层的单机数据库提供存储和执行能力，在多个单机数据库上封装一层中间层，以统一分片规则管理及处理分布在不同数据库节点的数据，并提供SQL解析，请求转发和结果合并的能力；第二类是原生分布式数据库，在架构设计之初，便根据分布式一致性协议做底层设计，因此，数据的存储、查询、处理都天然具备分布式特性，各数据节点提供对等的读写服务，组成统一的集群对外提供服务；第三类是通过构建分布式共享存储实现扩展，采用非对称计算节点，大部分公有云数据库都属于此类。在本文中，我们重点说说前两类。　　无论是分库分表中间件还是原生分布式数据库，目的都是解决数据容量问题，但实际上，二者的实践路径有本质区别。那么具体而言，分库分表中间件与原生分布式数据库的区别在哪，各自有哪些优劣势？原生分布式数据库与如今热炒的云原生数据库又是什么关系？CSDN采访了OceanBase CTO杨传辉（日照），以下为他的解读。一、原生分布式数据库与分库分表中间件的区别       区别一：是否依赖中间件　　分库分表中间件大多采用中间件来补充分布式的能力，也就是说在各数据库节点上，架构一层事务处理和查询优化的中间层。在这套系统中，各个数据库可能是同构型，也可能是异构型，将各个数据库组合在一起，是一种松耦合的方式，会暴露不少问题，如事务处理能力、高可用受限等。　　原生分布式数据库，由各个同构型的数据库组成，每个数据库节点天然具备分布式的能力，无需借助额外的中间件，也无需用户关注集群实现细节，是一个紧耦合的系统。由此可见，原生分布式数据库的能力有很大发展空间，但其开发难度也较大。 　　区别二：是否依赖分库分表　　弹性扩容能力是考验分布式数据库面对流量高峰或极端场景时能否持续稳定运行的重要因素。比如在交易场景中，高峰时每秒可产生一百万笔订单，每笔订单对于数据库而言都是一个业务，需要数据库做扩容处理，其中的关键点就在于是否采用分库分表的方式，这对扩容能力有很大制约。　　分库分表中间件的分片规则基于算法提供，下层计算节点之间并不会进行数据交互，扩展下层计算节点的时候就无法按需扩展。通过分库分表将原有机器划分为一百份，每台机器处理一笔业务，而如果想进一步拆分为一千份、一万份就很难做到了。这个过程还需要停机，由开发人员手动拆库，效率低，且弹性有限，但好在对数据库的依赖也低。　　原生分布式数据库中设有分区表的功能，可以将中间件所拆分的一百份，每份再拆一百份，总共一万份，且每一份都至少能在一台机器被处理。在此过程中，系统自动扩容、按需扩容，不受数量和规模的限制，且无需人为干预。　　分库分表中间件的核心理念是让多台服务器协同工作，完成单台服务器无法处理的任务，尤其是高并发或者大数据量的任务。而原生分布式高可用设计能够在普通服务器上实现无限水平扩展，通过添加低成本服务器即可扩展算力，提升数据库集群的整体性能。　　区别三：是否实现数据强一致　　分库分表中间件由于其架构特性，本质是将把单机数据库进行二次处理，在数据一致性、全局事务能力、全局MVCC、副本控制、高可用等方面存在短板，需要有针对性增强。　　大多数原生分布式数据库是在分布式KV的基础上发展出SQL计算引擎，将分布式存储、事务、计算有机的结合在一起，数据由系统自动打散并存储多个副本，通过一致性协议保证多个副本和事务日志的一致性，对分布式事务、全局MVCC等支持更为彻底。 　　区别四：能否实现业务平滑迁移　　众所周知，数据库对企业与机构来说是心脏所在，尤其是金融、能源、社保、政务等行业。当数据库已达到能力天花板或不足以满足企业需求时，企业也会考虑“换心”来维持活力。此时数据能否平滑迁移至新的数据库，保证数据的正确性且不丢失、保证业务不受影响是重要考虑因素。　　分库分表中间件由于本身不具备分布式的能力，进行数据迁移时需要对业务做改造。才能使数据库正常运行。而且，由于每张表只能有一个分片规则，业务建模需要重新规划，业务代码也要相应修改，改造成本高。　　而原生分布式数据库因其高兼容和透明性的优势，可以在不改业务代码的情况下，支持数据迁移，并保证数据库正常运行，不损害性能。因为整个分布式结构是包裹在集群内部的，应用对此无感知，对应用来说，与使用集中式数据库没有区别，所以不需要分布式改造。此外，由于原生分布式数据库对硬件依赖少，在云时代，可以灵活进行混合云和多云部署，以及跨多云的数据管理，为企业提供了更多且更方便的服务选择。　　总的来说，分库分表中间件通常是在单机数据库之上构建数据分区的特性，支持扩展能力。因为基于传统的单机数据库，相对来说比较稳定，用户更容易上手。但缺点也很明显，其底层不具备分布式能力，只是在宏观架构上加补丁，不断增加机器冗余和系统复杂度，能力天花板较低。原生分布式数据库虽然综合表现更佳，而且支持调整底层模型，优化各方面的能力。但由于技术发展时间相对短，一些产品解决方案成熟度待提升。从眼下的行业发展趋势来看，随着技术的不断成熟，原生分布式数据库正在成为主流，大量企业与组织开始着手对传统数据库进行升级。二、原生分布式数据库和云原生数据库的区别       云原生数据库天然生长在云环境中，而且都是分布式的。云原生数据库有两种分布式的方式，一种方式是计算存储分离，例如，计算部分采用集中式数据库，存储采用远程的、分布式的文件系统。另一种方式是，计算与存储都采用分布式。　　而原生分布式数据库既可以部署在本地或私有云，也可以部署在公有云上。比如OceanBase，除了支持计算存储分离的分布式之外，它还支持计算系统的分布式扩展，提升系统的处理能力。当它被部署到云上，就成为了云原生分布式数据库，提供与本地相同的用户体验。　　此外，原生分布式数据库部署灵活的特性意味着不被特定硬件和服务绑定，能够做到机房部署、任意公有云部署，甚至集群内跨多基础设施的混合云或多云部署，被称为“多云原生”。三、总结       分库分表中间件在十多年前顺应互联网时代而生，相比传统集中式数据库，它确实帮助很多企业解决了降本增效的根本问题，顶住了更多的服务压力。如今十几年过去，新的数据库处理需求使传统分布式数据库的不足与限制暴露无遗，适应新环境需求的解决方案，即原生分布式数据库应时而生，逐渐变得炙手可热。未来，原生分布式数据库结合云原生，将发挥更大的能力。       而企业在选择数据库时，不管是分库分表中间件还是原生分布式数据库，亦或云原生分布式数据库，首要考虑数据的正确性。怎么判定数据库是否能够保证数据正确性呢？第一，这款分布式数据库经过了核心业务场景的检验，比如在金融、大促等海量、实时的数据处理场景中，持续稳定。第二，该分布式数据库已经在行业中证明自己，如TPC-C（主要测试联机交易处理能力）、TPC-H（检测系统处理复杂查询分析能力的多个方面）等数据库行业公认的测试，以及行业企业的良好口碑。       此外，每个企业需要根据业务特性选择数据库的功能特性，可以视情况做具体取舍。如今，分库分表中间件面临的挑战愈发巨大，具备一体化架构的原生分布式数据库正成为不少企业试用并应用的对象。其兼顾集中式与分布式的双重技术优势，将多种负载能力融合于一套数据库中。一方面具备强兼容性，能够兼容传统数据库如MySQL、Oracle的功能与单机性能；一方面具备强扩展性，当机器容量不足时，只需扩展机器，就能够解决大规模的需求。重要的是，一套系统便可处理OLTP（联机事务处理）与OLAP（联机分析处理）的需求，并保证事务的ACID（原子性、一致性、隔离性和持久性），加之本地部署与多云部署的灵活特性，也更适用于社会数字化时代。文章来源：CSDN