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

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

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

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

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

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

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

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

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