不知道从何时起 。选型
“选数据库必选分布式”成了一种潮流 。别盲布式
数据查询慢
？上分布式 ！
使用总是多企瘫 ？上分布式 ！
事务体量大
？业用上分布式！
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 场景 ，相似数仓
、实时数仓 ，比如数据一致汇总渠道
、大数据剖析渠道
、进出口贸易货品计算体系等等。
最终 ，仍是那句话 ：技能的挑选要回归事务实质 ，而非追逐技能潮流 。
理解这个道理 ，咱们就把握了消除成见 、翻越大山的中心奥义
。
怎么样 ？您的数据库选对了吗？
广告声明：文内含有的对外跳转链接（包括不限于超链接 、二维码 、口令等方式） ，用于传递更多信息 ，节约甄选时刻 ，成果仅供参考，一切文章均包括本声明 。
