以前寫過一篇ElasticSearch初識之吐槽,不知覺居然過去了兩年了。哎,時光催人老啊。最近又用到了ES,想找找過去的總結文檔,竟然只有一篇,搞了半年的ES,遇到那麼多的問題,產出只有這麼點,真是說不過去啊。只好又從新撿起ES,發現ES槽點依然不少,不兼容的更新太多了,各個版本之間的差別不小,感受ES就是偏理論算法的人設計出來的,而不是工程學家寫的。很是像公司裏面,算法工程師吐槽後端應用開發算法能力弱,後端應用開發吐槽算法工程師工程能力太差。做爲一個應用開發對ES差很少就是這種感受。不過要用到搜索,不用他又不行。既然不能拒絕,只能去享受了。html
爲何要分析寫入了,由於好奇唄。好比有以下問題一直困惑着我node
首先咱們從分佈式集羣的角度分析下寫入,採用系統默認的參數來講明mysql
集羣有三個節點,都存儲數據,indexA 有5個分片,2個複製集。
數據以下分佈
Node1: shard1
Node2: shard2,shard3,shard1-R1(shard1的複製集)
Node3: shard4,shard5,shard-R2(shard1的複製集)算法
爲了簡化問題,shard2,shard5等shard的複製集忽略問題了。
如今以寫入shard1爲例說明問題。sql
coordinate節點不是很master/client/data節點一個維度的描述,它就是指處理客戶端請求的節點。這個描述和cassandra的coordinate節點是一個概念。集羣中全部的節點均可以是coordinate節點。數據庫
shard = hash(document_id) % (num_of_primary_shards)
,而後根據節點上維護的shard信息,將請求發送到node1上。寫入到shard
。整個過程coordinate node部分相似cassandra,主shard節點和副本集受master-slave模式影響,必須有master決定寫入成功與否,和mysql相似的。後端
上面第三步驟,shard內寫入還須要詳細分析下緩存
flush index
到磁盤中。作增量flush的。各類數據庫的單節點寫入過程大同小異,通常都是寫內存,記錄操做日誌(防止節點宕機,內存中的數據丟失)而後flush到磁盤,有個線程不斷的merge 數據塊。不過是寫入的數據格式不一樣。elasticsearch
另外分佈式或者主從式部署結構,又須要將寫入的數據複製
到不一樣的節點,這個過程比較複雜,每一個數據庫處理也有不一樣的邏輯。分佈式
elastic search
寫入的中間過程還多了一層buffer,咱們知道buffer和cache雖然都是爲了提升寫入效率,可是工做原理不一樣,
一、Buffer(緩衝區)是系統兩端處理速度平衡(從長時間尺度上看)時使用的。它的引入是爲了減少短時間內突發I/O的影響,起到流量整形的做用。好比生產者——消費者問題,他們產生和消耗資源的速度大致接近,加一個buffer能夠抵消掉資源剛產生/消耗時的忽然變化。
二、Cache(緩存)則是系統兩端處理速度不匹配時的一種折衷策略。由於CPU和memory之間的速度差別愈來愈大,因此人們充分利用數據的局部性(locality)特徵,經過使用存儲系統分級(memory hierarchy)的策略來減少這種差別帶來的影響。
因此寫入到buffer中的數據,仍是原始數據,尚未索引,搜索不到的。只有到Cache中還能夠。
數據庫寫入過程都須要寫入操做日誌,複製集日誌,不一樣的數據庫不同的處理方法。
有些數據庫是共用的,有些數據庫則是分開的。
寫操做日誌的過程通常是直接寫入磁盤的,由於它自己就是防止進程,機器宕機形成內存數據丟失,而用來恢復數據的。寫入buffer中又會可能會致使數據的丟失。因此像elastic search mysql innodb
這種操做日誌寫buffer的也會提供配置項,來保證當事務成功後,操做日誌會被刷盤的。不過es
的操做日誌最小刷盤不能低於100ms
.
下面是各個數據庫的日誌對比,相同的功能,可是每一個建立者都有本身的逼格,須要有不一樣的命名。
數據庫 | 記錄日誌,刷磁盤 | 複製日誌 | 備註 |
---|---|---|---|
cassandra | commit log | commit log | commit log 直接寫磁盤的 |
mongo | journal | oplog | journal log寫磁盤的 |
mysql | redo logs | bin log | redo logs寫buffer的, |
elastic search | translog | translog | 寫buffer的 |
有興趣的同窗能夠以前寫過的mongo,cassandra寫入分析
關注公衆號【方丈的寺院】,第一時間收到文章的更新,與方丈一塊兒開始技術修行之路
https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-translog.html
https://www.elastic.co/pdf/architecture-best-practices.pdf
https://lalitvc.files.wordpress.com/2018/05/mysql_architecture_guide.pdf
https://www.infoq.cn/article/analysis-of-elasticsearch-cluster-part01
https://blog.insightdatascience.com/anatomy-of-an-elasticsearch-cluster-part-i-7ac9a13b05db