{"name":"ElasticSearch","id":"中间件-数据库-ElasticSearch","content":"# ElasticSearch\n\n## 一、ElasticSearch 的设计目标与哲学\n\n### 1.1 核心问题定义（第一性原理）\n\nElasticSearch 解决的不是“存数据”，而是：\n\n> **如何在海量数据上，低延迟地完成模糊搜索、相关度计算与聚合分析，并且可以横向扩展。**\n\n由此决定了 ES 的一切设计取舍。\n\n### 1.2 三个基本假设\n\n1. **搜索比事务更重要**（Search > Transaction）\n2. **读多写少，允许近实时**（NRT 而非强一致）\n3. **数据规模一定会超过单机极限**（必须分布式）\n\n这些假设直接否定了传统 OLTP 数据库的设计路径。\n\n---\n\n## 二、ES 的四大第一性模型（世界观层）\n\n### 2.1 存储模型：不可变段（Immutable Segment）\n\n* 数据一旦写入 Segment，不再修改\n* 更新 / 删除 = 标记 + 新写入\n* 通过 Merge 解决空间与性能问题\n\n**本质动机**：\n\n* 避免随机写\n* 最大化顺序 IO\n* 提升查询并发与缓存命中率\n\n> **不可变性是 ES 高并发搜索的根基。**\n\n---\n\n### 2.2 计算模型：Shard 级并行计算\n\n* 一个 Shard = 一个 Lucene Index\n* 查询在所有 Shard 上并行执行\n* 结果在协调节点做 Reduce\n\n**推论**：\n\n* Shard 是性能与扩展的最小单元\n* 过多 / 过少分片都会导致系统退化\n\n---\n\n### 2.3 一致性模型：主分片 + 最终一致\n\n* 写入只发生在 Primary Shard\n* Replica 异步复制\n* 通过 seq_no + primary_term 实现乐观锁\n\n**本质取舍**：\n\n> 用一致性换可用性与性能（CAP 中偏向 AP）。\n\n---\n\n### 2.4 扩展性模型：水平扩展优先\n\n* 不支持自动拆分单个 Shard\n* 扩展靠 Shard 在节点间重新分布\n\n**结论**：\n\n> 分片数是一次性架构决策，不是运行期参数。\n\n---\n\n## 三、核心抽象模型（概念边界澄清）\n\n### 3.1 概念层级映射\n\n| 抽象层 | ES 概念    | 本质含义       |\n| --- | -------- | ---------- |\n| 集群  | Cluster  | 资源与状态一致性边界 |\n| 节点  | Node     | 计算与存储执行单元  |\n| 索引  | Index    | 逻辑数据集合     |\n| 分片  | Shard    | 并行与扩展单位    |\n| 段   | Segment  | 不可变倒排索引文件  |\n| 文档  | Document | 最小检索对象     |\n\n> **Index ≠ Database，Shard ≠ Table Partition。**\n\n---\n\n## 四、数据生命周期（从写入到消亡）\n\n### 4.1 写入路径（近实时本质）\n\n1. 写入 Memory Buffer + Translog\n2. Refresh：生成可搜索 Segment（1s）\n3. Flush：Segment 持久化 + Commit Point\n4. Merge：后台合并段文件\n\n**关键认知**：\n\n* 可搜索 ≠ 已落盘\n* Refresh 是搜索语义，Flush 是持久化语义\n\n---\n\n### 4.2 读取与搜索路径\n\n* Shard 本地执行 Query\n* 利用 Filesystem Cache\n* 协调节点完成排序 / 分页 / 聚合\n\n> 搜索性能 ≈ Cache 命中率 × 并行度\n\n---\n\n## 五、分布式查询与算分模型\n\n### 5.1 两阶段搜索模型\n\n1. Query Phase：每个 Shard 本地算分\n2. Fetch Phase：协调节点拉取文档\n\n### 5.2 算分不准的根因\n\n* Shard 之间统计信息隔离\n* IDF 基于局部数据\n\n**解决方案**：\n\n* 单主分片\n* dfs_query_then_fetch\n\n---\n\n## 六、数据建模的工程哲学\n\n### 6.1 建模第一原则\n\n1. **为查询建模，而非为存储建模**\n2. **反范式优于范式**\n3. **写入成本 < 查询复杂度**\n\n### 6.2 三种结构的取舍\n\n| 模型           | 使用场景  | 代价       |\n| ------------ | ----- | -------- |\n| 扁平文档         | 默认选择  | 写入冗余     |\n| Nested       | 局部强关联 | 查询慢      |\n| Parent-Child | 高频更新  | 内存与算分成本高 |\n\n---\n\n## 七、资源与性能模型\n\n### 7.1 三大瓶颈\n\n* CPU：查询、聚合、脚本\n* 内存：Segment Metadata / Fielddata\n* IO：Merge / 冷数据访问\n\n### 7.2 缓存哲学\n\n* Filesystem Cache 是王者\n* ES 内部缓存是辅助\n\n> **不给 OS 内存，就是主动放弃性能。**\n\n---\n\n## 八、容量规划与演进策略\n\n### 8.1 容量规划不是算公式\n\n而是回答：\n\n* 数据增长曲线\n* 查询模型稳定性\n* 故障时是否可降级\n\n### 8.2 索引演进策略\n\n* 时间分区（日志）\n* 业务分区（实体数据）\n* ILM：Hot → Warm → Cold → Delete\n\n---\n\n## 九、治理、监控与系统稳定性\n\n### 9.1 Cluster State 是核心共享资源\n\n* Mapping\n* Shard 元数据\n* Index 配置\n\n**原则**：\n\n> 减少变更频率，控制规模。\n\n### 9.2 健康度认知\n\n* Green：理想态\n* Yellow：可运行但有风险\n* Red：服务不完整\n\n---\n\n## 十、反模式（Anti-Patterns）\n\n* 把 ES 当数据库用\n* 大量 Join / Nested 查询\n* 无限制深度分页\n* 动态字段失控\n* 分片数拍脑袋\n\n---\n\n## 十一、ES 的能力边界\n\n### ES 适合\n\n* 搜索\n* 实时分析\n* 日志与行为数据\n\n### ES 不适合\n\n* 强事务\n* 账务系统\n* 复杂关系型查询\n\n## 关联内容（自动生成）\n\n- [/数据技术/检索技术.md](/数据技术/检索技术.md) 检索技术涵盖了倒排索引、搜索空间裁剪、候选生成等核心技术，与ElasticSearch的搜索原理和实现机制密切相关\n- [/中间件/数据库/索引.md](/中间件/数据库/索引.md) 索引技术详细介绍了B+树、哈希索引、位图索引等数据结构，这些是ElasticSearch中段（Segment）和倒排索引的底层实现基础\n- [/软件工程/架构/系统设计/分布式/分布式系统.md](/软件工程/架构/系统设计/分布式/分布式系统.md) 分布式系统理论涵盖了CAP定理、一致性模型、分片策略等概念，这些都是ElasticSearch分布式架构设计的核心原理\n- [/中间件/数据库/分布式数据库.md](/中间件/数据库/分布式数据库.md) 分布式数据库的分片（Sharding）、副本复制、一致性模型等内容与ElasticSearch的分布式架构和数据管理方式有诸多相似之处，可作对比参考\n","metadata":"tags: ['中间件', '分布式系统', '数据库']","hasMoreCommit":true,"totalCommits":26,"commitList":[{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2026-01-12T19:35:20+08:00","author":"MY","message":"doc(elasticsearch): 重构文档","hash":"355474c70caf0df19eec17610dba76906c6ef7b1"},{"date":"2024-12-12T15:26:38+08:00","author":"MY","message":"📦ES","hash":"28b974130d8b4a8ae778d39e061492a9ceeaf871"},{"date":"2024-11-20T19:43:10+08:00","author":"MY","message":"✏ES","hash":"270b0046fd04c188311d1ec73be1cd3b76a9c403"},{"date":"2024-07-17T15:54:07+08:00","author":"MY","message":"✏ES","hash":"06cfd00bffe6d7d4c91c3aad727c982645d3aeea"},{"date":"2024-07-10T20:07:07+08:00","author":"MY","message":"✏ES","hash":"530693ddb6a170ef95e83e016a78b99c6a3c2afb"},{"date":"2024-07-09T20:10:40+08:00","author":"MY","message":"✏ES","hash":"5ca1fa41444725bf69b3a526fb578f57a2110978"},{"date":"2024-07-08T20:12:06+08:00","author":"MY","message":"✏ES","hash":"1d37eaff55d1d757c29cddf43495f567cfeaa82e"},{"date":"2024-07-08T17:04:51+08:00","author":"MY","message":"✏ES","hash":"073af9b7436f29f48782ac072e87c0cd99887823"},{"date":"2024-07-04T16:10:57+08:00","author":"MY","message":"✏ES","hash":"e954c3ec638854e03ec500320021f9e573e998eb"}],"createTime":"2019-09-03T22:29:51+08:00"}