使用ElasticSeach作为我的部分DB的主要源

Question

我看到了许多类似于这个主题的问题(包括这个讨论了ElasticSearch版本6如何克服了它作为主要数据存储的许多限制)，但我仍然不清楚以下几点：

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

这是my的简化版本(用户可以在网站上发布产品以供销售)

​

​

我正在学习ElasticSearch，我想用它来搜索我的网站上的产品。我不需要用户和ProductReview被搜索，只有产品表。

我可以想出两个解决方案来实现这一点：

1. 定期将产品表从MySQL复制到ES
2. 在ES中保留用户和ProductReview中的MySQL和Product

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

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

• ES作为主要数据来源可靠吗？
• 在某个时候，如果我必须修改Product结构，我是否能够这样做而不删除和重新创建产品索引？
• 如果是MySQL，我通常会备份Prod并在Test上恢复它.是否仍然可以使用ES进行从Prod到Test的备份和恢复？

我没有使用ES/NoSQL的经验，希望得到任何建议。

Answer 1

首先，我要指出，严格意义上说，Elasticsearch不是一个数据库，在理想情况下不应该使用。然而，没有什么能阻止你去做它(而且很多人都在这么做)，根据弹性公司的好人所说，他们永远不会努力使ES成为一个真正的数据库。专家系统的主要目标是成为一个快速可靠的搜索和分析引擎。

如果可以的话，您应该始终保留另一个主要的真理来源，如果有什么事情发生了，您可以随时轻松地(重新)建立您的ES索引。

在您的情况下，选项1似乎是可行的，因为您只想让用户搜索您的产品，所以没有必要同步ES中的其他表。

选项2听起来很有吸引力，但是只有当您决定只使用ES时，如果您想要依赖事务(ES没有事务支持)，就不应该使用ES。另一件您需要知道的事情是，如果您只在ES中拥有数据，并且您的索引由于某种原因(在升级期间、ES中的bug、代码中的bug等等)而损坏，那么您的数据就会消失，您的业务就会受到影响。

因此，为了更准确地回答你的问题：

1. 如果你在游戏中投入足够的努力和金钱，ES可以作为一个主要的真理来源。然而，您可能还没有数百万的产品和用户(目前为止)，因此，拥有一个至少有三个节点的HA集群来搜索几千个有几个字段的产品似乎不太好。
2. 当您的products表发生更改时，很容易将表重新索引到ES中(甚至在实时中)，如果您有几千个产品，那么它的速度就足够快了，您不必真正担心它。如果由于某种原因同步失败，您可以再次运行该进程，而不会浪费太多时间。使用零停机别名技术，您可以在不影响用户的情况下这样做。
3. ES还提供快照/还原功能，以便您可以获取PROD的快照，并使用单个REST调用将其安装在测试集群中。

Answer 2

解决这个问题的方法很多.这就是我最后所做的：

我选择了选项1，并构建了一个同步器来定期将我的产品复制到Elasticsearch。其实很简单..。我实现了这里解释的方法：如何使数据库与ElasticSearch同步使用Elasticsearch嵌套客户端