一、背景介紹

我們都知道，ElasticSearch 真正的強大的地方在于面對海量數據，依然能實現高效搜索，既然如此，本篇就以此為基礎，將數據庫查詢與 Elasticsearch 進行查詢性能對比，看看誰的查詢速度更快！

廢話不多說，先新建一張學生表student，字段內容如下：

圖片

為了貼近海量數據這一特性，小編特意在學生表student中造了1千萬條數據，本來是想造 1個億的，但是造數據實在太耗時了，挑戰比較大，當一張表的數據量到達1千萬時，查詢性能查詢已經很明顯了，所以造 1 個億的夢想暫且擱置！

圖片

下面，我們就一起來看看兩者之間的性能差別！

• 數據庫版本：mysql-8.0.18
• ElasticSearch 版本：6.1.0

二、數據庫性能測試

可能有些同學很好奇，當一張表的數據量到達1千萬之后，單表的增刪改查是否如往常一樣高效？

今天我們就一起來實戰觀察，先直接利用數據庫工具來測試一下！

2.1、CRUD測試

2.1.1、查詢測試

• 通過主鍵id，搜索信息

圖片

圖片

• 通過非主鍵id，搜索姓名張三1的信息

圖片

圖片

可以很清晰的看到，搜索花費時間6s，可能有些同學不信，一條查詢結果無法令人信服，那我換別的名稱測試一下！

圖片

圖片

圖片

從數據上，可以很清晰的看到，如果通過主鍵ID查詢會非常快，但是如果通過非主鍵字段查詢比較慢，一個單表查詢平均耗時 6s！

2.1.2、新增測試

• 插入一條數據，姓名趙云

圖片

圖片

從數據上看，插入耗時比較短！

2.1.3、修改測試

• 通過主鍵id，修改信息

圖片

圖片

• 通過非主鍵，修改信息

圖片

圖片

可以很清晰的看到，如果通過主鍵ID來修改會非常快，如果是通過非主鍵修改會非常慢！

2.4、刪除測試

• 通過主鍵id，刪除數據

圖片

圖片

• 通過非主鍵字段，刪除數據

圖片

圖片

從數據上可以看出，當通過主鍵ID進行刪除非常快，但通過非主鍵刪除超級慢！

總結：從curd測試結果來看，一張單表數據超過1千萬時，增刪改查效率會逐漸變慢！一般情況下，我們的接口請求都會設置超時時間，例如，頻繁的查詢功能都需要耗時6秒，接口請求基本百分之百的報超時錯誤！

2.2、為字段添加索引

面對這種情況應該如何應對呢？首先我們試試給關鍵字段name添加索引！

圖片

再來，搜索姓名張三1的信息，結果如下：

圖片

搜索姓名張三88的信息，耗時結果如下：

圖片

搜索姓名張三8888的信息，耗時結果如下：

圖片

從結果上看，整體耗時：0.003s！

從這里，我們可以很清晰的看出：創建索引，可以大大提高表的性能！

這也說明了，為什么我們在創建表的時候，明確規定，對于關鍵的查詢字段，一定要加索引的原則！

當然創建過多的索引也有缺點！

• 第一：創建索引和維護索引比較耗費時間，當對表中的數據進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了數據的維護速度，同時隨著數據量的增加，維護索引的耗時也會更長。
• 第二：索引需要占用物理空間，隨著表數據不斷的增大，索引需要空間也會變大。

因此，在實際開發中，還需要根據具體的業務場景來確定哪些字段需要創建索引！

三、Elasticsearch 性能測試

說完數據庫，我們接著來看看 Elasticsearch 的表現如何！

為了跟數據庫中的數據量保持一直，小編也花了一些時間，將數據庫中學生表的數據全部遷移到了 Elasticsearch 中！

我們可以通過Elasticsearch-head插件登錄 Elasticsearch 的 Web 管理頁面查看結果！

圖片

3.1、CRUD測試

3.1.1、查詢測試，默認每頁最多查詢10條

圖片

圖片

圖片

從數據結果上看，耗時基本在0.5s之內，可以說吊打從數據庫直接查詢數據的耗時！

3.1.2、新增測試

插入一條數據，耗時0.2s左右，結果如下：

圖片

批量插入，耗時在0.1s左右，結果如下：

圖片

3.1.3、修改測試

修改時，只需要傳入ID即可，Elasticsearch 會根據ID作為索引，判斷是否存在，如果存在，就進行更新，如果不存在，就將其插入！

圖片

圖片

修改不存在的ID，進行請求！

圖片

查詢王小賤信息！

圖片

3.1.4、刪除測試

傳入指定ID，即可刪除信息！

圖片

四、總結

本文內容，主要圍繞數據庫與 ElasticSearch，在大數據查詢方面，性能的實測比較！

總的來看，ElasticSearch 在大數據查詢方面要遠優于從數據庫中直接查詢，因此，如果所在項目的數據庫容量已經超過千萬，建議將數據遷移到 ElasticSearch 上進行全文搜索，或者合理的使用索引，性能會明顯翻倍！