MySQL：關(guān)系型數(shù)據(jù)庫，主要面向OLTP，支持事務(wù)，支持二級索引，支持sql，支持主從、Group Replication架構(gòu)模型（本文全部以Innodb為例，不涉及別的存儲引擎）。

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

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

Hbase

基本概念

HBase是一個分布式、可擴(kuò)展、高性能的列式存儲系統(tǒng)，基于Google的Bigtable設(shè)計。它是Hadoop生態(tài)系統(tǒng)的一部分，可以與HDFS、MapReduce、ZooKeeper等組件集成。HBase的主要特點是提供低延遲的隨機(jī)讀寫訪問，支持大規(guī)模數(shù)據(jù)的存儲和管理。

HBase核心概念：

• HFile：HBase的底層存儲結(jié)構(gòu)，是一個自平衡的B+樹。HFile可以存儲多個表的數(shù)據(jù)，并支持隨機(jī)讀寫訪問。HFile的索引功能是基于B+樹的索引實現(xiàn)的，可以提高查詢性能。
• MemStore：HBase的內(nèi)存存儲結(jié)構(gòu)，是HFile的基礎(chǔ)。MemStore是一個有序的鍵值對緩存，每次寫入數(shù)據(jù)時，數(shù)據(jù)首先寫入MemStore，然后定期刷新到HFile。MemStore的搜索功能是基于內(nèi)存中的數(shù)據(jù)實現(xiàn)的，可以提高查詢性能。
• Bloom過濾器：HBase使用Bloom過濾器來減少不必要的磁盤訪問。Bloom過濾器是一種概率數(shù)據(jù)結(jié)構(gòu)，可以用來判斷一個元素是否在一個集合中。Bloom過濾器可以提高查詢性能，減少磁盤I/O。
• 索引文件：HBase為每個表創(chuàng)建一個索引文件，用于存儲表中的所有列名。索引文件可以幫助查詢引擎快速定位需要查詢的列，提高查詢性能。
• 搜索引擎：HBase提供了一個基本的搜索引擎，可以用來實現(xiàn)基本的模糊查詢和范圍查詢。搜索引擎使用了一些基本的搜索算法，如詞法分析、詞匯分析、排序等。

HRegion是HBase中的基本存儲單元，負(fù)責(zé)存儲一部分行鍵(Row Key)對應(yīng)的數(shù)據(jù)。HRegion內(nèi)部由多個HStore組成，每個HStore存儲一部分列族(Column Family)的數(shù)據(jù)。MemStore中存儲的是用戶寫入的數(shù)據(jù)，一旦MemStore存儲達(dá)到閾值時，里面存儲的數(shù)據(jù)就會被刷新到新生成的StoreFile中(底層是HFile)，該文件是以HFile的格式存儲到HDFS上，具體如圖4所示。

HRegion支持自動分區(qū)：
HBase中的一個表，剛創(chuàng)建時，只有一個HRegion，隨著數(shù)據(jù)量遞增，達(dá)到閾值時，等分成兩個HRegion，分布在不同的HRegionServer結(jié)點上。閾值由屬性hbase.hregion.max.filesize指定，默認(rèn)10G

HBase是一個分布式系統(tǒng)，這點跟MySQL不同，它的數(shù)據(jù)是分散不同的server上，每個table由一個或多個region組成，region分散在集群中的server上，一個server可以負(fù)責(zé)多個region。

這里有一點需要特別注意：table中各個region的存放數(shù)據(jù)的rowkey（主鍵）范圍是不會重疊的，可以認(rèn)為region上數(shù)據(jù)基于rowkey全局有序，每個region負(fù)責(zé)它自己的那一部分的數(shù)據(jù)。

索引原理

Hbase寫流程：

WAL是保存在HDFS上的持久化文件。數(shù)據(jù)到達(dá) Region 時先寫入WAL，然后被加載到MemStore中。這樣就算Region宕機(jī)了，操作沒來得及執(zhí)行持久化，也可以再重啟的時候從WAL加載操作并執(zhí)行。跟Redis的AOF類似。

