10倍压缩比？Lindorm与其他数据库实测大比拼

科技 08-31 来源：阿里云数据库

引言

Lindorm是一款阿里云推出的云原生超融合多模数据库。Lindorm在阿里内部已经使用长达10年之久，是阿里集团内部数据体量最大，覆盖业务最广的数据库产品之一。目前Lindorm在阿里云上也成为了众多大数据用户的选择。用户选择Lindorm，除了它丰富的多模处理能力，超强的性能之外，一个重要的点就是Lindorm对数据的压缩比非常高，能够给用户带来非常大的存储成本节省。

空说无凭，面对不同用户的不同场景，Lindorm究竟能做到多少压缩比？相对于其他开源数据库，Lindorm能有多好的表现？本文特地选取了订单、车联网、日志和用户行为这四个在Lindorm上常见的场景，使用真实的数据集对各个数据库的压缩表现进行了评测。

其中，Lindorm使用了阿里云发行最新版本，Lindorm默认使用的压缩算法是深度优化的ZSTD，并且Lindorm在ZSTD上做了字典采样优化，本文分别测试了Lindorm默认压缩和开启了字典压缩后的效果。

MySQL使用了8.0版本，MySQL虽然支持zlib压缩，但使用MySQL的用户基本不会开启压缩，因为开启压缩会对性能产生严重影响，因此我们测试的是常见的MySQL默认不开启压缩的情况

HBase使用了2.3.4版本，虽然HBase后续版本支持了ZSTD，但需要高版本Hadoop支持，同时开源集成的ZSTD并不稳定，非常容易core dump。根据我们的了解，绝大部分自建HBase用户都是使用SNAPPY压缩方法，因此本文使用HBase的SNAPPY压缩进行对比。

MongoDB使用了5.0版本，MongoDB默认使用的是SNAPPY压缩，同时MongoDB支持将压缩算法改成ZSTD，因此我们测试了MongoDB在两种压缩算法下的表现。

本文使用测试数据均来自开源数据集，大家也可以拿同样的数据集和相关语句对结果进行复现。

1.订单场景

1.1 数据准备

使用基准测试程序TPC-H，TPC-H是业界常用的一套Benchmark，由TPC委员会制定发布，用于评测数据库的分析型查询能力。

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.76GB，共有数据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)

1.2 建表

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

Hbase

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

1.3 压缩效果对比

数据库

Lindorm

（默认压缩）

Lindorm

(开启字典压缩)

HBase

MySQL

MongoDB

(默认snappy)

MongoDB

（zstd）

表大小

784 MB

639 MB

1.23 GB

2.10 GB

1.63 GB

1.32 GB

2 车联网场景

使用NGSIM数据集，NGSIM 的全称为 Next Generation Simulation，是由美国联邦公路局发起的一项数据采集项目，被交通界学者广泛用于车辆跟驰换道等驾驶行为研究，交通流分析，微观交通模型构建，车辆运动轨迹预测，驾驶员意图识别，自动驾驶决策规划等。所有数据均为在美国高速公路国道101上采集的实际运行轨迹数据。

2.1 数据准备

下载文件Next_Generation_Simulation__NGSIM__Vehicle_Trajectories_and_Supporting_Data.csv，文件大小1.54GB，共有数据1185万行，每行25列。数据结构详情请见NGSIM数据集

2.2 建表

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

Hbase

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

2.3 压缩效果对比

数据库

Lindorm(默认压缩)

Lindorm

(开启字典压缩)

HBase

MySQL

MongoDB

(默认snappy)

MongoDB

（zstd）

表大小

995 MB

818 MB

1.72 GB

2.51 GB

1.88 GB

1.50 GB

3 日志场景

使用Web服务器访问日志数据集：Zaker, Farzin, 2019, "Online Shopping Store - Web Server Logs", https://doi.org/10.7910/DVN/3QBYB5, Harvard Dataverse, V1

3.1 数据准备

在日志数据集网页上点击下载日志文件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/)" "-"

3.2 建表

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

Hbase

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

3.3 压缩效果对比

数据库

Lindorm

(开启字典压缩)

HBase

MySQL

MongoDB

(默认snappy)

MongoDB

（zstd）

表大小

646 MB

387 MB

737 MB

3.99 GB

1.17 GB

893 MB

4 用户行为

使用来自阿里云天池的数据集：Shop Info and User Behavior data from IJCAI-15

4.1 数据准备

在用户行为数据集网页上点击下载data_format1.zip，选用里面的user_log_format1.csv，文件大小1.91 GB，共有数据5492万行。文件结构示例如下：

4.2 建表

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

Hbase

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

4.3 压缩效果对比

数据库

Lindorm

(开启字典压缩)

HBase

MySQL

MongoDB

(默认snappy)

MongoDB

(zstd)

表大小

805 MB

721 MB

1.48 GB

2.90 GB

3.33 GB

2.74 GB

5 总结

通过对比我们可以看到，无论是存储订单、车辆轨迹数据、日志数据还是用户行为数据，即使不开启字典压缩，相对于其他开源数据库，Lindorm的压缩比有明显优势。在开启字典压缩之后，Lindorm的压缩效果更是效果拔群，基本上是开源HBase的1到2倍，MongoDB的2到4倍，MySQL的3到10倍！由此可见，在使用Lindorm后，单单通过压缩优化，从存储成本来讲，就能节省数倍投入，同时Lindorm还具备数据冷热分离、纠删码、异构混合副本等多种降本技术。因此，Lindorm“存得起，看得见”的理念，并不是仅停留在纸面，而是在实际场景中，确实能给大家带来极致的低成本体验。

云原生多模数据库Lindorm_多模数据库_工业物联网_数据库-阿里云