本文介紹云原生多模數據庫 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 |