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

同時実行ユーザー数が想定より増えるとCPUコア数を増やさないとレスポンス時間の要件を満たせなくなる恐れがあります。低速なストレージ・デバイスの速度をカバーするためのメモリーの容量を後で追加したくなることもあります。データベースのデータは日々増え続けるため、ストレージ・デバイスを後から追加することもあります。
オンプレミス・システムではハードウェアの調達に数か月かかることもあります。これに対しパブリック・クラウドでは、クラウド・ベンダーがすでにデータセンターに配置しているハードウェア・リソースを借りるという方法で極めて短時間でハードウェア・リソースを調達することができるようになりました。
しかし、ハードウェア・リソースを調達できるということと、データベース・エンジンがシステムを稼働させたままハードウェア・リソースを動的に増減できるかというのはまた別の話です。今回はデータベース・エンジンがハードウェア・リソースを動的に増減させる実装についてみていきましょう。
この記事は参考になりましたか?
- オラクル技術エキスパートが紹介する 開発者のためのデータベース完全ガイド連載記事一覧
-
- サーバー増設=性能向上ではない? クラスタ構成の限界と課題から紐解く「DBアーキテクチャ」
- データベースを止めずにリソースを変更するには? ストレージを動的に増減し性能を引き出す仕組...
- データベースを止めずにリソースを変更するには? CPUとメモリーを動的に増減させる仕組み
- この記事の著者
-
日下部 明(日本オラクル株式会社)(クサカベ アキラ)
日本オラクル株式会社でOracle Databaseを担当するエンジニア。主にOracle Real Application Clustersを中心とする高可用性構成や性能チューニングの問題解決およびコンサルティングに従事。著書に「これは使えるOracle新機能活用術」(翔泳社)。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
