2024年8款数据库数据分析能力（TPC-H）机能评测真有100倍差距_数据_数据库

文章目录 [+]

测试方法

TPC-H：国际数据库标准测试组织TPC推出的面向决策支持系统的数据库方法，紧张用于数据剖析场景性能评测，TPC-H统共须要运行22条数据剖析型SQL。
本次测试属于TPC-H自由测试，仅测试查询SQL，没有实行更新和事务。

数据集：TPC-H v3.0.1测试数据集，200GB（非报告标准size）。

2024年8款数据库数据分析能力（TPC-H）机能评测真有100倍差距_数据_数据库 2024年8款数据库数据分析能力（TPC-H）机能评测真有100倍差距_数据_数据库科学

计时方法：统计每条SQL实行韶光，全部累加。
设置SQL最长实行韶光为300秒(5分钟)，如果实行出错或者超时，则本条SQL韶光按600秒打算。

（图片来自网络侵删）

测试硬件

为了公正起见，本次TPC-H测试利用了完备相同的硬件，所有产品都是单机支配，重点是测试各个产品的单机处理能力。

1台阿里云ECSi4r.4xlarge处理器：16核2.7 GHz主频的Intel (®) Xeon (®) 可扩展处理器（Ice Lake ），内存：128GB硬盘：1块本地Nvme SSD，空间894GB操作系统：CentOS7.9

测试结论

排名

数据库

运行韶光

单位：秒

总结

Doris

v2.1.2

97.97

整体表现非常精良，轻松完成所有任务

Starrocks

v3.2.6

106.57

整体表现非常精良，轻松完成所有任务

DuckDB

v0.10.2

119.11

整体表现非常精良，轻松完成所有任务，作为一个后起新秀，嵌入式的OLAP数据库，表现非常出色

Oracle

19c

1245.74

完成所有任务，性能中等，表现很稳定，不会涌现内存不敷的征象。

ClickHouse

2024.04

2370.76

完成20个任务，数据导入非常快，单表查询表现出了精良的性能力，两表Join以上性能急剧下滑，繁芜查询随意马虎涌现内存不敷而运行出错

PostgreSQL

v15.7

3527.1

完成19个任务，普遍性能不高，算法细节实现和Oracle还有差距，可以运用于大略的HTAP场景

达梦V8

202404

8851.57

完成11个查询SQL，整体性能不高，HASH JOIN内存掌握还有待提升，随意马虎涌现内存不敷导致SQL实行出错

MySQL

v8.0.32

12641.84

22个任务仅完成1个，完备不适宜数据剖析

接下来详细描述TPC-H测试方法和8种数据库的测试成绩TPC-H数据模型简介

TPC-H紧张仿照供应商和采购商之间的订单交易，模型统共8张表

region：区域表，固定5条记录nation：国家表，固定25条记录supplier：供应商表，数据量因子10000条记录customer：客户表，数据量因子150000条记录part：商品表，数据量因子200000条记录partsupp：供应商物件表：数据量因子800000条记录orders：订单表，数据量因子1500000条记录lineitem：订单明细表，数据量因子6000000条记录（最大的表，占总数据率70%）

TPC-H测试的数据量大小可以任意指定，本次测试采取了200GB的规模，最大的lineitem表数据量约12亿条(2006000000)。

模型建表

以下是MySQL语法参考，其他数据库可以根据语法修正

