Day31-19｜10.6.8 大型网站系统架构演化实例（八）：NoSQL 与搜索引擎

一、教材定位

随着网站数据类型、访问模式和规模不断变化，单一关系数据库并不一定适合承载所有数据。用户行为、缓存状态、海量日志、社交关系、文档内容、时序数据和全文检索，可能需要 NoSQL 数据库或搜索引擎提供更适合的模型和访问能力。本阶段的架构演化不是“关系数据库被 NoSQL 取代”，而是根据数据特征和业务查询选择合适的数据存储。

NoSQL 和搜索引擎能够改善特定场景的扩展性、灵活性和查询性能，但通常需要应用承担更多数据建模、一致性、索引同步、备份和运维责任。考试答题要说明为什么选择、存什么数据、如何同步、故障如何恢复、谁是权威来源，以及哪些场景仍然必须使用关系数据库。

二、NoSQL 的基本特点

NoSQL 通常强调灵活的数据模型、水平扩展、高吞吐或特定访问模式。不同 NoSQL 类型差异很大，不能一概而论。选择时要从数据结构、查询方式、一致性、事务、容量、延迟、扩展和运维能力分析。

1. 键值数据库

以唯一键访问值，适合会话、缓存、配置、计数器和简单对象。优点是访问快速、扩展简单；缺点是复杂查询和关联能力弱，业务需要自行维护结构和过期。

2. 文档数据库

以 JSON 或类似文档保存对象，适合结构变化较多、聚合读取和文档型业务。文档内嵌可以减少关联查询，但文档过大、重复和跨文档一致性需要谨慎设计。

3. 列族数据库

按列族组织数据，适合海量写入、宽表和按特定键查询。建模通常从查询出发，需要预先设计访问模式，不能直接照搬关系模型。

4. 图数据库

以节点和边表达关系，适合社交关系、路径、推荐和依赖分析。图查询复杂度、遍历范围和分布式扩展是主要考虑因素。

5. 时序数据库

适合指标、设备数据和事件序列，通常提供时间分区、压缩和聚合能力。要设计保留期限、降采样、写入热点和查询窗口。

三、选择 NoSQL 的判断依据

1. 数据模型是否适配

数据是否结构灵活、规模巨大、关联简单或访问模式明确。若需要复杂多表事务、强约束和灵活 ad hoc 查询，关系数据库可能更合适。

2. 一致性要求

公开内容、推荐和行为日志可能允许最终一致；支付、账务、库存和权限通常需要严格一致和事务。NoSQL 提供的局部事务或可调一致性不能自动满足业务不变量。

3. 访问模式

NoSQL 常需要先确定查询方式，再反向设计数据。要明确主键、分区键、排序、范围、聚合和热点，避免上线后才发现查询需要扫描全部节点。

4. 运维与组织能力

团队是否具备备份、扩容、监控、升级、故障恢复和容量规划能力。引入新数据库会增加技术栈和人才成本，应评估长期维护而不是只看基准性能。

四、搜索引擎的架构作用

搜索引擎通过倒排索引、分词、相关性计算、过滤、聚合和排序，支持全文检索、模糊查询、联想、日志分析和多条件筛选。它通常是面向查询的派生系统，不应自动成为所有业务数据的唯一权威来源。

1. 索引和文档

原始数据被转换为搜索文档，字段配置分词、类型、是否索引和是否存储。索引设计决定查询能力和空间成本，字段类型错误会导致排序、范围和聚合结果不正确。

2. 分片和副本

索引被分成多个分片，分片再配置副本以提高查询并发和可用性。分片过少限制扩展，过多会增加元数据和调度成本；副本过多增加存储和写入负担。

3. 查询和相关性

搜索结果不仅看是否匹配，还涉及权重、分词、同义词、过滤、排序和业务规则。相关性调整要通过样本、评测和灰度验证，不能只依赖技术默认值。

五、关系数据库与 NoSQL、搜索引擎的协作

常见做法是关系数据库保存权威交易数据，NoSQL 保存适合其模型的高吞吐或灵活数据，搜索引擎保存查询索引。数据通过同步、事件、变更数据捕获或批处理进入派生系统。

必须明确数据流向和权威来源：数据库提交成功后发布事件，消费者更新 NoSQL 或搜索索引；索引更新失败进入重试和死信；定期全量校验和重建保证最终收敛。搜索结果不能直接修改交易数据，写入应回到权威系统。

六、索引同步与一致性

1. 同步写入

业务请求同时写数据库和搜索引擎，能较快看到索引结果，但任一边失败都会产生部分成功和事务协调问题。除非能够接受补偿和一致性窗口，否则不应把两次写入当作一个原子事务。

