不知道从何时起 。选型

“选数据库必选分布式”成了一种潮流。别盲布式

数据查询慢 ？上分布式！

使用总是多企瘫？上分布式
 ！

事务体量大
 ？业用上分布式 ！

KPI 查核不合格
？错分上分布式！

“分布式数据库”的作用
。

就这样被神话了 。别盲布式

跟数据和使用相关的什许数据各种疑难杂症。

好像都能够拿“分布式大法”来治 。多企

果真如此吗？只能说。

用户心中的错分「成见」
，像一座大山  。选型

曩昔几年分布式数据库造势太猛 。别盲布式

甭管什么场景，什许数据只管整就完了！

这座大山是怎么构成的？

上个十年，互联网公司的事务大迸发 ，让互联网范式走上了神坛。

互联网大厂的事务模型、中台理念、使用架构以及分布式数据库 ，乃至互联网公司的从业人员，都成了香饽饽  。

那么，由此带来的香饽饽之一“分布式数据库” ，究竟好不好？

不可否认，的确好 ！

分布式数据库的最大优势在于其横向扩展才能，轻松处理超大规划数据和并发恳求，比方电商渠道 、交际媒体或其它超重载使用
。

而这，恰恰是互联网事务场景的特色 ↓ 。

海量用户 ，高速扩张，峰值秒杀，大批高端技能牛马担任运维保证… 。

可是  ，一旦抛开互联网事务 ，来到传统企业级场景，你会发现 ↓
。

分布式数据库没那么神，乃至 ，还有一些下风 ——。

业界从前流传着一个很闻名的事例：

某银行做分布式数据库试点，用 600 台 x86 服务器承载分布式数据，替换了一个三节点 O 记 RAC 。

功用和扩展性好像上来了，但运维本钱大幅添加（人力、电费 、机房空间、备件）。

所以，技能挑选需求回归事务实质
，而非追逐技能潮流。

分布式数据库肯定不是包治百病的良药 ，任何场景，都需求对症下药。

数据库究竟应该怎么选？

一、要搞清自己的事务需求和痛点，再对症下药 ↓ 。

假如是面向海量用户
，超大数据量和增加潜力，并伴有高峰值并发
、秒杀型的典型互联网事务特征 ，这的确是分布式数据库舒适区。

假如是杂乱事务核算和数据抢手会集的场景，选用会集式库更适宜，比方 12306 客票 、医院 HIS、外汇交易、出产调度、ERP 等事务 。

二、要对分布式祛魅 ，许多所谓的“分布式场景”
 ，都跟分布式数据库没半毛钱联系 。

1、“分布式使用”场景
：

有的客户期望用分布式的云原生架构，比方微服务化 / 分布式使用，支撑灵敏开发 DevOps 。

分布式使用的实质 ，是将上层事务模块解耦、拆分，每个模块都能够独立开发 、保护、扩展，并完结容错阻隔 。

假如仅仅使用解耦 ，而数据库坚持不变 ，很明显这个进程与数据库是不是分布式没联系。

而假如在使用解耦进程中，一起将数据库拆解并绑定到特定微服务使用中，那明显数据库面临的压力变小了 ，也与分布式更没联系了。

至于灵敏开发、CICD 、DevOps 什么的  ，跟数据库是不是分布式相同没联系  。

2、“分布式用户”场景。

有些用户的原意是期望节约本钱，一套数据库能满意多个部分、多个使用的需求。

他们以为分布式数据库能够更好地满意这样多部分、多事务需求。

这种状况跟分布式毫无联系，这是数据库的多租户场景，选用支撑多租户方式的会集式数据库本钱更低
、作用更佳。

3 、“分布式标底”场景  。

前两种只能算“过错认知”，而这一种就可谓魔幻了。

有人仅仅觉得分布式数据库更抢手 、更拉风 ，就写进了收购标底
。

成果收购回来
，实践布置的时分，却当成单机版 ，会集式布置，妥妥“冤大头”
。

要知道这种把分布式数据库当会集式布置的状况，归纳功用远不如原生的会集式数据库 。

以上这三种“分布式”场景，都不需求“分布式数据库”。

此刻
，挑选适宜的会集式数据库，能够取得更优的功用、更好的运维体会，以及更低的本钱。

挑选金仓，应对企业全栈场景。

接下来
，咱们以金仓数据库为例
，讲一讲面临各种事务需求，详细怎么选型。

作为国产数据库范畴的领军企业，金仓数据库产品线丰厚，既有会集式产品，也有分布式数据库 ，广泛适配各种事务需求。

榜首、分布式使用需求。

乍一看
 ，分布式使用很杂乱 ，其实每个拆分后的微服务使用 ，比较单体使用，功用愈加朴实、简略，反而对数据库的要求大大降低了。

所以，能扛起大型单体使用的金仓数据库，针对分布式使用这点“小 Case”，天然轻松拿捏
。

一起 ，针对不同微服务模块的事务特征，能够选用不同类型的数据库来调配 ，然后到达最优的作用 
。

