使用ElasticSearch作为真理的来源

Question

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

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

例如，如果我下了订单，订单将插入到DB中，那么就会有一个RabbitMQ侦听器/批处理，它将数据从DB同步到ES。

不知怎么的，这个系统甚至只有一百万条记录都失败了。当我说“失败”时，它意味着记录没有以ES的形式及时更新，例如，我创建了一个优惠券，然后在DB中生成优惠券，当产生优惠券时，客户试图立即赎回它，尽管ES还没有关于优惠券的信息，所以它失败了。当然有一些选项可以使用RabbitMQ的优先级队列等，但是我得到的问题是非常基本的

我脑子里没有几个问题，我问过团队，但仍然没有得到令人满意的答案。

1. 当我们使用弹性搜索时，最小负载应该是什么?如果我们只有1M的记录，这难道不是一个过头吗？
2. 使用ES作为实时数据的真实来源真的有意义吗？
3. ES是否用于处理类似关系的数据库，以及处理不断更新的数据？AFAIK这样的搜索优化数据库都是一次写，多读类.
4. 如果我们这样做是为了处理负载，那么它与将MSSQL数据库集群作为真理的来源和使用ES进行分析有什么不同呢？

我想到的主要问题是，我们如何优化这个体系结构，使我们能够更好地扩展？

PS:当我问到最小负载时，我真正的意思是，我们可以说ES比传统关系数据库快的记录/事务的数量是多少？还是根本就没有这样的术语？

Answer 1

1. 当我们使用弹性搜索时，最小负载应该是什么?如果我们只有1M的记录，这难道不是一个过头吗？

答:可能的负载取决于服务器的功能。

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

来自ES网站："Elasticsearch是一个分布式的、RESTful搜索和分析引擎，能够解决越来越多的用例。作为弹性堆栈的核心，它集中存储您的数据，以便您能够发现预期和发现意外情况。“

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

1. ES是否用于处理类似关系的数据库，以及处理不断更新的数据？AFAIK这样的搜索优化数据库都是一次写，多读类.

这是一个很好的点，作为任何最终一致的系统，它确实没有优化到一系列的修改！

1. 如果我们这样做是为了处理负载，那么它与将MSSQL数据库集群作为真理的来源和使用ES进行分析有什么不同呢？

不会的。请记住，上面引用的ES是为了适应搜索和分析的需求而构建的。如果这不是你打算用它做的，你应该考虑另一个工具。为正确的工作使用正确的工具。

Answer 2

1)不存在最小期望荷载。您可以有2个小节点(主节点和数据)，每个索引有2个碎片(1个主节点+1个副本)。

如果从功能的角度来看(即如何搜索数据)，您也可以将数据拆分为多个索引。

2)根据我的经验，您从ElasticSearch获得的主要好处是：

• 接近线性可伸缩性。
• 基于Lucene的文本搜索。
• 使用数据的许多方法: RESTful查询API，Kibana.
• 易于管理(与典型的RDBMS相比)。

如果您的项目没有得到这些好处，那么极有可能ES不是适合这项工作的工具。

3) ElasticSearch不喜欢频繁更新的数据。最好的用例是只读数据.

无论如何，这并不能解释您所获得的高延迟；您的问题必须在于RabbitMQ或网络。

4)实际上，这就是我要做的: MSSQL集群用于应用程序数据，ES用于分析。