Elasticsearch到底能玩多大的數據量？

01-09

聽說能玩到PB級，聽說可以上百個節點，但一切都是聽說。
網上搜索的結果大多就是做個日誌分析之類的，一天幾個T（只是峰值）就算大數據量了。
到底有沒有哪家公司用ES處理了很大數據量的？

這邀請，我也沒法回答啊，因為我就是那個「就是做個日誌分析之類的，一天幾個T（只是峰值）就算大數據量了」。每天6-8TB的水準吧。

Elastic{ON}2015上是有公司的演講說了自己單集群100+的nodes，然後一共有1000+的nodes在運行。關於PB的數據，我沒印象。

-------------------

補充幾個slide好了：

http://www.slideshare.net/TinLe1/elk-atlinked-in linkedin的ELK演講，單集群規模應該還沒我大，不過也是有好多個集群。

https://www.elastic.co/elasticon/2015/sf/scaling-elasticsearch-for-production-at-verizon Verizon的ELK演講。

單獨看ES能玩多大數據意義不大，具體實踐中往往因為各種業務要求而無法繼續增加數據量。目大的方面考慮有如下幾點：

1、查詢速度。ES可以支持的查詢類型多種多樣，單一的term匹配，複雜的historm agg，甚至父子文檔模式下bool查詢之後繼續做文本高亮，數據量越大查詢時間越長。如果只是簡單的把數據寫進去然後按照ID獲取數據，那就儘管往裡面寫數據吧。

2、寫入速度。數據量越大，寫入速度受影響的可能性越大。業務要求1小時的數據1小時內必須寫完，如果做不到就得考慮分索引或者分集群了。

3、更新速度。同上，更新比單純的寫入操作更多，先get再merge再overwrite到es。

4、其他因素。

目前我遇到的ES集群，有1.5T-2T索引量的情況下，需要支持平均查詢在500ms以內的高並發高亮查詢。在我們的場景下這個量級不算小了。

目前我們項目中用的32個節點，數據是目前只是TB級別的，偶爾會出現問題，一般是因為網路的原因，導致節點鏈接不正常，其他沒有發現什麼異常

我們用ES索引上百萬台伺服器的日誌，每小時shard一個index，目前數據量幾百TB吧

ES很好scale，數據量多的話如果可以多線程查詢多個index根本感覺不出來性能差別

線上看過相關數據，數據量十億，訪問qps一萬是能夠承受的。

目前我們業務數據量20T，因為磁碟緊張，會定期刪除數據。

es玩的數據得看你的數據是不是高可靠的，普通的數據上不封頂。

FireEye 分享了，PB，2000台機器。

http://www.infoq.com/cn/articles/elasticsearch-with-aws-scaling-to-pb-scale

那得看有多少機器…

Netflex 去年的公開數據說已經超過一共超過 2000 個 nodes，當然是多個集群。我個人很少聽說公司 in production 真的用了很多nodes

補充公開的use case ：

https://www.elastic.co/use-cases

真到了PB級就要優化了

應付常見的日誌摘要和分析是沒問題的，按三斗說的數據來看，上PB級的數據量也不是難事。

但數據容量，二次抽洗，以及周邊生態，還是沒有Hadoop來得好

我們現在有二十幾個節點大約100億左右數據，運行的非常好

這真的要依照應用場景測試，我最多用過4台 16核60GB內存1TB SSD的ES集群，並不是很大。如果有PB級的數據還是用hadoop吧，如果不是要用「全文檢索」，就分析各日誌用不到ES。

PS：ES比較消耗內存，成本是比較高的。