はじめに
この連載は、第1回に紹介したDBMSの3階層構造における「アーキテクチャと実装」についての技術の紹介から始まり、第8回からはアプリケーションから見たデータ操作階層である「データ・モデルとデータ型」についてお伝えしてきました。
データベースは巨大なデータ量を扱うため、ハードウェアのリソースも大量に必要になります。今回からは、データベースの性能に大きな影響を持つハードウェア・リソースの追加と削減についてみていきましょう。今回は１つのOS上のデータベース・エンジンのリソースを動的に増減させる実装についてです。
なお、本連載で例として挙げるデータベースはオラクルが提供しているものが多いですが、オラクル製品を使っていない方にも参考にしていただけるように解説します。
対象読者
この連載では以下の読者を想定しています。
- データ資産を活用する、新しいアプリケーションの構想や設計を担われる方
- データ基盤の運用を担われている方や、今後検討される方
- 新たに開発するアプリケーションの、最適なデータベースをお探しの方
- 目的別データベースから、価値ある情報を素早く引き出す検討をされている方
データベースのハードウェア・リソース
データベースは不揮発性のストレージに巨大な容量のデータを記録しており、多数のユーザーからの同時アクセスがあるという使われ方をします。第７回でも説明したように、データが格納されている大容量なハードディスクやフラッシュ・メモリーの不揮発性ストレージ・デバイスは比較的低速であるため、そのデータをデータベース・サーバー内の小容量であるが高速なメモリー（DRAM）に一旦移動させてCPUが処理するという構造になっています。
同時実行ユーザー数が想定より増えるとCPUコア数を増やさないとレスポンス時間の要件を満たせなくなる恐れがあります。低速なストレージ・デバイスの速度をカバーするためのメモリーの容量を後で追加したくなることもあります。データベースのデータは日々増え続けるため、ストレージ・デバイスを後から追加することもあります。
オンプレミス・システムではハードウェアの調達に数か月かかることもあります。これに対しパブリック・クラウドでは、クラウド・ベンダーがすでにデータセンターに配置しているハードウェア・リソースを借りるという方法で極めて短時間でハードウェア・リソースを調達することができるようになりました。
しかし、ハードウェア・リソースを調達できるということと、データベース・エンジンがシステムを稼働させたままハードウェア・リソースを動的に増減できるかというのはまた別の話です。今回はデータベース・エンジンがハードウェア・リソースを動的に増減させる実装についてみていきましょう。
