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

我已经看到很多关于这个主题的类似问题(包括这个问题,它讨论了ElasticSearch版本6如何克服了它作为主要数据存储的许多限制),但我仍然不清楚以下内容:

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

这是我的数据库的简化版本(用户可以在网站上发布产品待售)

我正在学习ElasticSearch(这很棒),我想用它来搜索我网站上的产品.我不需要搜索User和ProductReview - 只有Product表.

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

MySQL和ES中的重复产品表

在MySQL和产品中保留用户和ProductReview

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

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

ES是否可靠成为主要的数据来源？

在某个时间点,如果我必须修改Product表结构,我是否可以在不删除和重新创建产品索引的情况下执行此操作？

在MySQL的情况下,我通常备份Prod DB并在测试数据库上恢复它...是否仍然可以使用ES进行从Prod到Test的备份和恢复？

我没有ES/NoSQL的经验,我很感激任何建议.

让我指出,Elasticsearch不是一个数据库,在这个词的严格意义上的开始,应该最好不这样使用.然而,没有什么可以阻止你这样做(很多人都这样做)并且根据Elastic的优秀人员,他们不会努力尝试让ES成为真正的数据库.ES的主要目标是成为一个快速可靠的搜索和分析引擎.

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

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

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

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

如果您在游戏中投入足够的精力和金钱,ES可以作为真实的主要来源.但是,您可能还没有数百万的产品和用户(因此),因此拥有一个至少有三个节点的HA群集来搜索具有少量字段的数千个产品似乎不是一个好消费.

当您的产品表更改时,很容易将表重新索引到ES(甚至是实时),如果您有几千个产品,它可以足够快,您不必担心它.如果由于某种原因同步失败,您可以再次运行该过程而不会浪费太多时间.使用零停机别名技术,您可以在不影响用户的情况下完成此操作.

ES还提供快照/恢复功能,以便您可以拍摄PROD快照并使用单个REST调用将其安装在TEST群集中.