使用facebook linkbench 测试PostgreSQL社交关系图谱场景性能

本文涉及的产品
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介:

facebook linkbench 测试PostgreSQL社交关系图谱场景性能

作者

digoal

日期

2016-09-11

标签

PostgreSQL , facebook , linkbench


背景

Linkbench是facebook提供的一款数据库性能测试开源软件,它的思路是围绕社交关系图谱构建一套测试数据,然后在此基础之上对数据进行关系查询,新增关系,断开关系等操作。

Linkbench的介绍可参考
https://www.facebook.com/notes/facebook-engineering/linkbench-a-database-benchmark-for-the-social-graph/10151391496443920

http://www.oschina.net/translate/linkbench-a-database-benchmark-for-the-social-graph

linkbench的测试模型在用户社交关系领域,很具有代表性,所以我打算提供一份该测试模型下PostgreSQL数据库性能表现的测试数据,以及测试方法。

用户再看完测试数据后,可以与其他数据库对比测试一下,看看性能差异。

linkbench测试模型介绍

社交图谱(social graph),其中的对象如人(people),文章(posts),评论(comments)和页面(pages)是通过节点间不同的关系类型(模型)相互关联(图中的有向边-directed edges)的。

不同的关联关系类型可以表示好友关系(friendship between two users),用户喜欢某个对象的关系(user like another object),还可以表示文章属主(ownership of post)关系等等。

pic1

LinkBench是一个用于生成图(graph-serving)的性能测试工具,而不是处理图(graph-processing)的测试工具--区别在于前者会模拟在一个交互式的社交应用中的那些具有事务性的动作(transactional workload),而后者只是模拟动作的流程(analytics workload)。

这个测试工具不是用于解决图的社区发现问题(find graph communities)或图的切分问题(graph partitioning),而是用来实时地查询并更新数据库中的图谱。

例如,对于图的查询比较常见的形式就是找到所有来自节点X并且是A类型的所有的边,而更新操作就是插入、删除边或者更新图中的节点或边。

举个更新操作的例子,如“从user4插入一个好友关系的边到user63459821”。

通过将数据库查询划分为针对关系(边)和对象(节点)的许多小的核心操作,我们就可以逐个地分析在生产数据库环境下对社交图谱的每个操作的性能了。

下面的表列出了用于保存或查询图谱时所对应的查询或更新操作。

pic2

对于边的操作和读操作,特别是边界扫描(edge range scan)会给系统带来极大的负担。

举个边界扫描的例子,如“按最早到最近的时间顺序找出某个文章的所有评论”或“找出某个用户的所有好友”。

优化提示

这个问题在于数据的存放,如果某文章的评论已聚合,则扫描的块会很少,性能不会差。用户的好友查询也一样,如果用户的好友进行了聚合,则也不会出现以上性能问题。

或者通过cluster进行聚集,也能减少行扫描。

linkbench for PostgreSQL的工具介绍

性能测试工作是由LinkBench driver负责的,它是一个用于生成社交图谱和各种操作的Java程序。

原来只支持MySQL,已经扩展为支持PostgreSQL,但是务必使用PostgreSQL 9.5以及以上版本,因为QUERY包含UPSET(insert on conflict),这个功能是9.5新加的。
https://github.com/mdcallag/linkbench

安装linkbench软件

mkdir ~/app  
cd ~/app  

JDK

cd ~  
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html  
get     
Java SE Development Kit 8u102  
Linux x64   173.03 MB   jdk-8u102-linux-x64.tar.gz  

tar -zxvf jdk-8u102-linux-x64.tar.gz  
mv jdk1.8.0_102 /home/digoal/app/  

apache-maven

http://maven.apache.org/download.cgi  

wget http://mirrors.cnnic.cn/apache/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz  
tar -zxvf apache-maven-3.3.9-bin.tar.gz  
mv apache-maven-3.3.9 /home/digoal/app/  

配置环境

export JAVA_HOME=/home/digoal/app/jdk1.8.0_102  
export PATH=/home/digoal/app/apache-maven-3.3.9/bin:/home/digoal/app/jdk1.8.0_102/bin:$PATH  
export LD_LIBRARY_PATH=/home/digoal/app/apache-maven-3.3.9/lib:$LD_LIBRARY_PATH  

