這是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數據庫作爲你的主要數據源，你就會好起來的。