• Client 先訪問 zookeeper，訪問 /hbase/meta-region-server 獲取 hbase:meta 表位于哪個 Region Server。
• 訪問對應(yīng)的 Region Server，獲取 hbase:meta 表，根據(jù)讀請求的 namespace:table/rowkey，查詢出目標(biāo)數(shù)據(jù)位于哪個 Region Server 中的哪個 Region 中。并將該 table 的 Region 信息以及 meta 表的位置信息緩存在客戶端的 meta cache，方便下次訪問。
• 與目標(biāo) Region Server 進(jìn)行通訊。
• 將數(shù)據(jù)順序?qū)懭耄ㄗ芳樱┑?WAL。
• 將數(shù)據(jù)寫入對應(yīng)的 MemStore，數(shù)據(jù)會在 MemStore 進(jìn)行排序。
• 向客戶端發(fā)送 ack，此處可看到數(shù)據(jù)不是必須落盤的。
• 等達(dá)到 MemStore 的刷寫時機(jī)后，將數(shù)據(jù)刷寫到 HFile
• 在web頁面查看的時候會隨機(jī)的給每一個Region生成一個隨機(jī)編號。

Hbase讀流程：

• Client 先訪問 ZooKeeper，獲取 hbase:meta 表位于哪個 Region Server。
• 訪問對應(yīng)的 Region Server，獲取 hbase:meta 表，根據(jù)讀請求的 namespace:table/rowkey， 查詢出目標(biāo)數(shù)據(jù)位于哪個 Region Server 中的哪個 Region 中。并將該 table 的 region 信息以 及 meta 表的位置信息緩存在客戶端的 meta cache，方便下次訪問。
• 與目標(biāo) Region Server 進(jìn)行通訊。
• 分別在 Block Cache(讀緩存)，MemStore 和 Store File(HFile)中查詢目標(biāo)數(shù)據(jù)，并將 查到的所有數(shù)據(jù)進(jìn)行合并。此處所有數(shù)據(jù)是指同一條數(shù)據(jù)的不同版本(time stamp)或者不同的類型(Put/Delete)。
• 將從文件HFile中查詢到的數(shù)據(jù)塊(Block，HFile 數(shù)據(jù)存儲單元，默認(rèn)大小為 64KB)緩存到 Block Cache。
• 將合并后的最終結(jié)果，然后返回時間最新的數(shù)據(jù)返回給客戶端。

性能調(diào)優(yōu)

1，HBase預(yù)分區(qū)：

HBase表在剛剛被創(chuàng)建時，只有1個分區(qū)（region），當(dāng)一個region過大（達(dá)到hbase.hregion.max.filesize屬性中定義的閾值，默認(rèn)10GB）時，表將會進(jìn)行split，分裂為2個分區(qū)。表在進(jìn)行split的時候，會耗費大量的資源，頻繁的分區(qū)對HBase的性能有巨大的影響。

HBase提供了預(yù)分區(qū)功能，即用戶可以在創(chuàng)建表的時候?qū)Ρ戆凑找欢ǖ囊?guī)則分區(qū)。減少由于region split帶來的資源消耗。從而提高HBase的性能。

2，定期進(jìn)行Major Compaction：

HBase中的數(shù)據(jù)是以StoreFile的形式存儲的，隨著數(shù)據(jù)的不斷寫入，StoreFile的數(shù)量會逐漸增加，影響查詢效率。

優(yōu)化方案
定期執(zhí)行Major Compaction操作，將多個小文件合并成一個大文件，減少StoreFile的數(shù)量。

ElasticSearch

基本概念

ElasticSearch 是一個分布式的搜索引擎，所以一般由多臺物理機(jī)組成。每個物理機(jī)器上可以有多個節(jié)點，使用不同的端口和節(jié)點名稱。節(jié)點按主要功能可以分為三種：主節(jié)點(Master Node)，協(xié)調(diào)節(jié)點(Coordianting Node)和數(shù)據(jù)節(jié)點(Data Node)：

• 主節(jié)點：處理創(chuàng)建，刪除索引等請求，維護(hù)集群狀態(tài)信息?？梢栽O(shè)置一個節(jié)點不承擔(dān)主節(jié)點角色
• 協(xié)調(diào)節(jié)點：負(fù)責(zé)處理請求。默認(rèn)情況下，每個節(jié)點都可以是協(xié)調(diào)節(jié)點。
• 數(shù)據(jù)節(jié)點：用來保存數(shù)據(jù)?？梢栽O(shè)置一個節(jié)點不承擔(dān)數(shù)據(jù)節(jié)點角色

• Index (索引)

Index(索引) 是具有稍微類似特征文檔的集合，同在一個索引中的文檔共同建立倒排索引。類似于 MySQL 中的 database 概念，但 ES 中的 Index 更加靈活，用起來也更加方便。提交給同一個索引中的文檔，最好擁有相同的結(jié)構(gòu)。這樣對于 ES 來說，不管是存儲還是查詢，都更容易優(yōu)化。