安装linkbench

git clone https://github.com/mdcallag/linkbench  

打包linkbench

$ cd linkbench  

$ mvn clean package -P pgsql -D skipTests  

[INFO] ------------------------------------------------------------------------  
[INFO] BUILD SUCCESS  
[INFO] ------------------------------------------------------------------------  
[INFO] Total time: 5.146 s  
[INFO] Finished at: 2016-09-11T13:07:55+08:00  
[INFO] Final Memory: 39M/1582M  
[INFO] ------------------------------------------------------------------------  

生成环境变量配置文件
$ vi ~/.bash_profile

# append  
export JAVA_HOME=/home/digoal/app/jdk1.8.0_102  
export PATH=/home/digoal/app/linkbench/bin:/home/digoal/app/apache-maven-3.3.9/bin:/home/digoal/app/jdk1.8.0_102/bin:$PATH  
export LD_LIBRARY_PATH=/home/digoal/app/apache-maven-3.3.9/lib:$LD_LIBRARY_PATH  
export CLASSPATH=.:/home/digoal/app/linkbench/target/FacebookLinkBench.jar  

$ linkbench

Using java at: /home/digoal/app/jdk1.8.0_102/bin/java  
Did not select benchmark mode  
usage: linkbench [-c <file>] [-csvstats <file>] [-csvstream <file>] [-D  
       <property=value>] [-L <file>] [-l] [-r]  
 -c <file>                       Linkbench config file  
 -csvstats,--csvstats <file>     CSV stats output  
 -csvstream,--csvstream <file>   CSV streaming stats output  
 -D <property=value>             Override a config setting  
 -L <file>                       Log to this file  
 -l                              Execute loading stage of benchmark  
 -r                              Execute request stage of benchmark  

测试工作分为两个阶段:

1. 载入阶段(load phase),会生成一个初始的图谱并载入(loaded in bulk)到数据库中;

2. 请求阶段(request phase),许多请求线程会用各种操作对数据库进行并发访问。在请求阶段,各种操作的延迟和吞吐量都会被统计并给出报告。

在两个阶段的具体行为是通过一个配置文件进行控制的,通过这个配置文件可以轻松地控制性能测试中的各个参数。

配置文件模板为 config/LinkConfigPgsql.properties

pic3

PostgreSQL 部署

本文不包括OS的参数优化部分。

$ wget https://ftp.postgresql.org/pub/source/v9.6rc1/postgresql-9.6rc1.tar.bz2      
$ tar -jxvf postgresql-9.6rc1.tar.bz2      
$ cd postgresql-9.6rc1      
$ ./configure --prefix=/home/postgres/pgsql9.6rc1 --enable-debug       
$ gmake world -j 32      
$ gmake install-world      

环境变量配置


$ vi ~/env_pg.sh      
# add by digoal      
export PS1="$USER@`/bin/hostname -s`-> "      
export PGPORT=1921      
export PGDATA=/data01/pgdata/pg_root_96      
export LANG=en_US.utf8      
export PGHOME=/home/postgres/pgsql9.6rc1      
export LD_LIBRARY_PATH=$PGHOME/lib:/lib64:/usr/lib64:/usr/local/lib64:/lib:/usr/lib:/usr/local/lib:$LD_LIBRARY_PATH      
export DATE=`date +"%Y%m%d%H%M"`      
export PATH=$PGHOME/bin:$PATH:.      
export MANPATH=$PGHOME/share/man:$MANPATH      
export PGHOST=$PGDATA      
export PGDATABASE=postgres      
alias rm='rm -i'      
alias ll='ls -lh'      
unalias vi      
$ . ~/env_pg.sh     

创建测试库

1) 初始化数据库
initdb -D $PGDATA -E UTF8 --locale=C -U postgres

2) 创建数据库

    $> psql   
    DROP DATABASE IF EXISTS linkdb;  
    CREATE DATABASE linkdb ENCODING='latin1' template template0;  

    --drop user linkbench to create new one  
    DROP USER  IF EXISTS linkdb;  

    --  You may want to set up a special database user account for benchmarking:  
    CREATE USER linkdb password 'password';  
    -- Grant all privileges on linkdb to this user  
    GRANT ALL ON database linkdb TO linkdb;  

