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

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

就我而言，沒(méi)有場(chǎng)景的速度測(cè)試是無(wú)賴的。根據(jù)需求場(chǎng)景優(yōu)化數(shù)據(jù)庫(kù)和選擇數(shù)據(jù)庫(kù)前后的速度肯定是不同的。

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

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

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

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

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

我們使用elasticsearch存儲(chǔ)了近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ù)增長(zhǎng)）。目前單個(gè)文檔的查詢效率基本處于實(shí)時(shí)狀態(tài)；對(duì)于1到2周數(shù)據(jù)的聚合統(tǒng)計(jì)操作，結(jié)果也可以在10秒內(nèi)返回。

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

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

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

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

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

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

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