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

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
云数据库 Tair(兼容Redis),内存型 2GB
简介: 让数据存储得起,我们不是说说而已。

引言

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

6.png

空说无凭,面对不同用户的不同场景,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委员会制定发布,用于评测数据库的分析型查询能力。

tpch下载

下载文件 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-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(默认压缩) 784 MB

Lindorm(开启字典压缩)

639 MB

HBase

1.23 GB

MySQL

2.10 GB

MongoDB(默认snappy)

1.63 GB

MongoDB(zstd)

1.32 GB

1.png

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}

2.3 压缩效果对比

数据库
表大小
Lindorm(默认压缩) 995 MB

Lindorm(开启字典压缩)

818 MB

HBase

1.72 GB

MySQL

2.51 GB

MongoDB(默认snappy)

1.88 GB

MongoDB(zstd)

1.50 GB

2.png

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-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 646 MB

Lindorm(开启字典压缩)

387 MB

HBase

737 MB 

MySQL

3.99 GB

MongoDB(默认snappy)

1.17 GB

MongoDB(zstd)

893 MB

3.png

4.用户行为

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

4.1 数据准备

在用户行为数据集网页上点击下载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

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 压缩效果对比

数据库
表大小
Lindorm 805 MB

Lindorm(开启字典压缩)

721 MB

HBase

1.48 GB

MySQL

2.90 GB

MongoDB(默认snappy)

3.33 GB

MongoDB(zstd)

2.74 GB

4.png

5.汇总

5.JPG

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


相关文章
|
存储 人工智能 Cloud Native
阿里云瑶池数据库训练营权益:《玩转Lindorm》学习资料开放下载!
阿里云瑶池数据库训练营权益:《玩转Lindorm》学习资料开放下载!
|
5月前
|
存储 SQL 运维
当「内容科技企业」遇上多模数据库:新榜采用Lindorm打造全域数据“超级底盘”
新榜业务以数据服务提升内容产业信息流通效率,其数据处理需求聚焦于跨平台实时数据融合处理、实时分析检索、批量更新效率三大维度。Lindorm通过多模超融合架构,提供检索分析一体化、多引擎数据共享,分布式弹性扩展等能力,成为支撑新榜内容服务的核心引擎,助力客户在内容生态竞争中持续领跑。
|
8月前
|
存储 人工智能 固态存储
软硬联合创新:打造极致压缩比的高性能瑶池数据库
本文介绍了阿里云瑶池数据库的软硬联合创新,旨在打造极致压缩比和高性能的数据库系统。内容涵盖五个方面:1) AMD EPC赋能阿里云数据库,提升计算性能;2) AMD EPYC全面支持阿里云数据库及AI应用;3) 小盈科技分享Polar DB的最佳实践,解决业务发展中的挑战;4) 基于阿里云新硬件完成存储规模拓展和性能演进,实现大规模数据处理;5) 阿里云资源存储部件的应用历史与演进,展示自研硬件的进步。通过这些创新,瑶池数据库实现了延迟降低30%、存储成本降低40%,并提供更高的安全性和灵活性。
127 5
|
8月前
|
传感器 安全 物联网
时序数据库TDengine + MQTT :车联网时序数据库如何高效接入
现代新能源汽车配备大量传感器,产生海量数据需上报至车联网平台。TDengine作为时序大数据平台,支持MQTT协议,可轻松实现车辆状态、位置及用户行为数据的实时采集与分析,提升驾驶体验和安全保障。通过简单的Web界面配置,无需编写代码,即可完成从MQTT到TDengine的数据接入。整个过程包括注册TDengine Cloud、创建数据库、安装代理插件、新增数据源、配置解析规则等步骤,快速实现数据同步。
279 2
|
9月前
|
存储 安全 数据管理
时序数据库TDengine 与中移软件达成兼容性互认证,推动虚拟化云平台与时序数据库的深度融合
在数字化转型和智能化升级的浪潮下,企业对数据的需求日益增长,尤其是在物联网、大数据和实时分析等领域。随着设备数量的激增,时序数据的管理和处理变得愈发复杂,企业亟需高效、稳定的数据解决方案来应对这一挑战。时序数据库作为专门处理时间序列数据的工具,正逐渐成为各行业数字化转型的重要支撑。
183 4
|
存储 SQL 多模数据库
多模数据库Lindorm再升级:对接Dataphin,打通数据治理“最后一公里”
Lindorm通过与Dataphin的深度整合,进一步解决了数据集成和数据治理的问题,为企业提供更加高效和更具性价比的方案。
多模数据库Lindorm再升级:对接Dataphin,打通数据治理“最后一公里”
|
存储 传感器 数据挖掘
请解释一下时序数据库的工作原理,并提供一个使用时序数据库的实际应用场景。
请解释一下时序数据库的工作原理,并提供一个使用时序数据库的实际应用场景。
514 0
|
存储 监控 物联网
从实时数据库转战时序数据库,他陪伴 TDengine 从 1.0 走到 3.0
他与 TDengine 的六年故事,始于一个“无奈之举”。
315 1
|
存储 SQL 机器学习/深度学习
VLDB论文解读|一文剖析阿里云Lindorm数据库在DB for AI领域的探索
论文主要针对大规模监控场景下海量时序数据的存储、访问、分析和管理带来的挑战,描述了阿里云多模数据库 Lindorm 带来的一站式解决方案。
|
人工智能 自然语言处理 多模数据库
视野数科联合阿里云Lindorm多模数据库推动AIGC应用在金融领域落地
野数科与阿里云Lindorm多模数据库达成AIGC应用联合创新合作

相关产品

  • 云原生多模数据库 Lindorm