[Database] Big Data: In-Memory MapReduce

不可能なことを可能にするにはコストがかかるわけですが、今日のビッグデータの場合、そのコストはレイテンシです。リアルタイムでビッグデータを分析するためには、ビッグデータプラットフォームを根本から改善する必要があります。このエントリでは並行分析（Parallel Analytics）、そして非常に大量のデータをインメモリ（リアルタイム）で捌く方法をご紹介します。

メモリ上で動作する並行処理プラットフォーム
Oracle Database 11gR2で実現したことのうち、よく見逃しがちなことの一つとしてRACクラスタをまたがってインメモリ上に存在するデータの振る舞いです。クラスタ内の一つのノードのメモリサイズにデータサイズを制限されずに、データベースはメモリをラージプールとして扱うことができます。もはやオブジェクトのあらゆるデータを全ノードに複製するためのキャッシュフュージョンは不要なのです。

キャッシュフュージョンプロセスは上記のように、状態Aではノード1、ノード2がそれぞれ異なるデータを取得してバッファキャッシュに入れます。キャッシュフュージョンが起きるとオブジェクト中の全データは両ノードのキャッシュに展開されます。
11gR2ではこの方式を変更し、並行実行してバッファキャッシュをグリッドとして使えるようにしました。これにより、キャッシュフュージョンをする必要はなくなりましたが、そのかわりにデータ（affinitizeはあまり適切ではない英単語ですが）を内部アルゴリズムに従ってノードのメモリ上に配置します。並行実行ではデータの場所と、（キャッシュフュージョンを使ってデータを移動させるのではなく）そのノードへのクエリを入れ替えた場所を追跡し続けます。

その仕組みが上図です。P1とP2はバッファキャッシュに存在するデータ群で、あるノードに存在しており、当該ノード上のパラレルサーバプロセスはクエリを実行し、結果をクエリの発行元ノードに返す、というものです。インメモリグリッドを使うと、ずっと大きなデータ量を扱えるのです。

データベースでのMapReduceはインメモリMapReduceへ
データベースでのMapReduceについてこのブログで議論してきましたので詳しくは説明しません。ご存知ない方は以下のエントリをどうぞ。

In-Database MapReduce (Map-Reduce)
http://blogs.oracle.com/datawarehousing/entry/in-database_map-reduce

データベースの設計上の理由により、データベース中で並行処理を活用して実行するコードはマシンのメモリに存在するデータを利用できます。グリッドの有無は関係ありません。MapReduceのコードをメモリ上で実行できるシステムの構築方法を理解するよりは、単にコードの書き方を理解べきです。Oracleはデータのサイズ次第でディスクではなくメモリを活用します（下図）。

ではビッグデータとはどれぐらいのことを言うのでしょう。Exadata X2-8マシンの場合、2TBのメモリを搭載しており、Exadata Hybrid Columnar Compression（メモリ上にデータを圧縮した格納する機能）を利用すれば、簡単に10TB以上のデータをメモリ上で扱えるのです。メモリ 増やせば、より多くのデータをメモリ内に格納でき、ますます興味深いデータ分析ができるのです。いずれにせよ、複雑な分析がリアルタイムで可能になるのです。

原文はこちら。
http://blogs.oracle.com/datawarehousing/entry/big_data_in_memory_mapreduce