あらかじめ多数のストレージ装置に配置
ストレージ全体の性能を引き出す2つ目の方法は、あらかじめ多数のストレージ・デバイスにデータを分散しておくことで、1つのストレージ・デバイスの性能が飽和しないようにすることです。
これはパブリック・クラウドのデータベース・サービスやストレージ・サービスで使用される構成です。1つのデータベースのデータをかなり多数のストレージ装置に最初から配置するので、容量と性能の理論上限はかなり高いところにあります。しかし容量と性能にリミッターをかけ、ユーザーの課金に応じてそのリミッターを緩和していくことで「使った分だけ支払う」というモデルを構築しています。
また、技術的にストレージ性能のリミッターを実装することが難しい場合、性能上限のリミッターに対して課金するのではなく、ストレージへのアクセス回数などの観測可能な数値に比例した課金体系になっているものもあります。
この方式でも、ストレージ・デバイスの故障などでストレージ・デバイスの削除と追加は発生します。2よりも多い台数のストレージ・デバイス間でのデータのミラーがなされていれば、1台の故障でも交換されるまでの間を耐えることができればデータの再配置機能は不要です。
データベースのデータへのアクセスの傾向
ここまで、各ストレージ・デバイスへのアクセスがほぼ均等に発生しないとストレージ・デバイス全体の合計の性能が出せないという話でした。
しかし、各ストレージ・デバイスに格納されるデータの量だけをみて均等に配分したのでは、アクセスは分散しません。データへのアクセス・パターンを考慮に入れる必要があります。
一般的に、データはそれが生成された直後は頻繁にアクセスされ、時間が経過するとともにアクセスされなくなっていく傾向があります。例えば、商品を注文するシステムにおいては、注文が発生した直後はその決済や発送のためにそのデータへのアクセスが頻繁に発生します。しかしその注文に関連する現実世界での処理が完了したらそれに関連するデータは更新が発生しなくなるためアクセスされなくなっていきます。
アクセスが発生するデータの分布が各ストレージ・デバイスに分散していないと、特定のストレージ・デバイスにアクセスが集中してしまいます。
そのため、各ストレージ・デバイスの容量だけが均等になっていればよいわけではなく、データが新しく追加される時点ですべてのストレージに分散されるようになっていないと、データへのアクセスの頻度が偏ってしまいます。
データベースのデータはデータベースの外側の概念ではファイルの集合として扱われます。データベースへのデータの追加はファイル・サイズの拡張として現れます。これを複数のストレージ・デバイスにわたって分散させるためには、1つのファイルをある程度連続する領域に分割し、その分割された小さな領域を異なるストレージ・デバイスに配置するという方法がとられます。ストレージの階層ではこの技法をストライピング（striping）といいます。
すべてのストレージ・デバイスに充分な空き容量があれば、ストライピングによって追加されていくデータはすべてのストレージ・デバイスに分散していきます。
また、データベースから表や索引が格納されているファイルを削除すると、広大な容量が削除されることになります。これによって各ストレージ・デバイスの空き容量が偏ることもあります。長期間にわたって稼働しているとこういった偏りが発生することもあるので、やはりデータベースを稼働させたままストレージのデータを再配置する機能があることが望ましいです。
まとめ
現在、複数回にわたって、ハードウェアのリソース追加と性能向上の関係（スケーラビリティ）について扱っています。前回は1台のデータベース・サーバーのCPUとメモリーのリソース調整を扱い、今回はストレージのリソース調整を説明しました。
データベースは扱うデータ量が時間の経過とともに増加していくため、後からストレージを追加するということが発生します。
ストレージ・デバイスを追加したとき、容量だけでなく性能も向上することが期待されますが、ストレージはデータが格納されているデバイスにアクセスされるという性質があるため、データのアクセス・パターンとストレージ・デバイスへのデータの配置が適合していないと、ストレージ・デバイス全体の分の性能を出すことができません。そのため、各ストレージ・デバイスの性能が飽和しないようにデータを配置する必要があります。
これらを踏まえて、次回は複数のデータベース・サーバーからなるクラスタ構成のデータベース・システムのリソース調整を扱います。データベース・サーバーを追加して性能が向上するためには、データのアクセス・パターンとアーキテクチャが密接に関係します。
