这是elasticsearch的正确用法吗？

Question

我有一个包含超过100个表的MySQL数据库。 CMS使用该数据库，每6小时一次，PHP脚本使用所有这些表，并使用大量逻辑，计算和SQL连接，并生成一个包含超过100万行的大型数据集，并将其插入到一张我们称之为“交易”。这基本上与50列的表和大量的优化指标和每一行都有同样的东西，这样的事情：

dealid，价格，产品名称，productcolor，productdimensions，onstock，品牌等

这个“交易”表格然后被许多其他前端和后端应用程序用于各种目的。示例如下：客户可以在其上进行过滤然后查看结果的页面。客户可以在其上查找交易信息的页面。由包含品牌X的所有产品（从1,000,000行表中+/- 150,000行）的联营公司使用的XML馈送。 iOS应用程序，用于向您显示可用于iPhone的附件类型。所有这些应用程序都使用相同的1,000,000行MySQL表格轻松查找和显示数据。

随着“交易”表增长，这些应用程序正在遇到速度问题。 MySQL处理这些数字似乎有很多麻烦。我不希望事实如此，但也许只有一台具有32GB RAM和8核心的MySQL服务器是一个问题。这不是一个升级到128GB内存的服务器的选项，也不是我真的相信这实际上可以解决问题。

我做了一个小小的PHP脚本，除了将1,000,000行插入到MySQL之外，还将它们在elasticsearch中编入索引。然后，我在一个简单的沙盒过滤应用程序中测试了MySQL表和ES索引。与基于MySQL的应用程序相比，基于ES的应用程序的速度是绝对惊人的。所以它看起来像速度明智，ES胜。

所以..这是一个ES实例的正确用法？或者我错误地认为ES会成为我的MySQL速度问题的最佳解决方案？

Answer 1

是的 - 这听起来像ES将是伟大的您的要求！ ES具有很高的可扩展性，速度非常快 - 100万行应该很容易。

您需要观察内存使用情况，安全性，事务性。

但是，只要你保持你的MySQL数据库作为你的主要数据源，你就会好起来的。