企业官网建设流程全解析

1. 为什么把这三个放在一起比：它们根本不是一类东西

在实际的分布式系统选型会上，我经常看到这样的场景：业务方拿着一个需求列表，直接问"MongoDB、HBase、Redis到底选哪个"。这个问题的前提就是错的。把这三者放在同一个维度上比较优劣势，本身就会得出很多误导性结论——因为它们不是竞争关系，更接近于"螺丝刀、扳手、电钻"的区别：都叫工具，但设计目标、底层机制、适用场景完全不同。

MongoDB是文档型数据库，定位是"灵活的业务数据存储"，擅长处理结构不固定、关系不复杂的业务数据；HBase是列族数据库，定位是"海量结构化数据的实时读写"，诞生于大规模日志、监控、时序类数据的存储需求；Redis是键值内存数据库，定位是"高速缓存与实时计算"，设计目标是在毫秒甚至微秒级别完成单条数据的读写。三者的核心关键词如果非要各抽一个，分别是：schema-flexible、scale-out、in-memory。

我建议把这次对比当成"三种典型NoSQL架构的底层原理拆解"，而不是简单罗列各自的优缺点。只有理解了它们为什么长成这个样子，才能在真实项目里做出不后悔的选型。这篇文章会从数据模型、存储引擎、扩展方式、一致性、运维成本几个维度横向展开，最后给出我自己常用的选型决策路径和踩过的一些坑。

先说一个反直觉的结论：论单机读写性能，HBase在绝大多数场景下是三者里最弱的；但论海量数据下的水平扩展能力和分区容错性，HBase又是三者里最稳的。而Redis单机性能最强，却是三者里最不适合当"数据库"用的。这种"性能最强的不适合当存储，扩展性最强的单机性能弱"的错位感，恰恰是理解NoSQL选型的钥匙。

2. 底层存储机制差异：为什么它们长成不同的样子

2.1 MongoDB：BSON文档与WiredTiger存储引擎

MongoDB的数据模型是BSON文档，你可以理解为"JSON的二进制扩展版"。它最大的特点是文档内部天然嵌套，一个订单的所有信息（用户、商品列表、收货地址、物流状态）可以塞进同一个文档，读取时一次IO全部拿到。

底层存储引擎从4.0开始默认是WiredTiger，核心结构是B+树和LSM树的混合体。默认情况下，每个集合的数据和索引都按B+树组织，支持行级锁和MVCC（多版本并发控制）。文档在磁盘上是连续存储的，配合内存映射（MMapv1时代的做法已经淘汰），在SSD上随机读性能相当不错。写入方面，WiredTiger会先写日志（WAL），再更新内存中的缓存页，异步刷盘。

这里有一个容易忽略的技术点：MongoDB的索引结构默认也是B+树，索引字段的更新会触发索引页的分裂合并。所以写多读少、更新频繁的业务，一定要控制索引数量。我在很多项目里遇到过"为了查询效率一口气建了七八个索引"，结果写入性能被索引维护拖垮的情况。

2.2 HBase：LSM树与列族稀疏存储

HBase的数据模型是稀疏的列族多维映射：row key + column family + column qualifier + timestamp，每个单元格都保存着多个历史版本。底层存储是HDFS上的HFile，写入路径完全走LSM树架构：数据先写WAL，再进内存中的MemStore，达到阈值后flush成不可变的HFile，后台不断做Minor Compaction和Major Compaction。

LSM树的精髓在于把随机写转化为顺序写。HBase的写入几乎不涉及磁盘随机IO，所以它的写入吞吐量在同硬件条件下远高于传统B+树数据库。但代价是读取路径复杂：一次读取可能要查MemStore、多个HFile、布隆过滤器逐层过滤，读放大问题明显。所以HBase"写快读慢"，恰好和MongoDB形成对比。

HBase的稀疏存储特性也很关键：某一行的某列如果没有值，就不占存储空间。对于几十亿行、每行列数不固定的场景（比如用户行为埋点），这种存储模型能节省大量磁盘。但如果你的数据天然是规整的二维表结构，用HBase反而会让模型变别扭。

