压缩测试

本文介绍云原生多模数据库 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程序下载

下载文件TPC-H_Tools_v3.0.0.zip。

生成数据

# 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

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

MySQL

MongoDB

Lindorm

create 'ORDERS', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}

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);

db.createCollection("ORDERS")

# 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));

压缩效果对比

image..png

数据库	Lindorm （默认压缩）	Lindorm （字典压缩）	HBase （SNAPPY）	MySQL	MongoDB （默认SNAPPY）	MongoDB （ZSTD）

数据库

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

MySQL

MongoDB

Lindorm

create 'NGSIM', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}

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));

db.createCollection("NGSIM")

# 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）

数据库

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

MySQL

MongoDB

Lindorm

create 'ACCESS_LOG', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}

CREATE TABLE ACCESS_LOG  ( ID        INTEGER NOT NULL,
                           CONTENT   VARCHAR(10000),
                           PRIMARY KEY(ID));

db.createCollection("ACCESS_LOG")

# lindorm-cli
CREATE TABLE ACCESS_LOG  ( ID        INTEGER NOT NULL,
                           CONTENT   VARCHAR(10000),
                           PRIMARY KEY(ID));

压缩效果对比

image..png

数据库	Lindorm （默认压缩）	Lindorm （字典压缩）	HBase （SNAPPY）	MySQL	MongoDB （SNAPPY）	MongoDB （ZSTD）

数据库

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

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

MySQL

MongoDB

Lindorm

create 'USER_LOG', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}

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));

db.createCollection("USER_LOG")

# 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));

压缩效果对比

image..png

数据库	Lindorm （默认压缩）	Lindorm （字典压缩）	HBase （SNAPPY）	MySQL	MongoDB （SNAPPY）	MongoDB （ZSTD）

数据库

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）

数据	文件大小	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

背景信息

订单场景

数据准备

建表

压缩效果对比

车联网场景

数据准备

建表

压缩效果对比

日志场景

数据准备

建表

压缩效果对比

用户行为

数据准备

建表

压缩效果对比

总结

销售支持

客户支持

聆听 & 举报违规

关于阿里云

阿里云全球基础设施

快速入门

全球办事处

2024年巴黎奥运会 New

罗兰加洛斯球场 - 岁月沉淀的辉煌 New

协和广场 - “打破”障碍 New

马恩河畔韦尔水上运动体育场 - 可持续的体育运动 New

国际广播中心 - 优质图像、声音和数据触达数十亿观众 New

客户成功案例 New

阿里云信任中心

合规计划

云合规资源

合规常见问题

云产品快报 New

Cloud Forward

新闻报道

阿里云电子期刊 New

阿里云调研分析报告

公告

阿里云出海业务 New

“橙”云出海服务联盟

China Gateway Hot

信息合规

China Gateway - MLPS 2.0 合规 New

China Gateway - 网络

China Gateway - 全球应用加速 New

China Gateway - 安全

China Gateway - 数据安全 New

ICP支持服务 Hot

China Gateway - 全域数据中台 New

China Gateway - 一方数据中台 New

China Gateway - 业务中台 New

China Gateway - 智能客服解决方案 New

China Gateway - 在线教育

China Gateway - 域名注册

在阿里云工作

经验丰富的专业人士

学生和毕业生

免费试用

定价

优惠中心

降价

花钱更少，部署更多

FinOps

云服务器 ECS

轻量应用服务器 SAS

GPU 云服务器

无影云电脑 EDS

对象存储 OSS

云企业网 CEN

Web 应用防火墙 WAF

域名

容器计算服务 ACS

办公安全平台 SASE

智能媒体服务 IMS

边缘安全加速 ESA（原DCDN）

智能媒体管理 IMM

专属钉钉

宜搭

大模型服务平台（百炼）

Apsara Prime - 轻松选择云产品

阿里云 ECS-满足您所有云主机需求

1TB CDN — 立即获取免费的 1 TB 出站流量套餐

安全 — 受到攻击？ 获取免费安全支持

短信服务 - 现已免费开放测试

云服务器 ECS Hot

云盒

计算巢服务

专有宿主机 Hot

弹性裸金属服务器（神龙）

无影云电脑 EDS Featured

GPU 云服务器 Featured

轻量应用服务器 SAS Hot

弹性伸缩

无影云手机 Beta

无影云电脑 EDS Featured

批量计算

弹性高性能计算 E-HPC

超级计算集群 SCC

安全 — 受到攻击？获取免费安全支持