3) Connect to linkdb and create tables and index

    $> \c linkdb linkdb  

    --add Schema keep the same query style (dbid.table_name)  
    DROP SCHEMA IF EXISTS linkdb CASCADE;   
    CREATE SCHEMA linkdb;  

    -- FIXME:Need to make it partitioned by key id1 %16  
    -- 建议使用分区表,也可以直接使用单表  
    -- 如果使用分区表,需要给子表id1加约束 check(mod(id1,16)=0), .....
    -- 同时还需要修改并重新编译src/main/java/com/facebook/LinkBench/LinkStorePgsql.java  
    -- 在原有id1=...的基础上加上约束相同的查询条件,例如where id1=val and mod(id1,16) = mod(val,16) ... 
    -- 这样pg的优化器才能过滤id1=val的条件
    CREATE TABLE linkdb.linktable (  
            id1 numeric(20) NOT NULL DEFAULT '0',  
            id2 numeric(20) NOT NULL DEFAULT '0',  
            link_type numeric(20) NOT NULL DEFAULT '0',  
            visibility smallint NOT NULL DEFAULT '0',  
            data varchar(255) NOT NULL DEFAULT '',  
            time numeric(20) NOT NULL DEFAULT '0',  
            version bigint NOT NULL DEFAULT '0',  
            PRIMARY KEY (link_type, id1,id2)  
            );  

    -- this is index for linktable  
    CREATE INDEX id1_type on linkdb.linktable(  
            id1,link_type,visibility,time,id2,version,data);  

    CREATE TABLE linkdb.counttable (  
            id numeric(20) NOT NULL DEFAULT '0',  
            link_type numeric(20) NOT NULL DEFAULT '0',  
            count int NOT NULL DEFAULT '0',  
            time numeric(20) NOT NULL DEFAULT '0',  
            version numeric(20) NOT NULL DEFAULT '0',  
            PRIMARY KEY (id,link_type)  
            );  

    CREATE TABLE linkdb.nodetable (  
            id BIGSERIAL NOT NULL,  
            type int NOT NULL,  
            version numeric NOT NULL,  
            time int NOT NULL,  
            data text NOT NULL,  
            PRIMARY KEY(id)  
            );  

配置装载模板

注意linkbench的配置文件,每个配置的value末尾不要有空格,否则可能解析错误。

配置导入多少测试数据

$ vi ~/app/linkbench/config/FBWorkload.properties

# end node id for initial load (exclusive)  
# With default config and MySQL/InnoDB, 1M ids ~= 1GB  
maxid1 = 1000000001  
# 配置为10亿条node记录,约1TB  

如何连接数据库,报告频率,线程数,每个线程测多少笔操作,最大测试时长 压测

$ vi ~/app/linkbench/config/LinkConfigPgsql.properties

workload_file = config/FBWorkload.properties  
linkstore = com.facebook.LinkBench.LinkStorePgsql  
nodestore = com.facebook.LinkBench.LinkStorePgsql  
# 数据库连接信息  
host = xxx.xxx.xxx.xxx  
user = linkdb  
password = linkdb  
port = 1922  
dbid = linkdb  
# 数据库表  
linktable = linktable  
counttable = counttable  
nodetable = nodetable  
# 信息输出等级  
debuglevel = INFO  
# 打印频率  
progressfreq = 300  
displayfreq = 1800  
# 允许每个线程装载、请求多少条记录  
load_progress_interval = 500000  
req_progress_interval = 500000  
maxsamples = 10000  
# 加载几个线程  
loaders = 64  
generate_nodes = true  
loader_chunk_size = 2048  
# 开多少个请求,乘以2得到连接数    
requesters = 192  
# 每个线程请求多少次  
requests = 5000000  
requestrate = 0  
maxtime = 100000  
warmup_time = 0  
max_failed_requests = 100  

装载测试数据

$ cd ~/app/linkbench  

$ ./bin/linkbench -c config/LinkConfigPgsql.properties -l  

配置测试模板

同上《配置装载模板》

压测

./bin/linkbench -c config/LinkConfigPgsql.properties -r  

测试结果解读

数据装载结果

