ここから本文です

ハードウェアはこれからのデータベースの在り方をどう変えるか――ストーンブレーカー氏が語る機械学習への進化

11/27(月) 8:15配信

@IT

英国のIT専門媒体、「The Register」とも提携し、エンタープライズITのグローバルトレンドを先取りしている「The Next Platform」から、@IT編集部が独自の視点で“読むべき記事”をピックアップ。プラットフォーム3へのシフトが急速に進む今、IT担当者は何を見据え、何を考えるべきか、目指すべきゴールを考えるための指標を提供します。

ストーンブレーカー氏:私にとって興味深いのは、十分な数のデータサイエンティストを教育できれば、BIはすぐにデータサイエンスに取って代わられるだろうということだ。BIは「SQLの集計に使いやすいUIを付加したもの」と言える。一方、データサイエンスは予測分析、回帰、K平均法などを利用するものであり、基本的に配列をベースにした線形代数だ。データサイエンスがデータベースシステムにどのように統合されていくかが重要になる。

 現状は混沌(こんとん)としている。現在、大規模なデータ分析の基盤技術として「Apache Spark」の人気が高い。だが、これはデータストレージと完全に切り離されている。このことから「データサイエンスはデータベースシステムの単なる外部アプリケーションになる」というシナリオも考えられる。

 考えられるもう1つのシナリオは「配列型データベースシステムが普及する」ことだ。「SciDB」「TileDB」「Rasdaman」の3つは普及する可能性がある。配列型データベースの利用がどのように広がるかは不明だが、ゲノミクスで人気を博するのは確かだ。ゲノミクスは配列データを扱うからだ。

 さらにもう1つのシナリオは、「現在のデータウェアハウスベンダーがユーザーにとってデータサイエンス機能を使いやすくする」ことだ。彼らは既に「R」のユーザー定義関数を利用できるようにしている。Sparkが今後、どのようなものになるかは分からない。実際、将来はどの技術も今とは違ったものになるだろう。データサイエンスは混沌としていると言わざるを得ない。

――さまざまな技術がストレージ階層において、どのように使われるかという話があった。コンピュート階層についてはどうか。具体的には、GPUアクセラレーテッドデータベース、例えば「MapD」「Kinetica」「BlazingDB」「Sqream」などについてはどう見ているのか?

ストーンブレーカー氏:私も非常に興味を持っていることの1つだ。シーケンシャルスキャンや浮動小数点演算を行いたい場合、GPUなら素晴らしく速い。だが、GPUの問題は、「全てのデータがGPUメモリに収まれば極めて高速だが、そうでないとデータを別の場所からロードする必要があり、ロードがボトルネックになる」ことだ。GPUメモリにロードできる小規模なデータを扱う分野では、極めて高いパフォーマンスが要求されるローエンドアプリケーションでGPUアクセラレーションが活用されるようになるのは間違いない。だが、他のデータベース分野では、GPUの利用がどれだけ広がるかは分からない。

 私にとって最も興味深いことは、ネットワーキングの高速化がCPUの性能向上やメモリの高速化を上回るペースで進んでいることだ。基本的に、マルチノードデータベースシステムは全て「ネットワーキングがボトルネックになる」という前提で設計されている。今のところ、40Gbpsイーサネットでは帯域が不足することはないことが分かっている。実際、われわれはこの5年で1Gbpsから40Gbpsイーサネットに移行した。この間に8ノード規模のクラスタも高速化したが、40倍には程遠い。メモリの高速化も同様だ。つまり、ネットワーキングはもはやボトルネックではないだろう。

――確かに、40Gbpsで事足りているため、100Gbpsイーサネットはそれほど支持されていない。それでもベンダーは、200Gbpsやさらには400Gbpsを実現するASICを1~2年以内に提供できることを示すデモを行っている。

ストーンブレーカー氏:もしそうなれば、基本的に、誰もがパーティショニングアーキテクチャを根本から見直すことになるだろう。それは大きな変化だと思う。

――その転換点を迎えるのはいつか? 帯域幅はどれだけあれば十分なのか? ネットワークの通信速度が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くらいの問題カテゴリーごとに各カテゴリーのアプリケーション固有のデータベースシステムが使われるようになるだろう。

――機械学習用のデータストアについてはどうか? 私が興味深いと思うのは、GPUアクセラレーテッドデータベースプロバイダーが皆、TensorFlowのような機械学習フレームワークのネイティブフォーマットを将来的にどのようにサポートするかを語っていることだ。実際、彼らはTensorFlowしか眼中にないようだ。彼らは同じデータベースプラットフォームで、高速OLTPと機械学習を橋渡ししようとしている。

ストーンブレーカー氏:少し話を戻すと、機械学習は配列ベースの計算と言える。TensorFlowは、素朴な配列の演算をワークフローに多数組み込める配列指向のプラットフォームだ。テーブルベースのシステムと100万行100万列の配列(1兆セル)がある場合、その配列をリレーショナルシステムにテーブルとして格納すると、3列または1行のテーブルと、全ての値を持つ巨大なBLOBを含むテーブルを格納することになる。

 配列ベースのシステムでは、これを配列として格納し、行方向、列方向ともに大きなものを格納するようにストレージを最適化する。リレーショナルエンジンでTensorFlowやRなど、配列を使用するものを実行するにはテーブルを変換しなければならず、この変換はコストが高くつく。

――その場合、どれだけパフォーマンスを損なうのか? 少なくとも、リレーショナルまたは配列のいずれかのワークロードに悪影響があると推察する。

ストーンブレーカー氏:2つの異なる答えがある。密な配列(全てのセルが埋まっている)の場合、変換すると高いコストがかかる。だが、非常に疎な配列の場合、疎配列をテーブルとしてエンコードするのは決して悪いアイデアではない。つまり、パフォーマンスへの影響は細部によって決まる。完全にアプリケーション次第であり、機械学習フレームワークに左右されるわけではない。

 繰り返しになるが、データサイエンスとストレージの統合は一筋縄ではいかず、混沌としている。

――あなたの答えは「OLTPにはVoltDBを、配列にはSciDBを使う」ということではないかと思われる。今はこれらの製品の事業には携わっていないのか?

ストーンブレーカー氏:企業では、データ統合が大きなアキレスけんとなっているようだ。そこで私は、2013年設立のTamrという新興企業に関わっている。

 Tamrの顧客の1社であるGeneral Electric(GE)は、75の異なる調達システムを持っている。ことによるともっと多いかもしれない。実は彼らも正確な数を把握していないからだ。GEのCFO(最高財務責任者)は、これらの調達システムが連携して稼働し、ベンダーとの最も有利な取引条件を要求すれば、年間約10億ドルのコスト節減効果が見込めると試算している。ただし、そのためにはバラバラに構築された75のサプライヤーデータベースを統合しなければならない。

――Tamrのようなツールは、異種システムを統合する方が、全システムを1つの大規模データベースに集約し、アプリケーションを書き換えたり、あるいは少なくとも1つのアプリケーションに統一したりするよりもはるかに簡単だという前提に立っている。

ストーンブレーカー氏:その通り。企業ではサイロ化が進んでいる。さまざまなビジネスを展開するために、複数のビジネス部門に分かれているからだ。サイロの統合は、クロスセルや購買の一元化、ソーシャルネットワーキング、さらには単一の顧客ビューの作成といったさまざまな目的で行われるが、いずれにしても大仕事だ。

出典:How Hardware Drives The Shape Of Databases To Come(The Next Platform)

●筆者  Timothy Prickett Morgan

IT industry analyst, editor, journalist

最終更新:11/27(月) 8:15
@IT