各位，我是老张。今天从一次实战出发，往下拆一层。
文档数据库这个品类，占了非关系型市场的大头。IDC统计过，三年前它的市占就超过六成。很多人觉得，MongoDB副本集够用了。数据量小的时候，确实够用。到了百亿级，问题就不是加内存能解决的。今天把这个问题拆开。先看副本集卡在哪，再看分片架构怎么接住百亿级。
一、副本集的天花板在哪
副本集的本质是主从复制。一份数据，多个副本。主节点负责写，从节点负责读和备份。部署简单，故障切换也快，中小业务用它省心。但它有两个硬限制。第一，数据全量放在每个节点上，存储上限跟着单机走。第二，写入还是走主节点，写放大明显。数据量越大，这两个限制越难受。
扩容也不是加台机器就完事。加节点要迁数据，要重建副本。数据到了百亿级，迁移窗口和恢复时间都会拉长。业务等不起，运维也不敢频繁动。读扩展也有上限。从节点加得再多，复制延迟还是存在。主节点写不过来，读节点再多也帮不上。副本集解决的是高可用和读分担，不解决写入扩展。这个区别，选型时一定要分清。
| 对比项 | 副本集 | 分片集群 |
|---|---|---|
| 数据分布 | 每个节点全量 | 按分片切分 |
| 存储上限 | 受单机限制 | 随数据节点扩展 |
| 写入扩展 | 主要靠主节点 | 多分片并行写入 |
| 扩容方式 | 迁数据、重建副本 | 增加数据节点 |
| 适用规模 | 千万级以内 | 十亿到百亿级 |
二、文档库为什么也要分片
文档模型字段灵活，不等于存储无限。政务的证照共享、金融的用户画像。能源的设备日志、运营商的行为分析。数据量都很大。这类场景有几个共同点。写入持续，查询多样，数据保留周期长。中小业务用单机或副本集，架构简单，维护也省心。到了几十亿、百亿级，必须横向扩展。这不是选型偏好，是数据量逼着你走这一步。
金仓数据库（KES）文档版，建立在KES多模内核上。KSOne把数据节点的能力，扩展到文档模型。应用还是按MongoDB协议访问，底层具备横向扩展能力。这句话要拆开看。兼容是应用层的事，扩展是架构层的事。两件事都做到，才算能接住百亿级文档场景。
三、先把三层架构拆开
分布式文档集群，KES文档版分成三层。计算层、元信息层、存储层，职责和扩展方式都不一样。计算层放的是KSOne代理。它本身不存数据，多个节点可以同时读写。查询进来，它负责找分片、收结果。连接压力上来，加代理节点就行。这一层是无状态的，扩起来相对简单。
元信息层管两件事。分片怎么分布，路由怎么找。注册中心和KES元信息集群一起维护这份地图。这一层不直接处理业务数据，但它是整个集群的导航。导航出问题，后面的查询都会受影响。
存储层按分片切。每个分片就是一个KES文档实例。需要几个副本，可以按业务配。备份恢复、主备高可用、统一管控、透明加密，这些能力沿用KES那一套。运维不用再学一套新工具。
| 层级 | 组件 | 主要职责 | 怎么扩展 |
|---|---|---|---|
| 计算层 | KSOne代理节点 | 查询路由、结果汇总 | 按连接压力加节点 |
| 元信息层 | 注册中心、KES元信息集群 | 分片拓扑、路由元数据 | 按元信息规模规划 |
| 存储层 | KES文档实例 | 存数据、多副本 | 增加数据分片 |
从查询路径看，顺序很清楚。应用先连代理，代理查元信息，找到目标分片。请求发过去，分片执行完，代理汇总结果，返回应用。这条链路里，代理和元信息都不存业务数据。真正扛容量的是存储层。这三层里，最容易忽略的是元信息层。它不扛业务流量，但所有路由都靠它。容量和故障恢复要提前规划，别等集群大了才发现导航先堵了。存储层扩得快，元信息层跟不上，整条链路还是会慢。
四、分片键决定上限
分片键是分布式文档库的第一道设计题。KES文档版支持单字段，也支持多字段组合，配套有四种分片策略。四种策略怎么选，要看业务查询模式。按时间查得多，和按用户ID查得多，选法不一样。分片策略没有绝对好坏。查询怎么走，数据怎么长，才是判断依据。选完还要看数据会不会倾斜，均匀分布比理论最优更重要。
路由分三种。第一种是分片集合。带了分片键，就直奔目标分片。没带分片键，就去所有分片并行找。第二种是广播集合。每个实例放全量。写入时每个实例都写。读取时任选一个。第三种是未分片集合。元信息直接告诉你，它在哪个实例。
分片键选不好，后面的问题会很多。我一般看三点。基数够不够高，分布够不够均匀，查询是不是经常带这个字段。三点都满足，分片才有意义。基数低，数据会堆在少数分片。分布不均，热点会集中。查询不带分片键，每次都要广播，加再多节点也救不了。
五、跨分片关联怎么解
分片之后，关联查询是第一个难题。数据被切到不同节点。原来一条SQL能做完的事，现在可能要跨节点搬数据。搬得越多，性能越差。KES文档版给了两种方案。
第一种叫绑定集合，解决大表对大表。两个集合都大，分片规则又一致，对应分片落在同一节点。跨节点关联就变成节点内关联，笛卡尔积的代价也避开了。第二种叫广播集合，解决大表对小表。小字典表读多写少，每个实例存一份全量。分片集合和它关联时，就地算，不搬数据。小表不大的时候，这个方案很划算。
这两种方案不是万能。绑定集合要求分片规则一致。广播集合要求表足够小，写入不能太频繁。选型时先问自己，大表关联多不多，小表是不是读多写少。答案不同，分片方案也不同。
六、兼容只是入场券
换文档库，最怕的是应用跑不起来。性能差一点还能调，接口对不上，业务直接停。KES文档版在协议层做了兼容。MongoDB 5.0以上的通信协议，它原生支持。常用命令和操作符，兼容度接近100%，迁移时通常只改连接地址。项目按功能域做了60多项验证，全部通过。数据类型与索引、CRUD、聚合管道、GridFS。管理命令、诊断命令、SCRAM-SHA-256认证、备份迁移、集群管理，都在验证范围里。
兼容性过关，只是拿到了入场券。应用能连上，不代表百亿级跑得动。很多选型只看兼容列表，不看分片、路由、跨分片关联。上线后数据一涨，问题才暴露。
七、性能数据怎么看
测试用YCSB。batchsize设10000，并发100。数据规模分两档，100万和1亿。负载覆盖四类，读多写少、纯读、热点读、读改写。对照的是MongoDB分布式版本。100万条这档，读多写少提升94%，纯读提升123%，热点读提升131%。到了1亿条，四类负载的提升落在153%到179%之间。数据规模越大，差距越明显。
为什么差距会拉大？100万条时，优势已经出来。数据量上到1亿，分片路由、并行执行、存储层扩展的作用更明显。规模越大，架构差异越清楚。
| 数据规模 | 负载场景 | 提升幅度 |
|---|---|---|
| 100万条 | 读多写少 | 94% |
| 100万条 | 纯读 | 123% |
| 100万条 | 热点读 | 131% |
| 1亿条 | 四类负载 | 153%～179% |
落地案例也有。某电力系统用KES Sharding。1个计算节点，4个数据节点。JDBC压测，100并发，batchsize 80000。1亿行写了24.33秒。平均411.01万行每秒。1440亿条数据入库用了11.01小时。
这些数字要连环境和参数一起看。脱离数据规模、并发数、batchsize，单看一个吞吐数字，说明不了问题。我拆性能数据，一向先看测试条件，再看结果。还有一点。benchmark测的是标准负载。真实业务的长尾查询、跨分片关联、批量导入，benchmark不一定覆盖。性能数据能证明方向，不能代替自己的业务压测。
八、分片之前，先看清前提
第一笔账，先看数据量。我一般把千万级当一条线。线以下，副本集够用。这个阶段上分片，只会增加复杂度。运维、监控、故障定位，都要多一层。跨分片事务多、关联特别复杂、强一致要求高的业务，也要先评估。分片能解决容量和吞吐，但会把关联和事务变复杂。这不是免费的。这笔账，扩容之前要先算清楚。
分片集群的运维能力，是另一个前提。分片键选错、热点处理不了、扩容不敢动。这些问题比单机故障更难查。架构升级，人和工具都要跟上。还有一条。分片键选不出来，说明业务模型还没想清楚。先回去梳理查询模式，别指望分片一上，问题自动消失。
我见过一些团队，数据还没到千万，先上了一套分片集群。结果分片键改了三次，运维成本翻倍。业务没涨多少，架构先复杂了。这不是进步，是提前背上包袱。
九、架构评审清单
我评审分布式文档库，会看这几项。数据规模，现在多少，三年后多少。分片键，基数、分布、查询命中率。跨分片关联，大表关联多不多，小表能不能广播。元信息层会不会成为瓶颈。副本和故障切换，RTO、RPO要求是多少。运维能力，监控、备份、扩容、升级能不能跟上。兼容性，协议、驱动、工具链是不是完整。
| 评审项 | 要回答的问题 |
|---|---|
| 数据规模 | 现在多大，三年后预计多大 |
| 分片键 | 基数是否够高，分布是否均匀 |
| 查询模式 | 是否经常带分片键 |
| 跨分片关联 | 大表关联多不多，小表能否广播 |
| 元信息层 | 会不会成为单点瓶颈 |
| 高可用 | RTO、RPO要求是否明确 |
| 运维能力 | 监控、备份、扩容是否可落地 |
十、写在最后
文档库的扩展性，不是加节点那么简单。分片键、路由、跨分片关联、元信息管理，每一层都要设计。少想一层，后面就多一次返工。
金仓KES文档版，沿用了KES的企业级能力。再用KSOne做分布式扩展。这个组合解决的是两个问题。应用兼容，架构能扩。对百亿级文档场景来说，这两件事缺一不可。
但选型还是要看自己的业务。数据规模、访问模式、关联复杂度。三个问题答清楚，再决定分片方案怎么落地。别因为别人上了，自己也跟着上。
各位，你们现在文档库多大了？副本集还扛得住吗？评论区聊聊。
我是底层玩家老张。咱不聊概念，只聊源码和压测跑出来的东西。