はじめに
この連載は、第1回に紹介したDBMSの3階層構造における「アーキテクチャと実装」についての技術の紹介から始まり、第8回からはアプリケーションから見たデータ操作階層である「データ・モデルとデータ型」についてお伝えしてきました。
データベースは巨大なデータ量を扱うため、ハードウェアのリソースも大量に必要になります。前回第13回からは、データベースの性能に大きな影響を持つハードウェア・リソースの追加と削減に焦点を当てています。前回は1つのOS上のデータベース・エンジンのCPUとメモリーのリソースを動的に増減させる実装について扱いました。今回はデータベースのもう1つの重要な構成要素であるストレージの動的な増減について見ていきます。
ハードウェア・リソースを追加しただけでは性能は向上しません。性能が向上するには追加したハードウェアが適切に使用される必要があります。データのアクセス・パターンとアーキテクチャが適合していないとハードウェアの性能を引き出すことができません。
なお、本連載で例として挙げるデータベースはオラクルが提供しているものが多いですが、オラクル製品を使っていない方にも参考にしていただけるように解説します。
対象読者
この連載では以下の読者を想定しています。
- データ資産を活用する、新しいアプリケーションの構想や設計を担われる方
- データ基盤の運用を担われている方や、今後検討される方
- 新たに開発するアプリケーションの、最適なデータベースをお探しの方
- 目的別データベースから、価値ある情報を素早く引き出す検討をされている方
データベースのハードウェア・リソース
まず、データベース・サーバーの構成要素を振り返ります。データベースは不揮発性のストレージに巨大な容量のデータを記録しており、多数のユーザーからの同時アクセスがあるという使われ方をします。第7回でも説明したように、データが格納されている大容量なハードディスクやフラッシュ・メモリーの不揮発性ストレージ・デバイスは比較的低速であるため、そのデータをデータベース・サーバー内の小容量であるが高速なメモリー（DRAM）に一旦移動させてCPUが処理するという構造になっています。
前回で扱ったCPUとDRAMは、OSを再起動したり電源が途絶えると扱っていた情報が消失してしまうという性質を持っていました。CPUとDRAMをマザーボードに物理的に増設するには物理マシンの筐体のふたをあけて部品を追加／交換するという作業になるため、実質的には電源を停止して作業を行います。
データベース本体のデータを格納するハードディスク・ドライブやフラッシュ・メモリーといったストレージ・デバイスをデータベース・サーバーの物理マシンに格納する場合もあります。ストレージ・デバイスは物理マシン筐体の前面に交換モジュール形式で配置されていることが多いので、物理マシンの電源を停止せずに増設や交換ができるようになっています。しかし、1台の物理マシン筐体に格納できるストレージ・デバイスの台数は限られているため、多くの場合はネットワーク接続のストレージを使用します。
ネットワーク接続のストレージを使用すると、データベース・サーバーからストレージを認識できた時点で使用可能になるため、データベース・システムを稼働させたまま容量を追加することが極めて容易になります。
しかし、ストレージ・デバイスの容量を追加しただけではストレージ・サブシステム全体の性能は向上しないというのが今回の本題です。