2.3 Redis：全内存哈希与单线程事件循环

Redis的核心是"数据全在内存"，无论你用RDB快照还是AOF日志做持久化，主数据源始终是内存。底层是全局哈希表（dict），key直接映射到value的指针。配合单线程事件循环（6.0之后引入IO多线程，但命令执行仍是单线程），避免了锁竞争和上下文切换，单实例QPS可以轻松到10万以上，纯内存GET/SET更是能到几十万。

单线程模型听上去是短板，实际上反而带来了一个巨大的优势：所有操作是原子性的，不需要分布式锁就能实现简单的原子操作，比如INCR、LPUSH、SETNX。这让Redis不仅是缓存，更是分布式系统中"计数器、分布式锁、排行榜、消息队列"等组件的天然实现者。

但这套设计也有明确的边界：内存是有限且昂贵的。全量数据放内存意味着你的数据规模被机器内存锁死，单机几百GB已经算夸张了；而且一旦开启持久化，RDB快照fork子进程或AOF重写都会引发短暂的阻塞，这在追求极致低延迟的场景需要特别留意。

3. 读写性能、容量上限与扩展机制的实测边界

3.1 性能差异不是一两倍，而是量级差异

先给个直观的量级参考（基于普通SSD、8核16G云主机单节点，数据量在千万级）：

• Redis：GET/SET平均延迟在0.1~0.5ms，吞吐量5万~15万QPS，数据量受内存上限制约。
• MongoDB：简单主键查询1~3ms，索引查询3~10ms，批量写入几千到一两万每秒，吞吐量受磁盘IO和索引数量影响很大。
• HBase：单行get延迟在5~20ms，批量scan可以做到每秒百万行级别的扫描吞吐，但单行随机读因为要走MemStore+HFile的多级合并，很难做得特别低。

也就是说，如果你要的是一个"每次请求都能打到缓存层"的东西，选Redis；要的是"OLTP业务数据查询与事务"，选MongoDB；要的是"几十TB甚至PB级数据的实时写入与范围扫描"，选HBase。拿HBase去做用户订单查询是自找麻烦，拿Redis去存几十TB日志是资源黑洞，拿MongoDB去做物联网海量写入则要做好性能下滑的准备。

3.2 水平扩展机制：分片、Region与Cluster

三者的扩展方式差异也极大。

MongoDB通过**分片集群（Sharded Cluster）**扩展：按分片键把数据拆到多个shard上，每个shard是一套副本集，由mongos路由。分片键的选择直接决定集群命运，选得不好（比如低基数字段），会导致数据倾斜，少数节点承载绝大多数流量。这里有个实操经验：分片键尽量选基数高、写入分散、查询常用的字段，比如用户ID加时间组合。

HBase的扩展是Region的分裂与分布式自动管理：一张表按row key range切成多个Region，Region由RegionServer管理，数据量大了自动分裂，再通过HMaster把Region分配到其他节点。这套机制的好处是数据倾斜处理相对自动，只要row key设计合理，它可以线性扩展到上千台节点。但代价是运维复杂度极高，HDFS、ZooKeeper、HMaster、RegionServer四个组件都要维护，版本兼容性问题也常让人头疼。

Redis的扩展走的是集群分槽模式：Cluster模式把key空间分成了16384个slot，每个节点负责一部分slot。客户端通过CRC16(key)计算槽位，直连对应节点。这种设计让Redis Cluster的实现相当轻量，但多key操作（比如MGET）必须保证key在同一slot，否则会直接报错，这需要在key设计时用哈希标签（hash tag）去约束。相比前两者，Redis集群更接近"缓存集群"而不是"存储集群"——因为它的持久化能力和故障恢复能力都要弱一些。

3.3 一致性模型：最终一致与强一致之间的摇摆

这个维度虽然没有性能那么直观，却是选型时最容易埋雷的地方。

