Alexey Kovyazin、2014年5月16日

您可以以PDF格式下载本文。

最近，我们在IBSurgeon中对Firebird 2.5.2进行了一系列性能测试。Firebird 2.5.2是最流行的Firebird数据库版本，其用户经常遇到与Firebird性能相关的问题。

关于数据库性能，最重要的关注点之一是其性能退化。许多用户声称，当数据库达到某个阈值时，他们的应用程序会出现性能问题：这个阈值可能是3GB、5GB、RAM大小、20GB等。最常见的说法是“数据库大小超过RAM大小”：当Firebird数据库大小达到RAM大小时，据说会变得非常慢……这是真的吗？

我们决定进行一系列测试，以验证是否存在与数据库增长相关的性能退化。我们决定在同一硬件上模拟数据库的长期增长，并施加相同的负载，为此我们运行了11个测试，数据库大小在9GB到30GB之间：

图1. 测试用数据库大小

测试硬件和Firebird配置

测试硬件具有以下关键特性：

CPU AMD-FX8350、RAM 16GB、SATA软件RAID1 2x4Tb希捷硬盘、操作系统Windows Server 2008R2（2008R2为64位）。

如您所见，这是一个低端硬件配置；在撰写本文时（2014年5月），其价格不到1000美元，可以被视为典型的低端配置–可能除了大容量SATA硬盘，但根据制造商报告，1TB和4TB SATA硬盘的速度几乎相同。

由于测试的目标是衡量典型系统的性能变化，我们使用了Firebird（64位）SuperServer架构，而非Classic，以完全模拟小公司的情况–他们使用最初安装的版本多年。如您所知，SuperServer仅使用1个CPU核心，因此Classic或SuperClassic（可以使用所有CPU核心）可能在性能方面表现更好，但我们的目标不是性能调优。

不过，我们调整了firebird.conf，应用了我们推荐给所有Firebird SuperServer安装的明显更改：将页面缓冲区增加到10000，并增加了排序的临时空间。

所有测试数据库均以16384的页面大小创建，仅为保持一致性。

测试

加载

每个测试包含2个步骤：加载和模拟20个终端执行插入、更新和删除操作。

加载步骤由加载应用程序（load.exe）执行，它向多个表中插入数据。如图2所示，数据以不同的速度加载；速度从约35MB/秒到1MB/秒不等。

图2. 数据库加载速度（红色曲线）

这与加载应用程序的设计有关，而非Firebird：加载程序快速插入数据库的70%，然后缓慢填充其余数据，并且对所有大小的数据库都重复此过程。对我们来说重要的是加载程序执行相同的操作，因此我们可以使用其平均速度来衡量加载速度。

需要说明的是，加载程序只插入数据，索引在加载完成后创建。

让我们看一下11个9GB到30GB数据库加载步骤的结果表：

#	数据库大小，GB	加载时间，秒	SATA加载速度，MB/秒
1	9.04	2535	3.65166075
2	10.80	3197	3.45924304
3	13.00	4057	3.281242297
4	15.50	4698	3.378458919
5	17.30	5455	3.24751604
6	19.90	6037	3.375451383
7	21.60	6473	3.417024564
8	24.20	7539	3.287014193
9	26.00	7779	3.422547885
10	28.60	8851	3.308823862
11	30.30	9266	3.348499892

图3. 加载时间和速度

或者，最好用图4中的图表来展示：

图4. 测试结果：加载速度。

如您所见，图表相当稳定，加载过程的平均速度在3.3-3.4MB/秒左右波动。当数据库大小超过RAM大小后（从第5个数据库开始，大小为17.3GB），也没有加载速度下降的迹象。

性能

加载时间看起来很有希望，那么实际的性能结果如何呢？

在查看性能结果之前，让我们快速回顾一下模拟过程。

模拟运行20个线程，每个线程随机执行几个业务操作：创建新订单、处理付款、统计库存产品数量、处理订单交付等（详细信息可查看实际存储过程的SQL文本）。如您所见，这是抽象库存/销售应用程序的常见业务操作集。

测试应用程序测量每秒的业务操作数，并报告平均值。当然，这个数字是人为参数，但足以进行比较。

性能测试结果：

#	数据库大小，GB	SATA上的性能
1	9.04	494.73
2	10.80	491.94
3	13.00	480.36
4	15.50	469.11
5	17.30	446.42
6	19.90	431.61
7	21.60	426.85
8	24.20	424.5
9	26.00	414.04
10	28.60	409.14
11	30.30	407.97

图5. 性能测试结果表。

或者，最好以图形方式查看结果：

图6. 性能结果图

如您所见，随着数据库大小的增长，性能会缓慢下降–数据库越大，运行速度越慢（在同一硬件上）。当数据库大小超过RAM时，也没有出现大的性能下降。数据库从9GB增长到30GB导致大约20%的性能损失。

30GB的Firebird数据库现在随处可见，并且它们会随着时间的推移不断增长。然而，当数据库变得更大时会发生什么？我们指的是–更大！当数据库变得真正巨大时，性能会发生什么变化？

Mr.Big

为了回答这个问题，我们决定查看测试表的最后部分，并在同一硬件、相同设置下对1.7TB（1813GB）的数据库进行测试。

