一、背景介紹

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

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

圖片

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

圖片

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

• 數(shù)據(jù)庫版本：mysql-8.0.18
• ElasticSearch 版本：6.1.0

二、數(shù)據(jù)庫性能測試

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

今天我們就一起來實戰(zhàn)觀察，先直接利用數(shù)據(jù)庫工具來測試一下！

2.1、CRUD測試

2.1.1、查詢測試

• 通過主鍵id，搜索信息

圖片

圖片

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

圖片

圖片

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

圖片

圖片

圖片

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

2.1.2、新增測試

• 插入一條數(shù)據(jù)，姓名趙云

圖片

圖片

從數(shù)據(jù)上看，插入耗時比較短！

2.1.3、修改測試

• 通過主鍵id，修改信息

圖片

圖片

• 通過非主鍵，修改信息

圖片

圖片

可以很清晰的看到，如果通過主鍵ID來修改會非?？欤绻峭ㄟ^非主鍵修改會非常慢！

2.4、刪除測試

• 通過主鍵id，刪除數(shù)據(jù)

圖片

圖片

• 通過非主鍵字段，刪除數(shù)據(jù)

圖片

圖片

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

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

2.2、為字段添加索引

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

圖片

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

圖片

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

圖片

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

圖片

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

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

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

當然創(chuàng)建過多的索引也有缺點！

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

因此，在實際開發(fā)中，還需要根據(jù)具體的業(yè)務場景來確定哪些字段需要創(chuàng)建索引！

三、Elasticsearch 性能測試

說完數(shù)據(jù)庫，我們接著來看看 Elasticsearch 的表現(xiàn)如何！

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

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

圖片

3.1、CRUD測試

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

圖片

圖片

圖片

從數(shù)據(jù)結果上看，耗時基本在0.5s之內(nèi)，可以說吊打從數(shù)據(jù)庫直接查詢數(shù)據(jù)的耗時！

3.1.2、新增測試

插入一條數(shù)據(jù)，耗時0.2s左右，結果如下：

圖片

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

圖片

3.1.3、修改測試

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

圖片

圖片

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

圖片

查詢王小賤信息！

圖片

3.1.4、刪除測試

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

圖片

四、總結

本文內(nèi)容，主要圍繞數(shù)據(jù)庫與 ElasticSearch，在大數(shù)據(jù)查詢方面，性能的實測比較！

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