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