1、概念介紹

MySQL：關(guān)系型數(shù)據(jù)庫(kù)，主要面向OLTP（OLTP，也叫聯(lián)機(jī)事務(wù)處理(Online Transaction Processing)），支持事務(wù)，支持二級(jí)索引，支持sql，支持主從、Group Replication（MGR 是一個(gè)新的高可用與高擴(kuò)展的方案，集群中的任何節(jié)點(diǎn)數(shù)據(jù)都是一樣的，可以實(shí)現(xiàn)任何節(jié)點(diǎn)都可以寫(xiě)入，實(shí)現(xiàn)了真正意義上的多主。）架構(gòu)模型（本文全部以Innodb為例，不涉及別的存儲(chǔ)引擎）。

HBase：基于HDFS，支持海量數(shù)據(jù)讀寫(xiě)（尤其是寫(xiě)），支持上億行、上百萬(wàn)列的，面向列的分布式NoSql數(shù)據(jù)庫(kù)。天然分布式，主從架構(gòu)，不支持事務(wù)，不支持二級(jí)索引，不支持sql。

ElasticSearch：簡(jiǎn)稱ES是一款分布式的全文檢索框架，底層基于Lucene技術(shù)實(shí)現(xiàn)，雖然ES也提供存儲(chǔ)，檢索功能，但我一直不認(rèn)為ES是一款數(shù)據(jù)庫(kù)，但是隨著ES功能越來(lái)越強(qiáng)大，與數(shù)據(jù)庫(kù)的界限也越來(lái)越模糊。分布式，P2P架構(gòu)，但不支持事務(wù)，采用倒排索引提供全文檢索。

2、數(shù)據(jù)存儲(chǔ)方式

假設(shè)有這樣一張人員信息表：

MySQL數(shù)據(jù)庫(kù)要提前定義表結(jié)構(gòu)，數(shù)據(jù)表共有多少列（屬性）需要提前定義好，并且同時(shí)需要定義好每個(gè)列所占用的存儲(chǔ)空間。數(shù)據(jù)以行為單位組織在一起的，假如某一行的某一列沒(méi)有數(shù)據(jù)，也需要占用存儲(chǔ)空間。

HBase則是以列為單位存儲(chǔ)數(shù)據(jù)，每一列就是一個(gè)key-value，HBase的表列（屬性）不需要提前定義，而且列可以動(dòng)態(tài)擴(kuò)展，比如人員信息表中需要添加一個(gè)新的“address”字段，MySQL需要提前alter表增加字段，HBase可以直接插入即可。

ES比較靈活，索引中的field類(lèi)型可以提前定義（定義mapping），也可以不定義，如果不定義，會(huì)有一個(gè)默認(rèn)類(lèi)型，不過(guò)出于可控性考慮，關(guān)鍵字段建議提前定義好。（Solr中必須提前定義好schema.xml文件）

上圖展示了數(shù)據(jù)在MySQL和HBase中存儲(chǔ)差異（和真實(shí)的情況還有差距），可以看到即使第二條記錄的sex字段為空，MySQL依然會(huì)為該字段保留空間，因?yàn)楹罄m(xù)有可能會(huì)有update語(yǔ)句來(lái)更新該記錄，補(bǔ)上sex內(nèi)容。而HBase則是把每一列都看做是一條記錄，row+列名作為key，data作為value，依次存放。假如某一行的某一個(gè)列沒(méi)有數(shù)據(jù)，則直接跳過(guò)該列。針對(duì)稀疏矩陣的大表，HBase能大大節(jié)省存儲(chǔ)空間。

看到這里，大家是否會(huì)有一個(gè)疑問(wèn)：使用HBase存儲(chǔ)時(shí)，假如此時(shí)需要添加第二行的sex內(nèi)容，如何實(shí)現(xiàn)呢，數(shù)據(jù)是否連續(xù)？后面介紹讀寫(xiě)流程會(huì)解釋。

3、不一樣的ES

ES的存儲(chǔ)方式和上面兩個(gè)都不一樣，MySQL和HBase是將數(shù)據(jù)按不同的方式進(jìn)行存儲(chǔ)，好歹它們存的還是數(shù)據(jù)，而ES則存的是倒排索引。我們先來(lái)了解一下什么是倒排索引，以及為什么需要倒排索引（Inverted Index）：

我們肯定都會(huì)這樣的經(jīng)歷：偶然看到一段很好的文字，但是卻不知道出處，這時(shí)候去圖書(shū)館，一個(gè)一個(gè)翻找，無(wú)疑是大海撈針，這個(gè)時(shí)候便有了全文檢索這項(xiàng)技術(shù)，而它最核心的就是倒排索引。假如有如下文檔：

我們想要知道有哪些文檔含有you這個(gè)關(guān)鍵字，首先可以創(chuàng)建一個(gè)倒排索引，格式如下：

前面的部分叫做dictionary（字典），里面的每個(gè)單詞叫做term，后面的文檔列表叫做psoting-list，list中記錄了所有含有該term的文檔id，兩個(gè)組合起來(lái)就是一個(gè)完成的倒排索引（Inverted Index）。能夠看出，假如需要查找含有“you”的文檔時(shí)，根據(jù)dictionary然后找到對(duì)應(yīng)的posting-list即可。

而全文檢索中，創(chuàng)建Inverted Index是最關(guān)鍵也是最耗時(shí)的過(guò)程，而且真正的Inverted Index結(jié)構(gòu)也遠(yuǎn)比圖中展示的復(fù)雜，不僅需要對(duì)文檔進(jìn)行分詞（ES里中文可以自定義分詞器），還要計(jì)算TF-IDF，方便評(píng)分排序（當(dāng)查找you時(shí)，評(píng)分決定哪個(gè)doc顯示在前面，也就是所謂的搜索排名），壓縮等操作。每接收一個(gè)document，ES就會(huì)將其信息更新在倒排索引中。

可以看出ES和MySQL、HBase的存儲(chǔ)還是有很大的區(qū)別。而且ES不僅包含倒排索引，默認(rèn)同時(shí)還會(huì)把文檔doc存儲(chǔ)起來(lái)，所以當(dāng)我們使用ES時(shí)，也能拿到完整的文檔信息，所以某種程度上，感覺(jué)就像在使用數(shù)據(jù)庫(kù)一樣，但是也可以配置不存儲(chǔ)文檔信息，這時(shí)只能根據(jù)查詢條件得到文檔id，并不能拿到完整的文檔內(nèi)容。

總結(jié)：

MySQL：行存儲(chǔ)的方式比較適合OLTP業(yè)務(wù)。

HBase：列存儲(chǔ)的方式比較適合OLAP業(yè)務(wù)，而HBase采用了列族的方式平衡了OLTP和OLAP，支持水平擴(kuò)展，如果數(shù)據(jù)量比較大、對(duì)性能要求沒(méi)有那么高、并且對(duì)事務(wù)沒(méi)有要求的話，HBase可以考慮。

ES：ES默認(rèn)對(duì)所有字段都建了索引，所以比較適合復(fù)雜的檢索或全文檢索。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-786326.html

到了這里，關(guān)于es_MySQL、HBase、ElasticSearch三者對(duì)比詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！