使用ElasticSeach作为我的部分数据库的主要来源

Question

我已经看到很多关于这个主题的类似问题（including this one，它讨论了ElasticSearch版本6如何克服了它作为主要数据存储的许多限制），但我仍然不清楚以下内容：< / p>

我正在创建一个在线购物网站，我使用MySQL作为我的数据库。

这是我的数据库的简化版本（用户可以在网站上发布产品）

我正在学习ElasticSearch（这很棒），我想用它来搜索我网站上的产品。我不需要搜索用户和 ProductReview - 仅产品表。

我可以想到两个解决方案来实现这个目标：

1. 在MySQL和ES中复制产品表
2. 在MySQL和产品中保留用户和 ProductReview

据我所知，如果我使用选项1，那么我可以使用go-mysql-elasticsearch将MySQL与ES同步：这是一个很好的解决方案吗？

我更倾向于使用选项2，因为它更容易，我不需要担心数据同步。我对此选项的担忧是：

• ES是否可靠成为主要的数据来源？
• 在某个时间点，如果我必须修改Product表结构，我是否可以在不删除和重新创建产品索引的情况下这样做？
• 如果是MySQL，我通常会备份Prod DB并将其恢复到测试数据库中......是否仍然可以使用ES从Prod进行备份和恢复测试？

我没有ES / NoSQL的经验，并且不胜感激。

Answer 1

首先让我说明Elasticsearch不是一个严格意义上的数据库， 理想情况下不应该这样使用。然而，没有什么可以阻止你这样做（很多人都这样做）并且根据Elastic的优秀人员，他们不会努力尝试让ES成为真正的数据库。 ES的主要目标是成为一个快速可靠的搜索和分析引擎。

如果可以的话，你应该始终保留另一个主要的事实来源，如果有什么东西可以随时轻松（重新）建立你的ES索引。

在您的情况下，选项1似乎是要走的路，因为您要做的就是允许用户搜索您的产品，因此在同步ES中的其他表时毫无意义。

选项2听起来很有吸引力，但只有当你决定只使用ES时，如果你想依赖交易，你真的不应该这样做（ES没有交易支持）。您需要知道的另一件事是，如果您只有ES中的数据并且您的索引由于某种原因（在升级期间，ES中的错误，代码中的错误等）被破坏，您的数据就会消失，您的业务也就会消失会受苦。

所以更准确地回答你的问题：

1. 如果您在游戏中投入足够的精力和金钱，ES可以作为真实的主要来源。但是，您可能还没有数百万的产品和用户（因此），因此拥有一个至少有三个节点的HA群集来搜索具有少量字段的数千种产品并不是一件好事。 / p>

2. 当您的产品表发生变化时，很容易将表重新索引到ES中（甚至在real time中），如果您有几千种产品，它可以足够快以至于您没有＃39真的要担心它。如果由于某种原因同步失败，您可以再次运行该过程而不会浪费太多时间。使用zero-downtime alias technique，您可以在不影响用户的情况下执行此操作。

3. ES还提供快照/恢复功能，以便您可以拍摄PROD的快照，并通过一次REST调用将其安装在TEST群集中。

Answer 2

有很多方法可以解决这个问题......这就是我最终要做的事情：

我选择了选项1并构建了一个Synchronizer来定期将我的产品复制到Elasticsearch。实际上非常简单......我使用How To Synchronize a Database With ElasticSearch

实现了此处说明的方法：Elasticsearch NEST Client