654.38+00億文檔)，共有* * * 654.38+00個數據節點和2個元數據節點(48GB內存，8核CPU，es使用70%的內存)，每天文檔增量約3000W(速度
持續增加)。目前單個文檔的查詢效率基本處於實時狀態；從1到2周的數據的聚合統計操作也可以在10秒內返回結果。
然而，仍有改進的余地:
1.對於查詢單個數據的應用場景，我們可以使用ES路由機制，將所有具有相同特征(比如相同的userid)的文檔存儲在壹個節點的同壹個索引中，這樣我們後續的查詢就可以直接定位在這個節點上，而不需要將查詢廣播到所有節點；
2.隨著數據節點的增加，適當增加碎片的數量以提高系統的分布水平，也可以通過分而治之來優化查詢性能；
我個人覺得Elasticsearch作為壹個內部存儲還是不錯的，效率基本可以滿足。也有可能在某些方面取代傳統的DB，前提是妳的業務無法運營。
性事務有特殊要求；而權限管理也不必如此細致，因為ES的權限並不完善。因為我們的ES的應用場景只是在於壹定時間段內的數據聚合運算，並沒有大量的短文。
文件請求(比如通過userid找到壹個用戶的文檔，類似於NoSQL的應用場景)，所以是否能替代NoSQL需要妳自己測試。如果我有選擇，我會的
會盡量用ES代替傳統的NoSQL，因為它的橫向擴展機制太方便了。