開頭還是介紹一下群，如果感興趣polardb ,mongodb ,mysql ,postgresql ,redis 等有問題，有需求都可以加群群內(nèi)有各大數(shù)據(jù)庫行業(yè)大咖，CTO，可以解決你的問題。加群請聯(lián)系 liuaustin3 ，在新加的朋友會分到2群（共1300人左右 1 + 2 + 3 + 4） 3群即將突破 400 會關(guān)閉自由申請，新人會進(jìn)4群

這個系列很長時間沒有更新了，還差2篇的翻譯，最近會逐步更新。

一個時代的落幕，必然有成功者，也有失敗者，失敗是“成功者”定義的，而實際上“失敗者”?也未必單純是自己的問題，或許他只是出生在錯誤的時間，錯誤地點罷了，成功者也不必說，自己的一切都是自己的努力，帆船造型在好，材質(zhì)在輕，在堅固也需要有風(fēng)和浪。

IMIC 在PolarDB 中是保證一個類 MySQL的數(shù)據(jù)庫能處理MySQL無法處理的數(shù)據(jù)量與查詢方式。

————————————————————————————

4.3 數(shù)據(jù)打包壓縮和整理壓縮

當(dāng)部分package達(dá)到最大容量后，它會被轉(zhuǎn)換為big package并壓縮到磁盤上以減少空間消耗。壓縮過程采用寫同時復(fù)制模式避免訪問中產(chǎn)生沖突。也就是說，生成一個新package來保存壓縮數(shù)據(jù)，而不對部分package進(jìn)行任何更改。（建立一個存放數(shù)據(jù)的容器進(jìn)入的時候就被壓縮了）PolarDB-IMCI在壓縮后更新元數(shù)據(jù)，將部分打包的數(shù)據(jù)替換為新的package（即以原子方式更新指向新打包的指針）,對于不同的數(shù)據(jù)類型，列索引采用不同的壓縮算法。數(shù)值列采用參考幀、delta編碼和位壓縮的組合，而字符串列使用字典壓縮。此外，由于打包是不可變的，當(dāng)活動事務(wù)大于所有VID時，即沒有活動事務(wù)引用插入VID映射時，該打包的插入VID映射是無用的。在這種情況下，PolarDB-IMCI會刪除行組中的插入VID映射以減少內(nèi)存占用。

整理

刪除操作可能在一個打包中設(shè)置刪除VID，從而在該打包中留下空洞。隨著無效行的數(shù)量隨時間增加，掃描性能和空間利用效率會降低。PolarDB-IMCI定期檢測和重新整理不足的打包，以保持列索引無效行的低水位。例如，少于一半有效行的稀疏包被選為不能進(jìn)行package。然后，后臺線程發(fā)起一個整理事務(wù)，其中包括大量的更新操作，針對每個遷移的有效行，將選定的package的所有有效行,重新追加到部分打包中。請記住，列索引的更新操作是就地進(jìn)行的，因此舊行在整理期間甚至之后仍然可以進(jìn)行前臺操作，這使得更新操作不受阻塞。整理后選定的打包在沒有活動事務(wù)訪問時將被永久刪除。

5 更新

在本節(jié)中，我們描述了我們在同步異構(gòu)數(shù)據(jù)存儲方面的努力。對OLTP的最小干擾是PolarDB-IMCI的一個高優(yōu)先級目標(biāo)。為了實現(xiàn)這個目標(biāo)，PolarDB-IMCI中的更新傳播是通過REDO日志實現(xiàn)的，消除了將額外邏輯日志持久化的開銷。在REDO日志的基礎(chǔ)上，PolarDB需要盡可能及時地保持RO節(jié)點的更新以保持?jǐn)?shù)據(jù)的新鮮度。為此，我們引入了前置提交日志傳送(CALS)來減少可見延遲，并引入了兩階段無沖突并行回放(2P-COFFER)機制來提高回放吞吐量。

