按照id查詢，mysql、es、hbase三個(gè)哪個(gè)更快？就我而言，沒有場景的速度測試是無賴的。根據(jù)需求場景優(yōu)化數(shù)據(jù)庫和選擇數(shù)據(jù)庫前后的速度肯定是不同的。如果在一般情況下只有一個(gè)ID索引，這意味著您需要

按照id查詢，mysql、es、hbase三個(gè)哪個(gè)更快？

就我而言，沒有場景的速度測試是無賴的。根據(jù)需求場景優(yōu)化數(shù)據(jù)庫和選擇數(shù)據(jù)庫前后的速度肯定是不同的。

如果在一般情況下只有一個(gè)ID索引，這意味著您需要通過此ID定位數(shù)據(jù)，那么MySQL是最快的。毫無疑問。

在非結(jié)構(gòu)化文檔中，ES是最快的，數(shù)據(jù)量越大，速度就越快，因?yàn)镋S是NoSQL非關(guān)系數(shù)據(jù)庫，沒有事務(wù)處理能力。然而，ES作為一種基于Lucence服務(wù)器的全文搜索服務(wù)，非常適合于全文搜索。然而，ES一般用于復(fù)雜多變的檢索環(huán)境，單一的ID不能反映ES的性能。

對于大規(guī)模數(shù)據(jù)，HBase絕對是根據(jù)范圍讀寫數(shù)據(jù)的最佳選擇，它為大規(guī)模數(shù)據(jù)場景提供了更好的可擴(kuò)展性。

。我會在這里發(fā)表所有有關(guān)科技的有趣文章。偶爾，我能回答一些有趣的問題。如果您有任何問題，可以隨時(shí)在評論區(qū)回復(fù)和討論。

可否完全使用ElasticSearch代替數(shù)據(jù)庫存儲？

我們使用elasticsearch存儲了近50億個(gè)文檔（包括1個(gè)副本，近100億個(gè)文檔），共有10個(gè)數(shù)據(jù)節(jié)點(diǎn)和2個(gè)元數(shù)據(jù)節(jié)點(diǎn)（48gb內(nèi)存，8核CPU，ES占用70%內(nèi)存），每天文檔增量約3000W（速度

持續(xù)增長）。目前單個(gè)文檔的查詢效率基本處于實(shí)時(shí)狀態(tài)；對于1到2周數(shù)據(jù)的聚合統(tǒng)計(jì)操作，結(jié)果也可以在10秒內(nèi)返回。

但是對于查詢單個(gè)數(shù)據(jù)的應(yīng)用場景還有改進(jìn)的空間，我們可以使用ES的路由機(jī)制，將所有具有相同特征（如相同的userid）的文檔存儲在一個(gè)節(jié)點(diǎn)的同一索引中，這樣我們后續(xù)的查詢就可以直接定位在這個(gè)節(jié)點(diǎn)上，而不是將查詢廣播到所有節(jié)點(diǎn)上；

2隨著數(shù)據(jù)節(jié)點(diǎn)的增加，適當(dāng)增加分區(qū)的數(shù)量，提高系統(tǒng)的分布水平，通過分而治之的方式優(yōu)化查詢性能；

]我覺得彈性搜索是可行的適合內(nèi)部存儲，效率基本可以滿足。在某些方面也可以取代傳統(tǒng)的數(shù)據(jù)庫，前提是您的業(yè)務(wù)不具備可操作性

]特殊要求；而且由于ES權(quán)限不完善，權(quán)限管理也不太詳細(xì)。因?yàn)槲覀儗τ贓S的應(yīng)用場景只是在一定的時(shí)間段內(nèi)聚合數(shù)據(jù)，并且沒有大量的單文件請求（比如通過userid找到用戶的文檔，類似于NoSQL的應(yīng)用場景），它是否能取代NoSQL還需要自己的測試。如果我有選擇的話，我

會嘗試使用es而不是傳統(tǒng)的NoSQL，因?yàn)樗乃綌U(kuò)展機(jī)制太方便了。

es可以替代數(shù)據(jù)庫嗎？

Es更注重近實(shí)時(shí)搜索。數(shù)據(jù)庫更加注重?cái)?shù)據(jù)的存儲和查詢。兩種場景的使用是不同的，我們不能說誰代替誰。