可否完全使用ElasticSearch代替數(shù)據(jù)庫存儲？我們使用elasticsearch存儲了近50億個文檔（包括1個副本，近100億個文檔），共有10個數(shù)據(jù)節(jié)點和2個元數(shù)據(jù)節(jié)點（48gb內(nèi)存，8核C

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

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

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

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

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

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

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

會嘗試使用es而不是傳統(tǒng)的NoSQL，因為它的水平擴展機制太方便了。