応答時間、スループット、そして水平スケール

高価なハードウェアを使うようにしたからと言って、必ず処理が高速になるとは 限りません。しかし、通常はそれでたくさんの処理を行うことが可能になります。 高価なハードウェアは、高速な車と言うより、広い高速道路に例えるべきでしょう。 つまり、それ自体によってスピードを出すことはできないし、それが許されていないかもしれません。しかし、多くの車線はあるのです。これが、ハード ウェアに投資しても、必ずしも遅いSQLクエリを速くすることにつながらない理由です。

今や90年代ではありません。その頃、CPUコア1つの計算性能は急速に向上していました。多くの応答時間の問題は、新しいハードウェアを 導入することで解消されました。CPUが高速になったからです。それはさながら毎年旧モデルの2倍高速な新しいモデルの車が発売されるような ものでした。しかし、21世紀初めの数年間で、1CPUコアあたりの処理能力は頭打ちになり、その点での改善はほとんど見られなくなりました。 より高性能なCPUを発売し続けるため、各ベンダはマルチコア戦略を取り始めました。しかしそれは、複数のタスクを同時に処理することはできても、 1つしかタスクがない時のパフォーマンスを上げることはできません。つまり、 パフォーマンスを複数の側面から考える必要があるようになったのです。

水平方向のスケール(サーバの追加)にも、同じ制限があります。より多くのサーバがあればよりたくさんのリクエストを処理できますが、 個々のクエリの応答時間は高速にはなりません。検索を高速にするには、CouchDBやMongoDBと いったリレーショナルでないシステムの場合も含め、効率的な検索ツリーが必要になります。

適切なインデックスを作るのはすなわち、Bツリーインデックスの対数スケーラビリティの威力を十分に引き出すことです。しかし残念なことに、インデックスの作成は 非常にずさんに行われることも多いのです。「データ量に対する応答時間」の図では、そういったずさんなインデックスを明らかにするものです。

ずさんなインデックスと正しいインデックスの応答時間の違いは 驚くほどはっきりしています。この違いを、ハードウェアを追加することで埋め合わせるのは難しいでしょう。例えハードウェアによって応答時間を 小さくしようとしても、それが最善の方法なのかについては疑問が残ります。

いわゆるNoSQLシステムの多くは、あらゆるパフォーマンス問題はスケールアウトで解決できるとしています。ただし、ここで言う スケーラビリティは、多くの場合書き込み処理を対象にしていて、結果整合性(eventual consistency) モデルに従ったものです。SQLデータベースは書き込み処理を遅くする原因になる厳密な整合性モデルを採っていますが、それが必ずしも スループットが悪いことを示すわけではありません。これについての詳細は、「結果整合性とCAP定理」という題のボックスを参照してください。

ハードウェアを増やしても、通常は応答時間は改善されません。実際には、システムが複雑になることでレイテンシが蓄積するため、システムは 遅くなってしまう可能性すらあり得ます。アプリケーションとデータベースが同じコンピュータ上で動作している場合、ネットワークのレイテンシは 問題になりませんが、本番環境ではデータベースとアプリケーションをそれぞれ専用のハードウェアで動かすことが多いので、そういった構成は 一般的ではありません。セキュリティポリシー上、アプリケーションサーバとデータベースの間にファイアウォールを置かなくてはならない時もありますが、 これもネットワークレイテンシを倍増させる原因になります。インフラが複雑になればなるほど、レイテンシが積み重なり、応答時間は遅く なっていきます。こう言ったことが、高価な本番用ハードウェアが、安価なデスクトップPCの開発環境よりも遅いという、直感に反する振る舞いにつながる ことがあります。

もう1つ非常に重要なレイテンシに、ディスクのシークタイムがあります。 回転するハードディスク(HDD)は、要求したデータを読み込むために機械的なパーツを指定した場所に動かすのに、通常数ミリ秒という比較的長い時間を 要します。この時間は、4階層のBツリーを走査する時には4倍かかるわけですから、 合わせて数十ミリ秒かかることになります。それはコンピュータにとっては永遠に思われる程の時間ですが、1度しか行われない処理なら、我々の認識できる 長さとまではいかないでしょう。しかし、1つのSQL文で数百、場合によっては数千回のディスクシークが起きることも普通にあることで、特に複数の テーブルを結合する時にはなおさらです。キャッシュによってこういった問題は劇的に改善されますし、SSDのような新技術によって、 シークタイムは桁違いに減りますが、それでもなお結合は遅い処理だと言えるのではないでしょうか。次の章では、効率のよいテーブル結合のための インデックスの使い方を説明します。