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

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

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のアーキテクチャ面から、より深く理由を解説していきます。その上で、具体的な改善案について、ハードウェア・ソフトウェア両面から紹介していきます。お楽しみに。

おすすめ記事

記事・ニュース一覧