INFO 2016-09-12 01:19:07,229 [main]: LOAD_NODE_BULK count = 390625  p25 = [8000,9000]ms  p50 = [8000,9000]ms  p75 = [9000,10000]ms  p95 = [10000,100000]ms  p99 = [10000,100000]ms  max = 1259341.029ms  mean = 9759.494ms
INFO 2016-09-12 01:19:07,229 [main]: LOAD_LINKS_BULK count = 1708831  p25 = [10000,100000]ms  p50 = [10000,100000]ms  p75 = [10000,100000]ms  p95 = [10000,100000]ms  p99 = [10000,100000]ms  max = 1292335.24ms  mean = 33558.09ms
INFO 2016-09-12 01:19:07,229 [main]: LOAD_COUNTS_BULK count = 301615  p25 = [10000,100000]ms  p50 = [10000,100000]ms  p75 = [10000,100000]ms  p95 = [10000,100000]ms  p99 = [10000,100000]ms  max = 1318474.297ms  mean = 66637.2ms
INFO 2016-09-12 01:19:07,229 [main]: LOAD PHASE COMPLETED.  Loaded 100000000 nodes (Expected 100000000). Loaded 437452202 links (4.37 links per node).  Took 4060.6 seconds.  Links/second = 107731 

数据压测结果

单向指标的QUERY性能

INFO 2016-09-11 21:49:47,069 [main]: 
ADD_NODE 
count = 2471774  
p25 = [0.4,0.5]ms  百分之25的请求小于0.5毫秒
p50 = [0.5,0.6]ms  百分之50的请求小于0.6毫秒
p75 = [0.6,0.7]ms  百分之75的请求小于0.7毫秒
p95 = [1,2]ms  百分之95的请求小于2毫秒
p99 = [4,5]ms  百分之99的请求小于5毫秒
max = 213.324ms  最大RT
mean = 0.715ms   平均RT

p25表示 0-25%的请求RT范围为a,b毫秒, p50表示25-50%的请求RT范围a,b毫秒.

总体测试统计,包括QPS

INFO 2016-09-11 21:49:47,070 [main]: 
REQUEST PHASE COMPLETED. 
96000000 requests done in 796 seconds. 
Requests/second = 120482 

一个32Core机型的测试结果

INFO 2016-09-11 21:49:47,069 [main]: ADD_NODE count = 2471774  p25 = [0.4,0.5]ms  p50 = [0.5,0.6]ms  p75 = [0.6,0.7]ms  p95 = [1,2]ms  p99 = [4,5]ms  max = 213.324ms  mean = 0.715ms  
INFO 2016-09-11 21:49:47,069 [main]: UPDATE_NODE count = 7073914  p25 = [0.4,0.5]ms  p50 = [0.5,0.6]ms  p75 = [0.7,0.8]ms  p95 = [2,3]ms  p99 = [5,6]ms  max = 154.589ms  mean = 0.813ms  
INFO 2016-09-11 21:49:47,069 [main]: DELETE_NODE count = 971421  p25 = [0.3,0.4]ms  p50 = [0.4,0.5]ms  p75 = [0.6,0.7]ms  p95 = [2,3]ms  p99 = [4,5]ms  max = 80.185ms  mean = 0.731ms  
INFO 2016-09-11 21:49:47,070 [main]: GET_NODE count = 12414612  p25 = [0.4,0.5]ms  p50 = [0.6,0.7]ms  p75 = [0.9,1]ms  p95 = [2,3]ms  p99 = [5,6]ms  max = 78.739ms  mean = 0.943ms  
INFO 2016-09-11 21:49:47,070 [main]: ADD_LINK count = 8631075  p25 = [1,2]ms  p50 = [2,3]ms  p75 = [3,4]ms  p95 = [5,6]ms  p99 = [9,10]ms  max = 103.442ms  mean = 2.657ms  
INFO 2016-09-11 21:49:47,070 [main]: DELETE_LINK count = 2870975  p25 = [1,2]ms  p50 = [2,3]ms  p75 = [3,4]ms  p95 = [6,7]ms  p99 = [14,15]ms  max = 134.991ms  mean = 3.197ms  
INFO 2016-09-11 21:49:47,070 [main]: UPDATE_LINK count = 7694028  p25 = [1,2]ms  p50 = [2,3]ms  p75 = [3,4]ms  p95 = [5,6]ms  p99 = [9,10]ms  max = 91.146ms  mean = 2.654ms  
INFO 2016-09-11 21:49:47,070 [main]: COUNT_LINK count = 4690047  p25 = [0.4,0.5]ms  p50 = [0.6,0.7]ms  p75 = [1,2]ms  p95 = [2,3]ms  p99 = [5,6]ms  max = 79.349ms  mean = 1.026ms  
INFO 2016-09-11 21:49:47,070 [main]: MULTIGET_LINK count = 504147  p25 = [0.7,0.8]ms  p50 = [0.9,1]ms  p75 = [1,2]ms  p95 = [3,4]ms  p99 = [6,7]ms  max = 59.272ms  mean = 1.325ms  
INFO 2016-09-11 21:49:47,070 [main]: GET_LINKS_LIST count = 48678007  p25 = [0.7,0.8]ms  p50 = [0.9,1]ms  p75 = [1,2]ms  p95 = [3,4]ms  p99 = [6,7]ms  max = 117.932ms  mean = 1.386ms  
INFO 2016-09-11 21:49:47,070 [main]: REQUEST PHASE COMPLETED. 96000000 requests done in 796 seconds. Requests/second = 120482  

