RDBMSでも大規模データをあきらめないためには

第1回 大規模データではRDBMSのどこがボトルネックになるのか?

この記事を読むのに必要な時間:およそ 1.5 分

RDBMSはオワコン?

「右を向いても左を向いても⁠ビッグデータ⁠というキーワードが闊歩する時代に,いまさらRDBMSの話題?」

本連載のタイトルを見てそう思われたかもしれません。

「ディスクベースのRDBMSはオワコン,これからは○○(お好きなアーキテクチャを入れてください)の時代だ!」

とおっしゃる方もいるかと思います。

しかし,むしろ多くの企業がビッグデータに注目しているおかげで,RDBMS側でも大規模データを取り扱うニーズが増えています。

大規模データを取り扱う時にボトルネックとなる5つのポイント

数百ギガバイトといったレベルのRDBMSであれば,現場のエンジニアの方にとってはあたりまえの世界でしょう。しかし,テラバイトを大きく超えたデータを扱う場合には,ボトルネックの傾向が変化するのはご存じでしょうか。

次の図は,RDBMSにまつわるボトルネックを示したものです。

図1 大規模データ処理時のボトルネック

図1 大規模データ処理時のボトルネック

ここに挙げられているボトルネックを1つずつ見ていきましょう。

ディスクI/Oのボトルネック

RDBMSの性能で一番大きな課題となるのは,ディスクI/Oのボトルネックです。

ディスク上のデータへアクセスする時間は,メモリ上のデータにアクセスするより低速なので,ディスクI/Oが発生するのはやむを得ません。一般的なデータ量であれば,適切な索引を追加したり,一部のデータをメモリに乗せたりするチューニングが行われます。

しかし,大規模データを扱う際は,その中の単一データにアクセスするよりは,多くのデータを集計するニーズが多く,索引で絞り込みを行っても高パフォーマンスが得られないことが多々あります。また,大規模であるがゆえに,すべてのデータをメモリに乗せることも現実的ではありません。

問題を単純化してしまえば,より高速なアクセス速度を実現できる機器を使えばディスクI/O性能は改善します。しかし,費用対効果もあわせて考える必要があります。

CPUのボトルネック

大量データに対して,読み込み・集計・演算などの処理を行うには,当然ながらCPUパワーも必要です。しかし,CPUのクロック速度はある程度頭打ちしており,⁠高性能のCPUに取り替えれば処理が速くなる」という時代は終わりを告げつつあります。

その一方で,CPUのコア数は,驚くほどのペースで増えてきていますが,大量コアのCPUに換装しても,業務処理がそのまま速くなることはありません。大規模データを処理するためには,処理の並列化を実施する必要があります。

また,多くのシステムにおいては,大規模データを扱う処理だけでなく,その他の細々とした業務処理や管理系処理がDB上で同時に動いています。特に夜間の時間帯などで,特性が異なる処理間でCPUの奪い合いが発生し,システム全体が遅くなるケースがあります。

ネットワークのボトルネック

大規模データを扱うということは,⁠大量のデータの入出力がDBサーバに対して行われる」ことを意味します。DB内のデータは,必ずどこかからやってきます。バグでもない限り,データが自動で無限に増幅することはありません。

データの入出力は,ネットワークまたはストレージ回線経由で行われます。たとえばネットワークであれば,一般的には1GbE,最近では10GbEが利用されることも多くなってきました。さらに,InfiniBandも活用されるようになりました。

回線は,数を束ねることで帯域幅を増やすことができますが,それで問題は解決するでしょうか?

いいえ,帯域幅が増えても問題が解決することはありません。増えた帯域を有効活用するための設計やコーディングが必要となるためです。

CPUとI/Oのバランス

大規模データを扱うときには,ディスク容量を節約する目的で,圧縮技術を併用することが多いです。圧縮を行うことで,DBサーバのCPUとI/Oのボトルネックのバランスが大きく変化することがあります。

バランスが変化するということは,チューニングのアプローチも変化します。インメモリ化・フラッシュディスク・SSDなどの利用により,ディスクI/Oレスポンスが高速化されても,同じようにバランスの変化が起きます。よかれと思って実施したチューニングが,思わぬ被害を生んでしまう可能性もあるのです。

ロックのボトルネック

処理基盤として見たときのRDBMSの大きな利点は,トランザクションやロック制御を,基本的にRDBMS側におまかせできることです。Oracle Databaseを扱ったことがある方であれば,データが大規模であるからといって,注意すべき点が大きく変わることはありません。

ただし,大規模データに多数のユーザが同時にアクセスした場合,メモリ上やディスク上にて,同一データまたは特定グループのデータに対するロックの競合が発生することがあります。


次回以降は,上記でご紹介したボトルネックとなりやすいポイントについて,RDBMSのアーキテクチャ面から,より深く理由を解説していきます。その上で,具体的な改善案について,ハードウェア・ソフトウェア両面から紹介していきます。お楽しみに。

著者プロフィール

山崎泰史(やまざきやすし)

日本オラクル(株) コンサルティングサービス統括所属。横浜生まれのテキサス育ち。インフラが大好き。新人のころからOracle Database一筋。最近は専らExadata。

共著に『絵で見てわかるITインフラの仕組み』(翔泳社)がある。


武吉佑祐(たけよしゆうすけ)

2009年,新卒として日本オラクル入社。入社以来,おもにOracle Exadataの設計/構築/運用支援プロジェクトを手がけ,さまざまな業界のお客様にExadataのスピードを実感していただくべく,日々奮闘中。今後は,Exalyticsなど,他のExaファミリーにも触手を伸ばそうと目論んでいる。

共著に『即戦力のOracle管理術 ~仕組みからわかる効率的管理のノウハウ』(技術評論社)がある。

コメント

コメントの記入