未来的数据库发展一定是往云上发展的，倒不是云有什么好，主要还是成本的因素，成本因素比较复杂，这里不探讨，如果你单单认为只是一些机房等基础那就大大的错误了，有机会在探讨为什么以后DBA 大多都不会触及一些基础的数据库架构，要在云上去进行新一代的DBA 生涯了。
今天还是继续翻译一篇，PG在X86 或ARM 上性能的文字，
——————————————————————————————
最近，我在ARM64位的服务器上，和POSTGRESQL 玩了一场游戏，实际上几个月前我都还对ARM架构不怎么熟悉，甚至我都不知道什么是ARM，实际上PG已经有一阵有基于ARM64的安装包了，对于ARM 的信心来自我对不同场景下的测试结果。
这里我的测试方式是基于pgbench 测试的方式通过比较X86 64 VS ARM64 ，但这并不是目标，实际上我就想找到ARM结构的PG 在什么场景下，比X86的性能好。
测试的硬件与系统： Test Configuration ARM64 VM: Ubuntu 18.04.3; 8 CPUs; CPU frequency: 2.6 GHz; available RAM : 11GB x86_64 VM: Ubuntu 18.04.3; 8 CPUs; CPU frequency: 3.0 GHz; available RAM : 11GB
通过这两个硬件，我们通过pgbench 测试，其中相关PG的参数
shared_buffers = 8G 并且通过循环的方式进行测试
pgbench scale factor : 30pgbench command :for num in 2 4 6 8 10 12 14do pgbench [-S] -c num -j num -M prepared -T 40done
通过上面的程序我们不断的，增加pgbench 测试的负载。 测试通过不同的场景来进行测试
1 纯读的模式 pgbench -S option is used for read-only workload.
上图是在进程从2 到4的过程中，X86的性能相对于ARM结构要好至少30%，随着并发的进程越来越多4-6 时倒是稍微平坦了一些， 但从6-8时图形是十分的陡峭的，超过8后我们的变化就不太多了，这也是因为我们的CPU是8CORE的。这里还有一个事情要提到，PGBENCH 和我们的数据库是安装在一起，这个程序本身要占用20%的CPU 资源，另外有一点我也没有能明白就是在6-8时上升的速度这可能与LINUX 系统的参数有关，从测试的图中我们很明显的可以看到在8以后ARM结构的性能下降的要快，实际情况就是随着CPU越来越繁忙，ARM结构的性能越来越低。
测试方式 2
select exec_query_in_loop(n)
为了让测试更专业一些，去掉pgbench可能产生的影响，我进行了另一个测试，虽然可以把pgbench 放到其他的机器上进行测试，但我还的考虑网络的延迟等等一系列的问题，所以我用C语言写了一个 与pgbench 运行的只读语句一样的程序，并循环运行，这里我们也不用考虑提交和回滚的问题，我们来看看结果
SELECT abalance FROM pgbench_accounts WHERE aid = $1 Check details in exec_query_in_loop()
根据上面的图形我们可以看到不同，在超过8个进程后，ARM 本身也没有表现的和上面的图形一样，但一样的是超过8 threads后 ，我们性能并没有特别大的提升。Postgresql 在测试中仍然ARM 结构的PG 要比X86上的要低30%左右。
该实验还表明，前面使用内置pgbench脚本的结果与pgbench客户端干扰有关。而且，ARM的线程争用曲线的下降不是由服务器的争用引起的。注意，事务率是在客户端计算的。因此，即使查询已经为结果做好了准备，在请求结果、计算时间戳等方面，客户端可能会有一些延迟，特别是在高争用场景中。
测试3 通过plpgSQL 函数来进行测试 select exec_query_in_loop(n) - PLpgSQL function 在使用C语言做此事之前，我也用过PL/PGSQL 进行相关的测试，也发现了一些和上面的不同的情况。
这里基于ARM 结构的PG 要比 X86下的PG 慢65%，基于这个事情可以发现PL/PGSQL在ARM结构上执行的速度要远低于X86，我检查了性能报告，但在ARM和x86中都能看到或多或少相同的热点函数。但是由于某些原因，在ARM上执行的任何PL/pgSQL函数都比在x86上慢得多。
测试 4
Updates pgbench有一些内置的基于tpcb的内建脚本可以进行一些多表的升级测试。
这个结果ARM 和X86的性能差距在1-10%之间，其实问题的主要原因还是整体的消耗花在了等待锁，和磁盘进行commit的操作，并且磁盘并未使用ssd磁盘。对比其他的测试，PG上的ARM 在这个测试上表现的比较好看。 剩下的，我对聚合查询，分区，提高CPU的数量（32/64/128），以及更大的内存和一些 higher scale factor， 针对两个平台下的PG在大资源下的情况。 结论：
从上面的测试中可以看出在ARM64上工作情况还是良好的，虽然在两个平台上进行性能比较的工作其实也没有那么容易，我们实际上可以看到在不同模式下，两个平台各自的不同。 翻译结束 ——————————————————————————————
个人观点，测试时并不是很严谨，仅仅通过pgbench来进行测试，这里只能说明一些简单的语句在PG上的工作情况，但值得注意的是，ARM结构的硬件产品无论是针对 PG 还是 MYSQL （看上期），其实问题都蛮多的， 至少截止目前，个人建议还是使用X86结构的产品来使用PG 或MYSQL 会更好，尤其在高并发的情况下。
顺便说一句，此文中还提到过，之前作者测试关于应用程序高并发的情况下的结果，ARM 也是一团糟。
