我了解到 ElasticSearch 在持久性方面并不是最可靠的，但我想使用它在读取端存储数据以实现最佳搜索。
如果我们将事件（写入端）存储在 cassandra 数据库中，这意味着数据永远不会真正丢失。
我不太明白“数据持久性”是什么意思。
如果我们在读取端使用 ES，是否意味着某些数据可能无法正确导入？这是否意味着有一天数据可能会随机丢失，或者所有数据可能有一天会消失的风险？
用例是一个类似 Twitter 的基于地理位置的应用程序。
最终只在读取端使用 ES，而不需要更可靠的数据存储（写入端）来存储数据到底有多可靠？
根据这种“持久性”的含义，我想知道应该采取什么措施来重播事件并始终保持 ES 一致。
谢谢
【问题讨论】：
标签： elasticsearch cqrs lagom
我没有大量在生产环境中运行 ES 的经验，但从本质上讲，确保当您持久化数据时，它会保持持久化，尤其是在分布式系统中，这很难。有很多很多边缘情况很难正确处理，数据库需要时间来成熟并整理出这些边缘情况。不太耐用的数据库可能还没有解决所有这些问题。
当然，ElasticSearch 是流行的开源数据库，有一个蓬勃发展的社区维护它，因此可能没有明确定义的案例“您的数据会在这种情况下丢失”，而是可能没有出现的案例跨过，或者当他们在野外被用户遇到时，遇到他们的用户并没有足够关心调试它，因为他们只使用 ES 作为辅助数据存储，并且能够从他们的主数据库重建它数据存储。每当发现 ES 在易于理解的情况下丢失数据的情况下，ES 的维护者都会迅速修复它。
ES 最典型的用例是作为辅助数据库存储，在这种用例中，持久性并不那么重要，因为可以从主数据库重建数据存储。因此，您会发现持久性对于 ES 的维护者来说并没有那么高的优先级，因为他们的用户没有要求它——这并不是说它不是一个高优先级，只是相对于其他数据库而言，它没有那么高。
因此，如果您使用 ES，与其他更成熟或在开发过程中更注重持久性的数据库相比，您遇到会丢失数据的错误的可能性更高。
至于是否应该定期删除 ES 数据库并重放事件，这实际上取决于您的用例以及 ES 数据库保持一致的重要性。围绕 ES 持久性的许多边缘情况可能会导致严重的损坏并导致大量数据丢失 - 即，您会知道它是否发生，因此在这种情况下无需定期删除和重放。要考虑的另一件事是，由于 CQRS 读取边的工作方式，您的 ES 存储中只有有限数量的写入器，并且您可以轻松控制该并发。这意味着负载的峰值不会导致并发写入者的峰值，将会发生的是您的 ES 存储可能暂时落后于主存储的一致性。因此，您可能不太可能遇到可能触发 ES 丢失数据的边缘情况。
因此，除非发生灾难性事件，否则您可能不会费心放弃和重建，除非以您不会注意到的方式默默丢失少量数据的后果如此之高，以至于发生这种情况的可能性非常小发生是不可接受的。
【讨论】：
我知道这个话题已经超过 3 年了，但我也将 Elasticsearch 用于 CQRS 的读取端，但我认为还有其他平台更适合写入端，但它不仅仅是一种数据库技术，在今天的活动中更多的源范式是必要的，我正在使用 Akka 的有限状态机和 Cassandra，在我看来，它更适合排序极端写入负载，而不是 Elasticsearch。
我写了一篇关于它的博客，如果有人喜欢看，Write Side for Elasticsearch CQRS
【讨论】：