Question

我使用VMWare环境来比较Postgres-XL 9.5和PostgreSQL 9.5的性能。

的指示构建Postgres-XL群集

Physical HW:
    M/B: Gigabyte H97M-D3H
    CPU: Intel i7-4790 @3.60Mhz
    RAM: 32GB DDR3 1600
    HD: 2.5" Seagate SSHD ST1000LM014 1TB
Infra:
  VMWare ESXi 6.0
VM:
    DB00~DB05:
        CPU: 1 core, limit to 2000Mhz
        RAM: 2GB, limit to 2GB
        HD: 50GB
        Advanced CPU Hyperthread mode: any
        OS: Ubuntu 16.04 LTS x64 (all packages are upgraded to the current version with apt-update; apt-upgrade)
        PostgreSQL 9.5+173 on DB00
        Postgres-XL 9.5r1.2 on DB01~DB05

    userver: (for executing pgbench)
        CPU: 2 cores,
        RAM: 4GB,
        HD: 50GB
        OS: Ubuntu 14.04 LTS x64
Role:
    DB00: Single PostgreSQL
    DB01: GTM
    DB02: Coordinator Master
    DB03~DB05: datanode master dn1~dn3

DB01~DB05中的postgresql.conf

shared_buffers = 128MB
dynamic_shared_memory_type = posix  
max_connections = 300
max_prepared_transactions = 300
hot_standby = off
# Others are default values

DB00的postgresql.conf是

max_connections = 300
shared_buffers = 128MB
max_prepared_transactions = 300
dynamic_shared_memory_type = sysv
#Others are default values

在用户名上：

pgbench -h db00 -U postgres -i -s 10 -F 10 testdb;
pgbench -h db00 -U postgres -c 30 -t 60 -j 10 -r testdb;

pgbench -h db02 -U postgres -i -s 10 -F 10 testdb;
pgbench -h db02 -U postgres -c 30 -t 60 -j 10 -r testdb;

我确认所有表格pgbench_ *在Postgres-XL中平均分配为dn1~dn3

pgbench结果：

Single PostgreSQL 9.5: (DB00)

    starting vacuum...end.
    transaction type: TPC-B (sort of)
    scaling factor: 10
    query mode: simple
    number of clients: 30
    number of threads: 10
    number of transactions per client: 60
    number of transactions actually processed: 1800/1800
    tps = 1263.319245 (including connections establishing)
    tps = 1375.811566 (excluding connections establishing)
    statement latencies in milliseconds:
            0.001084        \set nbranches 1 * :scale
            0.000378        \set ntellers 10 * :scale
            0.000325        \set naccounts 100000 * :scale
            0.000342        \setrandom aid 1 :naccounts
            0.000270        \setrandom bid 1 :nbranches
            0.000294        \setrandom tid 1 :ntellers
            0.000313        \setrandom delta -5000 5000
            0.712935        BEGIN;
            0.778902        UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
            3.022301        SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
            3.244109        UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
            7.931936        UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
            1.129092        INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
    4.159086        END;

_

Postgres-XL 9.5
    starting vacuum...end.
    transaction type: TPC-B (sort of)
    scaling factor: 10
    query mode: simple
    number of clients: 30
    number of threads: 10
    number of transactions per client: 60
    number of transactions actually processed: 1800/1800
    tps = 693.551818 (including connections establishing)
    tps = 705.965242 (excluding connections establishing)
    statement latencies in milliseconds:
            0.003451        \set nbranches 1 * :scale
            0.000682        \set ntellers 10 * :scale
            0.000656        \set naccounts 100000 * :scale
            0.000802        \setrandom aid 1 :naccounts
            0.000610        \setrandom bid 1 :nbranches
            0.000553        \setrandom tid 1 :ntellers
            0.000536        \setrandom delta -5000 5000
            0.172587        BEGIN;
            3.540136        UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
            0.631834        SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
            6.741206        UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
            17.539502       UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
            0.974308        INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
        10.475378       END;

我的问题是，为什么Postgres-XL的TPS和其他索引（如INSERT，UPDATE）远远不如PostgreSQL？我认为Postgres-XL的性能应该比PostgreSQL更好，不是吗？

Answer 1

Postgres-XL旨在在多个物理节点上运行。在VMWare上运行它是一项很好的教育练习，但不应该表现出任何性能提升。您正在添加虚拟化开销和群集软件的开销。来自joyeu的答案的网页测试使用了4台物理机器。假设单个节点上引用的性能提升基于同一台机器，那么您将其读取为硬件的4倍，性能提高2.3倍。

Answer 2

也许你应该尝试一个大的“Scale”值。我得到了和你一样的结果。然后我在Postgres-XL官方网站上找到了这个网页： http://www.postgres-xl.org/2016/04/postgres-xl-9-5-r1-released/缓解/
它说：

除了证明其在商业智能工作负载上的勇气外， Postgres-XL在OLTP工作负载上的表现非常出色运行pgBench（基于TPC-B）基准测试。在一个4节点（比例：4000）配置与PostgreSQL相比，XL的TPS提高了230％（SELECT工作负载的-70％延迟比较）和高达130％（-56％）延迟比较）用于UPDATE工作负载。然而，它可以扩展很多甚至高于最大的单节点服务器。

所以我猜Postgres-XL在大数据量方面表现良好。我现在将进行测试以确认这一点。

Answer 3

Postgres-XL是一个集群服务器。单个事务总是稍微慢一些，但因为它可以扩展到大规模集群，使它能够同时处理更多数据，使其更快地处理大型数据集。

根据您使用的配置选项，性能也会有很大差异。

Answer 4

根据您的测试规格：

物理硬件：主板：技嘉H97M-D3H CPU：英特尔i7-4790 @ 3.60Mhz 内存：32GB DDR3 1600 高清：2.5英寸希捷SSHD ST1000LM014 1TB <-----

使用单个磁盘可能会导致瓶颈，并降低性能。考虑到GTM，协调器和数据节点将要访问/假脱机数据等，您将使用相同的读写速度除以4。

尽管人们谈论虚拟机管理程序引入的性能差距，但数据库是磁盘密集型应用程序，而不是内存/ cpu密集型应用程序，这意味着对于虚拟化而言是完美的，因为可以在磁盘组之间相应地分配工作负载。显然使用了预先分配的磁盘，否则您的插入速度会变慢。

Postgres-XL 9.5集群与单个PostgreSQL 9.5

4 个答案: