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