引言
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委员会制定发布，用于评测数据库的分析型查询能力。
# unzip TPC-H_Tools_v3.0.0.zip# cd TPC-H_Tools_v3.0.0/dbgen# cp makefile.suite makefile# vim makefile################生成ORACLE数据库的脚本和数据，主要修改以下字段CC = gccDATABASE = ORACLEMACHINE = LINUXWORKLOAD = TPCH################# make --生成dbgen# ./dbgen -s 10 --生成10GB数据
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 建表
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-cliCREATE 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（开启字典压缩） | 639 MB |
HBase | 1.23 GB |
MySQL | 2.10 GB |
MongoDB（默认snappy） | 1.63 GB |
MongoDB（zstd） | 1.32 GB |
2.车联网场景
2.1 数据准备
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-cliCREATE 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（开启字典压缩） | 818 MB |
HBase | 1.72 GB |
MySQL | 2.51 GB |
MongoDB（默认snappy） | 1.88 GB |
MongoDB（zstd） | 1.50 GB |
3.日志场景
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-cliCREATE 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（开启字典压缩） | 387 MB |
HBase | 737 MB |
MySQL | 3.99 GB |
MongoDB（默认snappy） | 1.17 GB |
MongoDB（zstd） | 893 MB |
4.用户行为
4.1 数据准备
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-cliCREATE 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 压缩效果对比
| 805 MB | |
Lindorm（开启字典压缩） | 721 MB |
HBase | 1.48 GB |
MySQL | 2.90 GB |
MongoDB（默认snappy） | 3.33 GB |
MongoDB（zstd） | 2.74 GB |
5.汇总
➤向右滑动查看完整数据
通过对比我们可以看到，无论是存储订单、车辆轨迹数据、日志数据还是用户行为数据，即使不开启字典压缩，相对于其他开源数据库，Lindorm的压缩比有明显优势。在开启字典压缩之后，Lindorm的压缩效果更是效果拔群，基本上是开源HBase的1到2倍，MongoDB的2到4倍，MySQL的3到10倍！由此可见，在使用Lindorm后，单单通过压缩优化，从存储成本来讲，就能节省数倍投入，同时Lindorm还具备数据冷热分离、纠删码、异构混合副本等多种降本技术。因此，Lindorm“存得起，看得见”的理念，并不是仅停留在纸面，而是在实际场景中，确实能给大家带来极致的低成本体验。
点击"阅读原文" 查看Lindorm更多信息