每一项代表了一个测试用例,具体参考前面的图,最后一行表示综合性能。

这里测试的PG linkbench性能达到了12万QPS。

主机32 Core。

参考

https://github.com/mdcallag/linkbench

https://www.facebook.com/notes/facebook-engineering/linkbench-a-database-benchmark-for-the-social-graph/10151391496443920

http://www.oschina.net/translate/linkbench-a-database-benchmark-for-the-social-graph

Count

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
4月前
|
安全 关系型数据库 MySQL
MySQL数据库高效秘籍:10个小技巧,让你轻松应对各种场景!
【8月更文挑战第25天】本文介绍了十个提升MySQL数据库效率与安全性的实用技巧。涵盖查询性能分析、索引优化、慢查询日志利用、图形化工具如MySQL Workbench的应用、性能分析工具、主从复制实现、备份与恢复策略、数据库迁移方法及安全性保障等多个方面。通过具体的示例代码展示每个技巧的实际操作方式,帮助读者深入理解并有效运用MySQL数据库。
192 0
|
2月前
|
存储 关系型数据库 MySQL
MySQL在企业内部应用场景有哪些
【10月更文挑战第17天】MySQL在企业内部应用场景有哪些
52 0
|
2月前
|
存储 关系型数据库 MySQL
介绍一下MySQL的一些应用场景
【10月更文挑战第17天】介绍一下MySQL的一些应用场景
201 0
|
4月前
|
缓存 关系型数据库 数据库
PostgreSQL性能
【8月更文挑战第26天】PostgreSQL性能
72 1
|
3月前
|
存储 SQL 关系型数据库
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
MySQL如何进行分库分表、数据迁移?从相关概念、使用场景、拆分方式、分表字段选择、数据一致性校验等角度阐述MySQL数据库的分库分表方案。
456 15
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
|
3月前
|
缓存 关系型数据库 数据库
如何优化 PostgreSQL 数据库性能?
如何优化 PostgreSQL 数据库性能?
130 2
|
2月前
|
容灾 Cloud Native 关系型数据库
实现MySQL异地多活场景
现代化互联网企业面临的最大威胁是意外导致的数据丢失或不可用。为应对这一挑战,企业通常采用“主从高可用”架构,但单一机房内的高可用仍存风险。真正的高可用需通过“跨机房容灾”或“异地容灾”实现。异地容灾将服务器部署在不同地域的机房中,确保一处受灾时,其他机房能迅速接管业务。更进一步的“异地多活”方案则让各节点同步处理业务流量,确保数据一致性,提高资源利用率。NineData 提供了实现这一方案的强大工具。
91 0
|
2月前
|
存储 关系型数据库 MySQL
四种数据库对比MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景
四种数据库对比 MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景
|
3月前
|
缓存 关系型数据库 数据库
PostgreSQL的性能
PostgreSQL的性能
160 2
|
4月前
|
缓存 关系型数据库 数据库
PostgreSQL 查询性能
【8月更文挑战第5天】PostgreSQL 查询性能
82 8

相关产品

  • 云原生数据库 PolarDB
  • 云数据库 RDS PostgreSQL 版