導航:首頁 > 源碼編譯 > lz4壓縮演算法

lz4壓縮演算法

發布時間:2022-09-28 05:20:25

㈠ clickhouse數據壓縮對比

Clickhouse 數據壓縮主要使用兩個方案LZ4和ZSTD
LZ4解壓縮速度上會更快,但壓縮率較低,
ZSTD解壓縮較慢。但是壓縮比例較高。
clickhouse不同壓縮演算法測試對比,LZ4最優。
https://www.percona.com/blog/2016/04/13/evaluating-database-compression-methods-update
以下測試主要驗證業內測試的結論,測試的zstd數據會多一點,測試不是十分嚴謹,僅供參考。

開發(dev) 機器數量:3 cpu:40core 內存:256G disk:2.0T*10

kafka TOPIC: cdn-log-analysis-realtime。可消費數據總量363255827。數據消費4次到ck。

cdn_log_analysis_realtime lz4壓縮
cdn_log_realtime zstd壓縮

在/etc/metrika.xml
<compression incl="clickhouse_compression"> --指定incl
<case>
<min_part_size>10000000000</min_part_size> --數據部分的最小大小
<min_part_size_ratio>0.01</min_part_size_ratio> --數據部分大小與表大小的比率
<method>zstd</method> --壓縮演算法,zstd和lz4
</case>
</compression>

執行sql :SELECT table AS 表名 , sum(rows) AS 總行數 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 壓縮大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes))*100, 0) AS 壓縮率 FROM system.parts WHERE (database IN ('default') AND (table = 'cdn_log_analysis_realtime') ) GROUP BY table

分別查看不同機器的壓縮比例

平均 4.85億 數據,原始數據 105G 壓縮後數據 27G ,平均壓縮率 27%

執行sql : select toDateTime(intDiv(toUInt32(its),60)*60) as t, count() as t_c, avg(speed) as t_v, quantile(0.99)(speed) as t_99, quantile(0.90)(speed) as t_90 , quantile(0.75)(speed) as t_75 , quantile(0.50)(speed) as t_50 , quantile(0.25)(speed) as t_25 from default.cdn_log_analysis_realtime_all where day=񟭔-12-17' group by t order by t_v desc

冷數據(第一次查詢)

熱數據(第二次查詢)

執行sql :
SELECT table AS 表名 , sum(rows) AS 總行數 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 壓縮大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes))*100, 0) AS 壓縮率 FROM system.parts WHERE (database IN ('default') AND (table = 'cdn_log_realtime') ) GROUP BY table

分別查看不同機器的壓縮比例

執行sql :select toDateTime(intDiv(toUInt32(its),60)*60) as t, count() as t_c, avg(speed) as t_v, quantile(0.99)(speed) as t_99, quantile(0.90)(speed) as t_90 , quantile(0.75)(speed) as t_75 , quantile(0.50)(speed) as t_50 , quantile(0.25)(speed) as t_25 from default.cdn_log_realtime where day=񟭔-12-25' group by t order by t_v desc

冷數據(第一次查詢)

熱數據(第二次查詢)

執行sql:SELECT 'ZSTD' as 壓縮方式 , table AS 表名 , sum(rows) AS 總行數 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 壓縮大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes)) 100, 0) AS 壓縮率 FROM cluster(ctyun31, system, parts) WHERE (database IN ('default') AND (table = 'cdn_log_realtime') ) GROUP BY table union all SELECT 'LZ4' as 壓縮方式 , table AS 表名 , sum(rows) AS 總行數 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 壓縮大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes)) 100, 0) AS 壓縮率 FROM cluster(ctyun31, system, parts) WHERE (database IN ('default') AND (table = 'cdn_log_analysis_realtime') ) GROUP BY table

測試不是十分嚴謹,ZSTD的ck表的數據多一點,但是不影響測試結果,僅做參考。
壓縮能力上,ZSTD的壓縮比例為 22% ,LZ4的壓縮比例為 27% ,ZSTD的壓縮性能更好。但是效果不是很明顯。
查詢能力上,冷數據查詢,兩者相差不大。熱數據方面,ZSTD為 3.884s ,而LZ4為 1.150s 。ZSTD查詢時間在 3.37倍 以上,LZ4的查詢能力更強。
綜上所述,建議使用LZ4。

