本文介紹Lindorm在不同情境下與開源HBase、開源MySQL和開源MongoDB之間壓縮能力的對比結果。
背景資訊
Lindorm除多模超融合、開放相容和雲原生彈性等能力外，還具備了高效的資料壓縮能力。Lindorm不僅支援深度最佳化的ZSTD壓縮演算法，還在此基礎上對字典採樣進行了最佳化，進一步減少儲存成本。
本文測試壓縮能力所使用到的資料庫版本及其說明如下：
Lindorm：使用阿里雲發行的最新版本。預設使用深度最佳化的ZSTD壓縮演算法，支援開啟字典壓縮。
開源HBase：使用2.3.4版本。在有高版本Hadoop支撐的情況下支援ZSTD壓縮演算法，但不穩定且易發生進程崩潰現象（Core Dump）。絕大部分自建HBase使用者使用SNAPPY壓縮演算法。
開源MySQL：使用8.0版本。預設不開啟資料壓縮。MySQL雖然支援ZLIB壓縮演算法，但由於開啟資料壓縮後會對查詢效能產生嚴重影響，因此MySQL使用者基本不會開啟資料壓縮。
開源MongoDB：使用5.0版本。預設使用SNAPPY壓縮演算法，同時支援將SNAPPY演算法替換為ZSTD演算法。
本文選取了訂單、車連網、日誌和使用者行為這四個在Lindorm中常見的情境，使用真實的資料集分別測試了Lindorm預設壓縮、Lindorm開啟字典壓縮、HBase使用SNAPPY演算法壓縮、MySQL不開啟壓縮、MongoDB使用SNAPPY演算法壓縮和MongoDB使用ZSTD演算法壓縮這六種方式的壓縮能力。
各情境下的測試對比結果匯總及測試結論請參見測試對比結果。
訂單情境
資料準備
該情境使用TPC-H資料集進行壓縮測試。TPC-H是業界常用的一套基準程式，由TPC委員會制定發布，用於評測資料庫的分析型查詢能力。
本測試並未完全依照<TPC benchmark name>基準測試規範，而是基於該測試規範進行了修改。本測試結果不能等同於完全遵守<TPC benchmark name>測試規範所獲得的測試結果，因此不能與完全遵守該測試規範獲得的測試結果進行對比。
TPC-H程式下載
產生資料
# unzip TPC-H_Tools_v3.0.0.zip
# cd TPC-H_Tools_v3.0.0/dbgen
# cp makefile.suite makefile
# vim makefile
################產生Oracle資料庫的指令碼和資料，主要修改以下欄位
CC = gcc
DATABASE = ORACLE
MACHINE = LINUX
WORKLOAD = TPCH
################
# make --產生dbgen
# ./dbgen -s 10 --產生10GB資料執行完成後會在目前的目錄下產生8個.tbl格式的檔案，每一個檔案對應一張表。選擇ORDERS.tbl檔案進行壓縮測試，檔案大小為1.76 GB，共有資料1500萬行，對應表結構如下：
Field | Type |
O_ORDERKEY | INT |
O_CUSTKEY | INT |
O_ORDERSTATUS | CHAR(1) |
O_TOTALPRICE | DECIMAL(15,2) |
O_ORDERDATE | DATE |
O_ORDERPRIORITY | CHAR(15) |
O_CLERK | CHAR(15) |
O_SHIPPRIORITY | INT |
O_COMMENT | VARCHAR(79) |
建表
HBase
create 'ORDERS', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}MySQL
CREATE TABLE ORDERS ( O_ORDERKEY INTEGER NOT NULL,
O_CUSTKEY INTEGER NOT NULL,
O_ORDERSTATUS CHAR(1) NOT NULL,
O_TOTALPRICE DECIMAL(15,2) NOT NULL,
O_ORDERDATE DATE NOT NULL,
O_ORDERPRIORITY CHAR(15) NOT NULL,
O_CLERK CHAR(15) NOT NULL,
O_SHIPPRIORITY INTEGER NOT NULL,
O_COMMENT VARCHAR(79) NOT NULL);MongoDB
db.createCollection("ORDERS")Lindorm
# lindorm-cli
CREATE TABLE ORDERS ( O_ORDERKEY INTEGER NOT NULL,
O_CUSTKEY INTEGER NOT NULL,
O_ORDERSTATUS CHAR(1) NOT NULL,
O_TOTALPRICE DECIMAL(15,2) NOT NULL,
O_ORDERDATE DATE NOT NULL,
O_ORDERPRIORITY CHAR(15) NOT NULL,
O_CLERK CHAR(15) NOT NULL,
O_SHIPPRIORITY INTEGER NOT NULL,
O_COMMENT VARCHAR(79) NOT NULL,
primary key(O_ORDERKEY));壓縮效果對比
資料庫 | Lindorm （預設壓縮） | Lindorm （字典壓縮） | HBase （SNAPPY） | MySQL | MongoDB （預設SNAPPY） | MongoDB （ZSTD） |
表大小 | 784 MB | 639 MB | 1.23 GB | 2.10 GB | 1.63 GB | 1.32 GB |
車連網情境
該情境使用NGSIM資料集。NGSIM（Next Generation Simulation）是由美國聯邦公路局發起的一項資料擷取專案，廣泛應用於車輛的跟馳和換道等駕駛行為的研究、交通串流分析、微觀交通模型構建、車輛運動軌跡預測和自動駕駛決策規劃等。所有資料來源於美國高速公路國道101上的實際運行軌跡採集。
資料準備
搜尋並下載資料集檔案NGSIM_Data.csv。檔案大小1.54GB，共有資料1185萬行，每行25列。資料結構的詳細介紹及下載方式，請參見NGSIM資料集。
建表
HBase
create 'NGSIM', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}MySQL
CREATE TABLE NGSIM ( ID INTEGER NOT NULL,
Vehicle_ID INTEGER NOT NULL,
Frame_ID INTEGER NOT NULL,
Total_Frames INTEGER NOT NULL,
Global_Time BIGINT NOT NULL,
Local_X DECIMAL(10,3) NOT NULL,
Local_Y DECIMAL(10,3) NOT NULL,
Global_X DECIMAL(15,3) NOT NULL,
Global_Y DECIMAL(15,3) NOT NULL,
v_length DECIMAL(10,3) NOT NULL,
v_Width DECIMAL(10,3) NOT NULL,
v_Class INTEGER NOT NULL,
v_Vel DECIMAL(10,3) NOT NULL,
v_Acc DECIMAL(10,3) NOT NULL,
Lane_ID INTEGER NOT NULL,
O_Zone CHAR(10),
D_Zone CHAR(10),
Int_ID CHAR(10),
Section_ID CHAR(10),
Direction CHAR(10),
Movement CHAR(10),
Preceding INTEGER NOT NULL,
Following INTEGER NOT NULL,
Space_Headway DECIMAL(10,3) NOT NULL,
Time_Headway DECIMAL(10,3) NOT NULL,
Location CHAR(10) NOT NULL,
PRIMARY KEY(ID));MongoDB
db.createCollection("NGSIM")Lindorm
# lindorm-cli
CREATE TABLE NGSIM ( ID INTEGER NOT NULL,
Vehicle_ID INTEGER NOT NULL,
Frame_ID INTEGER NOT NULL,
Total_Frames INTEGER NOT NULL,
Global_Time BIGINT NOT NULL,
Local_X DECIMAL(10,3) NOT NULL,
Local_Y DECIMAL(10,3) NOT NULL,
Global_X DECIMAL(15,3) NOT NULL,
Global_Y DECIMAL(15,3) NOT NULL,
v_length DECIMAL(10,3) NOT NULL,
v_Width DECIMAL(10,3) NOT NULL,
v_Class INTEGER NOT NULL,
v_Vel DECIMAL(10,3) NOT NULL,
v_Acc DECIMAL(10,3) NOT NULL,
Lane_ID INTEGER NOT NULL,
O_Zone CHAR(10),
D_Zone CHAR(10),
Int_ID CHAR(10),
Section_ID CHAR(10),
Direction CHAR(10),
Movement CHAR(10),
Preceding INTEGER NOT NULL,
Following INTEGER NOT NULL,
Space_Headway DECIMAL(10,3) NOT NULL,
Time_Headway DECIMAL(10,3) NOT NULL,
Location CHAR(10) NOT NULL,
PRIMARY KEY(ID)) ;壓縮效果對比
資料庫 | Lindorm （預設壓縮） | Lindorm （開啟字典壓縮） | HBase （SNAPPY） | MySQL | MongoDB （預設SNAPPY） | MongoDB （ZSTD） |
表大小 | 995 MB | 818 MB | 1.72 GB | 2.51 GB | 1.88 GB | 1.50 GB |
日誌情境
使用Web伺服器訪問日誌資料集：Zaker, Farzin, 2019, "Online Shopping Store - Web Server Logs", https://doi.org/10.7910/DVN/3QBYB5, Harvard Dataverse, V1。
資料準備
在日誌資料集網頁下載記錄檔access.log。檔案大小為3.51GB，共有資料1036萬行，日誌資料格式樣本如下：
54.36.149.41 - - [22/Jan/2019:03:56:14 +0330] "GET /filter/27|13%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,27|%DA%A9%D9%85%D8%AA%D8%B1%20%D8%A7%D8%B2%205%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,p53 HTTP/1.1" 200 30577 "-" "Mozilla/5.0 (compatible; AhrefsBot/6.1; +http://ahrefs.com/robot/)" "-"建表
HBase
create 'ACCESS_LOG', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}MySQL
CREATE TABLE ACCESS_LOG ( ID INTEGER NOT NULL,
CONTENT VARCHAR(10000),
PRIMARY KEY(ID));MongoDB
db.createCollection("ACCESS_LOG")Lindorm
# lindorm-cli
CREATE TABLE ACCESS_LOG ( ID INTEGER NOT NULL,
CONTENT VARCHAR(10000),
PRIMARY KEY(ID));壓縮效果對比
資料庫 | Lindorm （預設壓縮） | Lindorm （字典壓縮） | HBase （SNAPPY） | MySQL | MongoDB （SNAPPY） | MongoDB （ZSTD） |
表大小 | 646 MB | 387 MB | 737 MB | 3.99 GB | 1.17 GB | 893 MB |
使用者行為
該情境使用來自阿里雲天池的資料集：Shop Info and User Behavior data from IJCAI-15。
資料準備
在使用者行為資料集網頁下載data_format1.zip，並選用user_log_format1.csv檔案，檔案大小為1.91 GB，共有資料5492萬行。檔案結構樣本如下：
user_id | item_id | cat_id | seller_id | brand_id | time_stamp | action_type |
328862 | 323294 | 833 | 2882 | 2661 | 829 | 0 |
328862 | 844400 | 1271 | 2882 | 2661 | 829 | 0 |
328862 | 575153 | 1271 | 2882 | 2661 | 829 | 0 |
建表
HBase
create 'USER_LOG', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}MySQL
CREATE TABLE USER_LOG ( ID INTEGER NOT NULL,
USER_ID INTEGER NOT NULL,
ITEM_ID INTEGER NOT NULL,
CAT_ID INTEGER NOT NULL,
SELLER_ID INTEGER NOT NULL,
BRAND_ID INTEGER,
TIME_STAMP CHAR(4) NOT NULL,
ACTION_TYPE CHAR(1) NOT NULL,
PRIMARY KEY(ID));MongoDB
db.createCollection("USER_LOG")Lindorm
# lindorm-cli
CREATE TABLE USER_LOG ( ID INTEGER NOT NULL,
USER_ID INTEGER NOT NULL,
ITEM_ID INTEGER NOT NULL,
CAT_ID INTEGER NOT NULL,
SELLER_ID INTEGER NOT NULL,
BRAND_ID INTEGER,
TIME_STAMP CHAR(4) NOT NULL,
ACTION_TYPE CHAR(1) NOT NULL,
PRIMARY KEY(ID));壓縮效果對比
資料庫 | Lindorm （預設壓縮） | Lindorm （字典壓縮） | HBase （SNAPPY） | MySQL | MongoDB （SNAPPY） | MongoDB （ZSTD） |
表大小 | 805 MB | 721 MB | 1.48 GB | 2.90 GB | 3.33 GB | 2.74 GB |
總結
通過上述對比可以得知，在不同的情境下，面對類型不同且資料量較大的資料，即使不開啟字典壓縮，Lindorm的壓縮比相較於其他開來源資料庫也有明顯的優勢。在開啟了字典壓縮之後，Lindorm的壓縮效果更加突出，壓縮效果幾乎是開源HBase的1~2倍，開源MongoDB的2~4倍，開源MySQL的3~10倍。
各情境下的測試對比結果匯總如下：
資料 | 檔案大小 | Lindorm （預設壓縮） | Lindorm （字典壓縮） | HBase （SNAPPY） | MySQL | MongoDB （SNAPPY） | MongoDB （ZSTD） |
訂單資料 （TPC-H） | 1.76 GB | 784 MB | 639 MB | 1.23 GB | 2.10 GB | 1.63 GB | 1.32 GB |
車連網資料（NGSIM） | 1.54 GB | 995 MB | 818 MB | 1.72 GB | 2.51 GB | 1.88 GB | 1.50 GB |
日誌資料 （server log） | 3.51 GB | 646 MB | 387 MB | 737 MB | 3.99 GB | 1.17 GB | 893 MB |
使用者行為資料（IJCAI-15） | 1.91 GB | 805 MB | 721 MB | 1.48 GB | 2.90 GB | 3.33 GB | 2.74 GB |