create database tpch;use tpch;CREATE TABLE `customer` ( `c_custkey` int(11) NOT NULL, `c_name` varchar(25) NOT NULL, `c_address` varchar(40) NOT NULL, `c_nationkey` int(11) NOT NULL, `c_phone` varchar(15) NOT NULL, `c_acctbal` decimal(15,2) NOT NULL, `c_mktsegment` varchar(10) NOT NULL, `c_comment` varchar(117) NOT NULL, PRIMARY KEY (`c_custkey`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;CREATE TABLE `lineitem` ( `l_orderkey` bigint(20) NOT NULL, `l_partkey` int(11) NOT NULL, `l_suppkey` int(11) NOT NULL, `l_linenumber` bigint(20) NOT NULL, `l_quantity` decimal(15,2) NOT NULL, `l_extendedprice` decimal(15,2) NOT NULL, `l_discount` decimal(15,2) NOT NULL, `l_tax` decimal(15,2) NOT NULL, `l_returnflag` varchar(1) NOT NULL, `l_linestatus` varchar(1) NOT NULL, `l_shipdate` date NOT NULL, `l_commitdate` date NOT NULL, `l_receiptdate` date NOT NULL, `l_shipinstruct` varchar(25) NOT NULL, `l_shipmode` varchar(10) NOT NULL, `l_comment` varchar(44) NOT NULL, PRIMARY KEY (`l_orderkey`,`l_linenumber`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;CREATE TABLE `orders` ( `o_orderkey` bigint(20) NOT NULL, `o_custkey` int(11) NOT NULL, `o_orderstatus` varchar(1) NOT NULL, `o_totalprice` decimal(15,2) NOT NULL, `o_orderdate` date NOT NULL, `o_orderpriority` varchar(15) NOT NULL, `o_clerk` varchar(15) NOT NULL, `o_shippriority` bigint(20) NOT NULL, `o_comment` varchar(79) NOT NULL, PRIMARY KEY (`O_ORDERKEY`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;CREATE TABLE `part` ( `p_partkey` int(11) NOT NULL, `p_name` varchar(55) NOT NULL, `p_mfgr` varchar(25) NOT NULL, `p_brand` varchar(10) NOT NULL, `p_type` varchar(25) NOT NULL, `p_size` int(11) NOT NULL, `p_container` varchar(10) NOT NULL, `p_retailprice` decimal(15,2) NOT NULL, `p_comment` varchar(23) NOT NULL, PRIMARY KEY (`p_partkey`)) ENGINE=InnoDB DEFAULT CHARSET=latin1 ;CREATE TABLE `partsupp` ( `ps_partkey` int(11) NOT NULL, `ps_suppkey` int(11) NOT NULL, `ps_availqty` int(11) NOT NULL, `ps_supplycost` decimal(15,2) NOT NULL, `ps_comment` varchar(199) NOT NULL, KEY `IDX_PARTSUPP_SUPPKEY` (`PS_SUPPKEY`), PRIMARY KEY (`ps_partkey`,`ps_suppkey`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;CREATE TABLE `supplier` ( `s_suppkey` int(11) NOT NULL, `s_name` varchar(25) NOT NULL, `s_address` varchar(40) NOT NULL, `s_nationkey` int(11) NOT NULL, `s_phone` varchar(15) NOT NULL, `s_acctbal` decimal(15,2) NOT NULL, `s_comment` varchar(101) NOT NULL, PRIMARY KEY (`s_suppkey`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;CREATE TABLE `nation` ( `n_nationkey` int(11) NOT NULL, `n_name` varchar(25) NOT NULL, `n_regionkey` int(11) NOT NULL, `n_comment` varchar(152) DEFAULT NULL, PRIMARY KEY (`n_nationkey`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;CREATE TABLE `region` ( `r_regionkey` int(11) NOT NULL, `r_name` varchar(25) NOT NULL, `r_comment` varchar(152) DEFAULT NULL, PRIMARY KEY (`r_regionkey`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;TPC-H 评测SQL简介

TPC-H标准共有22条查询SQL，紧张磨练数据库的如下数据剖析能力：

多表Join子查询分组汇总（Group By，SUM）过滤打算（like模糊查询,Case when等）视图关联查询

以TPC-H第21号SQL举例，一条SQL包括了多表关联、子查询、Group by、Order By几种数据剖析中常见的运算：

#TPC-H 21号SQLselect s_name, count() as numwaitfrom supplier, lineitem l1, orders, nationwhere s_suppkey = l1.l_suppkey and o_orderkey = l1.l_orderkey and o_orderstatus = 'F' and l1.l_receiptdate > l1.l_commitdate and exists ( select from lineitem l2 where l2.l_orderkey = l1.l_orderkey and l2.l_suppkey <> l1.l_suppkey ) and not exists ( select from lineitem l3 where l3.l_orderkey = l1.l_orderkey and l3.l_suppkey <> l1.l_suppkey and l3.l_receiptdate > l3.l_commitdate ) and s_nationkey = n_nationkey and n_name = 'RUSSIA'group by s_nameorder by numwait desc, s_name;

tpc-h完全的22条sql可以参考dbgen工具包内容，不同的数据库须要根据语法特性微调。

测试数据天生

TPC-H官方供应了测试数据集构建标准程序，下载地址，下载后可以直接编译运行

https://www.tpc.org/TPC_Documents_Current_Versions/download_programs/tools-download-request5.asp?bm_type=TPC-H&bm_vers=3.0.1&mode=CURRENT-ONLY

cd dbgen#从模版中创建编译须要用的makefilecp makefile.suit makefile

配置makefile内容

CC=gcc，DATABASE=ORACLE,MACHINE=LINUX,WORKLOAD=TPCH，详细参考如下：

## CHANGE NAME OF ANSI COMPILER HERE################CC = gcc# Current values for DATABASE are: INFORMIX, DB2, TDAT (Teradata)# SQLSERVER, SYBASE, ORACLE, VECTORWISE# Current values for MACHINE are: ATT, DOS, HP, IBM, ICL, MVS, # SGI, SUN, U2200, VMS, LINUX, WIN32 # Current values for WORKLOAD are: TPCHDATABASE=ORACLE MACHINE = LINUX WORKLOAD = TPCH

# 实行编译，天生dbgen可以实行文件make

接下来可以用dbgen天生测试数据集，dbgen有非常多的参数，可以根据须要灵巧利用，如果是100GB以内的小数据量，可以直接单线程一键天生

# -s后面跟上数据集大小，单位是GB./dbgen -s 100

dbgen实行完成后，在目录下会产生以下数据文件，都是csv格式，字段间分隔符是"|"

customer.tblnation.tblregion.tblsupplier.tblpart.tblpartsupp.tbllineitem.tblorders.tbl

如果超过100GB的数据量，建议几个大表并行天生数据，尤其是订单和明细表 orders,lineitem这个两个大表，如下：-T 表示单独天生某个表的数据，-C表示操持分割为几个文件，-S表示当前天生第几份数据，通过分割文件可以并行天生数据，提升效率，后面导入到数据库也可以直接并行加速。

./dbgen -s 200 -T o -C 10 -S 1 &./dbgen -s 200 -T o -C 10 -S 2 &./dbgen -s 200 -T o -C 10 -S 3 &./dbgen -s 200 -T o -C 10 -S 4 &./dbgen -s 200 -T o -C 10 -S 5 &./dbgen -s 200 -T o -C 10 -S 6 &./dbgen -s 200 -T o -C 10 -S 7 &./dbgen -s 200 -T o -C 10 -S 8 &./dbgen -s 200 -T o -C 10 -S 9 &./dbgen -s 200 -T o -C 10 -S 10 &以下是各种数据库的测试明细MySQLv8.0.32

导入数据

# 为了优化导入性能，可以做以下优化，都是危险操作，千万不要在生产数据库操作。

1. 关闭Binlog2. 关闭REDO_LOG3. 关闭Double Write

利用mysql的load data指令导入数据

load data local infile '/data/tpch3/dbgen/customer.tbl' into table customer fields terminated by '|';load data local infile '/data/tpch3/dbgen/lineitem.tbl' into table lineitem fields terminated by '|';load data local infile '/data/tpch3/dbgen/nation.tbl' into table nation fields terminated by '|';load data local infile '/data/tpch3/dbgen/orders.tbl' into table orders fields terminated by '|';load data local infile '/data/tpch3/dbgen/partsupp.tbl' into table partsupp fields terminated by '|';load data local infile '/data/tpch3/dbgen/part.tbl' into table part fields terminated by '|';load data local infile '/data/tpch3/dbgen/region.tbl' into table region fields terminated by '|';load data local infile '/data/tpch3/dbgen/supplier.tbl' into table supplier fields terminated by '|';实行TPC-H SQL（操作省略）

确实是小试牛刀，MySQL根本不适宜TPC-H，纵然设置了并行查询，但是只有在比较大略的单表SQL查询中可以，加上group by或者join后基本都只能是单线程操作，MySQL末了只完成了Q2，其他21条SQL都查询超时

查询语句

实行韶光

超时

41.84

超时

...

Q22

超时

总结：这个成绩真惨不忍睹，如果你要把MySQL用于查询剖析，那基本是去世翘翘。

PostgreSQL v15.7

功能最强大的开源关系型数据库PostgreSQL，看看是否能完成任务。

PostgreSQL可以采取copy导入csv文件，语法如下：

COPY customer FROM '/data/tpch3/dbgen/customer.tbl' delimiter '|' ;

须要把稳的是TPC-H dbgen天生的csv格式末了多了一个"|"，PostgreSQL COPY无法直接导入，可以在TPCH所有表增加一个临时的字段，或者用shell脚本批量把末了的"|"去除，类似下面的脚本

for i in `ls .tbl`; do sed 's/|$//' $i > ${i/tbl/csv}; done

#大表设置并行alter table LINEITEM set (parallel_workers=16);alter table ORDERS set (parallel_workers=16);alter table PARTSUPP set (parallel_workers=16);alter table PART set (parallel_workers=16);#关闭表autovacuumALTER TABLE LINEITEM SET (autovacuum_enabled = off);ALTER TABLE ORDERS SET (autovacuum_enabled = off);ALTER TABLE PARTSUPP SET (autovacuum_enabled = off);ALTER TABLE PART SET (autovacuum_enabled = off);ALTER TABLE CUSTOMER SET (autovacuum_enabled = off);ALTER TABLE SUPPLIER SET (autovacuum_enabled = off);

实行结果

查询

实行韶光

149.26

29.07

90.03

72.53

102.01

55.74

77.44

87.11

超时

Q10

98.25

Q11

19.69

Q12

71.94

Q13

63.79

Q14

64.32

Q15

272.28

Q16

125.39

Q17

94.37

Q18

超时

Q19

51.14

Q20

超时

Q21

195.04

Q22

7.72

总结：22条SQL，PostgreSQL实行成功19条，有3条SQL实行超时，比MySQL好了很多，对付一些HTAP场景，可以知足基本需求，超时的3条SQL都是有3张以上表的Join，PostgreSQL在并行查询性能方面算法还有待提升。

Oracle19c

老牌商业数据库，本次测试的是普通Oracle19c，没有利用Exadata，因此只利用行存模式。

#软件从官方下载https://www.oracle.com/database/technologies/oracle-database-software-downloads.html#安装手册https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/running-rpm-packages-to-install-oracle-database.html

#设置表不记录log，可以加速导入alter table lineitem NOLOGGING;alter table partsupp NOLOGGING;alter table orders NOLOGGING;alter table part NOLOGGING;

导入csv数据可以利用Oracle自带的sqlldr工具

sqlldr userid=test/test@ORCLPDB1 control=load_tpch_customer.ctl rows=1000000 bindsize=20971520 direct=true

load_tpch_customer.ctl文件示例

#设置大表开启并行查询alter table LINEITEM parallel(degree 16);alter table PART parallel(degree 4);alter table CUSTOMER parallel(degree 4);alter table ORDERS parallel(degree 4);alter table PARTSUPP parallel(degree 4);#网络表统计信息，数据导入完毕后实行EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=> 'TEST',tabname=> 'LINEITEM',estimate_percent=>0.1,block_sample=> TRUE, method_opt=> 'FOR ALL COLUMNS SIZE AUTO');EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=> 'TEST',tabname=> 'PART',estimate_percent=>1,block_sample=> TRUE, method_opt=> 'FOR ALL COLUMNS SIZE AUTO');EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=> 'TEST',tabname=> 'SUPPLIER',estimate_percent=>1,block_sample=> TRUE, method_opt=> 'FOR ALL COLUMNS SIZE AUTO');EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=> 'TEST',tabname=> 'PARTSUPP',estimate_percent=>1,block_sample=> TRUE, method_opt=> 'FOR ALL COLUMNS SIZE AUTO');EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=> 'TEST',tabname=> 'CUSTOMER',estimate_percent=>1,block_sample=> TRUE, method_opt=> 'FOR ALL COLUMNS SIZE AUTO');EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=> 'TEST',tabname=> 'ORDERS',estimate_percent=>1,block_sample=> TRUE, method_opt=> 'FOR ALL COLUMNS SIZE AUTO');EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=> 'TEST',tabname=> 'NATION',estimate_percent=>1,block_sample=> TRUE, method_opt=> 'FOR ALL COLUMNS SIZE AUTO');EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=> 'TEST',tabname=> 'REGION',estimate_percent=>1,block_sample=> TRUE, method_opt=> 'FOR ALL COLUMNS SIZE AUTO');

实行结果

查询

实行韶光

59.67

13.64

77.75

64.06

65.95

57.43

66.98

67.43

82.34

Q10

141.63

Q11

9.97

Q12

63.82

Q13

41.26

Q14

16.67

Q15

59.17

Q16

18.37

Q17

29.33

Q18

74.68

Q19

71.02

Q20

31.64

Q21

127.94

Q22

4.99

总结：Oracle19c完成了所有任务，性能中等，Join表现很稳定，不会涌现内存不敷的征象。
由于Oracle列存压缩仅在Exadata支持，本次利用的是行存模式，并不能展现出Oracle的最强能力。
Oracle在大表扫描方面利用并行全表查询，硬盘性能大约3GB/s，因此须要全表访问大表lineitem（140GB）的任务，基本都是50秒以上。

达梦8 v20240408

达梦是老牌国产数据库，超过20年历史，以Oracle兼容性著称

达梦8安装安装比较方便，可以在官网直接下（https://www.dameng.com），根据安装文档一步一步安装即可

可以自带的dmfldr工具导入csv数据，语法和Oracle的sqlldr类似

./dmfldr userid=TEST/Dameng_123:5236 control=\'load_tpch_customer.ctl\' direct=true

#load_tpch_customer.ctl 文件示例

#设置并行SP_SET_PARA_VALUE (1,'MAX_PARALLEL_DEGREE',16);

实行结果

查询

实行韶光

326.49

65.59

95.43

290.35

内存不敷

285.07

内存不敷

Q10

内存不敷

Q11

20.92

Q12

292.27

Q13

超时

Q14

273.94

Q15

270.57

Q16

28.65

Q17

内存不敷

Q18

超时

Q19

超时

Q20

超时

Q21

超时

Q22

28.78

总结：22条SQL，达梦实行成功11条，其余11条SQL实行超时或出错，超时或出差的11条SQL都是有3张以上表的Join，达梦在Hash Join的内存管理方面欠佳，纵然设置了内存大小，但还是很随意马虎报全局内存不敷。

ClickHousev2024.04

ClickHouse是非常盛行的开源列式数据仓库，由俄罗斯Yandex公司研发，目前是ClickHouse公司在推动发展。
ClickHouse以惊人的单表查询能力著称，很好的填补了大数据平台OLAP交互式剖析能力。

由于ClickHouse并不能实行标准TPC-H的SQL语法，以是须要在查询语法上做一些修正，详细参考如下文章

https://www.cnblogs.com/syw20170419/p/16421131.html

ClickHouse数据导入非常大略，可以直策应用Insert into table from infile语法，如下所示

SET format_csv_delimiter = '|'；INSERT INTO customer from infile '/data/tpch3/dbgen/customer.tbl' FORMAT CSV;

实行结果：

查询

实行韶光

0.415

7.632

45.953

175.988

110.021

3.691

112.006

172.344

内存不敷

Q10

44.416

Q11

4.62

Q12

6.768

Q13

48.432

Q14

6.037

Q15

2.86

Q16

5.08

Q17

28.806

Q18

215.036

Q19

118.199

Q20

48.293

Q21

内存不敷

Q22

14.16

总结：ClickHouse数据导入非常快，单线程可以到达300MB/s，统共完成20个任务，2个任务失落败，单表查询表现出了精良的性能力，两表Join以上性能急剧下滑，繁芜查询随意马虎涌现内存不敷而运行出错。
ClickHouse有浩瀚的利用者，碰着普通问题在网上都可以找到办理方案。

Doris 2.1.2

Apache Doris 是一款基于 MPP 架构的高性能、实时的剖析型数据库。

Apache Doris 最早是出身于百度广告报表业务的 Palo 项目，2017 年正式对外开源，2018 年 7 月由百度捐赠给 Apache 基金会进行孵化，之后在 Apache 导师的辅导下由孵化器项目管理委员会成员进行孵化和运营。
2022 年 6 月，Apache Doris 成功从 Apache 孵化器毕业，正式成为 Apache 顶级项目（Top-Level Project，TLP）。
目前 Apache Doris 社区已经聚拢了来自不同行业数百家企业的 600 余位贡献者，并且每月生动贡献者人数也超过 120 位。

Doris 采取 MySQL 协议，高度兼容 MySQL 语法，整体上是FE（前端节点）+BE（后端打算与数据存储节点）的MPP架构，如下图所示。

doris可以利用stream load的模式导入csv数据，性能可以达到200MB/s

curl --location-trusted -u admin:admin -T /data/tpch3/dbgen/customer.tbl -H "column_separator:|" -H "columns: c_custkey, c_name, c_address, c_nationkey, c_phone, c_acctbal, c_mktsegment, c_comment, temp" http://127.0.0.1:8030/api/tpch200/customer/_stream_load#如果导入的csv文件很大，可以先设置最大导入的文件大小curl -X POST http://127.0.0.1:8030/api/update_config?streaming_load_max_mb=10240

实行结果：

查询

实行韶光

13.22

0.761

3.731

3.308

6.293

0.415

2.212

3.793

11.499

Q10

6.835

Q11

0.709

Q12

0.944

Q13

8.835

Q14

0.527

Q15

0.803

Q16

1.435

Q17

1.929

Q18

15.366

Q19

3.095

Q20

2.428

Q21

8.755

Q22

1.079

总结：Doris数据导入非常快，并且轻松完成了所有任务，本次测试内存128GB，Doris导入列式压缩后实际空间大约60GB，因此大部分要求都是在内存中可以打算完成，如果数据量更大，Doris可能会发生内存不敷的征象。

Starrocks

Starrocks与Doris在早期是同一个内核引擎，也是FE+BE的架构，现在已经是独立开源产品演进。
Starrocks最新版本支持存储打算完备分离的架构，可以把数据存储在S3、HDFS、MinIO等共享工具存储上，通过增加无数据的CN节点完成打算扩展，如下图所示。

本次测试采取单机FE+BE架构支配

starrocks操作与doris基本同等，可以利用stream load的模式导入csv数据，性能可以达到200MB/s

实行结果：

查询

实行韶光

10.42

0.44

6.02

4.66

7.99

0.35

4.58

4.71

12.76

Q10

7.94

Q11

0.73

Q12

1.21

Q13

10.09

Q14

0.84

Q15

0.95

Q16

1.79

Q17

2.51

Q18

12.03

Q19

3.29

Q20

1.26

Q21

10.93

Q22

1.07

总结：Starrocks数据导入非常快，并且轻松完成了所有任务。

DuckDB（0.10.2）

DuckDB是2019年荷兰人发布的一个高性能的嵌入式开源剖析性数据，它的定位类似面向OLAP的SQLite，非常轻巧，不须要安装，可以嵌入到多种措辞中。
比如在java中，只须要引入duckdb的jar包，就可以在代码里创建一个本地文件存储的duckdb数据仓库。
DuckDB性能非常出色，本次测试中表现非常亮眼，一个仅15MB的小型嵌入式数据库达到了大型MPP系统的性能。

duckdb在tpc-h和tpc-ds方面都附加的插件，可以直策应用，非常方便

https://duckdb.org/docs/extensions/tpch

#安装tpch插件INSTALL tpch;#加载插件LOAD tpch;#天生200GB数据CALL dbgen(sf = 200);#运行详细的TPC-H任务PRAGMA tpch(1);PRAGMA tpch(2);...PRAGMA tpch(22);

利用默认的tpc-h天生数据比较慢，也可以利用COPY语法导入利用TPC-H官方工具天生的数据，不须要知道分隔符，duckdb默认会自动识别CSV的格式，非常方便。

COPY customer FROM '/data/tpch3/dbgen/customer.tbl';

实行结果：

查询

实行韶光

5.209

1.417

3.369

3.051

3.492

1.006

15.31

3.995

8.681

Q10

5.756

Q11

1.074

Q12

2.548

Q13

11.28

Q14

2.139

Q15

3.372

Q16

1.496

Q17

3.339

Q18

21.53

Q19

5.679

Q20

2.808

Q21

10.56

Q22

2.003

总结：整体表现非常精良，轻松完成了所有任务，作为一个后起新秀，嵌入式的OLAP数据库，表现非常出色，如果数据库可以在单机内管理，duckdb是非常有竞争力的产品。

总结

从测试结果看：

Starrocks、Doris、DuckDB是目前OLAP引擎中第一梯队，可以轻松处理TPC-H的任务。
ClickHouse是非常盛行的开源数据仓库，在单表查询方面比较强，但是多表关联打算能力随意马虎较弱，并且随意马虎发生内存不敷征象。
MySQL、PostgreSQL、达梦数据库紧张还是面向OLTP场景，在本次TPC-H测试中表现欠佳。
Oracle作为老牌数据库，测试中表现非常稳定，数据量在增加也不会涌现内存不敷的征象，但是由于行式存储引擎的毛病，在性能上与列式存储引擎有巨大的差距，更适宜繁芜的HTAP场景。

为了公正起见，本次TPC-H测试利用了完备相同的硬件，所有产品都是单机支配，重点是测试各个产品的单机处理能力，没有测试Starrocks、Doris、ClickHouse这些MPP产品的分布式处理能力。
操持在未来的事情中连续完善。

关于作者

叶正盛，NineData 创始人 &CEO，资深数据库专家，原阿里云数据库产品管理与办理方案部总经理。
NineData（www.ninedata.cloud）是云原生数据管理平台，供应数据库 DevOps（SQL IDE、SQL 审核与发布、性能优化、数据安全管控）、数据复制（迁移、同步、ETL）、备份等功能，可以帮助用户更安全、高效利用数据。

原文链接：https://mp.weixin.qq.com/s/s4QLlNVY87ue39e_ACQjOQ