集群數據量後期預估,按當前使用lz4壓縮方案,3分片1副本,計算3 5.5 10*0.8(按磁碟最多使用80%算) 的硬碟能存儲大概多少數據。

一天數據100億
一天磁碟消耗 (10000000000/1453023308.0 84.98)/1024.0=0.57TB
能存儲天數 3 5.5 10 0.8/0.57=231.57 day。

一天數據1000億
231.57/10=23.1day。

㈡ mysqlbinlog的問題求助

1. 開啟壓縮功能後,通過 ZSTD 演算法對每個事務進行壓縮,寫入二進制日誌。

2. 新版本更改了 libbinlogevents,新增 Transaction_payload_event 作為壓縮後的事務表示形式。

class Transaction_payload_event : public Binary_log_event { protected: const char *m_payload; uint64_t m_payload_size; transaction::compression::type m_compression_type; uint64_t m_uncompressed_size;

3. 新增 Transaction_payload_event 編碼器/解碼器,用於實現對壓縮事務的編碼和解碼。

㈢ 二進制壓縮演算法有哪些

二進制數據壓縮演算法二進制是計算技術中廣泛採用的一種數制。二進制數據是用0和1兩個數碼來表示的數。它的基數為2,進位規則是「逢二進一」,借位規則是「借一當二」,由18世紀德國數理哲學大師萊布尼茲發現。當前的計算機系統使用的基本上是二進制系統,數據在計算機中主要是以補碼的形式存儲的。計算機中的二進制則是一個非常微小的開關,用「開」來表示1,「關」來表示0。

20世紀被稱作第三次科技革命的重要標志之一的計算機的發明與應用,因為數字計算機只能識別和處理由『0』。『1』符號串組成的代碼。其運算模式正是二進制。19世紀愛爾蘭邏輯學家喬治布爾對邏輯命題的思考過程轉化為對符號「0『』。『』1『』的某種代數演算,二進制是逢2進位的進位制。0、1是基本算符。因為它只使用0、1兩個數字元號,非常簡單方便,易於用電子方式實現。

二進制壓縮 - 演算法

二進制壓縮

編程時遇到每個數據只有兩種狀態,且 dfs 或者 bfs 時遍歷時間復雜度高時,可以採用二進制壓縮數據,尤其是二維數組。LZFSE

1,zlib和gzip都對deflate進行了封裝,比deflate多了數據頭和尾

1,蘋果開源了新的無損壓縮演算法 LZFSE ,該演算法是去年在iOS 9和OS X 10.10中 引入 的。按照蘋果公司的說法,LZFE的壓縮增益和ZLib level 5相同,但速度要快2~3倍,能源效率也更高。

LZFSE基於Lempel-Ziv,並使用了 有限狀態熵編碼,後者基於Jarek Duda在

非對稱數字系統(ANS)方面所做的熵編碼工作。簡單地講,ANS旨在「終結速度和比率的平衡」,既可以用於精確編碼,又可以用於快速編碼,並且具有數據加密功能。使用ANS代替更為傳統的

Huffman和 算術編碼方法的壓縮庫 越來越多,LZFSE就位列其中。

顯然,LZFSE的目標不是成為最好或最快的演算法。事實上,蘋果公司指出,

LZ4的壓縮速度比LZFSE快,而 LZMA提供了更高的壓縮率,但代價是比Apple

SDK提供的其他選項要慢一個數量級。當壓縮率和速度幾乎同等重要,而你又希望降低能源效率時,LZFSE是蘋果推薦的選項。

GitHub上提供了LZFSE的參考實現。在MacOS上構建和運行一樣簡單:

$ xcodebuild install DSTROOT=/tmp/lzfse.dst

如果希望針對當前的iOS設備構建LZFSE,可以執行:

xcodebuild -configuration 「Release」 -arch armv7 install DSTROOT=/tmp/lzfse.dst

除了 API文檔之外,蘋果去年還提供了一個 示例項目,展示如何使用LZFSE 進行塊和流壓縮,這是一個實用的LZFSE入門資源。

LZFSE是在谷歌 brotli之後發布的,後者在去年開源。與LZFSE相比,brotli 似乎是針對一個不同的應用場景進行了優化,比如壓縮靜態Web資產和Android APK,在這些情況下,壓縮率是最重要的。

㈣ ClickHouse數據壓縮

ClickHouse支持多種方式的數據壓縮:LZ4和ZSTD。
關於壓縮演算法的測試,見 這篇文章 。簡而言之,LZ4在速度上會更快,但是壓縮率較低,ZSTD正好相反。盡管ZSTD比LZ4慢,但是相比傳統的壓縮方式Zlib,無論是在壓縮效率還是速度上,都可以作為Zlib的替代品。
下面我們對比一下這兩種壓縮方式。壓縮測試所用的表(lineorder)結構和數據來自 這里 。未壓縮的數據集是680GB。
把上述數據載入到ClickHouse後,默認的LZ4壓縮演算法下,數據容量是184G(壓縮到27%),而ZSTD達到了135GB(壓縮到20%)。
如果想要使用ZSTD壓縮方式,修改為如下配置即可:

壓縮比率對比

壓縮後的查詢性能如何,我們來跑如下查詢看看:

為了保持客觀,查詢測試會跑兩次,第一次是冷數據請求,這次的數據沒有被操作系統緩存,第二次是熱數據情求,這次的數據已經被操作系統的內存緩存了。
LZ4的性能如下:

ZSTD性能如下:

冷數據查詢情況下,兩者區別不大,因為消耗在IO方面的時間,遠大於消耗在數據解壓縮上面的時間。
熱數據請求下,LZ4會更快,此時IO代價小,數據解壓縮成為性能瓶頸。
綜上所述,默認的LZ4壓縮方式,會給我們提供更快的執行效率,但是同時需要佔用較多的磁碟容量。
ClickHouse拋開高效的SQL執行效率,數據壓縮比率也是一個非常喜人的地方。使用Hadoop Node低配置伺服器,再加上ClickHouse優秀的壓縮性能,單機容量輕松可達幾十T,推薦直接使用默認的LZ4壓縮方式,用可以接受的少量空間來換查詢執行效率的提升。

㈤ Kafka:如何高效運維之主題篇

作為一個 Kafka 初學者,需要快速成長,承擔維護公司 Kafka 的重任,對 Kafka 的學習,我按照三步走策略:

本文屬於學習的第二階段:[ 從運維實戰的角度學習 Kafka ],重點學習 Kafka 的主題,通過運維命令創建、更新主題,從 Topic 的 可運維屬性,了解 Topic 在 Kafka 內部的運作機制

Kafka 提供了 kafka-topics 腳步用來創建、修改、刪除、查詢 topic,位於${kafka_home}/bin/kafka-topics.sh,其中 kafka_home 表示 Kafka 的安裝目錄。

一些不那麼直觀的選項進行單獨介紹。

收到指定副本數量和分區信息,該參數不能和--partitions、--replication-factor 同時使用。

其格式為:每一個逗號表示一個分區的配置,每一個分區分布的 broker 用冒號隔開。

--replication-factor0:1,1:2,0:2 表示的含義是什麼呢?

分區數量為 3 個,其中分區 0(p0)分布在 broker 0 和 1 上,分區 1(p1)分布在 broker 1,2 上,分區 2(p2)分布在 broker 0 與 2 上。從而推出分區數量為 3,副本因子為 2,每一個分區的第一個 broker 為 Leader,其演示效果如下:

通過 kafka-topics 腳本在創建 topic 時可通過--config 選項來定製化 topic 的屬性,接下來試圖從這些屬性來探究 Kafka 背後的運作機制。

數據文件清除機制,支持 Broker 全局配置,Topic 定製化制定,可選策略:delete、compact,默認值為 delete。Kafka 提供了數據段壓縮的功能,按照相同 Key 只保留最新 Key 的策略,減少數據段大小,系統主題__consumer_offsets(用於存儲消息進度的主題)其清除策略就是 compact。

壓縮類型,Kafka 目前支持的壓縮演算法:gzip,snappy,lz4,zstd,還支持如下兩個配置:

不開啟壓縮

由發送方指定壓縮演算法,客戶端的可選值為 gzip,snappy,lz4,zstd。

數據進行壓縮,能節省網路帶寬與存儲空間,但會增加 CPU 的性能,故 最佳實踐 :Broker 服務端不配置壓縮演算法, 由發送方指定,在發送方進行壓縮,服務端原封不動進行存儲,並且在消費端解壓縮

如果 cleanup.policy 策略為 compact 時,針對消息體為 null 的消息,Kafka 會認為對其進行壓縮沒有意義,立馬刪除也太草率,故 Kafka 引入了該參數,用來設置這些 body 為 null 的消息,在一次壓縮執行後,多久後可被刪除,默認值為 24h。

文件在刪除時延遲時間,默認為 60s,Kafka 中可以支持按 topic 刪除日誌文件(數據文件),執行刪除之前,首先會將該 topic 下的分區文件重名為*.deleted,等待 file.delete.delay.ms 才從文件系統中刪除。

按消息條數設置刷盤頻率,如果設置為 1 表示每寫一條消息就觸發一次刷盤,默認值為 Long.MaxValue,在大部分場景 官方不建議設置該值,直接利用操作系統的刷盤機制即可,Kafka 希望通過副本機制能保證數據的持久可靠存儲

按時間間隔設置刷盤頻率,默認為 Long.MaxValue,Kafka 希望藉助操作系統的刷盤機制,數據可靠性通過副本機制來保證。( 副本機制其實無法保證同機房斷電帶來的數據丟失 )

索引文件的密度,Kafka 並不會為每一條消息(消息偏移量)建立索引,而是每隔一定間隔,建立一條索引。該參數就是設置其間隔,默認為 4096 個位元組。

一次消息發送(Batch)允許的最大位元組數量,默認為 1000000,約等於 1M。

是否開啟消息格式的自動轉化,如果設置為 false,Broker 不會執行消息格式轉化,將不兼容老的客戶端消費消息。

可以指定該主題按特定版本的 API 版本所對應的存儲格式進行存儲。

設置消息中存儲的時間戳的獲取方式,可選值:

消息在客戶端的創建時間

Broker 服務端接收到的時間,默認為 CreateTime。

當 message.timestamp.type 設置為 CreateTime 時,允許 Broker 端時間與消息創建時間戳最大的差值,如果超過該參數設置的闊值,Broker 會拒絕存儲該消息, 默認為:Long.MaxValue,表示不開啟開機制

控制可壓縮的臟數據比例,默認為 0.5d,如果一個文件中"臟數據"(未被壓縮的數據)低於該闊值,將不繼續對該文件進行壓縮,該方法生效的條件為 cleanup.policy 設置為 compact

設置一條消息進入到 Broker 後多久之內不能被 compact,默認為 0,表示不啟用該特性,該方法生效的條件為 cleanup.policy 設置為 compact

如果客戶端在消息發送時將 ack 設置為 all,該參數指定必須至少多少個副本寫入成功,才能向客戶端返回成功,默認為 1,這個是一個兜底配置,all 的含義表示在 ISR 中的副本必須全部寫入成功。

是否開啟預熱文件(提前創建文件),默認為 false。

一個日誌分區保留的最大位元組數,默認為-1,表示不限制。

一個日誌分區允許保留的最大時長,默認保留 7d。

一個日誌段的大小,默認為 1G。

一個日誌段索引文件的大小,默認為 10M。

段滾動的最大隨機差。

Kafka 強制滾動一個段的間隔時間,及時該段並未全部填滿消息,默認值為 7d

是否允許不在 ISR 中副本在沒有 ISR 副本選擇之後競爭成為 Leader,這樣做有可能丟數據,默認為 false。

本文從運維命令開始學習,從使用運維層面全面了解 Topic,從而窺探其 Kafka 內部一些重要特性,為後續從源碼角度研究其實現打下堅實基礎。

本文的最後給出一個分區數量為 3,副本因子為 3 的 topic 分區圖來結束本文的講解。

㈥ 打ab包時如何打需要更新的內容

AB分配策略:
確定如何將項目的資產劃分為AssetBundles並不容易。關鍵決策是如何將對象分組到AssetBundles中。以下是unity手冊提供的主要策略是:

1. 邏輯實體分組(Logical Entity Grouping)
例子

捆綁用戶界面屏幕的所有紋理和布局數據
捆綁一個角色/一組角色的所有模型和動畫
捆綁跨多個級別共享的場景片段的紋理和模型
最常用的策略:按功能出現需要的資源,將需要的資源捆綁到一個ab里,這樣,載入該功能界面的時候,只要載入該ab就可以,如果功能比較復雜,可以視情況拆分粒度 邏輯實體分組是可下載內容(DLC)的理想選擇,因為通過這種方式將所有內容分開,您可以更改單個實體,而無需下載其他不變的資產。
使用前提:開發人員必須精確地了解項目將在何時何地使用每種資產。
2. 類型分組(Type Grouping)
預制
音頻
熱更腳本
類型分組是構建供多個平台使用的AssetBundle的較好策略之一。
3. 並發內容分組(Concurrent Content Grouping)
每個關卡都包含完全獨特的角色,紋理,音樂等
基於場景的包,每個場景束應包含大部分或所有場景依賴關系。
這些資產將同時載入和使用。
最後,無論您採用哪種策略,以下都是一些可以全面記住的其他提示:
將經常更新的對象與很少更改的對象分離
把需要同時載入的Asset盡量打包到同一個AB里。例如模型,其紋理和動畫。
如果一次經常載入少於50%的捆綁包,請考慮將其拆分
如果您發現多個AssetBundle中的多個對象都依賴於完全不同的AssetBundle中的單個資產,請將依賴關系移至單獨的AssetBundle。
根據依賴樹進行的最優打包策略,公共資源單獨打ab,獨立資源打到一起。
如果不太可能同時載入兩組對象(例如標准和高清資產),請確保它們位於自己的AssetBundle中。
考慮合並較小(少於5到10個資產)但經常同時載入其內容的AssetBundle
如果一組對象只是同一對象的不同版本,請考慮使用AssetBundle Variants
通常情況下,1M左右的AssetBundle包載入性能最好,冗餘也可以接受,但是在Unity 5.3版本之後,對於AB文件的文件大小其實不必再限定於1MB之內。使用LZ4壓縮,基於其Chunk的載入特點,AB載入很快,且內存佔用要比之前小很多。所以LZ4的AB其實可以考慮更加粗粒度一些。
shader字體等其他細碎並且需要常駐內存的資源打包到一起,啟動游戲的時候常駐內存。
根據項目實際需求將需要經常熱更新的資源進行單獨打包。
————————————————
版權聲明:本文為CSDN博主原創
原文鏈接:https://blog.csdn.net/qq_39329287/article/details/122109028

閱讀全文

與lz4壓縮演算法相關的資料

熱點內容
程序員用得到數字區嗎 瀏覽:170
python求商 瀏覽:473
ipad能用c語言編譯器嗎 瀏覽:557
軟泥解壓球最新版 瀏覽:994
4萬程序員辭職創業 瀏覽:755
thinkingphp 瀏覽:593
安卓相冊移動文件夾 瀏覽:2
耳朵清潔解壓聲控99的人都睡得著 瀏覽:201
叉車出租網站源碼 瀏覽:870
共享單車的app是什麼 瀏覽:404
不帶gui的伺服器什麼意思 瀏覽:369
金剛經及PDF 瀏覽:98
php中冒號 瀏覽:354
php5432 瀏覽:348
命令在哪使用 瀏覽:168
php獲取網頁元素 瀏覽:704
為什麼需要硬體驅動編譯 瀏覽:881
pm編程怎樣看導柱孔對不對稱 瀏覽:134
農業大學選課找不到伺服器怎麼辦 瀏覽:645
路由配置網關命令 瀏覽:931