MySQL8.0 新特性:Partial Update of LOB Column
MySQL8.0對json進行了比較完善的支持, 我們知道json具有比較特殊的存儲格式,通常存在多個key value鍵值對,對於類似更新操作通常不會更新整個json列,而是某些鍵值。
對於某些復雜的應用,json列的數據可能會變的非常龐大,這時候一個突出的問題是:innodb並不識別json類型,對它而言這些存儲統一都是LOB類型,而在之前的版本中Innodb處理LOB更新的方式是標記刪除舊記錄,並插入新記錄,顯然這會帶來一些存儲上的開銷(盡管Purge線程會去後臺清理),而寫入的redo log和Binlog的量也會偏高,對於超大列,可能會嚴重影響到性能。為了解決這個問題,MySQL8.0引入了LOB列部分更新的策略。
官方博客有幾篇文章介紹的非常清楚,感興趣的可以直接跳過本文,直接閱讀官方博客:
1: partial update of json values
2: introduces lob index for faster update
以及相關的開發worklog:
WL#8963: Support for partial update of JSON in the optimizer
WL#8985: InnoDB: Refactor compressed BLOB code to facilitate partial fetch/update
WL#9141: InnoDB: Refactor uncompressed BLOB code to facilitate partial fetch/update
WL#9263: InnoDB: Enable partial access of LOB using multiple zlib streams
WL#10570: Provide logical diffs for partial update of JSON values
WL#2955: RBR replication of partial JSON updates
本文僅僅是筆者在理解該特性時做的一些簡單的筆記,,記錄的主要目的是用於以後如果涉及到相關的工作可以快速展開,因此比較淩亂
目前partial update需要通過JSON_SET, 或者JSON_REPLACE等特定接口來進行json列的更新,並且不是所有的更新都能夠滿足條件:
沒有增加新的元素
空間足夠大,可以容納替換的新值
但類似數據長度(10 =>更新成7=>更新成9)是允許的
下面以json_set更新json列為例來看看相關的關鍵堆棧
檢查是否支持partial update
如上所述,需要指定的json函數接口才能進行partial update
mysql_execute_command |--> Sql_cmd_dml::execute |--> Sql_cmd_dml::prepare |--> Sql_cmd_update::prepare_inner |---> prepare_partial_update |-->Item_json_func::supports_partial_update
這裏只是做預檢查,對於json列的更新如果全部是通過json_set/replace/remove進行的,則將其標記為候選partial update的列(TABLE::mark_column_for_partial_update
), 存儲在bitmap結構TABLE::m_partial_update_columns
設置partial update
入口函數:TABLE::setup_partial_update()
在滿足某些條件時,需要設置logical diff(用於記錄partial update列的binlog,降低binlog存儲開銷):
binlog_row_value_options設置為"partial_json"
binlog 打開
log_bin_use_v1_row_events關閉
使用row format
然後創建Partial_update_info對象(Table::m_partial_update_info
), 用於存儲partial update執行過程中的狀態
Table::m_enabled_logical_diff_columns
TABLE::m_binary_diff_vectors
TABLE::m_logical_diff_vectors
創建更新向量
當讀入一行記錄後,就需要根據sql語句來構建後鏡像,而對於partial update所涉及的json列,會做特殊處理:
Sql_cmd_update::update_single_table |--> fill_record_n_invoke_before_triggers |-->fill_record |--> Item::save_in_field |--> Item_func::save_possibly_as_json |--> Item_func_json_set_replace::val_json |--> Json_wrapper::attempt_binary_update |--> json_binary::Value::update_in_shadow |--> TABLE::add_binary_diff
json_wrapper::attempt_binary_update
: 做必要的數據類型檢查(是否符合partial update的條件)後,計算需要的空間,檢查是否有足夠的空閑空間Value::has_space()
來替換成新值。Value::update_in_shadow
: 進一步將變化的數據存儲到binary diff對象中(TABLE::add_binary_diff
),每個Binary_diff
對象包含了要修改對象的偏移量,長度以及一個指向新數據的const指針
如下例,摘自函數Value::update_in_shadow
的註釋,這裏提取出來,以便於理解json binary的格式,以及如何產生Binary Diff
創建測試表:
root@test 10:00:45>create table t (a int primary key, b json); Query OK, 0 rows affected (0.02 sec) root@test 10:01:06>insert into t values (1, '[ "abc", "def" ]'); Query OK, 1 row affected (0.07 sec)
json數據的存儲格式如下:
0x02 - type: small JSON array 0x02 - number of elements (low byte) 0x00 - number of elements (high byte) 0x12 - number of bytes (low byte) 0x00 - number of bytes (high byte) 0x0C - type of element 0 (string) 0x0A - offset of element 0 (low byte) 0x00 - offset of element 0 (high byte) 0x0C - type of element 1 (string) 0x0E - offset of element 1 (low byte) 0x00 - offset of element 1 (high byte) 0x03 - length of element 0 'a' 'b' - content of element 0 'c' 0x03 - length of element 1 'd' 'e' - content of element 1 'f'
更新json列的'abc'為'XY', 則空出一個字節出來:
root@test 10:01:39>UPDATE t SET b = JSON_SET(b, '$[0]', 'XY'); Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0
此時的存儲格式為:
0x02 - type: small JSON array 0x02 - number of elements (low byte) 0x00 - number of elements (high byte) 0x12 - number of bytes (low byte) 0x00 - number of bytes (high byte) 0x0C - type of element 0 (string) 0x0A - offset of element 0 (low byte) 0x00 - offset of element 0 (high byte) 0x0C - type of element 1 (string) 0x0E - offset of element 1 (low byte) 0x00 - offset of element 1 (high byte) CHANGED 0x02 - length of element 0 CHANGED 'X' CHANGED 'Y' - content of element 0 (free) 'c' 0x03 - length of element 1 'd' 'e' - content of element 1 'f'
此處只影響到一個element,因此 只有一個binary diff
再執行更新:
UPDATE t SET j = JSON_SET(j, '$[1]', 'XYZW')
第二個element從3個字節更新成4個字節,顯然原地沒有足夠的空間,但可以利用其一個element的剩余空間
0x02 - type: small JSON array 0x02 - number of elements (low byte) 0x00 - number of elements (high byte) 0x12 - number of bytes (low byte) 0x00 - number of bytes (high byte) 0x0C - type of element 0 (string) 0x0A - offset of element 0 (low byte) 0x00 - offset of element 0 (high byte) 0x0C - type of element 1 (string) CHANGED 0x0D - offset of element 1 (low byte) 0x00 - offset of element 1 (high byte) 0x02 - length of element 0 'X' - content of element 0 'Y' - content of element 0 CHANGED 0x04 - length of element 1 CHANGED 'X' CHANGED 'Y' CHANGED 'Z' - content of element 1 CHANGED 'W'
這裏會產生兩個binary diff,一個更新offset, 一個更新數據
我們再執行一條update,將字符串修改成整數,這種情況下,原來存儲字符串offset的位置被更改成了整數,而原來字符串占用的空間變成Unused狀態。這裏只
UPDATE t SET b= JSON_SET(b, '$[1]', 456)
0x02 - type: small JSON array 0x02 - number of elements (low byte) 0x00 - number of elements (high byte) 0x12 - number of bytes (low byte) 0x00 - number of bytes (high byte) 0x0C - type of element 0 (string) 0x0A - offset of element 0 (low byte) 0x00 - offset of element 0 (high byte) CHANGED 0x05 - type of element 1 (int16) CHANGED 0xC8 - value of element 1 (low byte) CHANGED 0x01 - value of element 1 (high byte) 0x02 - length of element 0 'X' - content of element 0 'Y' - content of element 0 (free) 0x04 - length of element 1 (free) 'X' (free) 'Y' (free) 'Z' - content of element 1 (free) 'W
類型從string變成int16,使用之前offset的字段記錄int值,而原來string的空間則變成空閑狀態, 這裏產生一個binary diff。
我們再來看看另外一個相似的函數Value::remove_in_shadow
,即通過json_remove從列上移除一個字段,以下樣例同樣摘自函數的註釋:
json列的值為
{ "a": "x", "b": "y", "c": "z" } 存儲格式: 0x00 - type: JSONB_TYPE_SMALL_OBJECT 0x03 - number of elements (low byte) 0x00 - number of elements (high byte) 0x22 - number of bytes (low byte) 0x00 - number of bytes (high byte) 0x19 - offset of key "a" (high byte) 0x00 - offset of key "a" (low byte) 0x01 - length of key "a" (high byte) 0x00 - length of key "a" (low byte) 0x1a - offset of key "b" (high byte) 0x00 - offset of key "b" (low byte) 0x01 - length of key "b" (high byte) 0x00 - length of key "b" (low byte) 0x1b - offset of key "c" (high byte) 0x00 - offset of key "c" (low byte) 0x01 - length of key "c" (high byte) 0x00 - length of key "c" (low byte) 0x0c - type of value "a": JSONB_TYPE_STRING 0x1c - offset of value "a" (high byte) 0x00 - offset of value "a" (low byte) 0x0c - type of value "b": JSONB_TYPE_STRING 0x1e - offset of value "b" (high byte) 0x00 - offset of value "b" (low byte) 0x0c - type of value "c": JSONB_TYPE_STRING 0x20 - offset of value "c" (high byte) 0x00 - offset of value "c" (low byte) 0x61 - first key ('a') 0x62 - second key ('b') 0x63 - third key ('c') 0x01 - length of value "a" 0x78 - contents of value "a" ('x') 0x01 - length of value "b" 0x79 - contents of value "b" ('y') 0x01 - length of value "c" 0x7a - contents of value "c" ('z')
將其中的成員$.b移除掉:
UPDATE t SET j = JSON_REMOVE(j, '$.b'); 格式為: 0x00 - type: JSONB_TYPE_SMALL_OBJECT CHANGED 0x02 - number of elements (low byte) 0x00 - number of elements (high byte) 0x22 - number of bytes (low byte) 0x00 - number of bytes (high byte) 0x19 - offset of key "a" (high byte) 0x00 - offset of key "a" (low byte) 0x01 - length of key "a" (high byte) 0x00 - length of key "a" (low byte) CHANGED 0x1b - offset of key "c" (high byte) CHANGED 0x00 - offset of key "c" (low byte) CHANGED 0x01 - length of key "c" (high byte) CHANGED 0x00 - length of key "c" (low byte) CHANGED 0x0c - type of value "a": JSONB_TYPE_STRING CHANGED 0x1c - offset of value "a" (high byte) CHANGED 0x00 - offset of value "a" (low byte) CHANGED 0x0c - type of value "c": JSONB_TYPE_STRING CHANGED 0x20 - offset of value "c" (high byte) CHANGED 0x00 - offset of value "c" (low byte) (free) 0x00 (free) 0x0c (free) 0x1e (free) 0x00 (free) 0x0c (free) 0x20 (free) 0x00 0x61 - first key ('a') (free) 0x62 0x63 - third key ('c') 0x01 - length of value "a" 0x78 - contents of value "a" ('x') (free) 0x01 (free) 0x79 0x01 - length of value "c" 0x7a - contents of value "c" ('z')
這裏會產生兩個binary diff,一個用於更新element個數,一個用於更新offset。
從上面的例子可以看到,每個Binary diff表示了一段連續更新的數據,有幾段連續更新的數據,就有幾個binary diff。 binary diff存儲到TABLE::m_partial_update_info->m_binary_diff_vectors
中,
寫入logical diff
logical diff 主要用於優化寫binlog
Sql_cmd_update::update_single_table |--> fill_record_n_invoke_before_triggers |-->fill_record |--> Item::save_in_field |--> Item_func::save_possibly_as_json |--> Item_func_json_set_replace::val_json |-->TABLE::add_logical_diff
新的LOB存儲格式
相關代碼:
storage/innobase/lob/*, 所有的類和函數定義在namesapce lob下面
從上面的分析可以看到,Server層已經提供了所有修改的偏移量,新數據長度,已經判斷好了數據能夠原地存儲,對於innodb,則須要利用這些信息來實現partial update 。
在展開這個問題之前,我們先來看下innodb針對json列的新格式。從代碼中可以看到,為了實現partial update, innodb增加了幾種新的數據頁格式:
壓縮表: FIL_PAGE_TYPE_ZLOB_FIRST FIL_PAGE_TYPE_ZLOB_DATA FIL_PAGE_TYPE_ZLOB_INDEX FIL_PAGE_TYPE_ZLOB_FRAG FIL_PAGE_TYPE_ZLOB_FRAG_ENTRY 普通表: FIL_PAGE_TYPE_LOB_INDEX FIL_PAGE_TYPE_LOB_DATA FIL_PAGE_TYPE_LOB_FIRST
我們知道,傳統的LOB列通常是在聚集索引記錄內留一個外部存儲指針,指向lob存儲的page,如果一個page存儲不下,就會產生lob page鏈表。而新的存儲格式,則引入了lob index的概念,也就是為所有的lob page建立索引,格式如下:
ref pointer in cluster record ------- | FIL_PAGE_TYPE_LOG_FIRST | FIL_PAGE_TYPE_LOB_INDEX -----------> FIL_PAGE_TYPE_LOB_DATA | FIL_PAGE_TYPE_LOB_INDEX -------------> FIL_PAGE_TYPE_LOB_DATA | ... ....
Note: 本文只討論非壓縮表的場景, 對於壓縮表引入了更加復雜的數據類型,以後有空再在本文補上。
ref Pointer格式如下(和之前相比,增加了版本號)
字段 | 字節數 | 描述 |
---|---|---|
BTR_EXTERN_SPACE_ID | 4 | space id |
BTR_EXTERN_PAGE_NO | 4 | 第一個 lob page的no |
BTR_EXTERN_OFFSET/BTR_EXTERN_VERSION | 4 | 新的格式記錄version號 |
第一個FIL_PAGE_TYPE_LOG_FIRST頁面的操作定義在 lob::first_page_t類中格式如下(參考文件: include/lob0first.h lob/lob0first.cc):
字段 | 字節數 | 描述 |
---|---|---|
OFFSET_VERSION | 1 | 表示lob的版本號,當前為0,用於以後lob格式改變做版本區分 |
OFFSET_FLAGS | 1 | 目前只使用第一個bit,被設置時表示無法做partial update, 用於通知purge線程某個更新操作產生的老版本LOB可以被完全釋放掉 |
OFFSET_LOB_VERSION | 4 | 每個lob page都有個版本號,初始為1,每次更新後遞增 |
OFFSET_LAST_TRX_ID | 6 | |
OFFSET_LAST_UNDO_NO | 4 | |
OFFSET_DATA_LEN | 4 | 存儲在該page上的數據長度 |
OFFSET_TRX_ID | 6 | 創建存儲在該page上的事務id |
OFFSET_INDEX_LIST | 16 | 維護lob page鏈表 |
OFFSET_INDEX_FREE_NODES | 16 | 維護空閑節點 |
LOB_PAGE_DATA | 存儲數據的起始位置,註意第一個page同時包含了lob index 和lob data,但在第一個lob page中只包含了10個lob index記錄,每個lob index大小為60字節 |
除了第一個lob page外,其他所有的lob page都是通過lob index記錄來指向的,lob index之間鏈接成鏈表,每個index entry指向一個lob page,
普通Lob Page的格式如下
字段 | 字節數 | 描述 |
---|---|---|
OFFSET_VERSION | 1 | lob data version,當前為0 |
OFFSET_DATA_LEN | 4 | 數據長度 |
OFFSET_TRX_ID | 6 | 創建該lob page的事務Id |
LOB_PAGE_DATA | lob data開始的位置 |
lob index entry的大小為60字節,主要包含如下內容(include/lob0index.h lob/lob0index.cc):
偏移量 | 字節數 | 描述 |
---|---|---|
OFFSET_PREV | 6 | Pointer to the previous index entry |
OFFSET_NEXT | 6 | Pointer to the next index entry |
OFFSET_VERSIONS | 16 | Pointer to the list of old versions for this index entry |
OFFSET_TRXID | 6 | The creator transaction identifier. |
OFFSET_TRXID_MODIFIER | 6 | The modifier transaction identifier |
OFFSET_TRX_UNDO_NO | 4 | the undo number of creator transaction. |
OFFSET_TRX_UNDO_NO_MODIFIER | 4 | The undo number of modifier transaction. |
OFFSET_PAGE_NO | 4 | The page number of LOB data page |
OFFSET_DATA_LEN | 4 | The amount of LOB data it contains in bytes. |
OFFSET_LOB_VERSION | 4 | The LOB version number to which this index entry belongs. |
從index entry的記錄格式我們可以看到 兩個關鍵信息:
對lob page的修改會產生新的lob page(“lob::replace()”) 和新的lob index entry
lob page no及其數據長度,據此我們可以根據修改的數據在json column裏的offset,通過lob index快速的定位到其所在的lob page
每個lob page的版本號: 為了實現mvcc多版本,用戶線程先從undo log中找到對應版本的clust record,找出其中存儲的版本號v1,然後在掃描lob index時,如index entry中記錄的版本號<= v1,則是可見的,如果> v1, 那麽就需要根據OFFSET_VERSIONS鏈表,找到對應版本的index entry,並
根據這個老的Index entry找到對應的lob page, 如下所示:
EXTERN REF (v2) | LOB IDX ENTRY (v1) | LOB IDX ENTRY(v2) -----> LOB IDX ENTRY(v1) | LOG IDX ...(v1)
多版本讀判斷參考函數 'lob::read'
lob更新lob::update
: 根據binary diff,依次replace
Note: 不是所有的lob數據都需要partial update, 額外的lob index同樣會帶來存儲開銷,因此定義了一個threshold(ref_t::LOB_BIG_THRESHOLD_SIZE),超過2個page才去做partial update; 另外row_format也要確保lob列不存儲列前綴到clust index ( ref btr_store_big_rec_extern_fields
)
寫入binlog
在更新完一行後,對應的變更需要打包到線程的cache中(THD::binlog_write_row() --> pack_row()
), 這時候要對partial update進行特殊處理,需要設置特定選項:
binlog_row_image = MINIMAL;
binlog_row_value_options=PARTIAL_JSON
如上例第一個update產生的binlog如下:
UPDATE t SET b = JSON_SET(b, '$[0]', 'XY'); binlog: '/*!*/; ### UPDATE `test`.`t` ### WHERE ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### SET ### @2=JSON_REPLACE(@2, '$[0]', 'XY') /* JSON meta=4 nullable=1 is_null=0 */
由於存在主鍵,因此前鏡像只記錄了主鍵值,而後鏡像也只記錄了需要更新的列的內容,對於超大Json列,binlog上的開銷也是極小的,考慮到binlog通常會成為性能瓶頸點,預計這一特性會帶來不錯的吞吐量提升
原文鏈接
MySQL8.0 新特性:Partial Update of LOB Column