続・ハードウェアはこれからのデータベースの在り方をどう変えるか――ストーンブレーカー氏が語る機械学習への進化：「The Next Platform」で読むグローバルITトレンド（16）（2/3 ページ）

これからのデータベースの在り方について、リレーショナルデータベース技術のパイオニアの1人であるマイケル・ストーンブレーカー氏に話を聞いた。今回は、同氏へ行ったインタビューの後編をお届けする。

[Timothy Prickett Morgan, The Next Platform]

――その転換点を迎えるのはいつか？　帯域幅はどれだけあれば十分なのか？　ネットワークの通信速度が400Gbpsや800Gbpsとなり、プロトコルを選ぶことができ、レイテンシが300ナノ秒程度となったら何が起こるだろうか？

ストーンブレーカー氏：Amazon Web Services（AWS）の例を見てみよう。通常、トップオブラック（ToR）の接続は10Gbpsだ。これを1GB／秒と換算しよう。これに比べて、ノード同士は限りなく高速に接続される。だが、ToRのような速さでストレージからデータを読み出せるだろうか。ディスクから読み出す場合、各ドライブのデータ転送速度は100MB／秒だ。つまり、10台のドライブをRAID構成で並列に使うことで、やっとToRに追い付ける。従って、ストレージがネットワーキングと比べてどれだけ高速かが問題になる。

　私としては、ネットワーキングは進化して、少なくともストレージシステムと同じくらい強固なものになるだろうが、データベースシステムはその段階でネットワークに制約されなくなり、何か他のものがボトルネックになるだろうとみている。データサイエンスに取り組んでいる場合は、ボトルネックはCPUだろう。特異値分解において、セル数に関連したキューブ演算を行うことになるからだ。また、従来のBIを実行している場合はストレージに制約されるだろう。一方、OLTPの場合は、既にメインメモリにデータを格納できるようになっている。

　OLTPでは、100万トランザクション／秒を実現するのも大変なことではない。VoltDBやMemSQLのようなソフトウェアを使えば、お気に入りのクラスタで実現できる。これに対し、Oracle、DB2、MySQL、SQL Serverなどのデータベースでは、100万トランザクション／秒は絶対に実現できない。オーバーヘッドが大き過ぎるからだ。

　2009年、われわれのグループが論文を作成するに当たり、オープンソースデータベースシステムを構成して詳細に測定した。このシステムでは、データは全てメインメモリに格納することを想定していた。つまり、基本的に全てがキャッシュを使って行われる。そして、われわれはさまざまなデータベース機能がいかに高コストかを測定していった。

　中でもバッファープールの管理は大きな問題だった。バッファープールを持つと、更新を行う場合はデータをそこから取り出してメインメモリフォーマットに変換し、操作を加えてバッファープールに戻し、どのブロックがダーティーかを把握してLRUリストとブロック全体を保持しなければならない。概算だが、このオーバーヘッドが作業全体の約3分の1を占める。

　マルチスレッディングのオーバーヘッドも、作業全体の3分の1程度を占める。データベースシステムはクリティカルセクションが多いことから、使用するCPUが多いとクリティカルセクションで衝突が頻発し、待たされることになる。

　OLTPにおけるログの書き込みのオーバーヘッドも15％程度を占める。データ処理前のイメージと処理後のイメージを作成し、処理前にログを書き込まなければならない。

　以上により、他のオーバーヘッドも加味すると、実際に行われる有用な作業は全体の15％くらいかもしれない。こうした機能を持つ商用リレーショナルデータベースは、作業全体の85〜90％がオーバーヘッドということになる。

　このオーバーヘッドをなくすには全てを設計し直す必要がある。インメモリOLTPシステムは、そうして構築されている。

――それと比べて、配列型データベースはどの程度効率的なのか？　また、配列型データベースは長時間トランザクションにも対応できるのか？　あるいは、OLTPシステムには有効ではないのか？

ストーンブレーカー氏：全く有効ではない。10年以上前に書いた論文で万能のデータベースは存在しないことを説明したが、これについては私の意見は何も変わっていない。

　OLTPを行う場合は行ベースのメモリストアが望ましく、データウェアハウジングを行う場合にはディスクベースの列ストアが望ましいことが分かっている。これらは根本的に別物だ。

　同様に、データサイエンスを行う場合はテーブルベースのデータモデルではなく、配列ベースのデータモデルが望ましい。さらに、回帰や特異値分解などへの最適化が必要になる。だが、テキストマイニングを行う場合は、これらはどれもうまくいかない。予想できる範囲では、例えば、12くらいの問題カテゴリーごとに各カテゴリーのアプリケーション固有のデータベースシステムが使われるようになるだろう。