• 分片 & 副本（Shards & Replicas）

索引可以存儲大量的數(shù)據(jù)，可能會超過單個節(jié)點的硬件限制，而且會導(dǎo)致單個節(jié)點效率問題。ES 提供了將單個 Index 拆分到多個 Shard 上的能力，可以支持水平擴(kuò)展，分布式和并行跨 Shard 操作（可能在多個節(jié)點），從而提高了性能和吞吐量。
為了避免故障導(dǎo)致節(jié)點及分片出現(xiàn)問題，ES 可以為分片設(shè)置副本（Replicas），副本通常在不同的節(jié)點上，從而保證高可用性。

• 類型（Type）

Document 的類型，類似于關(guān)系型數(shù)據(jù)庫中的表的概念。該概念在6.X 時還可以使用，但在 Type 的概念已在7.X 開始廢棄，官方認(rèn)為這是個錯誤的設(shè)計。

• Document (文檔)

文檔是 ES 索引的基本單位，每個索引都是由數(shù)量眾多的文檔組成，Document 相當(dāng)于傳統(tǒng)數(shù)據(jù)庫中的行，ES 中數(shù)據(jù)以 JSON 的形式來表示。

• 字段（Fields）

每個 Document 都類似一個 JSON 結(jié)構(gòu)，它包含了許多字段，每個字段都有其對應(yīng)的值，多個字段組成了一個 Document，可以類比關(guān)系型數(shù)據(jù)庫數(shù)據(jù)表中的字段。

• 映射（mapping）

相當(dāng)于數(shù)據(jù)庫中的 schema，用來約束字段的數(shù)據(jù)類型，每一種數(shù)據(jù)類型都有對應(yīng)的使用場景。mapping 中定義了一個文檔所包含的所有 field 信息，每個文檔都有映射。mapping 不是必須創(chuàng)建，因為 ES 中實現(xiàn)了動態(tài)映射。

{
  "_index": "user",
  "_type": "_doc",
  "_id": "qbuOs4AB1VH6WaY_OsFW",
  "_version": 1,
  "_score": 1,
  "_source": {
    "name": "張三",
    "address": "廣東省深圳市",
    "remark": "他是一個程序員",
    "age": 28,
    "salary": 8800,
    "birthDate": "1991-10-05",
    "createTime": "2019-07-22T13:22:00.000Z"
  }
}

上圖為 ES 一條文檔數(shù)據(jù)，而一個文檔不只有基礎(chǔ)數(shù)據(jù)，它還包含了元數(shù)據(jù)(metadata)——關(guān)于文檔的信息，也就是用下劃線開頭的字段，它是官方提供的字段：

• _index ：文檔所屬索引名稱，即文檔存儲的地方。
• _type ：文檔所屬類型名（此處已默認(rèn)為_doc）。
• _id ：文檔的唯一標(biāo)識。在寫入的時候，可以指定該 Doc 的 ID 值，如果不指定，則系統(tǒng)自動生成一個唯一的 UUID 值。
• _score ：顧名思義，得分，也可稱之為相關(guān)性，在查詢是 ES 會 根據(jù)一些規(guī)則計算得分，并根據(jù)得分進(jìn)行倒排。除此之外，ES 支持通過 Function score query 在查詢時自定義 score 的計算規(guī)則。
• _source ：文檔的原始 JSON 數(shù)據(jù)。字段Field
• 在動態(tài)映射的作用下，name會映射成text類型，age會映射成long類型，birthDate會被映射為date類型

索引原理

我們知道ES的搜索是非?？斓?，并且比MySQL快很多，所以來看下兩者的索引原理：

• MySQL的索引原理：B+Tree索引
• ElasticSearch的索引原理：倒排索引

倒排索引：也叫反向索引，首先對文檔數(shù)據(jù)按照id進(jìn)行索引存儲，然后對文檔中的數(shù)據(jù)分詞，記錄對詞條進(jìn)行索引，并記錄詞條在文檔中出現(xiàn)的位置。這樣查找時只要找到了詞條，就找到了對應(yīng)的文檔。概括來講是先找到詞條，然后看看哪些文檔包含這些詞條。通俗地來講，正向索引是通過key找value，倒排索引則是通過value找key。跟MySQL中的索引回表查詢有點類似。

