引言Lindorm是一款阿里云推出的云原生超融合多模数据库。Lindorm在阿里内部已经使用长达10年之久,是阿里集团内部数据体量最大,覆盖业务最广的数据库产品之一。目前Lindorm在阿里云上也成为了众多大数据用户的选择。本文特地选取了订单、车联网、日志和用户行为这四个在Lindorm上常见的场景,使用真实的数据集对各个数据库的压缩表现进行了评测。所有数据均为在美国高速公路国道101上采集的实际运行轨迹数据。

引言
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 = gccDATABASE = ORACLEMACHINE = LINUXWORKLOAD = 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) |
MySQL
CREATE TABLE ORDERS( O_ORDERKEYINTEGER NOT NULL,O_CUSTKEYINTEGER NOT NULL,O_ORDERSTATUSCHAR(1) NOT NULL,O_TOTALPRICEDECIMAL(15,2) NOT NULL,O_ORDERDATEDATE NOT NULL,O_ORDERPRIORITYCHAR(15) NOT NULL,O_CLERKCHAR(15) NOT NULL,O_SHIPPRIORITYINTEGER NOT NULL,O_COMMENTVARCHAR(79) NOT NULL);
MongoDB
db.createCollection("ORDERS")
Lindorm
# lindorm-cliCREATE TABLE ORDERS( O_ORDERKEYINTEGER NOT NULL,O_CUSTKEYINTEGER NOT NULL,O_ORDERSTATUSCHAR(1) NOT NULL,O_TOTALPRICEDECIMAL(15,2) NOT NULL,O_ORDERDATEDATE NOT NULL,O_ORDERPRIORITYCHAR(15) NOT NULL,O_CLERKCHAR(15) NOT NULL,O_SHIPPRIORITYINTEGER NOT NULL,O_COMMENTVARCHAR(79) NOT NULL,primary key(O_ORDERKEY));
Hbase
create 'ORDERS', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}
数据库 | 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-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}
数据库 | 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:140330] "GET /filter/27|13 مگاپیکسل,27|کمتر از 5 مگاپیکسل,p53 HTTP/1.1" 200 30577 "-" "Mozilla/5.0 (compatible; AhrefsBot/6.1;http://ahrefs.com/robot/)" "-"
MySQL
CREATE TABLE ACCESS_LOG( IDINTEGER NOT NULL,CONTENTVARCHAR(10000),PRIMARY KEY(ID));
MongoDB
db.createCollection("ACCESS_LOG")
Lindorm
# lindorm-cliCREATE TABLE ACCESS_LOG( IDINTEGER NOT NULL,CONTENTVARCHAR(10000),PRIMARY KEY(ID));
Hbase
create 'ACCESS_LOG', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}
数据库 | Lindorm | 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( IDINTEGER NOT NULL,USER_IDINTEGER NOT NULL,ITEM_IDINTEGER NOT NULL,CAT_IDINTEGER NOT NULL,SELLER_IDINTEGER NOT NULL,BRAND_IDINTEGER,TIME_STAMPCHAR(4) NOT NULL,ACTION_TYPECHAR(1) NOT NULL,PRIMARY KEY(ID));
MongoDB
db.createCollection("USER_LOG")
Lindorm
# lindorm-cliCREATE TABLE USER_LOG( IDINTEGER NOT NULL,USER_IDINTEGER NOT NULL,ITEM_IDINTEGER NOT NULL,CAT_IDINTEGER NOT NULL,SELLER_IDINTEGER NOT NULL,BRAND_IDINTEGER,TIME_STAMPCHAR(4) NOT NULL,ACTION_TYPECHAR(1) NOT NULL,PRIMARY KEY(ID));
Hbase
create 'USER_LOG', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}
数据库 | Lindorm | 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_多模数据库_工业物联网_数据库-阿里云
