关于国产数据库的46个问题

近年来，国内数据库已成为一个热门话题。越来越多的公司考虑使用国内数据库产品。twt在社区互动中，发现有很多相关的讨论，关注度也很高。我特别提取了我回答的一些问题，这也是我个人对几个热点问题的看法。

在做出适当的选择之前，需要做以下准备:

1. 业务画像

在业务侧制作数据库肖像，包括但不限于以下维度：

• 业务指标：使用方法、使用特征（在线用户、峰值用户、并发用户等）、重要级别和可用性要求。此外，还应评估未来的发展。
  

• 系统指标包括应用系统来源、技术栈、语言开发、系统拓扑、数据库交互等

• 数据库指标包括数据规模、访问特征、物理环境、软件环境、数据库拓扑等

• 操作特点：场景分类（TP、AP、混合)、架构分类、数据规模、数据特征、计算规模、事务一致性、可扩展性、高可用性、应用耦合等

2. 产品测试

测试数据库产品，形成对产品的统一理解。这包括对数据库核心、管理、开发、安全等能力的评估。这方面可以参考我之前分享的分布式数据库评估标准。

3. 其他因素

除此之外，还应考虑企业内部的一些因素，如成本、运维、开发改造等。

综合考虑上述因素后，才能做出相对合理的选择。

• 性能问题需要仔细考虑。如果只考察个人表现，分布式数据库很可能不如传统的单机数据库或集中式数据库。其分布式架构在原理上存在一些先天缺陷，不适合要求极端性能的场景。

• 分布式数据库的优势在于扩展系统的整体吞吐量，可以承载更多的业务量。因此，原则上，扩展后性能不会提高。当然，在扩展分布式系统后，对数据库进行更多的拆分将有助于提高单个执行效率。在这种情况下，性能将得到提高。

基于以上，在应用架构设计中，应充分利用分布式数据库的数据分布特性，做好业务单元化工作。优化效果通过在较小的数据单元中完成。

分布式数据库组件较多，大致可分为数据节点、计算节点算节点和控制节点。其中，计算节点一般为无状态，故障后可切换自动恢复；控制节点一般采用自身的高可用性保证，问题会主动愈合；数据节点问题更重要，因为上述数据。我理解这个问题主要与这个角色相对应。对于数据节点，不同分布式数据库产品的底部实现大致可分为两种情况：

? 1.主从复制模式基于单机数据库

? 2.基于多数派协议保证的多副本模式

无论是哪种模式，当出现故障时，都会自动选择和切换，从而实现高可用性。目前，大多数产品都可以在同一时间实现AZ、同城跨AZ独立切换，对业务没有感觉（业务需要实现错误重试机制）。一般建议人工干预，而不是自动完成切换。

就我个人而言，我认为两者之间没有平衡关系。一般来说，一致性要求来自业务，很难做出业务选择。在有明确一致性要求的情况下，尽量做到最好。

分布式改造的必要性主要来自几个方面：

• 业务驱动(需要扩展数据规模、计算能力不足等)

• 政策驱动(监管机构需求明确)

• 技术驱动（为适配技术栈革新）

• 管理驱动(从统一管理的角度考虑)

在这里，我们需要权衡分布式转型带来的投入产出比和相应的风险评估。个人建议中小银行的稳定业务不需要分布式转型，需要更严格的评价。

目前还没有统一OLTP测试标准的原因是银行的业务也不同，很难找到统一的标准。一般的做法是找出一些有代表性的业务，简化和精炼，形成测试case。通过不同的测试case组合，形成满足某个业务的测试集。

目前还处于早期阶段，趋势发展不太明朗。个人有以下判断:

1.多技术路线将长期共存

2.未来云会统一，但周期会很长

3.MySQL、PG它将成为事实生态标准，适应所有产品

目前，没有统一的国家和行业标准，有条件的企业正在制定自己的标准。根据以往的工作，有必要梳理选择测试的许多评估维度和详细指标。这里有很多工作量。以下是我最近发布的一些内容：分布式数据库评估维度分析

存算分离取决于具体解决的问题。它最初是由云制造商提出的，旨在解耦资源，从而实现不同资源的分层扩展。看这个特点，或者看它背后的好处，是否是他们自己的关注；否则就没有多大意义了。

