elasticsearch - CQRS(Lagom)elasticsearch读取侧

Question

我已经读过，ElasticSearch在持久性方面并不是最可靠的，但是我想用它在读取侧存储数据以实现最佳搜索。
如果我们将事件(写端)存储在cassandra数据库中，则意味着数据永远不会真正丢失。

我不太了解“数据持久性”的含义。
如果我们在读取端使用ES，这是否意味着某些数据可能无法正确导入？这是否意味着有一天可能会随机丢失数据，或者有一天可能会丢失所有数据的风险？

用例是一个类似Twitter的基于地理位置的应用程序。
最终，仅在读取侧使用ES而不需要更可靠的数据存储(写入侧)来存储数据到底有多可靠？
取决于“持久性”的含义，我想知道应该采取什么措施来重播事件并使ES始终保持一致。

谢谢

Answer 1

我没有在生产中运行ES的大量经验，但是从本质上讲，确保持久存储数据(尤其是在分布式系统中)时保持持久性很难。有很多很难解决的极端情况，数据库成熟并整理这些极端情况需要花费时间。持久性较差的数据库可能尚未解决所有这些问题。

当然，ElasticSearch是一个受欢迎的开源数据库，拥有蓬勃发展的社区对其进行维护，因此可能没有明确定义的案例，“在这种情况下您的数据将丢失”，相反，可能还没有遇到过这样的案例，或当用户在野外遇到它们时，遇到他们的用户并不关心调试它，因为他们仅将ES用作辅助数据存储并能够从其主数据存储中重建它。只要确定在众所周知的情况下ES丢失数据的情况，ES的维护者就会迅速解决。

ES的最典型用例是作为辅助数据库存储，在这种用例中，持久性并不重要，因为可以从主数据库重建数据存储。因此，您会发现持久性并不是ES维护者的优先事项，因为他们的用户并没有要求持久性-这并不是说它并不是一个高度优先事项，就相对于其他数据库而言，它并不那么重要。

因此，与使用更成熟或在开发中更加注重持久性的其他数据库相比，如果使用ES，则遇到丢失数据的错误的机会更大。

至于是否应该定期删除ES数据库并重播事件，这实际上取决于您的用例以及保持ES数据库一致性的重要性。 ES耐用性的许多边缘情况都可能导致重大破坏，并造成大量数据丢失-即，您会知道它是否会发生，因此在这种情况下无需定期删除和重播。还要考虑的另一件事是，由于CQRS读取方的工作方式，您在ES存储区中的写入器数量有限，并且您可以轻松地控制该并发性。这意味着加载的高峰不会导致并发写入器的高峰，这将是您的ES存储可能暂时滞后于主存储的一致性。因此，您不太可能遇到可能触发ES丢失数据的边缘情况。

因此，除非灾难性事件发生，否则您可能不会打扰删除和重建，除非以您不会注意到的方式静默丢失少量数据的后果如此之大，以致发生这种情况的可能性极小，这是 Not Acceptable 。