問題來源
最近新做一個項目，有部分搜索比較頻繁的數(shù)據(jù)，而且量級比較大，預(yù)計一兩年時間很可能達到100G，項目要求不要存在數(shù)據(jù)庫中，最終出來有兩個方案，一個是使用Protocol Buffers存儲在文件上，另外就是存在Elasticsearch中，也方便搜索，但這兩個方案需要驗證，到底哪個方案好，從存儲速度，搜索響應(yīng)，占用空間方面做對比，而我負責(zé)給出Elasticsearch的部分技術(shù)建議！
驗證需求
1、數(shù)據(jù)量：初步只算52億條
2、寫數(shù)據(jù)速度：需要超過1W條每秒
遇到問題以及解決辦法
而在驗證過程中遇到了無論是使用Elasticsearch.Net或者PlainElastic.Net來寫數(shù)據(jù)，并且是使用了Bulk的api，加上多線程，都是太慢了，粗略算了一下，大概一秒插入3千條左右，這樣的話，52億條數(shù)據(jù)，得插到何年何月啊，太慢了，根據(jù)查閱資料，網(wǎng)上也有人說插入數(shù)據(jù)還是挺快 的，一秒可以插入18w條，但具體也沒說是用什么辦法插入的，所以只能到官方看看了，發(fā)現(xiàn)用REST API的_bulk來批量插入，這樣速度明顯快了，可以達到5到10w條每秒，速度還可以，但問題是這方法是先定義一定格式的json文件，然后再用curl命令去執(zhí)行Elasticsearch的_bulk來批量插入，所以得把數(shù)據(jù)寫進json文件，然后再通過批處理，執(zhí)行文件插入數(shù)據(jù)，另外在生成json文件，文件不能過大，過大會報錯，所以建議生成10M一個文件，然后分別去執(zhí)行這些小文件就可以了，說了這么多都是文字，真的有點暈乎乎的，看圖吧！
