はい、大きな声で！「インメモリKVS！」「分散！」「実行！」
さて、じゃあインメモリデータグリッドの2つ目の条件とは？
「『分散していること』です。インメモリKVSの最大の強みは、データ更新を極めて高速に処理できるところにあるんですが、大量データの更新となると、やはり1台のマシンだけでは性能が頭打ちになってしまいます。そこで複数のノードに処理を分散させて、性能をスケールアウトできる仕組みが必要になります」（梅田さん）
ふーん。でも、最近のサーバだと相当大量にメモリ積めるようになってるし、1台のサーバを目いっぱいスケールアップさせるだけでも、そこそこいけそうな気も。
「たとえば、携帯電話キャリアの通信ログや、電力会社のスマートメーターなどのシステムでは、秒間数十万件ものデータ更新をさばかなくてはいけません。これだけ大量・高速の更新となると、スケールアップではとても対処できません」（杉本さん）
秒間数十万件の更新！！ そりゃさすがに1台じゃ厳しいわな……というわけで、「分散させずばインメモリデータグリッドにあらず」ということですね、はい。ちなみに、ちょっと前から耳にするようになってきた「分散KVS」というやつは、まさに今説明したような特徴を備えた製品のことで、Facebook発祥の「Cassandra」とかが代表選手。
では、最後の3つ目の条件は？
「『実行できる』こと、つまりサーバ上で、ある程度のデータ加工・計算処理を実行できることです。分散KVS自体は、キーを指定してデータを個別に出し入れする機能しかありませんが、これだけだと実際の業務で使う際、アプリケーションとのやりとりのオーバヘッドが大きくなってしまいます。そこで、せっかくたくさんのサーバがCPUを搭載しているので、サーバ上である程度のデータ処理をやらせてしまおうというわけです。一般的なリレーショナルデータベースで言うところの、ストアドプロシージャやトリガみたいなものでしょうか」（梅田さん）
こういう仕組みがあれば、一般的なデータベースの性能ではとても更新処理が追い付かないような大量のデータが飛んできても、とりあえずはインメモリデータグリッドに全部ボコボコ放り込んじゃって、ある程度データを集計した上で、あらためてバックエンドのデータベースに渡すようなことが可能になる。つまり、データベースの手前の「キャッシュ」としてこいつを置くことで、これまで処理できなかったような大量・高速のデータ更新をさばききれるようになるというわけだ。つまり、インメモリデータグリッドは既存のデータベースを置き換えるものじゃなくて、データベースといい感じで組み合わせて使うものなのね。
と、ここまで説明してきた「インメモリKVS→分散→実行」という順番は、実はインメモリデータグリッドの技術発展の歴史そのものだそうで、ここまで詳しく語ってくれたということは、もちろん日立のEADsはこれらをすべて満たしてるわけですよね？
「もちろんです！ 2012年末にリリースしたバージョン2でこの3つの条件すべてを満たして、さらに2013年7月にリリース予定のバージョン3では、基盤部分を大幅強化しています」（梅田さん）
おお、自信満々ですね！ そういえば、DB Onlineでは2012年6月に、梅田さんにEADsについて語ってもらった記事を載せてるけど（「日立のインメモリ型KVSが登場！ その背景と技術的特徴を訊いた」）、じゃああのとき話してくれたのは、EADsの初代バージョンのこと？
「ああ、はい、うーん、でもあの時はなあ……（遠い目）」（梅田さん）
ん？ なんだか急に微妙な空気が漂い始めたぞ……。
