【发布时间】：2015-02-05 10:02:08
【问题描述】：
我有一个包含 100 多个表的 MySQL 数据库。该数据库由 CMS 使用，每 6 小时，PHP 脚本会使用所有这些具有大量逻辑、计算和 SQL 连接的表，并生成一个包含超过 100 万行的大型数据集，并将其插入到我们称之为“交易”的表中”。这基本上是一个有 50 列和许多优化索引的表，每一行都有相同的内容，如下所示：
交易、价格、产品名称、产品颜色、产品尺寸、库存、品牌等。
此“交易”表随后被许多其他前端和后端应用程序用于各种目的。例如：客户可以在其上过滤然后查看结果的页面。客户可以在其上找到有关交易的信息的页面。关联公司使用的 XML 提要，其中包含品牌 X 的所有产品（来自 1,000,000 行表的 +/- 150,000 行）。一个 iOS 应用程序，用于向您展示您的 iPhone 有哪些可用的配件。所有这些应用程序都使用同一个 1,000,000 行 MySQL 表来轻松查找和显示数据。
随着“交易”表的增长，这些应用程序遇到了速度问题。 MySQL 似乎在处理这些数字时遇到了很多麻烦。我不希望出现这种情况，但也许只有一台具有 32GB RAM 和 8 个内核的 MySQL 服务器是个问题。升级到几台具有 128GB RAM 的服务器不是一种选择，而且我也不太相信这真的能解决问题。
我制作了一个小的 PHP 脚本，除了将 1,000,000 行插入 MySQL 之外，还在 elasticsearch 中对它们进行索引。然后，我在一个简单的沙盒过滤应用程序中测试了 MySQL 表和 ES 索引。与基于 MySQL 的应用程序相比，基于 ES 的应用程序的速度绝对惊人。所以看起来在速度方面，ES 赢了。
那么.. 这是 ES 实例的正确用法吗？还是我错误地认为 ES 将是解决我的 MySQL 速度问题的最佳解决方案？
【问题讨论】：
标签： php mysql database elasticsearch database-performance