es處理器的優(yōu)缺點？首先ES是設(shè)計和實現(xiàn)Lucene這個太完全成熟的索引方案，另算上一些分布式的實現(xiàn)：集群，sharding，replication等。ES的優(yōu)勢通常這個可以看以下幾個方面：豎向可擴展

es處理器的優(yōu)缺點？

首先ES是設(shè)計和實現(xiàn)Lucene這個太完全成熟的索引方案，另算上一些分布式的實現(xiàn)：集群，sharding，replication等。

ES的優(yōu)勢通常這個可以看以下幾個方面：

豎向可擴展性：只需要減少一臺服務(wù)器，做一點兒配置，啟動后一下ES進(jìn)程就可以原屬集群；

分片機制需要提供更好的分布性：同一個索引分成多個分片（sharding），這點像HDFS的塊機制；分治的來修為提升處理效率，我相信大家都肯定不會陌生；

高可用：需要提供圖片文件夾（replica）機制，一個分片是可以可以設(shè)置多個剪切粘貼，令某臺服務(wù)器宕機的情況下，集群仍舊可以不一切照常不運行，并會把由于服務(wù)器宕機全部丟失的圖片文件夾重新恢復(fù)到其它用些節(jié)點上；這點也不同于HDFS的復(fù)制機制（HDFS中默認(rèn)是3份圖片文件夾）；

當(dāng)然，也要明白其不足之處：

各節(jié)點的一致性問題：其系統(tǒng)默認(rèn)的機制是多播機制，離線元數(shù)據(jù)信息，可是在比較比較極忙的集群中，可能會會而網(wǎng)絡(luò)的阻塞，或則節(jié)點處理能力提升到飽和現(xiàn)象造成各節(jié)點元數(shù)據(jù)不一致——也就是所謂的的腦裂問題，這樣的話會使集群在不一致狀態(tài)。目前完全沒有個徹底的解決方案來幫忙解決這個問題，但可以不實際將工作節(jié)點與元數(shù)據(jù)節(jié)點沒分開的部署方案來可緩解狀況。

沒有精巧細(xì)致的權(quán)限管理機制，也就是說，也沒像MySQL那樣的分各種用戶，每個用戶又有不同的權(quán)限。因為在操作上的限制是需要自己變更土地性質(zhì)一個系統(tǒng)來成功；

總結(jié)歸納：只不過從優(yōu)勢與不足的對比看，我看還是小小的瑕疵，是值得一試的技術(shù)。

es一條記錄能存多大？

盡量的避免有太大的分片，只不過大的分片很可能會對集群從故障中復(fù)原的能力出現(xiàn)負(fù)面影響。這對多大的分片是沒有固定不動的限制，但是分片大小為50GB大多被如何界定為區(qū)分于各種用例的限制。

es shard中存儲的是什么？

shard是Elasticsearch數(shù)據(jù)存儲的小于單位，index的存儲容量為所有shard的存儲容量之和。Elasticsearch集群的存儲容量則為所有index存儲容量之和。

一個shard就填寫了一個lucene的library。相對于一個shard，Elasticsearch提高了translog的功能，傳說中的HBaseWAL，是數(shù)據(jù)寫入文件過程中的中間數(shù)據(jù)，其余的數(shù)據(jù)都在lucene庫中管理的。

所以我Elasticsearch索引使用的存儲內(nèi)容要注意它取決于lucene中的數(shù)據(jù)存儲。