白日夢的Elasticsearch筆記(一)基礎篇
## 一、導讀 ![](https://img2020.cnblogs.com/blog/1496926/202101/1496926-20210113231945281-1997291032.png)
Hi All!我們一起學點有意思的!NoSQL!歡迎訂閱白日夢Elasticsearch專題系列文章。按計劃這個專題一共有四篇文章。所有文章公眾號首發。
所有文章公眾號首發!
所有文章公眾號首發! [點選閱讀原文可以關注我哦!在第一時間追到更新](https://mp.weixin.qq.com/s/vpx-YztORgqROzPIL3_yig)
所有文章公眾號首發!
所有文章公眾號首發!
Notice!!!白日夢並不能保證通過這四篇文章讓你掌握ES,但是!我會用大白話串講ES的一些概念、和花哨的玩法。起碼可以把你對Elasticsearch的陌生度降到最低,等有一天你自己業務需要使用ES時,會因為提前讀了白日夢的ES筆記而快速上手。 ![](https://img2020.cnblogs.com/blog/1496926/202101/1496926-20210113231947355-1999243584.png)
為寫這篇文章我還華為雲上購置了一臺2C4G的伺服器,歡迎關注白日夢,我們一起學點實用的!有趣的技術!
![](https://img2020.cnblogs.com/blog/1496926/202101/1496926-20210113231948507-1478196786.png)
### 1.1、認識ES
關係型資料庫: 像MySQL這種資料庫就是傳統的關係型資料庫。它有個很直觀的特點:每一張資料表的列在建立表的時候就需要確定下來。比如你建立一個user表,定義了3列id、username、password。這時如果你的實體類中多了一個age的欄位,那這個實體是不能儲存進user表的。(當然後續你可以通過DDL修改新增列或者減少列。讓實體類的屬性和表中的列一一對應)。
非關係型資料庫: 非關係型資料庫也就是我們常聽說的NoSQL。常見的有:MongoDB、Redis、Elasticsearch。 且不說效能方面,單說使用方面NoSQL這種非關係型別的資料庫都支援你往它裡面儲存一個json物件,這個json有多少個欄位並不是它關係的,拿上面的例子來說,只要你給他一個物件,不管有沒有age、它都能幫你儲存進去。 關於ES更多的知識點我們在下文中展開,再說一下ES常見的使用場景和特性:
站內搜尋: 如果你的公司想做自己的站內搜尋,那ES再合適不過了。作為非關係型資料庫的ES允許你往它裡面儲存各種格式不確定的Json物件,還為你提供了全文字搜尋和分析引擎。它使您可以快速,近乎實時地(1 s)儲存,搜尋和分析大量資料。一個字:快!
日誌採集系統: Elasticsearch是Elastic公司的核技術,並且Elastic公司還有其他諸如:Logstash、Filebeat、Kibana等技術棧。常見的公司裡面使用的日誌管理系統就可以使用ELK+Filebeat搭建起來,Filebeat收集日誌推送到Logstash做處理,然後Logstash將資料儲存入ES,最終通過Kibana展示日誌。
可擴充套件性:
Elasticsearch天生就是分散式的,既能以單機的形式執行一臺效能很差的伺服器上。它也可以形成一個成百上千節點的叢集。並且它自己會管理叢集中的節點,在ES中我們可以隨意的新增、摘除節點,叢集自己會將資料均攤在各個節點上。
### 1.2、安裝、啟動ES、Kibana、IK分詞器
1. 安裝很簡單,所以詳細過程不會寫到文章中。
2. 安裝啟動教程、ES、Kibana、IK分詞器安裝包都以百度網盤的方式分享給大家,後臺回覆:es 可領取
## 二、核心概念
因為這是第一篇基礎篇,對小白友好一些,所以需要先了解一些基本概念,你可以耐折性子讀一下,都不難理解的哈。
### 2.1、Near Realtime (NRT)
ES號稱對外提供的是近實時的搜尋服務,意思是資料從寫入ES到可以被Searchable僅僅需要1秒鐘,所以說基於ES執行的搜尋和分析可以達到秒級。
### 2.2、Cluster
**叢集**:叢集是一個或多個node的集合,它們一起儲存你存放進去的資料,使用者可以在所有的node之間進行檢索,一般的每個叢集都會有一個唯一的名稱標識,預設的名稱標識為 `elasticsearch` ,這個名字很重要,因為node想加入cluster時,需要這個名稱資訊。
![](https://img2020.cnblogs.com/blog/1496926/202101/1496926-20210113231949433-1543085412.png)
確保別在不同的環境中使用相同的叢集名稱,進而避免node加錯叢集的情況,一顆考慮下面的叢集命名風格`logging-stage`和`logging-dev`和`logging-pro`。
### 2.3、Node
**單臺server**就是一個node,它和cluster一樣,也存在一個預設的名稱。但是它的名稱是通過UUID生成的隨機串,當然使用者也可以定製不同的名稱,但是這個名字最好別重複。**這個名稱對於管理來說很在乎要,因為需要確定,當前網路中的哪臺伺服器,對應這個叢集中的哪個節點**。
node存在一個預設的設定,**預設的,當每一個node在啟動時都會自動的去加入一個叫elasticsearch的節點,這就意味著,如果使用者在網路中啟動了多個node,它們會彼此發現,然後組成叢集**。
**在單個的cluster中,你可以擁有任意多的node**。假如說你的網路上沒有其它正在執行的節點,然後你啟動一個新的節點,這個新的節點自己會組建一個叢集。
### 2.4、Index
**Index是一類擁有相似屬性的document的集合**,比如你可以為消費者的資料建立一個index,為產品建立一個index,為訂單建立一個index。
**index名稱(必須是小寫的字元)**, 當需要對index中的文件執行索引、搜尋、更新、刪除、等操作時,都需要用到這個index。
**理論上:你可以在一個叢集中建立任意數量的index**。
### 2.5、Type
Type可以作為index中的邏輯類別。為了更細的劃分,比如使用者資料type、評論資料type、部落格資料type
**在設計時盡最大努力讓擁有更多相同field的document劃分到同一個type下。**
### 2.6、Document
document就是ES中儲存的一條資料,就像mysql中的一行記錄一樣。它可以是一條使用者的記錄、一個商品的記錄等等
### 2.7、一個不嚴謹的小結:
為什麼說這是不嚴謹的小結呢? 就是說下面三個對應關係只能說的從表面上看起來比較相似。但是ES中的type其實是一個邏輯上的劃分。資料在儲存是時候依然是混在一起儲存的(往下看下文中有寫),而mysql中的不同表的兩個列是絕對沒有關係的。
| Elasticsearch | 關係型資料庫 |
| :-----------: | :----------: |
| Document | 行 |
| type | 表 |
| index | 資料庫 |
### 2.8、Shards & Replicas
#### 2.8.1、問題引入:
如果讓一個Index自己儲存1TB的資料,響應的速度就會下降。**為了解決這個問題,ES提供了一種將使用者的Index進行subdivide的騷操作,就是將index分片,每一片都叫一個Shards,進而實現了將整體龐大的資料分佈在不同的伺服器上儲存**。
#### 2.8.2、什麼是shard?
shard分成replica shard和primary shard。顧名思義一個是主shard、一個是備份shard, 負責容錯以及承擔部分讀請求。
shard可以理解成是ES中最小的工作單元。所有shard中的資料之和,才是整個ES中儲存的資料。 可以把shard理解成是一個luncene的實現,**擁有完整的建立索引,處理請求的能力**。
下圖是兩個node,6個shard的組成的叢集的劃分情況:
![兩個節點的分佈情況](https://img2018.cnblogs.com/blog/1496926/201911/1496926-20191104182523996-1922424329.png)
你可以看一下上面的圖,圖中無論java應用程式訪問的是node1還是node2,其實都能獲取到資料。
#### 2.8.3、shard的預設數量
新建立的節點會存在5個primary shard,**注意!後續不然能再改動primary shard的值**,如果每一個primary shard都對應一個replica shard,按理說單臺es啟動就會存在10個分片,但是現實是,同一個節點的replica shard和primary shard不能存在於一個server中,因此單臺es預設啟動後的分片數量還是5個。
#### 2.8.4、如何拓容Cluster
首先明確一點: 一旦index建立完成了,primary shard的數量就不可能再發生變化。
因此**橫向拓展**就得新增replica的數量, 因為**replica shard的數量後續是可以改動的**。也就是說,如果後續我們將它的數量改成了2, 就意味著讓每個primary shard都擁有了兩個replica shard, 計算一下: 5+5*2=15 叢集就會拓展成15個節點。
如果想讓每一個shard都有最多的系統的資源就增加伺服器的數量,讓每一個shard獨佔一個伺服器。
#### 2.8.5、舉個例子:
![shard和replica入門圖](https://img2018.cnblogs.com/blog/1496926/201911/1496926-20191104182522587-1256603317.png)
上圖中存在上下兩個node,每個node中都有一個 **自己的primary shard**和**其它節點的replica shard**,為什麼是**強調自己和其它**呢? 因為ES中規定,同一個節點的replica shard和primary shard不能存在於一個server中,而不同節點的primary shard可以存在於同一個server上。
當primary shard宕機時,因為它對應的replicas shard在其它的server沒有受到影響,所以ES可以繼續響應使用者的讀請求。通過這種分片的機制,並且分片的地位相當,假設單個shard可以處理2000/s的請求,通過橫向拓展可以在此基礎上成倍提升系統的吞吐量,天生分散式,高可用。
此外: 每一個document肯定存在於一個primary shard和這個primary shard 對應的replica shard中, 絕對不會出現同一個document同時存在於多個primary shard中的情況。
## 三、入門探索:
下面的小節中你會看到我使用大量的GET / POST 等等包括什麼query。其實你不用詫異為啥整一堆這些東西而不寫點程式碼。
其實這些命令對於ES來說,就像是SQL和MySQL的關係。換句話說,其實你寫的程式碼的底層幫你執行的也是我下面說得的這些命令。所以,別怕麻煩,下面的這些知識點無論如何你都不能直接跨越過去。
### 3.1、叢集的健康狀況
```http
GET /_cat/health?v
```
執行結果如下:
```bash
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1572595632 16:07:12 elasticsearch yellow 1 1 5 5 0 0 5 0 - 50.0%
```
解讀上面的資訊,預設的叢集名是`elasticsearch`,當前叢集的status是`yellow`,後續列出來的是叢集的分片資訊,最後一個`active_shards_percent`表示當前叢集中僅有一半shard是可用的。
狀態:
存在三種狀態分別是:red、green、yellow
* green : 表示當前叢集所有的節點全部可用。
* yellow: 表示ES中所有的資料都是可以訪問的,但是並不是所有的replica shard都是可以使用的(我現在是預設啟動一個node,而ES又不允許同一個node的primary shard和replica shard共存,因此我當前的node中僅僅存在5個primary shard,為status為黃色)。
* red: 叢集宕機,資料不可訪問。
### 3.2、叢集的索引資訊
```http
GET /_cat/indices?v
```
結果:
```bash
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open ai_answer_question cl_oJNRPRV-bdBBBLLL05g 5 1 203459 0 172.3mb 172.3mb
```
顯示狀態為yellow,表示存在replica shard不可用, 存在5個primary shard,並且每一個primary shard都有一個replica shard , 一共20多萬條文件,未刪除過文件,文件佔用的空間情況為172.3兆。
### 3.3、建立index
```http
PUT /customer?pretty
```
ES 使用的RestfulAPI,新增使用put,這是個很親民的舉動。
### 3.4、新增 or 修改
**如果是ES中沒有過下面的資料則新增進去,如果存在了id=1的元素就修改(全量替換)**。
* **格式:`PUT /index/type/id`**
> **全量替換時,原來的document是沒有被刪除的!而是被標記為deleted,被標記成的deleted是不會被檢索出來的,當ES中資料越來越多時,才會刪除它**。
```http
PUT /customer/_doc/1?pretty
{
"name": "John Doe"
}
```
響應:
```json
{
"_index": "customer",
"_type": "_doc",
"_id": "1",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 0,
"_primary_term": 1
}
```
**強制建立**,加添`_create`或者`?op_type=create`。
```
PUT /customer/_doc/1?op_type=create
PUT /customer/_doc/1/_create
```
* 區域性更新(Partial Update)
> **不指定id則新增document**。
```json
POST /customer/_doc?pretty
{
"name": "Jane Doe"
}
```
> **指定id則進行doc的區域性更新操作**。
```http
POST /customer/_doc/1?pretty
{
"name": "Jane Doe"
}
```
> **並且POST相對於上面的PUT而言,不論是否存在相同內容的doc,只要不指定id,都會使用一個隨機的串當成id,完成doc的插入**。
> **Partial Update先獲取document,再將傳遞過來的field更新進document的json中,將老的doc標記為deleted,再將建立document,相對於全量替換中間會省去兩次網路請求**
### 3.5、檢索
格式: GET /index/type/
```http
GET /customer/_doc/1?pretty
```
響應:
```json
{
"_index": "customer",
"_type": "_doc",
"_id": "1",
"_version": 1,
"found": true,
"_source": {
"name": "John Doe"
}
}
```
### 3.6、刪除
刪除一條document。
> **大部分情況下,原來的document不會被立即刪除,而是被標記為deleted,被標記成的deleted是不會被檢索出來的,當ES中資料越來越多時,才會刪除它**。
```http
DELETE /customer/_doc/1
```
響應:
```json
{
"_index": "customer",
"_type": "_doc",
"_id": "1",
"_version": 2,
"result": "deleted",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 1,
"_primary_term": 1
}
```
刪除index
```http
DELETE /index1
DELETE /index1,index2
DELETE /index*
DELETE /_all
可以在elasticsearch.yml中將下面這個設定置為ture,表示禁止使用 DELETE /_all
action.destructive_required_name:true
```
響應
```json
{
"acknowledged": true
}
```
### 3.6、更新文件
上面說了POST關鍵字,可以實現不指定id就完成document的插入, `POST` + `_update`關鍵字可以實現更新的操作。
```json
POST /customer/_doc/1/_update?pretty
{
"doc": { "name": "changwu" }
}
```
> **POST+_update進行更新的動作依然需要指定id, 但是相對於PUT來說,當使用POST進行更新時,id不存在的話會報錯,而PUT則會認為這是在新增。**
此外: 針對這種更新操作,ES會先刪除原來的doc,然後插入這個新的doc。
## 四、document api
### 4.1、search
* 檢索所有索引下面的所有資料
```http
/_search
```
* 搜尋指定索引下的所有資料
```http
/index/_search
```
* 更多模式
```http
/index1/index2/_search
/*1/*2/_search
/index1/index2/type1/type2/_search
/_all/type1/type2/_search
```
### 4.2、_mget api 批量查詢
mget是ES為我們提供的批量查詢的API,我們只需要制定好 index、type、id。ES會將命中的記錄批量返回給我們。
* 在docs中指定`_index`,`_type`,`_id`
```json
GET /_mget
{
"docs" : [
{
"_index" : "test",
"_type" : "_doc",
"_id" : "1"
},
{
"_index" : "test",
"_type" : "_doc",
"_id" : "2"
}
]
}
```
* 在URL中指定index
```json
GET /test/_mget
{
"docs" : [
{
"_type" : "_doc",
"_id" : "1"
},
{
"_type" : "_doc",
"_id" : "2"
}
]
}
```
* 在URL中指定 index和type
```json
GET /test/type/_mget
{
"docs" : [
{
"_id" : "1"
},
{
"_id" : "2"
}
```
* 在URL中指定index和type,並使用ids指定id範圍
```json
GET /test/type/_mget
{
"ids" : ["1", "2"]
}
```
* 為不同的doc指定不同的過濾規則
```json
GET /_mget
{
"docs" : [
{
"_index" : "test",
"_type" : "_doc",
"_id" : "1",
"_source" : false
},
{
"_index" : "test",
"_type" : "_doc",
"_id" : "2",
"_source" : ["field3", "field4"]
},
{
"_index" : "test",
"_type" : "_doc",
"_id" : "3",
"_source" : {
"include": ["user"],
"exclude": ["user.location"]
}
}
]
}
```
### 4.3、_bulk api 批量增刪改
#### 4.3.1、基本語法
```json
{"action":{"metadata"}}\n
{"data"}\n
```
存在哪些型別的操作可以執行呢?
- delete: 刪除文件。
- create: _create 強制建立。
- index: 表示普通的put操作,可以是建立文件也可以是全量替換文件。
- update: 區域性替換。
**上面的語法中並不是人們習慣閱讀的json格式,但是這種單行形式的json更具備高效的優勢**。
ES如何處理普通的json如下:
- 將json陣列轉換為JSONArray物件,這就意味著記憶體中會出現一份一模一樣的拷貝,一份是json文字,一份是JSONArray物件。
但是如果上面的單行JSON,ES直接進行切割使用,不會在記憶體中整一個數據拷貝出來。
#### 4.3.2、delete
delete比較好看僅僅需要一行json就ok
```json
{ "delete" : { "_index" : "test", "_type" : "_doc", "_id" : "2" } }
```
#### 4.3.3、create
兩行json,第一行指明我們要建立的json的index,type以及id
第二行指明我們要建立的doc的資料
```json
{ "create" : { "_index" : "test", "_type" : "_doc", "_id" : "3" } }
{ "field1" : "value3" }
```
#### 4.3.4、index
相當於是PUT,可以實現新建或者是全量替換,同樣是兩行json。
第一行表示將要新建或者是全量替換的json的index type 以及 id。
第二行是具體的資料。
```json
{ "index" : { "_index" : "test", "_type" : "_doc", "_id" : "1" } }
{ "field1" : "value1" }
```
#### 4.3.5、update
表示 parcial update,區域性替換。
它可以指定一個`retry_on_conflict`的特性,表示可以重試3次。
```json
POST _bulk
{ "update" : {"_id" : "1", "_type" : "_doc", "_index" : "index1", "retry_on_conflict" : 3} }
{ "doc" : {"field" : "value"} }
{ "update" : { "_id" : "0", "_type" : "_doc", "_index" : "index1", "retry_on_conflict" : 3} }
{ "script" : { "source": "ctx._source.counter += params.param1", "lang" : "painless", "params" : {"param1" : 1}}, "upsert" : {"counter" : 1}}
{ "update" : {"_id" : "2", "_type" : "_doc", "_index" : "index1", "retry_on_conflict" : 3} }
{ "doc" : {"field" : "value"}, "doc_as_upsert" : true }
{ "update" : {"_id" : "3", "_type" : "_doc", "_index" : "index1", "_source" : true} }
{ "doc" : {"field" : "value"} }
{ "update" : {"_id" : "4", "_type" : "_doc", "_index" : "index1"} }
{ "doc" : {"field" : "value"}, "_source": true}
```
### 4.4、滾動查詢技術
如果你想一次性查詢好幾萬條資料,這麼龐大的資料量,ES效能肯定會受到影響。這時可以選擇使用滾動查詢(scroll)。一批一批的查詢,直到所有的資料被查詢完成。也就是說它會先搜尋一批資料再搜尋一批資料。
示例如下:每次傳送一次scroll請求,我們還需要指定一個scroll需要的引數:一個時間視窗,每次搜尋只要在這個時間視窗內完成就ok。
```json
GET /index/type/_search?scroll=1m
{
"query":{
"match_all":{}
},
"sort":["_doc"],
"size":3
}
```
響應
```json
{
"_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAACNFlJmWHZLTkFhU0plbzlHX01LU2VzUXcAAAAAAAAAkRZSZlh2S05BYVNKZW85R19NS1Nlc1F3AAAAAAAAAI8WUmZYdktOQWFTSmVvOUdfTUtTZXNRdwAAAAAAAACQFlJmWHZLTkFhU0plbzlHX01LU2VzUXcAAAAAAAAAjhZSZlh2S05BYVNKZW85R19NS1Nlc1F3",
"took": 9,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 2,
"max_score": null,
"hits": [
{
"_index": "my_index",
"_type": "_doc",
"_id": "2",
"_score": null,
"_source": {
"title": "This is another document",
"body": "This document has a body"
},
"sort": [
0
]
},
{
"_index": "my_index",
"_type": "_doc",
"_id": "1",
"_score": null,
"_source": {
"title": "This is a document"
},
"sort": [
0
]
}
· ]
}
}
```
查詢下一批資料時,需要攜帶上一次scroll返回給我們的`_scroll_id`再次滾動查詢
```json
GET /_search/scroll
{
"scroll":"1m",
"_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAACNFlJmWHZLTkFhU0plbzlHX01LU2VzUXcAAAAAAAAAkRZSZlh2S05BYVNKZW85R19NS1Nlc1F3AAAAAAAAAI8WUmZYdktOQWFTSmVvOUdfTUtTZXNRdwAAAAAAAACQFlJmWHZLTkFhU0plbzlHX01LU2VzUXcAAAAAAAAAjhZSZlh2S05BYVNKZW85R19NS1Nlc1F3"
}
```
滾動查詢時,如果採用基於_doc的排序方式會獲得較高的效能。
## 五、下一篇目錄:
一、_search api 搜尋api
1.1、query string search
1.2、query dsl 20個查詢案例
1.3、其它輔助API
1.4、聚合分析
1.4.1、filter aggregate
1.4.2、巢狀聚合-廣度優先
1.4.3、global aggregation
1.4.4、Cardinality Aggregate 基數聚合
1.4.5、控制聚合的升降序
1.4.6、Percentiles Aggregation
二、優化相關性得分與查詢技巧
2.1、優化技巧1
2.2、優化技巧2
2.3、優化技巧3
2.4、優化技巧4
2.5、優化技巧5
2.6、優化技巧6
2.7、優化技巧7
三、下一篇目錄
## 推薦閱讀(公眾號首發,歡迎關注白日夢)
1. [MySQL的修仙之路,圖文談談如何學MySQL、如何進階!(已釋出)](https://mp.weixin.qq.com/s/c7KLGRNd5FT4xVoeJ4tvag)
2. [面前突擊!33道資料庫高頻面試題,你值得擁有!(已釋出)](https://mp.weixin.qq.com/s/c7KLGRNd5FT4xVoeJ4tvag)
3. [大家常說的基數是什麼?(已釋出)](https://mp.weixin.qq.com/s/FgxwAFQbEjv5i-TxjvLK6Q)
4. [講講什麼是慢查!如何監控?如何排查?(已釋出)](https://mp.weixin.qq.com/s/tXTLMCiVpEnnmhUclYR19Q)
5. [對NotNull欄位插入Null值有啥現象?(已釋出)](https://mp.weixin.qq.com/s/b30fKiQJTZARZazQdv6WKw)
6. [能談談 date、datetime、time、timestamp、year的區別嗎?(已釋出)](https://mp.weixin.qq.com/s/9zKX86P4kzlKla6-NyS3EA)
7. [瞭解資料庫的查詢快取和BufferPool嗎?談談看!(已釋出)](https://mp.weixin.qq.com/s/GB1OVQc8Cwv5Qpy329PIaA)
8. [你知道資料庫緩衝池中的LRU-List嗎?(已釋出)](https://mp.weixin.qq.com/s/OXAvtiZd9GA4Zx_rUJ6Wzw)
9. [談談資料庫緩衝池中的Free-List?(已釋出)](https://mp.weixin.qq.com/s/D3piti1Z-b7z1-Es5iEEpg)
10. [談談資料庫緩衝池中的Flush-List?(已釋出)]( https://mp.weixin.qq.com/s/56-DE61mEte6glmJ3lFvOg)
11. [瞭解髒頁刷回磁碟的時機嗎?(已釋出)]( https://mp.weixin.qq.com/s/56-DE61mEte6glmJ3lFvOg)
12. [用十一張圖講清楚,當你CRUD時BufferPool中發生了什麼!以及BufferPool的優化!(已釋出)](https://mp.weixin.qq.com/s/p5BgyX2Qg-UayPQAxslArw)
13. [聽說過表空間沒?什麼是表空間?什麼是資料表?(已釋出)](https://mp.weixin.qq.com/s/CwxRjGI843UerF89G_WJ-Q)
14. [談談MySQL的:資料區、資料段、資料頁、資料頁究竟長什麼樣?瞭解資料頁分裂嗎?談談看!(已釋出)](https://mp.weixin.qq.com/s/yPTO_QgkaNrU-gNoddjl-Q)
15. [談談MySQL的行記錄是什麼?長啥樣?(已釋出)](https://mp.weixin.qq.com/s/-Q_sqyUU60sF-H-XFv4Pdg)
16. [瞭解MySQL的行溢位機制嗎?(已釋出)](https://mp.weixin.qq.com/s/-Q_sqyUU60sF-H-XFv4Pdg)
17. [說說fsync這個系統呼叫吧! (已釋出)](https://mp.weixin.qq.com/s/tyxd64gGa_SmR6c9vrwf1w)
18. [簡述undo log、truncate、以及undo log如何幫你回滾事物! (已釋出)](https://mp.weixin.qq.com/s/zDiuK1wTIdwK4U3W3mrIlg)
19. [我勸!這位年輕人不講MVCC,耗子尾汁! (已釋出)](https://mp.weixin.qq.com/s/YiurAKs4gISp-RZNG_1JEQ)
20. [MySQL的崩潰恢復到底是怎麼回事? (已釋出)](https://mp.weixin.qq.com/s/6dQnlvjqOo6A0e_h8vST3w)
21. [MySQL的binlog有啥用?誰寫的?在哪裡?怎麼配置 (已釋出)](https://mp.weixin.qq.com/s/DN1shuyxPJ6BkE_RLezAnA)
22. [MySQL的bin log的寫入機制 (已釋出)](https://mp.weixin.qq.com/s/MtWzoiJtupso5M8z1KUaQQ)
23. [刪庫後!除了跑路還能幹什麼?(已釋出)](https://mp.weixin.qq.com/s/uVRtjKEaWRonwo_wWZGdxQ)
24. [全網最牛的事務兩階段提交和分散式事務串講! (已釋出)](https://mp.weixin.qq.com/s/Y6bWS4RVnpMZ5K2RKXCbyg)
參考:
https://www.elastic.co/guide/en/elasticsearch/reference/6.0