加载

因此，我们创建了这样的数据库：

图7. 数据库大小–现在为1813GB

加载耗时566448秒–157小时，6.55天。这是一个很长的时间，但平均加载速度是……3.28MB/秒！

#	数据库大小，GB	加载时间，秒	SATA加载速度，MB/秒
12	1813.969025	566448	3.279214122

图8. 1.7TB Firebird数据库的加载时间和速度

在图表上看起来非常好：最后一点（#12）。因此，Firebird的插入算法表现出非常好的结果。

图9. 加载速度–第12点对应1.7TB Firebird数据库

Mr.Big的性能

然后我们运行了相同的性能测试–第12行对应1.7TB数据库。

#	数据库大小，GB	SATA上的性能
1	9.04	494.73
2	10.80	491.94
3	13.00	480.36
4	15.50	469.11
5	17.30	446.42
6	19.90	431.61
7	21.60	426.85
8	24.20	424.5
9	26.00	414.04
10	28.60	409.14
11	30.30	407.97
12	1813.969025	169.33

图10. 性能测试结果–第12行对应1.7TB数据库

そしてグラフはこちら：


図11. パフォーマンス、ポイント#12は1.7Tbデータベース

この結果は、Firebirdにおいて緩やかで安定したパフォーマンス低下があることを確認しています - データベースサイズが60倍（30Gbから1813Gb）に成長した一方、パフォーマンス損失は2.4倍（407ポイントから169ポイント）でした。

同じローエンドハードウェアでデータベースが30Gbから1.7Tbに成長するのは珍しい状況ですが、Firebirdはこのような状況でも動作します。

大規模データベースの詳細

1.7Tbデータベースをより深く理解するために、Mr.Bigデータベースの統計情報を収集し、IBAnalystで分析しました：

図12. IBAnalystでの1.7Tbデータベースのテーブル

ご覧のとおり、2つの大きなテーブルがあります - ORDER_LINE（約600Gb）で63億レコード、STOCK（約680Gb）で21億レコードです。

そして、これらのテーブルには深さ=4のインデックスが2つあります - これは、実際のデータ読み取りの前に、すべてのリクエストがインデックスページを4回読み取ることを意味します。ORDER_LINE_PKインデックスのサイズは50Gbです。

図13. Firebird 1.7Tbデータベースのインデックス

膨大なレコード数にもかかわらず、データベース統計は良好に見えるため、Firebirdがローエンドハードウェアでも大規模データベースに対してかなり良い結果を示すのは驚くべきことではありません。

SSDドライブでのFirebirdテスト

ローエンドハードウェアでの一連のFirebirdテストを完了した後、データストレージ技術のもう一方の端でどのような結果になるかを確認することにし、同じサーバーにSSDドライブをインストールしました。

Plextor PX-256M M5 Pro SSDドライブをインストールし、同じ設定で同じ一連のテスト（1.7Tbデータベースを除く）を実行しました。結果はSATAデバイスのグラフに追加されました。以下をご覧ください。

ロード

ご覧のとおり、SSDでのロード時間はSATAと同じです。これは予想通りの結果です：シーケンシャル書き込み操作の速度はSATAとSSDドライブでほぼ同じです。

図14. SSDとSATAでのロード

パフォーマンス

パフォーマンス結果をご覧ください：

図15. SSDとSATAでのパフォーマンス

ご覧のとおり、ランダムIO操作でのパフォーマンスはSSDドライブで約8倍良い結果を示しています。お客様のデータベースでの経験から、SSDは実際のアプリケーションで30〜50%高速であることは知っていましたが、8倍の向上は非常に高いものです。

ただし、このテストは人工的であり、大量のフェッチなしで多くの更新/削除を伴う高負荷のOLTP操作をシミュレートするように特別に設計されています。通常のデータベースアプリケーションは常にこのモードで動作するわけではありません。これが、この特定のケースでSSDがこれほど高い結果を示す理由を説明しています。

まとめ

では、これらのテストから何を学んだのでしょうか？

まず第一に - Firebirdのパフォーマンスは、サイズ制限に関連する大きな低下はありません。同じハードウェアでは、データベースサイズの成長に伴ってパフォーマンスは緩やかに低下します。このようなパフォーマンス低下は、Firebird設定のチューニングや賢明なハードウェアアップグレードで補うことができます。

ここで、IBSurgeonがFirebirdパフォーマンス最適化サービスを提供していることに触れるのは良いでしょう - このようなテストから収集した実験データを使用して、FirebirdおよびInterBaseデータベースのパフォーマンスを大幅に向上させることができます。

次に、非常に大きなFirebirdデータベース（1.7テラバイト）でも、ローエンドハードウェアで大幅ではあるが許容可能なパフォーマンス損失で動作することを確認しました。

そして第三に、SSDはOLTPアプリケーションに本当に適しています。おそらく現時点でデータベースパフォーマンスをアップグレードする最も安価な方法です。もちろん、SSDを使用しても悪いクエリプランや非効率的なインデックスの問題は修正されませんが、全体的なパフォーマンスを向上させることができます。

続く：1.7テラバイトFirebirdデータベースの詳細。