可否完全使用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核C

可否完全使用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è)文檔的查詢(xún)效率基本處于實(shí)時(shí)狀態(tài)；對(duì)于1到2周數(shù)據(jù)的聚合統(tǒng)計(jì)操作，結(jié)果也可以在10秒內(nèi)返回。

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

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

]我覺(jué)得彈性搜索是可行的適合內(nèi)部存儲(chǔ)，效率基本可以滿(mǎn)足。在某些方面也可以取代傳統(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找到用戶(hù)的文檔，類(lèi)似于NoSQL的應(yīng)用場(chǎng)景），它是否能取代NoSQL還需要自己的測(cè)試。如果我有選擇的話(huà)，我

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