一、背景介紹

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

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

圖片

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

圖片

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

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

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

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

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

2.1、CRUD測試

2.1.1、查詢測試

• 通過主鍵id，搜索信息

圖片

圖片

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

圖片

圖片

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

圖片

圖片

圖片

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

2.1.2、新增測試

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

圖片

圖片

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

2.1.3、修改測試

• 通過主鍵id，修改信息

圖片

圖片

• 通過非主鍵，修改信息

圖片

圖片

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

2.4、刪除測試

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

圖片

圖片

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

圖片

圖片

從數(shù)據(jù)上可以看出，當(dāng)通過主鍵ID進(jìn)行刪除非?？欤ㄟ^非主鍵刪除超級慢！

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

2.2、為字段添加索引

面對這種情況應(yīng)該如何應(yīng)對呢？首先我們試試給關(guān)鍵字段name添加索引！

圖片

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

圖片

搜索姓名張三88的信息，耗時(shí)結(jié)果如下：

圖片

搜索姓名張三8888的信息，耗時(shí)結(jié)果如下：

圖片

從結(jié)果上看，整體耗時(shí)：0.003s！

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

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

當(dāng)然創(chuàng)建過多的索引也有缺點(diǎn)！

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

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

三、Elasticsearch 性能測試

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

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

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

圖片

3.1、CRUD測試

3.1.1、查詢測試，默認(rèn)每頁最多查詢10條

圖片

圖片

圖片

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

3.1.2、新增測試

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

圖片

批量插入，耗時(shí)在0.1s左右，結(jié)果如下：

圖片

3.1.3、修改測試

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

圖片

圖片

修改不存在的ID，進(jìn)行請求！

圖片

查詢王小賤信息！

圖片

3.1.4、刪除測試

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

圖片

四、總結(jié)

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

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