在优化蜂窝通信成本的服务开发过程中，Dr。Dr . 与一个合作伙伴一起进行联合试点的关税（iOS，Android），我们需要一个庞大而高效的关系数据库。HDD的性能显然不够。数据库的大小应该为数百GB，因此将其放置在RAM中将过于昂贵。SSD最适合此任务。但是一个SSD驱动器可能不够用，因此决定组装一个包含两个驱动器的RAID-0阵列。借此机会，我们决定在一个和两个SSD磁盘上进行PostgreSQL性能测试。测试的主要目标
1.将PostgreSQL在SSD RAID-0阵列上的性能与单个SSD上的性能进行比较。2.根据表的大小，连接数，服务器设置和其他参数，研究基本操作（SELECT和UPDATE）的性能。测试进行了多次迭代。对于每个部分，决定写一篇详细的文章并附上报告：- 测试单个SSD驱动器
- 测试2个SSD驱动器的RAID-0阵列
- 服务器设置对数据库性能的影响
- SSD与HDD的比较
铁件
所有测试均在以下配置中进行：- 英特尔i7 4770。
- 16 Gb RAM。
- 系统驱动器的英特尔SSD。
- 英特尔SSD 480 Gb 530系列，用于带数据库驱动器。型号-SSDSC2BW480A401
- 东芝硬盘3000 Gb。型号-DT01ACA300
- 所有分区的文件系统均为Ext4。磁盘通过SATA 3连接。
柔软的
测试计算机上已安装Linux Mint 17.2操作系统。PostgreSQL版本是“ x86_64-unknown-linux-gnu上的PostgreSQL 9.4.4，由gcc编译（Ubuntu / Linaro 4.6.3-1ubuntu5）4.6.3，64位”在SSD上格式化后，可获得440GB。下图显示了一个SSD驱动器的性能。
读写性能约为500 Mb / s，瓶颈是SATA接口。除以下参数外，Postgres设置是标准设置：shared_buffers = 2048 Mb端口= 5400max_connections = 1000测试中
有3个选项作为负载源：- 标准pg_bench
- 具有Psycopg2的Python客户端
- 具有SQLAlchemy的Python客户端
最初的pgBench测试显示了良好的性能，但是它们在新生成的表上起作用。我们希望测试尽可能接近实际条件。当然，您可以编写自己的测试脚本，但客户端首选Python。第一个客户候选人是SQLAlchemy。它具有通过execute方法调用原始SQL命令的能力。对一个小样本的最初测试表明，SQLAlchemy消耗了大量（百分之几十）的CPU。在测试Psycopg2客户端时，处理器消耗约为15％，这在测试中是可以接受的，因为在大多数情况下磁盘子系统是瓶颈。所有其他测试都是使用带有Psycopg2的Python客户端执行的。为每个数据库连接创建了一个单独的Python进程。测试图案：CREATE TABLE numbers
(
"number" bigserial NOT NULL,
operator smallint,
region smallint,
CONSTRAINT numbers_pkey PRIMARY KEY (number)
)
为了测试阅读，使用了以下命令：'SELECT * FROM numbers WHERE number=%d'
该数字是随机选择的。为了测试记录，使用了以下命令：'UPDATE numbers set region=%d, operator=%d WHERE number=%d'
所有参数都是在有效范围内随机的。 UPDATE可以在不更改数据库大小的情况下读写数据到磁盘，因此决定将其用于复杂的写负载。测试期间未使用INSERT和DELETE。每个单独的测试花费了几分钟。单独的测试运行了几次，并且所产生的性能与大约1％的精度重合。要创建RAID-0阵列，使用了mdadm。 RAID是使用整个磁盘而不是分区创建的。为了记录大量行，使用了COPY功能。数据先前已写入临时文件，然后导入数据库。通过这种方法，超过1小时的时间就将10亿条记录输入到数据库中。填充数据库后立即在一个SSD磁盘上执行测试。该表的大小为10亿条记录。在磁盘上，表占用42GB，每个索引占用21GB。瓶颈是磁盘子系统。让我们考虑数据库性能如何根据活动连接数而变化。
SELECT表现
首先，性能取决于连接数而平均增长。从大约16个连接开始，通过邻接磁盘来稳定整体性能。
性能更新
更新记录时，图片是相似的。有16个用户，性能稳定。瓶颈是磁盘。PostgreSQL使用MVCC提供ACID。这尤其说明了，当更改整个表中一列的值时，该表的大小将更改约2倍。更新表和索引中的许多记录后，有许多失效记录，这会影响性能。考虑这如何影响阅读性能。
如您所见，阅读性能下降了15-20％。底座的尺寸也略有增加。为了提高生产率并释放空间，需要使用VACUUM命令。这个问题不在本文讨论范围之内；有关此问题的更多详细信息，请参见文档。在完成所有测试并停止PostgreSQL之后，我们决定为从磁盘读取速度重复测试。
如您所见，写入磁盘的性能下降了。该图可以在各种大小的读取数据下稳定地再现。我们对此没有任何解释。如果有人解释速度下降的原因，我们将很高兴。摘要
从这些测试可以看出，该数据库在SSD驱动器上运行良好，表中的条目数高达10亿。令人愉快的结果是，即使有980个活动连接，数据库性能实际上也不会降低。最有可能的是，许多活动的连接将消耗更多的RAM和处理器，而磁盘子系统的连接数少于千的瓶颈是磁盘子系统，但这是另一篇文章的主题。下一篇文章将测试RAID-0 SSD上的数据库性能，并且表大小将增加到100亿个条目。好吧，博士Android和iOS的资费。订阅我们的新闻，并在Vkontakte和Facebook上与您的朋友分享信息。