es mysql 適用場景對比
問題一
全文檢索毫無疑問直接上es，那么除了這種場景，什么時候該選es？為啥mysql不行？
對枚舉字段的搜索
mysql創(chuàng)建索引的原則是對于那些區(qū)別度高字段建立索引，區(qū)別度越高的索引，在數(shù)據(jù)量大的情況下，索引效果越好。
因為mysql建立b+樹時是這樣，每創(chuàng)建一行就新建立索引字段，如果需要對枚舉類型的字段進行搜索的時候比如該字段是布爾型只有兩種值，對這種值進行搜索即使建立了索引效果仍然不好，如果一張表有千萬數(shù)據(jù)，其中有
五百萬數(shù)據(jù)是該值為true，需要搜索表中為true的數(shù)據(jù)，即使掃描索引，也要掃描500萬次。
而es則不同，es建立的倒排索引是索引值后面跟了一個倒排列表，也就是只需要最多掃描兩次便能找到數(shù)據(jù)。
復(fù)雜條件的搜索
當搜索的條件足夠復(fù)雜后，比如10多個條件字段的搜索，由于b+樹的特性，不可能同時對這10多個字段建立聯(lián)合索引，此時用上es就很合適。es可以將10多個條件字段求出各自的bitmap，然后求交集。
問題二
拋開問題一的兩種場景，當數(shù)據(jù)量越來越大時，應(yīng)該選用es作為存儲嗎？
es針對海量數(shù)據(jù)的存儲與搜索的好處在于，其水平擴容的便捷性。
mysql在數(shù)據(jù)量大了以后，涉及到分庫分表，而分庫分表帶來的問題的是什么？其一是分庫分表時，數(shù)據(jù)的遷移，需要考慮遷移過程中業(yè)務(wù)是否受到影響。其二在于 分庫分表后業(yè)務(wù)系統(tǒng)的改動，比如翻頁邏輯，可能需要去到每個庫或表中查出前n條數(shù)據(jù)，然后進行翻頁。
而es將擴容部分的這些都做了，es存數(shù)據(jù)是天然的分片存儲，在海量數(shù)據(jù)查詢時，可以通過增加副本的機制分擔讀壓力。
那是不是在選用數(shù)據(jù)存儲時，直接選用es就好了呢，這樣以后可以不用擔心擴容問題？
當然不是，來說說選用es的問題。
es比較吃系統(tǒng)資源。
來看一組數(shù)據(jù)，雖然環(huán)境有差異，可能不太準確，但能說明一定問題。
一臺4c8g的 linux 云數(shù)據(jù)庫，能支持大約上萬qps，內(nèi)存占用大概6g。
而我用一臺mac m1 的8c 16g機器去做查詢壓測，當qps達到3700時，cpu就已經(jīng)去到480% 超過了4核。
所以在產(chǎn)品并發(fā)量不高的情況下，只從數(shù)據(jù)存儲而言，選用mysql會更節(jié)約成本。
但是單機的性能的確有限，如果產(chǎn)品對數(shù)據(jù)庫的qps需要去到好幾萬，即使選用最高配的機器也是無法支撐的，這時選用多臺便宜的機器來做將數(shù)據(jù)做分布式存儲將更有優(yōu)勢。
所以我認為，當查詢量越來越大以后，選用es來做海量數(shù)據(jù)存儲，將不會擔心數(shù)據(jù)查詢問題，隨著查詢壓力的上漲，可以通過增加副本來解決，雖然mysql可以通過分庫分表解決，但是正如前面而言，分庫分表的成本是比較大且風險是高于es擴容的，es增加副本帶來的分片數(shù)據(jù)遷移工作，是由es集群自身完成，這樣對于整個架構(gòu)的擴展性來說是最高效便捷的。文章來源：http://www.zghlxwxcb.cn/news/detail-464316.html
感嘆一句，架構(gòu)就是這樣，有得必有失，帶來了架構(gòu)的便捷性，但是可能對于mysql分庫分表方案會更貴一點。文章來源地址http://www.zghlxwxcb.cn/news/detail-464316.html
到了這里，關(guān)于es mysql 適用場景對比的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