MongoDB的副本集默认读主库，写入主库后同步到从库，默认配置下是强一致读（read preference为primary时）。但如果把read preference设为secondary，就会读到旧数据。它支持事务（4.0之后引入多文档事务），但在分片集群里跨分片事务的性能代价很大。

HBase默认也是RegionServer上的主写，通过ZooKeeper保证Region的分配一致性。它在单Region内是强一致的，但跨Region（跨Server）没有原生事务机制。HBase的强一致是"分区内强一致、跨分区最终一致"。

Redis在主从复制下是异步复制，所以主节点挂了之后，从节点顶上时可能丢数据（取决于配置，即使配置了wait也不会。它的一致性模型非常弱，Cluster模式下连多key原子操作都做不到。所以Redis是所有NoSQL里最不适合作为"主数据库"存强一致性业务的。

4. 典型场景与高频误用：我在项目里见过的最典型错误

4.1 各自的"舒适区"

先说正确用法。

MongoDB的舒适区是：业务数据模型迭代快、字段不固定、读写比例大约7:3到8:2的通用业务系统。典型例子有内容管理系统、用户画像、订单管理系统、IoT设备的元数据管理。它最吸引人的是开发效率：不需要预先定义表结构，代码里加一个字段，文档里就自然多一个字段，不用写ALTER TABLE。

HBase的舒适区特别窄，但特别深：海量时序数据写入、日志存储、监控指标、消息流落库。比如一个每天产生50亿条埋点数据的系统，数据按天生成、按时间范围扫描、定期归档删除，这种场景用HBase几乎是教科书级的匹配。Row key用"反序时间戳+设备ID"的设计可以保证最新数据热区连续，读写都高效。

Redis的舒适区是：需要极低延迟的缓存层、分布式锁、计数器、排行榜、会话管理。比如秒杀系统的库存扣减，用Redis的DECR原子操作保证不超卖；排行榜用Sorted Set，毫秒级拿到Top100。注意，这些都属于"辅助能力"，Redis永远不要当唯一的真相源。

4.2 我亲眼踩过或帮别人收拾过的典型误用

误用一：把MongoDB当数据仓库跑数。

有个项目用MongoDB存了半年的用户行为流水，然后做大屏BI查询，跑一个聚合查询要几十秒。因为MongoDB的聚合框架在单文档内很强，但对跨文档的大规模group by、join并不擅长，而且它没有列式存储，大范围扫描的成本非常高。正确的做法是：明细流水入HBase或数据仓库，MongoDB只存元数据和结果集。

误用二：把Redis当唯一存储，开着AOF以为就安全了。

AOF持久化确实能减少丢数据窗口，但Redis的fork机制在内存数据量大时会导致秒级阻塞，而且AOF文件重写期间性能明显下降。我在线上见过Redis内存用了80GB，开启AOF之后主线程阻塞1.2秒的案例，那1.2秒里所有业务请求排队，超时雪崩。所以，Redis永远只能当"缓存+实时计算层"，底层数据必须能重建——要么有可靠的上游数据库，要么有离线数据源。

误用三：HBase的row key设计太随意。

HBase的读写在根本上依赖row key的顺序性。如果直接把用户ID当row key，热点集中在小部分高活跃用户，个别Region会被打爆，集群其余节点闲得慌。正确的设计是"盐化"或"反转ID"，把热点分散到不同Region。这个调优不做好，HBase集群规模越大，性能反而越差。

4.3 三者混用的经典组合

实际的高并发系统里，三者的关系往往不是"选一个"，而是各司其职：

• Redis：承接所有前端请求，做热点数据的缓存、计数器、限流、排行榜；
• MongoDB：存储业务主数据，比如用户信息、订单、商品，提供灵活的查询和事务能力；
• HBase：承接数据流水、埋点、日志的海量存储，提供时间范围扫描，供离线计算或在线服务读取。

比如一个电商中台：商品详情页的缓存放Redis；订单和用户档案存MongoDB；用户行为埋点流水写HBase，异步被Spark或Flink消费，生成推荐特征和报表数据。这个组合几乎是大厂最通用的后端数据层架构，三者之间没有冲突。