提前提交日志傳輸 為了最小化性能干擾，在PolarDB-IMCI中，對RO節(jié)點的更新是完全異步的。鑒于此，為增強數(shù)據(jù)的新鮮度，PolarDB-IMCI使用了提前提交日志傳輸（CALS）技術(shù)，在提交之前將事務(wù)傳送到其他節(jié)點。如圖5所示，一個事務(wù)由多個日志項組成：最后一個日志項是提交或中止日志，前面的日志項是DML日志。每個日志項都被分配了一個日志序列號（LSN）。例如，事務(wù)TID為101的日志項有LSN 300～302。日志項300和301是DML操作的日志，而日志項302包含了事務(wù)的決定（即中止）。當(dāng)RW節(jié)點將一個日志項寫入共享存儲（即PolarFS）后，它通過廣播其最新的LSN（在我們的例子中為299）通知RO節(jié)點。當(dāng)接收到LSN時，RO節(jié)點立即從PolarFS中讀取日志。然后，每個DML日志都會被解析為一個DML語句，并基于其TID存儲在一個事務(wù)緩沖區(qū)中（每個事務(wù)一個緩沖單元）。整個過程不需要等待RW節(jié)點提交事務(wù)。例如，在日志項299中的最終提交之前，具有TID 100的事務(wù)中的DML操作將被傳輸。當(dāng)RO節(jié)點讀取一個提交日志項時，較早的DML語句已經(jīng)被解析并作為邏輯操作交付到事務(wù)緩沖區(qū)中，使得PolarDB-IMCI能夠立即重放這些DML操作。當(dāng)讀取一個中止日志項時，RO節(jié)點只需釋放事務(wù)緩沖區(qū)，無需回滾數(shù)據(jù)。

兩階段無沖突并行回放 如前所述，PolarDB-IMCI不會為了更新傳播而生成額外的邏輯日志，而是重用REDO日志。其原因是日志傳送會使RW節(jié)點寫入更多的日志項，從而影響OLTP性能。然而，從長遠(yuǎn)來看，使用REDO日志同步異構(gòu)存儲被認(rèn)為幾乎是不可能的。這存在三個挑戰(zhàn)：

(1) REDO日志僅記錄行存儲中物理頁面的變化，缺乏數(shù)據(jù)庫級別或表級別的信息（例如，RO節(jié)點不知道頁面更改對應(yīng)哪個表）。

(2) REDO日志還包括由行存儲本身引起的頁面更改，而不僅僅是用戶的DML操作，例如B+樹的分裂/合并和頁面整理。列索引不能應(yīng)用這些日志，否則可能導(dǎo)致不一致。

(3) REDO日志僅包含差異而不是完整的更新，以減少日志占用空間。

如圖6所示，PolarDB-IMCI通過兩個重放階段解決了這些挑戰(zhàn)。第一階段是將REDO日志重放到RO節(jié)點的內(nèi)存中的行存儲的副本。在這個階段，PolarDB-IMCI獲取完整的信息，將REDO日志解析為邏輯DML語句。然后，第二階段是將DML語句重放到列索引中，重放的性能對我們的系統(tǒng)至關(guān)重要。這些工作要么以會話粒度進(jìn)行并行重放，要么以事務(wù)粒度進(jìn)行并行重放，并借助沖突處理輔助工具（例如鎖）或者樂觀控制。與這些工作不同，PolarDB-IMCI提出了一種新的重放方法，即2P-COFFER，使得兩個重放階段都是無沖突的。在2P-COFFER中，第一階段以頁面粒度進(jìn)行，而第二階段以行粒度進(jìn)行，以實現(xiàn)對不同頁面/行的并發(fā)修改。修改相同頁面/行但屬于不同事務(wù)的日志條目被視為依賴項，應(yīng)該按順序重放。使用2P-COFFER，RO節(jié)點的重放吞吐量要遠(yuǎn)高于RW節(jié)點的OLTP吞吐量。

5.3 物理日志解析 如圖7所示，PolarDB的REDO日志記錄包含多個字段。為簡單起見，我們以更新操作為例，其他類型的操作類似。

• TID是創(chuàng)建此記錄的事務(wù)標(biāo)識符。

• LSN表示日志中此記錄的順序。

