为什么使用 Elasticsearch 很糟糕，因为我需要实时数据检索，而不仅仅是快速搜索

Source: Dev.to

🚧 我实际在解决的问题

在生产环境中，我们的痛点不是搜索速度。
而是实时的正确性。

我们有一些工作流要求：

• 用户操作必须立即反映
• 状态变化必须在毫秒级可见
• “最终一致”根本无法向客户或支持团队交代

但当时，我把问题框定错了：

“查询慢 → 加入 Elasticsearch”

这种框定让我们损失了数月时间。

🔍 大规模时出了什么问题

Elasticsearch 正如它所承诺的那样：

• 对已索引数据进行快速、分布式搜索。

它 不 承诺的则是：

• 强实时保证
• 写入后的立即一致性
• 作为事务性流程的主数据源

在真实的生产流量中，我们开始看到：

• 最近更新的记录在结果中缺失
• 写入成功但读取延迟的边缘情况
• 复杂的重试和刷新逻辑渗入业务代码

每个 bug 看似“罕见”，但累计起来却是常态。
非技术利益相关者并不在乎原因，只看到不可靠的数据。

⚖️ 我低估的权衡

Elasticsearch 用性能换取了即时的正确性。
我们需要的是 写后可预测的读取。

🧠 给我留下深刻印象的教训

错误并不是使用 Elasticsearch 本身。
错误在于把它当作弥补需求定义不清的工具。

• 快速搜索 ≠ 实时数据检索
• 索引 ≠ 状态管理
• 可扩展性 ≠ 正确性

当我们把架构重新围绕以下核心：

• 一个主的、强一致性的数据存储
• 明确的读/写路径
• 仅在搜索有意义的场景下使用搜索

系统变得更平稳，事故下降，工程师也睡得更安稳。

🌱 这改变了我设计系统的方式

如今，我在引入“强大”基础设施时会更谨慎。
在添加任何新东西之前，我会问：

1. 这个系统给我什么保证？
2. 它明确 不 给我什么保证？
3. 六个月后我会在调试什么样的故障？

大多数生产痛点并非工具不足，而是保证不匹配。

结束语

Elasticsearch 是一款优秀的工具，只是它并不适合需要信任而非速度的问题。

经验告诉我，架构成熟度不在于掌握更多技术，而在于知道何时 不 使用它们。这个教训只能通过交付、出错以及承担后果来获得。