1. es可以一天存百萬條數據么
es不可以一天存百萬條數據。es一天最大的存儲量是90萬條數據，所以es不可以一天存百萬條數據。es全稱ElasticSearch,是一個基於Lucene的搜索伺服器。
2. ElasticSearch海量數據使用簡述
應用場景當中經常會遇到模糊查詢或多條件匹配查詢，數據量較小的情況下通過簡單的資料庫模糊查詢是可以解決的，但是對於數據量龐大的情況，資料庫模糊查詢就會出現性能問題。這種情況下的一種解決方案就是根據查詢內容構建反向索引，藉助搜索引擎進行查詢，提升查詢性能。
目前使用比較多的分布式搜索引擎是ElasticSearch。那麼項目中如何使用ES？如何保證ES的數據更新？下面簡單做個吵磨戚描述。
Elasticsearch使用可以簡單分為兩個階段。數據初始化階段、數據更新階段。
數據初始化階段。數據初始化常見的方式如下：
一、通過應用程序手動將資料庫中的數據，調用ES介面API插入ES索引庫中。
二、同過數據遷移工具將數據初始化到ES資料庫。目前常用的ES同步工具有logstash-input-jdbc、DataX。通過同步遷移工具可以全量將資料庫數據初始化到ES索引庫中。
數據更新階段。數據更新階段常見的處理方式如下：
一、通過應用服務直接調用ES更新介面。這種方式實現比較簡單但是對業務侵入性比較大。
二、對於實時性要求不高的可以採用定時任務監控數據表變化然後調用ES介面實現數據更新。
三、業務應用中通過發送消息非同步更新數據。
四、通過DataX同步工具定時將修改的數據同步到ES庫中。
上述是ElasticSearch使用的簡升陵單描述。使用的關鍵還是資料庫與ES間的數據同游手步。能否用的好關鍵也是數據間的同步。
3. es查詢超過10000條數據報錯
{
"敗巧升index"察老:{
"寬歷max_result_window":2000000
}
}
4. es存儲目錄分析
Elasticsearch中生成的數據文件一般來說主要有三種，分別是state、index和translog。
查看ES存儲目錄，可發現有多個_state目錄，目錄下存放了以.st為後綴的文件。例如
這些st文件內容在ES源碼里被稱之為MetaData，緩存了諸如NodeState，ClusterState，IndexState，ShardState等信息
nodes/0/_state/:
這層目錄在節點級別，該目錄下的global-1.st文件存儲的是MetaData中除去IndexMetaData的部分，即一些集群級別的配置和templates。node-0.st中存儲的是NodeId。
nodes/0/indices/2Scrm6nuQOOxUN2ewtrNJw/_state/:
這層目錄在index級別，2Scrm6nuQOOxUN2ewtrNJw是IndexId，該目錄下的state-2.st文件存儲的是IndexMetaData。
nodes/0/indices/2Scrm6nuQOOxUN2ewtrNJw/0/_state/:
這層目錄在shard級別，該目錄下的state-0.st存儲的是ShardStateMetaData，包含是否是primary和allocationId等信息。
可以看到，集群相關的MetaData和Index的MetaData是在不同的目錄中存儲的。另外，集群相關的Meta會在所有的MasterNode和DataNode上存儲，而Index的Meta會在所有的MasterNode和存儲了該Index數據的DataNode上存儲。
5. ES數據存儲可靠性和寫入流程
https://www.elastic.co/guide/en/elasticsearch/guide/2.x/near-real-time.html
https://www.elastic.co/guide/en/elasticsearch/guide/2.x/merge-process.html
1、數據存儲可靠性保證原理
1.1 translog機制
當一個文檔寫入Lucence後是存儲在內存中的，即使執行了refresh操作仍然是在文件系統緩存中，如果此時伺服器宕機，那麼這部分數據將會丟失
當進行文檔寫操作時會先將文檔寫入Lucene，然後寫入一份到translog，寫入translog是落盤的
tips:如果對可靠性要求不是很高，也可以設置非同步落盤，可以提高性能，由配置index.translog.rability和index.translog.sync_interval控制
tips:translog是追加寫入，因此性能比較好
先寫入Lucene再寫入translog。原因是寫入Lucene可能會失敗，為了減少寫入失敗回滾的復雜度，因此先寫入Lucene
1.2 flush操作
refresh_interval定時觸發 或當translog達到index.translog.flush_threshold_size（默認512mb)，ES會觸發一次flush操作：先執行refresh操作將buffer中的數據生成segment，然後調用lucene的commit方法將所有內存中的segment fsync到磁碟，最後會清空translog中的數據(6.x版本為了實現sequenceIDs，不刪除translog) 。
1.3 merge操作
refresh操作會產生大量的小segment，因此產生的每個文件都會消耗文件句柄，內存，CPU 使用等各種資源。更重要的是每個查詢請求都要順序檢查每個segment; segment越多檢索會越慢.
ES會運行一個檢測任務，在後台把近似大小的segment合並成一個新的大segment，並刪除舊segment
1.4、多副本機制
ES有多副本機制（默認是1個副本），一個分片的主副分片不能分片在同一個節點上，進一步保證數據的可靠性。
2、ES寫索引的流程
6. Elasticsearch 能夠存儲的數據量一般有多大
單獨看ES能玩多大數據意義不大，具體實踐中往往因為各種業務要求而無法繼續增加數據量。目大的方面考慮有如下幾點：
1、查詢速度。ES可以支持的查詢類型多種多樣，單一的term匹配，復雜的historm agg，甚至父子文檔模式下bool查詢之後繼續做文本高亮，數據量越大查詢時間越長。如果只是簡單的把數據寫進去然後按照ID獲取數據，那就盡管往裡面寫數據吧。
2、寫入速度。數據量越大，寫入速度受影響的可能性越大。業務要求1小時的數據1小時內必須寫完，如果做不到就得考慮分索引或者分集群了。
3、更新速度。同上，更新比單純的寫入操作更多，先get再merge再overwrite到es。
4、其他因素。
目前我遇到的ES集群，有1.5T-2T索引量的情況下，需要支持平均查詢在500ms以內的高並發高亮查詢。在我們的場景下這個量級不算小了。