5. 选型决策的实操路径：从业务需求反推数据库

5.1 先问五个问题，而不是先看性能

我在做技术选型时，不会先看Benchmark，而是先问业务五个问题：

1. 数据量级预期：上线一年后数据量是千万级、亿级还是百亿级？
2. 读写模型：是点查多、范围查多，还是写多读少？
3. 结构变化频率：字段是否经常增减？还是一次性定型？
4. 一致性要求：允许短暂读到旧数据吗？允许故障时丢失少量最近数据吗？
5. 团队运维能力：是否有专人维护分布式组件？

这五个问题的答案基本能直接排除掉一半选项。数据量千万级选MongoDB足够；百亿级日志流水直接选HBase；需要极低延迟的实时查询先接Redis；结构频繁变动的业务主体别碰HBase（它的列族设计想要动态加列，运维成本很高）；严格强一致事务场景，三者各加各的"辅助手段"都费劲，甚至要考虑回关系库。

5.2 一个实用的决策分叉参考

我常用这样的判断流程：

• 如果业务本质是"增删改查业务系统"，事务要求一般，结构灵活：MongoDB。
• 如果是海量数据的持续写入、定期扫描、按时间归档，比如日志、监控、推荐候选集：HBase。
• 如果目标是让接口变快、抗峰值流量、做实时计算，并且数据的持久源在别处：Redis。
• 如果既要写海量流水又要支持点查（比如订单流水查询），HBase加二级索引方案经常比MongoDB的集群方案抗压能力强得多，可以考虑。
• 如果是社交关系图谱、复杂关联查询，这三者都不是最优解，应该看图数据库或其他方案。

5.3 选型前做一次小规模压测比文档有用一万倍

每个数据库的官方文档都说自己能扛多少万QPS，但真实环境的差距可以很大。我建议在选型阶段用真实数据模型做一次3~5节点的压测：写入模型、读模型、操作比例按业务真实配比来，压测时间至少持续30分钟，监控延迟P99和CPU、内存、磁盘IO。MongoDB和HBase在长时间高并发写入下的磁盘碎片、Compaction抖动，往往是压测时长不够导致的"隐藏惊喜"。

压测时有一个细节容易被忽略：不要只测平均延迟，要测P99甚至P999。HBase的延迟曲线受Compaction影响会有明显毛刺，MongoDB的WiredTiger在脏页刷盘时会周期性出现延迟尖刺，这些在平均值里完全看不出来，但对线上体验的影响巨大。

6. 运维与迁移中的高频坑：从真实教训里说几条给你参考

6.1 MongoDB的集群分片键与慢查询排查

MongoDB分片集群部署后，最大的坑往往是分片键选错导致数据倾斜。我遇到过一次很典型的：某团队用了"日期"做分片键，结果每天的数据全部写到同一个shard，其他shard空转。分片键一旦设定不可更改，只能通过mongos导出导入重新分片，过程相当痛苦。读多写少的业务，还建议开启读写分离，把读流量分流到从节点，减少主节点的CPU压力。

慢查询排查方面，MongoDB的explain输出里，重点看executionStats和indexBounds，确认是否走了索引。一个很容易忽略的点是：MongoDB对负向查询（$ne、$nin）和正则前面带通配符的查询几乎不会走索引；字段存在性检查（$exists）也一样。这些查询一多，CPU立刻被打满。

6.2 HBase的Region热点与Compaction低谷

HBase运维里最常看到的是Region热点和Major Compaction导致的写入毛刺。Region热点99%和row key设计有关，排查方式是用Region监控看到部分RegionServer的写请求数是其他节点的好几倍。修复方案里，盐化前缀、反转时间戳、预分区都是常用手段，其中预分区最容易被忽略——很多人建表时没有预估数据量，导致所有数据先挤在少数Region，频繁分裂，集群不停抖动。

另外，Major Compaction是所有RegionServer周期性执行的大动作，会短时间内产生大量磁盘IO和网络IO，正好和业务高峰撞在一起，读写纷纷变慢。我的建议是把Major Compaction的自动触发时间调到凌晨低峰期，或者干脆关掉自动，手动在低峰期错峰触发。这个配置改动看起来小，实际能消掉一大半的"偶发P999超时"。

