【4.分佈式存儲】-數據編碼與壓縮

時間 2019-11-05

原文原文鏈接

帶狀態的分佈式離不開數據，本文想說下數據的格式，在內存中主要考慮空間複雜度和cpu操做時間複雜性，後面會單講，分佈式裏經常使用的B，B+，list,set,跳錶,hash,空間的R樹,前綴樹，壓縮前綴樹，涉及到這幾種。在網絡和磁盤中考慮格式和人編輯格式到物理格式之間的映射，在犧牲cpu處理壓縮和解壓縮下，能夠減小磁盤佔用和網絡開銷，下面主要講三種網絡通訊的數據壓縮thriftBP,PB,Avro和幾種磁盤數據壓縮性能對比，snappy的原理，EC原理。其中涉及到兩種壓縮算法：數字變長編碼和動態詞典編碼。html

內存數據結構

這個就太多了。。略redis

IO:json/xml(無類型，unicode支持很差等),二進制編碼

JSON演化messagePack
不流行，由於須要在編碼數據中包含對象名稱.只是刪除空白和標點的感受

thrift BinaryProtocal 字段名替換爲序號算法

{
    "userName": "Martin",
    "favoriteNumber": 1337,
    "interests": ["daydreaming", "hacking"]
}

=》壓縮格式：
shell

pb(thrift的compactProtocal和這個同樣)

field和type在單個字節。數據的優化數據最高位標識是否還有後續，這個1337有錯誤，是下面的apache
Avro
官方：http://avro.apache.org/docs/c...
這幾種網絡傳輸數據格式，由用戶定義，就考慮數據變動時的兼容：
從上面能夠看出thrift和protocal在壓縮時是依賴編號的，能夠換換名字，可是不能換編號，能夠增長編號，舊的編號刪了也不能再用，後加的向前兼容不能設爲必選。
Avro在數據變動方便及其靈活，模式和數據編碼分別傳送，一個傳一個模式，大批數據，無編號，讀者模式與做者模式匹配，讀者解析做者模式

只能添加或刪除有默認值的字段json

可變長數字編碼
int等固定64位的轉爲二進制，本身斷定長度。
1.連續位標識
以上數字的轉變全是基於VLQ可變長二進制數字編碼的變體。最低位加0表示整數，1表示負數，而後7位一個分割。從最後開始，每一個後面有第一位是1，不然是0.
2.前綴長度。
前綴標識固定的長度，redis中也有不少前綴標識長度的壓縮好比UTF8:網絡

第一個字節	第二個字節	第三個字節	第四個字節	用於實際編碼的bit數量	能表示的最大unicode值
0xxxxxxx				7	127
110xxxxx	10xxxxxx			11	2047
1110xxxx	10xxxxxx	10xxxxxx		16	65535
11110xxx	10xxxxxx	10xxxxxx	10xxxxxx	21	1114111

壓縮

壓縮算法對比

https://catchchallenger.first...:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO
https://www.percona.com/blog/...數據結構
snappy/LZ77/LZSS
DC動態詞典編碼：用它在詞典中的位置號碼代替。靜態實現須要知道所有詞典，講下動態的
前向緩衝區（數據流將要處理的全部字符）的開始字符串與滑動窗口中的字符串進行最長匹配，無移動窗口，若找到輸出<匹配字符串在滑動窗口的位置，長度，移除前置緩衝區中匹配部分移除後續第一個字符>,LZSS增長匹配長讀限制

如何快速找到最長匹配字符串？：簡單的將窗口中全部字符順序組合存入hash，也能夠存固定長度，好比2，匹配多個後再繼續向後比這些固定長度匹配的位置。
snappy 將整個數據切割爲32k一個大小的塊，塊之間無關聯，2個字節就可表示匹配字符串的相對位置，匹配長度至少爲4，hash字符串長度也固定爲4.輸出字符串的壓縮形式爲 <編碼方案，匹配字符串起始位置差值，匹配字符串長度>app
EC編碼：N個數據塊和校驗，能夠任意丟k個相互恢復
由於咱們都是多副本，
N個Data塊，生成K個Parity塊，N+K中可任意丟K個
可靠性相同時比多副本冗餘度低
只有一份數據可讀，修復較複雜
提升可靠性：增長K，增長N和K，提升修復速度
https://blog.csdn.net/shelldo...