es elastocsearch

倒排索引是在數(shù)據查詢之前建立，在查詢的時候可以直接通過關鍵詞定位到文檔內容。用空間換時間

分布式架構原理說一下？

es底層是基于lucene來的? ?大概就是一個用于全文檢索的jar包

用es來做分布式的搜索引擎? 可以承載一秒鐘幾千的搜索

es用來存儲數(shù)據的基本單位是索引。

index:mysql里的一張表

type：一個index里可以有多個type，每個type的字段都是差不多的，但是有一些略微的差別

比如mysql中的表? 有些訂單是實物訂單，有些是游戲點卡。兩種訂單大部分字段一樣，但是少部分字段可能有略微的差別。

mapping代表了對這個type表結構的定義，定義了這個type中每個字段名稱，字段是什么類型，然后還有這個字段的各種配置

document：往index里的一個type里面寫一條數(shù)據，叫做一條document，一條document代表了mysql中某個表的一行，每個document有多個field，每個field就代表了document中一個字段的值

架構：

每臺機器中有一個es進程，每個es進程中有多個shard，每個shard都會在其他的某個機器上有一個副本? ?一個索引的數(shù)據會被分布式存儲在多個shard上面? ? primary為主版本，replica為副版本

如果說masterNode節(jié)點（代表一個機器）突然掛了，那么es會重新選舉一個新的節(jié)點成為masterNode? ? ?原本需要的不是shard01跟shard02么? 此時新的masterNode里面是02跟03,02是replica Shard? 此時會將它變成primary Shard? ?

kafka是只能在lead里面讀寫? ?而es是可以在primary里面寫讀寫? 可以在replica里面讀

當剛剛宕機了的節(jié)點恢復后，它里面的shard02會變成replica shard

寫入與查詢的工作原理？

客戶端可以挑任意一個進程去寫，進去以后? 如果是找到了replica節(jié)點，那么replica會把數(shù)據路由到primary中，寫進primary，然后primary會將數(shù)據同步到replica中

寫進shard怎么寫的？

在寫進shard之后? 會寫進內存buffer中，同時會寫進tanslog日志中，每隔一段時間會把buffer中的數(shù)據刷進磁盤，refresh操作->刷到segmentFile中，segmentfile 中就存儲最近1秒內buffer中寫入的數(shù)據? 刷到segmentfile之前會先進os cache操作系統(tǒng)級別的一個內存緩存中 為什么說es是準實時的，因為是每隔1秒refresh一次，寫入的數(shù)據1秒后才能被看到

這樣一直重復，新的數(shù)據不斷進入buffer和translog中，不斷將buffer數(shù)據寫入一個又一個新的segment file中去，每次refresh完buffer清空，tanslog保留，隨著過程推進，translog會變得越來越大，當translog達到一定長度的時候，就會觸發(fā)conmit操作

commit操作：1寫comimit point? 2 OS cache數(shù)據fsync強刷到磁盤上去 3.清空translog日志文件

一般不叫commit? 一般叫flash操作

translog主要是用來做數(shù)據的恢復? 內存如果宕機 那么就可以根據translog來做一個恢復

1.他是準實時的，數(shù)據寫入一秒后可以搜索到，2可能會丟失數(shù)據的，你的數(shù)據有5秒的時間停留在buffer、translog、segment file? os cache中??

此時如果宕機? 可能會導致五秒的數(shù)據丟失

如果你希望一定不丟數(shù)據的話 ，可以設置參數(shù)，每次寫入一條數(shù)據，都是直接寫入buffer，同時寫入磁盤中的translog

刪除數(shù)據：有個.del的文件? 如果某條數(shù)據被刪除了，.del文件中會標記這條數(shù)據。然后你就不會搜索到這條數(shù)據了

merge操作：三個segment合并成一個segment，如果原來的segment中某條數(shù)據被標志成.del? 那么在合并后? 它就沒了? 被物理刪除了

讀數(shù)據過程：不斷輪詢 每次隨機找一個shard去讀，

在幾十億數(shù)量級場景下如何優(yōu)化查詢性能？

僅僅只是寫入es中要用來檢索的少數(shù)幾個字段就可以了 ， fileSystemcache里面的內存要大一點

你最好寫入es的數(shù)據小于等于 fileSystem cache? ?最好讓查詢大量的命中filesystemcache

數(shù)據預熱：經常要訪問的數(shù)據 把他刷到filesystemCache中? 就是從內存拿? 而不是磁盤

比如電商 你可以吧一些平時查看得比較多的商品，熱數(shù)據提前后臺搞個程序，每隔一分鐘，自己主動訪問一次，刷到filesystemCache中去

冷熱分離：? 就是經常用的數(shù)據放在一張表里面，不經常用的放在另一個shard里面

用es做分頁，越往后翻越慢

兩個思路來解決：

1.不允許深度分頁

2.默認翻得越深，性能越差

微博：可以用scroll? api

其實現(xiàn)在很多產品是不能隨意翻頁的? ?做成的是往下拉的這種? 而不是說一下從一百頁跳到200頁

生產環(huán)境的分布式搜索引擎是怎么部署的？

中小型公司：

?

集群部署了5臺機器，每臺機器是6核64G的，集群總內存是320G

日增量數(shù)據大概是2000萬條，每天日常增量數(shù)據大概是500MB，每月