2. 异步事件

数据库提交后发布领域事件，索引消费者异步更新。优点是解耦和抗峰值，缺点是索引存在延迟、重复和失败，需要幂等、重试、死信和对账。

3. 变更数据捕获

从数据库日志捕获变更，转成统一事件更新下游。它能减少业务代码侵入，但要治理日志保留、顺序、DDL变化和捕获延迟。

4. 全量重建

当索引结构、分词或映射变化时，建立新索引并从权威数据重建，验证后切换别名。重建期间要处理增量变化，通常使用时间点、变更日志或双写保证不丢更新。

七、NoSQL 和搜索的可靠性治理

1. 分片与热点

分片键选择不均会造成热点节点；搜索按时间或热门词写入可能集中。可以使用复合键、哈希、时间分桶和热点拆分，并监控分片负载和请求分布。

2. 容量和保留

为数据、索引、副本、日志、快照和重建预留容量。设置生命周期管理、归档、降采样和冷热分层，避免存储达到上限后全局不可用。

3. 备份和恢复

备份要包含数据、索引配置、映射、分片元数据和版本。搜索索引通常可以重建，但重建时间和源数据可用性必须评估。恢复演练要验证可查询、权限、别名和增量变化。

4. 降级和回源

搜索不可用时，核心业务不能全部不可用。可以使用热门结果、简单数据库查询、缓存或只读模式降级。降级结果要明确提示和监控，恢复后逐步回流，避免索引重建造成资源争用。

八、案例分析：商品搜索系统演化

某电商平台最初使用关系数据库的 LIKE 查询商品，数据增长后搜索延迟升高。团队计划把商品表全部复制到搜索引擎，并让搜索结果直接作为下单依据。

合理方案是将关系数据库作为商品和价格的权威来源，搜索引擎保存商品标题、描述、分类、标签和可搜索属性。商品变更提交后通过事件或变更捕获更新索引，消息带商品版本和事件ID，消费者幂等处理并拒绝旧版本覆盖新版本。搜索结果只返回商品标识和展示快照，下单时仍回到权威服务重新校验价格、库存、权限和商品状态。

索引映射、分词、同义词和排序规则通过新索引版本验证，采用别名切换和增量追平。消息失败进入死信，定期比较数据库和索引文档数量、版本和关键字段，发现差异后补偿或重建。搜索故障时使用缓存热门商品或简单查询降级，不能因为搜索结果不可用就错误下单。监控查询延迟、命中率、索引延迟、分片热点、消费积压和数据差异。

九、综合知识练习

题1

为什么搜索引擎通常不应作为交易数据的唯一权威来源？

参考答案：搜索引擎主要为查询和索引优化，更新具有延迟、分片和重建过程，通常缺少交易所需的完整约束和事务语义。交易数据应保存在权威系统，搜索引擎作为可重建的派生视图。

题2

选择 NoSQL 前应重点分析什么？

参考答案：数据模型、访问模式、查询和聚合、一致性、事务、容量、扩展、热点、故障恢复、备份、团队能力和长期运维成本，不能只依据单项性能指标。

题3

索引同步失败如何处理？

参考答案：记录事件和版本，使用重试、退避、死信和人工处理；定期全量或增量对账，支持从权威数据重建索引；查询侧可降级，不能静默丢失变更。

十、论文写作素材

论文中可以这样描述 NoSQL 和搜索引擎演化：

“针对关系数据库难以同时承载海量灵活数据和全文检索的问题，我按照数据模型和访问模式引入 NoSQL 与搜索引擎。关系数据库继续作为交易数据权威来源，NoSQL 用于高吞吐和特定访问场景，搜索引擎保存可重建的查询索引。数据库提交后通过可靠事件或变更捕获同步下游，消息带版本和幂等标识，失败进入死信并通过对账和重建收敛。索引采用分片、副本、冷热分层和生命周期管理，映射变化通过新索引、增量追平和别名切换完成；搜索故障时采用缓存和回源降级，确保查询优化不破坏交易正确性。”

十一、今日复盘

NoSQL 和搜索引擎是针对特定数据模型和访问模式的补充，不是关系数据库的简单替代。
选择存储要考虑一致性、事务、查询、容量、热点和运维能力。
搜索引擎通常是可重建的派生系统，交易数据仍应有权威来源。
索引同步需要事件、版本、幂等、重试、死信、对账和重建。
分片、副本、生命周期、备份和降级决定分布式存储的可靠性。
案例答题要写清数据权威、同步链路、一致性窗口和故障恢复。