下面倒排索引簡單實例

假設(shè)我們有如下幾篇文檔:

Doc1：喬布斯去了中國。
Doc2：蘋果今年仍能占據(jù)大多數(shù)觸摸屏產(chǎn)能。
Doc3：蘋果公司首席執(zhí)行官史蒂夫·喬布斯宣布，iPad2將于3月11日在美國上市。
Doc4：喬布斯推動了世界，iPhone、iPad、iPad2，一款一款接連不斷。
Doc5：喬布斯吃了一個蘋果。

這五個文檔中的數(shù)字代表文檔的ID，比如 Doc中的1。通過這5個文檔建立簡單的倒排索引:

單詞ID(WordID) 單詞(Word) 倒排列表(DocID)

1	喬布斯	1，3，4，5
2	蘋果	2，3，5
3	iPad2	3，4
4	宣布	3
5	了	1，4，5
…	…	…

首先要用分詞系統(tǒng)將文檔自動切分成單詞序列，這樣就讓文檔轉(zhuǎn)換為由單詞序列構(gòu)成的數(shù)據(jù)流，并對每個不同的單詞賦予唯一的單詞編號(WordID)，并且每個單詞都有對應(yīng)的含有該單詞的文檔列表即倒排列表。如上表所示，第一列為單詞ID，第二列為單詞ID對應(yīng)的單詞，第三列為單詞對應(yīng)的倒排列表。如第一個單詞ID“1”對應(yīng)的單詞為“喬布斯”，單詞“喬布斯”的倒排列表為{1,3,4,5}，即文檔1、文檔3、文檔4、文檔5都包含有單詞“喬布斯”。所以當(dāng)我們搜索的關(guān)鍵字中含有喬布斯的關(guān)鍵字時，此時就能找到文檔Doc1，Doc3，Doc4，Doc5。

這上面的列表是最簡單的倒排索引，下面介紹一種更加復(fù)雜，包含信息更多的倒排索引。

單詞ID(WordID)	單詞(Word)	倒排列表(DocID;TF;<Pos>)
1	喬布斯	(1;1;<1>),(3;1;<6>),(4;1;<1>),(5;1;<1>)
2	蘋果	(2;1;<1>),(3;1;<1>),(5;1;<5>)
3	iPad2	(3;1;<8>),(4;1;<7>)
4	宣布	(3;1;<7>)
5	了	(1;1;<3>),(4;1;<3>)(5;1;<3>)
…	…	…

• TF(term frequency): 單詞在文檔中出現(xiàn)的次數(shù)。
• Pos: 單詞在文檔中出現(xiàn)的位置。

這個表格展示了更加復(fù)雜的倒排索引，前兩列不變，第三列倒排索引包含的信息為(文檔ID，單詞頻次，<單詞位置>)，比如單詞“喬布斯”對應(yīng)的倒排索引里的第一項(1;1;<1>)意思是，文檔1包含了“喬布斯”，并且在這個文檔中只出現(xiàn)了1次，位置在第一個。

性能調(diào)優(yōu)

分片的設(shè)定：對于生產(chǎn)環(huán)境中分片的設(shè)定，需要提前做好容量規(guī)劃，主分片數(shù)是在索引創(chuàng)建的時候預(yù)先設(shè)定，事后無法修改

• 分片數(shù)設(shè)置過小
  • 后續(xù)無法增加節(jié)點實現(xiàn)水平擴(kuò)展
  • 單個分片的數(shù)據(jù)量太大，導(dǎo)致數(shù)據(jù)重新分配耗時
• 分片數(shù)設(shè)置過大，7.0開始，默認(rèn)主分片設(shè)置成1，解決了over-sharding的問題
  • 影響搜索結(jié)果的相關(guān)性打分，影響統(tǒng)計結(jié)果的準(zhǔn)確性
  • 單個節(jié)點上過多的分片，會導(dǎo)致資源浪費，同時也會影響性能
  • 用圖形表示出來可能是這樣子的：

參考：
https://blog.csdn.net/weixin_42081445/article/details/144748629
https://www.cnblogs.com/aspirant/p/11004991.html
https://blog.csdn.net/sadfasdfsafadsa/article/details/141716347
https://blog.csdn.net/universsky2015/article/details/135789000

到此這篇關(guān)于MySQL中的HBase、ES的特點和區(qū)別的文章就介紹到這了,更多相關(guān)mysql HBase ES特點內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論