为什么强调检索层定位
Elasticsearch 面向检索与分析：写入到可搜索之间有刷新间隔，更新是整篇文档重建，没有跨文档事务，深分页也受结果窗口限制。这些特性决定了它更适合当检索与分析层，而不是唯一的数据真相。
常见架构长什么样
权威数据放在关系库或文档库，通过变更捕获或同步任务写进 ES 承担检索与聚合，需要重建索引时可以从主存回灌。这样即使索引被误删或映射改错，也能在可控时间内恢复。按 ID 读取是实时的，所以"写入后立刻回查详情"这类需求用 ID 查询就能满足。
基本信息
| 近实时 | 默认 refresh_interval 为 1 秒，搜索可见性有延迟 |
|---|---|
| 更新成本 | 文档级整体重建，频繁更新字段代价高、段合并压力大 |
| 事务 | 没有跨文档事务，只有文档级版本并发控制 |
| 分页 | from 加 size 受结果窗口限制，深分页要用 search_after 或 PIT |
| 按 ID 读取 | 实时，不受刷新间隔影响 |
示例
示例
# 写入后立刻搜索可能查不到（还没刷新）
POST /orders/_doc/1
{ "status": "created" }
GET /orders/_search?q=status:created
# 按 ID 读取不受 refresh 影响，写入后立即可见
GET /orders/_doc/1
# 确实需要立刻可搜索时显式刷新（代价高，不适合高频调用）
POST /orders/_refresh典型使用场景
- 站内搜索：商品、文章与日志的全文检索与聚合统计
- 读写分离：主存负责事务与一致性，检索层负责查询与排序
- 重建索引：映射调整后从主存回灌，不影响在线写入
- 日志分析：高写入吞吐、近实时检索的场景
- 多条件筛选：把复杂的组合查询与排序交给检索层
关键差异与建议
| 关注点 | ES 的表现 | 架构建议 |
|---|---|---|
| 写入可见性 | 近实时，存在刷新延迟 | 实时性敏感的场景改用按 ID 读取 |
| 更新 | 整篇重建，更新放大 | 高频变化字段留在主存，减少更新 |
| 事务 | 无跨文档事务 | 关键约束放在主存，检索层只做副本 |
| 分页 | 深分页受限 | 用 search_after 或 PIT 代替 from 加 size |
常见架构是主存加检索副本：权威数据在主存，经同步链路写入 ES 承担检索与聚合，重建索引可以从主存随时回灌。
把 ES 当唯一数据源时，一次误删索引就是数据事故；快照仓库、回灌链路与索引模板要当作基础设施提前建好，而不是出事后再补。