6.3 Redis的缓存穿透、击穿、雪崩与内存淘汰策略

Redis运维里最常见的是缓存三兄弟问题，但选型角度我更想说的是内存淘汰策略需要和业务语义绑定。很多人直接默认用noeviction或者volatile-lru，前者在容量满了直接拒绝写操作，线上表现为"系统突然写不进缓存了"；后者可能会把你本来想长期驻留的数据淘汰掉。

我的经验是：不同业务场景用不同淘汰策略，甚至可以混合部署多个Redis实例分类对待——登录态会话用小容量Redis配allkeys-lru，保证活跃会话保留；热点活动数据用单独实例配noeviction，宁可写入失败也不能淘汰正在做活动的数据；排行榜类数据直接上持久化实例，内存给足。

6.4 数据迁移：从关系库迁到MongoDB的坑

把MySQL迁到MongoDB，不少人一上来就把SQL表结构一对一搬成Collection，还要大搞关联查询替代join，结果体验非常差。MongoDB的正确设计是"按查询维度建模"，把需要一起读的数据尽可能嵌到同一个文档里。比如订单和订单项，在关系库是两张表join，在MongoDB里就该是同一个文档的数组字段。迁移的时候如果不做模型重设计，等于把关系库的思维原封不动搬过去，性能优势一点体现不出来。

反过来，从MongoDB迁到HBase的案例我也见过几个，踩坑集中在：MongoDB的文档结构天然是嵌套的，HBase是扁平的单元格，需要先确定所有的"列"是什么，提前设计好列族和列名，还要解决row key如何保证原本的查询走索引。这个映射工作比想象中繁琐，需要列一个详细的字段级映射表，做好数据校验和回读测试再切流量。

6.5 监控指标：别只看CPU和内存

最后提一嘴监控。三个数据库都有各自的关键指标需要重点盯：

• MongoDB：关注oplog窗口（太小会从库同步不掉队）、wiredTiger cache的使用率、连接数、慢查询数。特别是oplog，很多团队是从0开始启用副本集，oplog默认大小在部分版本里只有几百MB，高峰期写入一大，从库追不上主库，就会触发复制落伍，导致整个副本集不可用。
• HBase：关注RegionServer的Heap使用、HFile数（过多说明Minor Compaction不充分）、Region分裂次数、Compaction队列长度、ZooKeeper会话超时。HFile数量一多，读性能会断崖式下跌。
• Redis：关注内存碎片率（mem_fragmentation_ratio）、key过期淘汰量（evicted_keys）、持久化造成的延迟、慢日志。内存碎片率如果长期高于1.5，说明频繁的过期删除产生了大量内存空洞，需要考虑定期执行memory purge或重启进行碎片整理。

这些指标往往比CPU、内存、磁盘这些基础监控更能提前暴露问题。我在维护三套集群时，统一用Prometheus加Grafana搭建监控面板，每个数据库单独一套Dashboard，告警阈值全部经过一段时间的基线和毛刺观察后再调整，避免误报轰炸。

写在最后：一点个人经验

三个数据库我都有大规模线上维护经验，如果非要用一句话总结选型心得，我会说：不要因为性能数字选数据库，要因为数据形态和访问模式选数据库。MongoDB吃得下绝大多数"业务数据"的活，是默认选项；当你发现数据量奔着百亿去了、访问模式变成了时间范围的扫描，再切HBase不迟；Redis永远值得在你系统的每一个热点路径上加一层，但它替代不了前两者的存储职责。

如果你正处在选型纠结期，我的建议是先从业务的数据模型、访问模式、量级预期三个维度把自己的需求写完，带着明确的约束去对比，而不是对着性能榜单找答案。选型和谈恋爱很像：不是选一个"最好"的，而是选一个"最合适"的。数据库没有银弹，但架构上提前想清楚，后面能省掉至少半年的运维痛苦。