使用 ElasticSearch 作为事实来源

Question

我正在与一个使用两个数据源的团队合作。

1. MSSQL 作为进行事务调用的主要数据源。
2. ES 作为查看数据的备份/只读事实来源。

例如，如果我下了一个订单，订单被插入到数据库中，然后有一个RabbitMQ监听器/批处理，然后将数据从数据库同步到ES。

不知怎的，即使只有一百万条记录，这个系统也会失败。当我说失败时，意味着ES中的记录没有及时更新，例如假设我创建了一张优惠券，然后在DB中生成了优惠券，当优惠券生成后，客户立即尝试兑换它，尽管ES没有'还没有优惠券的信息，所以失败。当然，可以选择使用 RabbitMQ 的优先级队列等，但我遇到的问题非常基本

我心里有几个问题，我向团队询问过，但仍然没有得到满意的答案

1. 当我们使用elasticsearch时，我们应该期望的最小负载是多少，如果我们只有1M条记录，这不是大材小用吗？
2. 使用 ES 作为实时数据的真实来源真的有意义吗？
3. ES 是为了处理类似关系型数据库以及处理不断更新的数据而设计的吗？据我所知，这种搜索优化的数据库是一次写入、多次读取的类型。
4. 如果我们这样做是为了处理负载，那么这与将 MSSQL 数据库集群作为事实来源并使用 ES 仅用于分析有何不同？

我想到的主要问题是，我们如何优化这个架构，以便更好地扩展？

PS： 当我问最小负载时，我真正的意思是我们可以说 ES 比传统关系数据库更快的记录/事务数量是多少？或者根本就没有这个词？

Answer 1

1. 当我们使用elasticsearch时，我们应该期望的最小负载是多少，如果我们只有1M条记录，这不是大材小用吗？

答：可能的负载取决于您服务器的能力

2. 使用 ES 作为实时数据的真实来源真的有意义吗？

来自 ES 网站：“Elasticsearch 是一个分布式、RESTful 搜索和分析引擎，能够解决越来越多的用例。作为 Elastic Stack 的核心，它集中存储您的数据，以便您可以发现预期的结果并发现意外的结果。”

所以，是的，它可以是你的真相来源，也就是说，它是“最终一致的”，这提出了一个问题，它需要多长时间才能被认为是“实时的”……如果不进行测试和测量，就无法回答这个问题你的系统 。

3. ES 是为了处理类似关系型数据库以及处理不断更新的数据而设计的吗？据我所知，这种搜索优化的数据库是一次写入、多次读取的类型。

这是一个很好的观点，因为任何最终一致的系统，它确实没有针对一系列修改进行优化！

4. 如果我们这样做是为了处理负载，那么这与将 MSSQL 数据库集群作为事实来源并使用 ES 仅用于分析有何不同？

不会的。请记住，如上所述，ES 是为了满足搜索和分析的要求而构建的。如果这不是您打算用它做的事情，您应该考虑使用其他工具。使用正确的工具完成正确的工作。