Oracle Database In-Memory／Amazon Kinesisが日本国内に：Database Watch（2014年7月版）（1/2 ページ）
ついに、Oracle Database In-Memoryが日本国内でも提供スタート。Amazon Kinesisは東京リージョンが選択できるようになった。ぞれぞれをウォッチした。
今月はついに出荷開始となった「Oracle Database In-Memory」機能と、東京リージョンで利用開始となったAmazon Web Service（以下AWS）のAmazon Kinesisについてです。ちなみに今回でこの連載は11年目に突入します。10年間の応援に感謝しつつ、これからもデータベースをわくわくしながら追いかけていきたいです。
ついに解禁「Oracle Database In-Memory」機能とは？
2014年7月23日、オラクルは「Oracle Database In-Memory」機能の国内提供開始を発表しました。こちらは単体の製品ではなく、Oracle DatabaseのEE（Enterprise Editon）のオプションで利用できる新機能です。昨年（2013年）秋のOracle OpenWorldで予告があり、つい最近、6月にアメリカのオラクル本社で行われたイベントで、CEOのラリー・エリソン氏が直々にこの機能について発表しました。ようやく解禁となったこの機能の詳細に迫ります。
昨年の予告段階ではIn-Memoryオプション機能に関しては、断片的な情報しかありませんでした。「インメモリ」で処理すること。そして「メモリ内に行指向と列指向を両方持ち、最適な方にアクセスする」ということです。だから「クエリがすごく速くなる。OLTPも早くなる」「真のリアルタイムを実現する」といったメッセージが中心でした。
何だかすごそうです。しかし同時に、ある疑問が浮かびました。どうやって2種類のデータを持つのか？ 更新があったらどう処理するのか？ ――そんな疑問だらけの筆者に日本オラクルの佐藤 裕之氏（写真）が解説してくれました。
まずは、メモリ内に併存する行指向型と列指向型のデータについて見ていきましょう。オラクルではこれを「デュアルフォーマット」とも呼んでいます。
メモリ内にある行指向型のデータ（RDBの標準的なデータ形式）というのは、いわゆるバッファーキャッシュであり、以前からあるものです。これに加えて列指向型のデータもメモリ内に持つようにしたのが新しいところです。先述した「最適な方を選んでアクセスする」といわれているのはデータの参照時です。
参照時に使い分けをするためとはいえ、行指向と列指向の両方持つとなると重複しますし、かさばりそうな気もします。しかし、列指向だと圧縮効率が高くなるため、行指向ほど場所はとらないそうです。メモリに列指向のデータを展開する前にOEM（Oracle Enterprise Manager）のCompression Advisorを使えば圧縮のオプション（圧縮率）ごとにどのくらいのデータ量になるのかを見積もることができます。
メモリに載せる列指向のデータはOEMから選択できます。テーブル、テーブルスペース、カラム、パーティション、マテリアルビューなど、クエリで参照しそうなデータを選んでメモリに列指向で格納しておけるということです。何を選ぶと効率的か悩む人にはOEMの新機能「In-Memory Advisor」が助けてくれるかもしれません。これまでの使用状況からメモリに載せる最適なデータをおすすめしてくれるそうです。
メモリ内に列指向でデータを持つのですから、それだけでも相当なインパクトがあるのは読者の方ならお分かりですよね。条件により、何倍早くなるかは一概に言えないので、数字はあまり気にしない方がいいかもしれません。
ただし、高速化については「メモリ内に列データも格納する」だけではありません。例えば、CPUにおけるSIMD（Single Instruction Multiple Data）命令セットの活用です。列指向だと等長のデータが多いためSIMDを使った並列計算が使いやすいことから、処理の高速化に寄与しています。また複数の列指向型データから結合表を作成する、いわゆるJOINの処理には、フィルターをうまく使うことで高速化を実現しました。こちらは主にレポート作成の処理速度を向上させました。
ところで更新処理はどうでしょうか。更新したら、行指向と列指向でどう同期を取るのでしょうか。佐藤氏によると「更新は全て行指向で」。これも従来通りの処理方法です。行指向にデータを更新したら、すぐ列指向にも反映します。その間にわずかな差はあるものの、データを参照するときにはトランザクションログも確認するため、古いデータを参照することにはならないようにできています。
考えてみればこれが普通になることに技術の進歩を感じます。例えばMicrosoft SQL Server 2012の目玉機能の一つにカラムストアインデックスがありました。これも集計に有利な列指向のデータ形式です。しかし、登場当時はまだリードオンリーの実装で、なおかつ、一度作成したら手動で更新する必要がありました（現在では更新可能）。ほんの数年の間に行指向に加えて列指向のデータを持つこと、さらに列指向は更新もできて普通の時代になったのですね。
さて実際に使い始めるにはどうしたらいいか。メモリに載せる列指向のデータを選び、圧縮のオプションを選ぶのはOEMでやるとして、機能を有効にするために最低限必要なのは以下の3つです。
In-Memory機能を有効にするための手順
（1）パラメーターの追加（列指向で使うメモリサイズを指定）
inmemory_size = XXX GB
（2）テーブルやパーティションをメモリに載せるためのコマンドを発行
alter table | partition … inmemory;
（3）不要なインデックスを削除
分析のために作成していたインデックスは列指向のデータを持つことで不要となります。残しておくと性能を劣化させるので削除しておきましょう。
画期的な新機能ではあるものの、種明かしをするとポイントは「メモリに集計用の列指向のデータも追加した」です（高速化のための工夫もありますが）。少なくとも従来の処理をがらりと変えたりはしていません。であれば「これまで使用していたアプリケーションはそのまま使える」というオラクルの主張は納得がいきます。
ちなみにIBM DB2には「BLUアクセラレーション」という機能があります。集計処理を高速化する技術で行指向と列指向のデータを両立させている点では「Oracle Database In-Memory」と共通性があります。ただしIBMの方はストレージ内で両立（ストレージのロードも含めてトータルで高速化を図る）、オラクルの方はメモリ内で両立させているという点で違います。
もう一つ、オラクルにはOracle TimesTen In-Memory Database（以下、TimesTen）という製品がありますね。こちらは「インメモリ」の部分で共通していますが、違いは今回の「Oracle Database In-Memory」機能はOracle Databaseそのものに同梱された機能であり、TimesTenは基本的にはアプリケーションサーバーで使う製品という点です。TimesTenを必要とするのは例えば証券系システムなど、アプリケーションサーバーで激しいトランザクションを実行するケースでは、TimesTenが有効です。
この他に、ハードウェア好きな人にはすてきなニュースもあります。今回の「Oracle Database In-Memory」機能にはメモリがあればあるほど有利ということで、先述した6月のイベントでラリーエリソンCEOがイチオシの製品として紹介したのが「M6-32 Big Memory Machine」です。SPARCサーバーでDRAMを32TB搭載できます。GBではなくTBですよ。Exadataの現行最上位モデル「ORACLE EXADATA DATABASE MACHINE X4-8」でもメモリは最大12TBなので、32TBとなると「メモリのお化け」みたいですね。
最初の予告から1年弱。長らく抱えていた疑問がようやく腹落ちしました。
Copyright © ITmedia, Inc. All Rights Reserved.