国内一些金融企业在这方面经验不多，自主搭建混沌测试平台，一些厂商(如PingCAP）也可以尝试开源混沌测试平台。

高可用性方案不同于每种产品。一般情况下，在同城双中心异地单中心的情况下，当同城某AZ当出现问题时，它不能自动切换到同一城市的第二个AZ，第三个需要引入AZ，满足仲裁要求。当然，有些可以写下切换逻辑，但不是标准的切换过程。因此，一般建议在同一城市使用3AZ，满足大多数选举，可以实现自动切换能力。一般不建议参与其中，毕竟有很长的延迟。

我在这方面没有太多的经验。据了解，如果仅从吞吐量来衡量，分布式数据库的能力一般高于传统数据库。当然，前提是批处理部分可以有明确的单元拆分，充分利用并行能力带来批处理的好处。

与传统的单机数据库或集中数据库相比，分布式数据库存在许多差异，因此在开发场所避免有针对性的数据库更为重要。常见点包括：业务规模SQL复杂性、分布式事务、DDL变更等。处理的基本原则是3B原则，即避免Big SQL、Big Transaction、Big Batch。此外，分布式数据库中的变化，无论是架构上的(如扩展)还是结构上的(如扩展)DDL）等。

这个话题有点大，请参考我的总结。

DBA定位、突破和职业发展

分布式数据库通常从软件层面保证可用性，如采用多副本机制，通常不采用基于硬件的传统可用性方案。

通常不会根据每个应用程序选择合适的数据库，技术堆栈可能太不同了。建议根据公司的业务场景，将其收敛到多种类型，然后选择每种类型2~3产品。选择多种产品的原因是为了避免制造商的绑定。然后根据每种场景制定开发规范(取2~3以产品功能交集为标准)。

1.如果同一城市出现问题，只要应用支持错误重试，一般分布式数据库可以实现自动切换，对应用有瞬时影响。

2.对于异地情况，一般不能自动切换(不推荐自动)，还需要人工仲裁判断是否切换。

替代Oracle或DB2产品可分为几种类型：

1.核心业务

这类业务的特点是数据规模大、并发性高、延迟要求低，但数据库的使用场景相对简单。通常，这种方法可以使用业务侧单元化 国内图书馆模式。该方法对图书馆的要求相对较低，可供选择。

2.中型业务

这类业务的特点是数据规模中等，数据库使用复杂。这种方法相对难以很好地替代。一般建议的做法是重建。当然，这里需要考虑的改造成本相对较高。可以考虑的选择范围是NewSQL系列产品。

3.小型业务

这类业务的特点是数据规模小，复杂性不低。这个系统数量多，可以考虑使用正确Oracle/DB2兼容性高的产品。例如，许多产品来自PG国内衍生产品或部分数据库产品。

迁移可分为三种情况：

• 物理迁移：基于数据库的日志CDC以这种方式进行。采用这种方式的商业产品很多，比如国内的DSG、英方等。

• 逻辑迁移：基于数据的迁移类似于通过窗口提取数据来实现迁移。有许多商业和开源产品使用这种方法，更典型sqoop。

• 应用程序迁移：应用程序侧需要自行才能解决迁移问题。

库内测试的问题一般不是通过数据库端实现的，而是通过互联网通常使用的阴影库解决的。还有一些开源产品(如shardingsphere），通过在上层模拟数据库的统一入口，内置此能力，内置分流和限流策略，完成压力测。

分布式数据库的成本来自几个方面：

• 软件授权费：这部分比较有优势，Oracle原厂成本较高。

• 软件服务成本:这部分相对于国产仓库来说比较高，因为成熟度不够，需要大量的人力投入，还没有形成成熟的服务生态

• 硬件采购成本:这部分布式国产仓库比较高，因为涉及的组件比较多，需要消耗更多的机器资源。

• 日常维护费用:这部分国产仓库比较高，因为需要重建团队，人工成本比较高

NewSQL同步主要取决于其结构：

• 基于分库分表架构，一般很难提供全局CDC能力只能通过底层数据节点的数据同步，不能满足整体一致性的要求，存在一定的缺陷。

• 一般可以提供基于原生分布式架构的CDC能力（如TiDB），能满足上述需求。

这部分没有一定的规定。一般来说，国内分布式数据库的成熟度差异很大，需要根据各自不同的数据库来考虑。建议每次使用3~5一个，配置一个DBA，可长期过渡5~10个库一名DBA。

主要缺陷取决于不同数据库的结构，这是非常不同的。

• 分布式事务，全局一致性

• 全局日志，数据唯一性

• 同城&异地高可用

• 生态功能(如研发)

• 控制能力(管理、优化、监控等)

NewSQL毫无疑问，它代表着未来的趋势。我相信它将在未来3~5年内，逐渐普及。

• 系统上限能力高

• 功能完整性高

• 能力可以快速增强

在去O在这个过程中，我们首先要明确的是，没有数据库产品是可以完全替代的。也就是说，完成去O工作需要通过应用改造 数据库选择 应用迁移来完成。这里需要考虑整体目标和路径。原则上，问题中的两种方法都可以完成O但对应用改造和迁移的影响差异较大。

• PG类产品，其企业级功能相对完善，使用体感和Oracle相似。有些基础PG内核产品，在Oracle兼容性做了很多工作。对于用户来说，使用和使用Oracle更相似，甚至大部分都可以无缝迁移；少数需要修改，工作量相对较小。

• MySQL类产品更受欢迎，但与Oracle相比之下，功能差异更大。O选择，需要做更大的修改。