我已经读过ElasticSearch在耐久性方面不是最可靠的，但是我想用它来在读取端存储数据以便进行最佳搜索。
如果我们将事件（写入端）存储在cassandra数据库中，这意味着数据永远不会丢失。
我真的不明白“数据持久性”的含义是什么 如果我们在读取端使用ES，这是否意味着某些数据可能无法正确导入？是否意味着有一天数据可能会随机丢失，或者有一天所有数据可能已经消失的风险？
用例是一个类似Twitter的地理定位应用程序
最终是否可靠地在读取端使用ES，而不需要更可靠的数据存储（写入端）来存储数据？
根据这个＆＃34;耐久性＆＃34;的含义，我想知道应该采取什么措施重播事件并始终保持ES一致。
由于
答案 0 :(得分：2)
我在生产中没有大量运行ES的经验，但实际上，确保当您持久保存数据时，它保持持久性，特别是在分布式系统中，很难。有很多很多边缘情况很难做到，数据库需要时间才能成熟并对这些边缘情况进行排序。一个不太耐用的数据库可能没有解决所有这些问题。
当然，ElasticSearch是一个受欢迎的开源数据库，有一个繁荣的社区维护它，因此可能没有明确定义的情况，“你的数据将在这种情况下丢失”，而是，有可能的情况要么没有来还有，或者当他们遇到了疯狂的用户时，遇到他们的用户并不在乎调试它，因为他们只使用ES作为辅助数据存储，并且能够从他们的主服务器重建它数据存储。每当发现一个案例表明ES在很好理解的情况下丢失了数据时，ES的维护者就会很快解决这个问题。
ES的最典型用例是作为辅助数据库存储，在这种用例中，持久性并不重要，因为可以从主数据库重建数据存储。因此，你会发现持久性并不是ES的维护者的优先考虑因为他们的用户并没有要求它 - 这并不是说它不是一个高优先级，只是相对于其他数据库而言，它不是那么高。 / p>
所以，如果你使用ES，那么你遇到错误的机会就会比其他更成熟的数据库更容易遇到错误，或者更多地关注开发中的持久性。
至于您是否应该定期删除ES数据库并重放事件，这实际上取决于您的用例以及ES数据库保持一致的重要性。围绕ES耐久性的许多边缘情况可能导致严重数据丢失的严重损坏 - 即，您将知道它是否发生，因此在这种情况下不需要定期丢弃和重放。另一件需要考虑的事情是，由于CQRS读取方式的工作方式，您的ES存储库只有有限数量的编写器，您可以轻松控制并发性。这意味着加载的峰值不会导致并发编写器出现峰值，会发生的情况是您的ES存储可能会暂时滞后于主存储的一致性。因此，您可能不太可能遇到可能触发ES丢失数据的边缘情况。
所以，除非发生灾难性事件，否则你可能不会费心去掉和重建，除非以一种你不会注意到的方式默默地丢失少量数据的后果如此之高，以至于这种可能性非常小发生是不可接受的。