• PageID標(biāo)識此記錄更新的行所屬的物理頁面。偏移字段（SlotID）進(jìn)一步確定更新的行在頁面上的位置。

  Data字段（差分日志）包含更新值與原始值之間的差異。第一階段根據(jù)PageID將REDO日志分發(fā)給不同的工作者，并且每個工作者按照LSN的順序重放頁面更改以重現(xiàn)DML的細(xì)節(jié)。分發(fā)過程與第二階段類似，但是以頁面粒度進(jìn)行，對于更新類型的日志記錄，工作者在重放過程中將生成一個刪除DML和一個插入DML，因為列索引是被更新到新的地方的。REDO日志的字段可能不包含主鍵（PK）信息，而刪除DML需要主鍵信息因此，工作者根據(jù)PageID和偏移字段從PolarFS中獲取舊行，并在工作條目之前使用舊行組裝一個刪除類型的DML。字段應(yīng)用于提取的行中以重放頁面更改，并在應(yīng)用后組裝插入DML。為了真正將操作組合成邏輯DML，每個操作還必須補充其他的信息。

  通過記錄在頁面上的表ID來獲取結(jié)構(gòu)信息，同時必須識別行存儲本身生成的日志條目（例如，B+樹分裂）。為了處理這個問題，先檢查一個日志條目是否屬于活動事務(wù)。如果不屬于，則確認(rèn)該條目不是由用戶事務(wù)生成的。如果屬于，則進(jìn)一步檢查該條目的主鍵是否在活動事務(wù)中被重復(fù)插入（通過一個主鍵集合）。注意，重復(fù)的主鍵插入不是用戶DML。因此，重復(fù)使用REDO日志會導(dǎo)致重放所有頁面更改。作為一種優(yōu)化，PolarDB-IMCI允許RO節(jié)點像RW節(jié)點一樣維護行存儲的緩沖池，以減少數(shù)據(jù)頁面讀取量。在我們的實踐中，第一階段的計算能力遠(yuǎn)遠(yuǎn)超過RW的日志產(chǎn)生能力。一方面，RO節(jié)點直接重現(xiàn)頁面更改，無需重做事務(wù)的開銷，如B+樹遍歷。另一方面，REDO日志在實際工作負(fù)載下始終作用于熱頁面，使得緩沖池的命中率接近99%。盡管緩沖池減少了用于OLAP的內(nèi)存，但我們在這里進(jìn)行了權(quán)衡，因為通過REDO日志減少對OLTP的干擾在我們的場景中具有更高優(yōu)先級的。

  第二階段：邏輯DML應(yīng)用 REDO日志的LSN順序確保了日志重放的基本前提，這意味著在RO節(jié)點中的更改可以按照與RW相同的順序進(jìn)行。第一階段打破了這個順序。因此，在轉(zhuǎn)換之后，后臺線程將根據(jù)關(guān)聯(lián)日志條目的LSN對DML進(jìn)行排序。然后，后臺線程將DML插入到事務(wù)緩沖單元中。

  在第二階段，調(diào)度程序?qū)⒁慌聞?wù)分發(fā)給多個工作者，以并行的方式對列索引進(jìn)行修改。分發(fā)是逐行進(jìn)行的，來自單個事務(wù)的DML語句將被分配給多個工作者進(jìn)行重放。對于一個DML語句，調(diào)度程序通過對行主鍵的哈希值取模來分配指定的工作者。因此，即使這些DML語句屬于不同的事務(wù)，修改相同行的DML語句將按照提交順序被分配給相同的工作者。調(diào)度程序按照提交順序處理每個事務(wù)，確保對同一行修改不同的值按照順序傳遞給相同的線程，從而保證一致性。每個工作者按照步驟依次重放每個DML語句，并將更改批量提交到列索引中。

• 如果一個事務(wù)包含太多的操作，它的事務(wù)緩沖區(qū)單元可能會消耗大量的內(nèi)存根據(jù)相關(guān)的原理，為了避免過度的內(nèi)存消耗，PolarDB-IMCI對大事務(wù)進(jìn)行預(yù)提交：當(dāng)事務(wù)緩沖單元中的DML語句數(shù)量達(dá)到給定閾值時，將進(jìn)行預(yù)提交。預(yù)提交的基本思想是將更新寫入到具有無效插入和刪除VID的部分?jǐn)?shù)據(jù)包中，使得更新在暫時不可見。預(yù)提交的具體步驟如下。首先，為當(dāng)前事務(wù)緩沖區(qū)中的所有行請求連續(xù)的RID，并保存此RID范圍。在預(yù)提交階段，全局RID定位器尚不能更改，以避免未提交事務(wù)的暴露。PolarDB-IMCI創(chuàng)建一個臨時的RID定位器，而不是更新RID全局定位器以緩存新的PK到RID映射關(guān)系。然后，PolarDB-IMCI將更新寫入到部分?jǐn)?shù)據(jù)包中，同時將插入和刪除VID設(shè)置為無效以使其不可見。最后，PolarDB-IMCI釋放事務(wù)緩沖單元使用的內(nèi)存。

  當(dāng)大事務(wù)提交時，PolarDB-IMCI將臨時RID定位器合并到全局RID定位器中，并使用事務(wù)提交序列號糾正無效的VID（在保存的RID范圍內(nèi)）。否則，如果大事務(wù)中止，則臨時定位器將被清除。部分?jǐn)?shù)據(jù)包中剩余的預(yù)提交行無效，并將在后臺的壓縮線程中稍后消除。

文章來源地址http://www.zghlxwxcb.cn/news/detail-733271.html