压缩测试

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

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

压缩效果对比

image..png

数据库

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

压缩效果对比

image

数据库

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

压缩效果对比

image..png

数据库

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

压缩效果对比

image..png

数据库

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