比方一个微服务化的电商使用 ，包括用户
、产品、订单、付出 、计算剖析等模块，那么能够针对性的进行数据库规划 。

用户服务：事务性、高牢靠要求，选用 KES 主备集群；

产品服务：事务性
，读多写少、缓存需求高 ，选用 KES 读写别离集群 (支撑 Redis 搬迁)。

订单服务
：事务性强、共同性要求高，并发读写压力大，选用 KES RAC；

付出服务
：高事务性、金融级共同性 ，选用 KES RAC；

计算剖析服务：数据量巨大、实时杂乱查询剖析 ，选用 KES ADC
。

第二、多租户需求。

在企业级场景
，不同部分 
、不同事务体系 ，都对数据库有要求  。

以往处理这种问题，最简略粗犷的方法便是收购多个数据库，多套物理硬件，各跑各的
，咱们都没定见 。

但这种方法会形成巨大的资源糟蹋，每个数据库使用率都很低，运维、晋级也要独立完结 。

想要完结多用户、多部分同享，最佳的处理计划是选用数据库的多租户功用。

针对多租户需求 ，金仓数据库是供给两大类四种场景的老练处理计划，灵敏满意不同建造现状、不同阻隔等级 、不同预算要求 。

1 
、VM 级多租户 。

适用于客户已建好有虚拟化 / 云渠道，金仓数据库能够无缝融入，资源硬件同享、根据 VM 阻隔，支撑 VM 级扩缩容。

2 、容器级多租户。

适用于客户已有 K8S 容器化渠道层 ，金仓数据库无缝融入 ，硬件、OS 同享 、根据容器阻隔，支撑 pod 级扩缩容
。

3 、数据库实例级多租户。

适用于中小型使用
，低本钱投入，单个服务器跑多个事务体系。金仓数据库天然支撑多实例特性
 ，每个事务独占一个数据库实例  。

并且在布置的时分，能够使用多台服务器池化，主备实例分隔布置，提高数据库冗余才能。

一起 ，金仓也支撑分布式数据库的多实例方式。

4
、数据库 User 级多租户
。

这种方式，经过将数据库创立若干资源组
，完结全体资源池化，然后创立用户租户，并指定分配的资源组。

然后完结数据库实例布置多租户体系，租户间资源阻隔
，提高软硬件资源使用率 ，大幅降低本钱。

第三、会集式高可用数据库需求。

大中型企业的出产级中心使用 
，都需求数据库支撑高可用集群
，或许再清晰一点，他们期望对 Oracle RAC 进行国产化代替 。

此刻，就轮到金仓的另两个重磅数据库产品上台了。

1
、KES RAC，多写同享存储集群。

看姓名咱们就秒懂了 ，这是对标 Oracle RAC 的场景。

KES RAC 集群支撑 2-8 个节点规划
，读写恳求横向扩展（吞吐量加速比超越 0.8） ，供给“RPO=0 、RTO<10s”可用性  ，满意金融级共同性
、高事务性和大规划并发读写需求。

2 、KES RWC，读写别离集群 。

根据事务等级的读写别离 ，自动识别 SQL 句子读写品种
，一主多备、一写多读
。

KES RWC 适用于大规划并发查询、读多写少的中 / 重载事务场景，支撑从实例 、集群到多中心的高可用保证，数据零丢掉 ，毛病秒切换。

第四 、实在的分布式数据库需求 。

在企业级商场，的确存在一些实在的分布式数据库需求
：比方超大型使用（超高并发、海量存储、横向扩展）、极致高可用（跨中心多活 、部分高容错）等等。

针对这样的实际需求和潜在需求 
，金仓数据库供给了强壮的“分布式三剑客” 。

1、KES TDC
，根据分布式存储的通明分布式计划。

该计划对上层使用彻底通明，不需求使用改造，可滑润搬迁，并具有横向扩展才能和节点毛病容错才能。

适用于超大型集团工作渠道、政务中心渠道、医疗 HIS 体系 、银行信贷管理体系、港口 TOS 体系等… 。

2
、KES Sharding，根据分布式中间件的分布式计划
。

该计划需求使用支撑分库分表改造，适用于对并发 、容量 、吞吐量扩展性要求高的事务处理场景，如运营商网间结算 、基金公司 TA 体系等。

3
、KES ADC，根据分布式 + 交融多存储引擎的剖析性分布式计划。

该计划适用于大规划 AP 或许 HTAP 场景 ，相似数仓 、实时数仓，比如数据一致汇总渠道、大数据剖析渠道、进出口贸易货品计算体系等等。

最终 ，仍是那句话 ：技能的挑选要回归事务实质 ，而非追逐技能潮流。

理解这个道理，咱们就把握了消除成见、翻越大山的中心奥义。

怎么样？您的数据库选对了吗？

广告声明
：文内含有的对外跳转链接（包括不限于超链接、二维码 、口令等方式）
，用于传递更多信息 ，节约甄选时刻 ，成果仅供参考 ，一切文章均包括本声明。