インメモリ・コンピューティングって、何？（その2）～1,000倍、1万倍、10万倍あたりまえ!?
前篇はこちら：「インメモリ・コンピューティングって、何？～13時間53分お待ちください!?」
インメモリ・コンピューティングとは、ひとことで言うと「すべてのデータをメモリ上に持つことによって、処理を圧倒的に高速化する」という新しい技術の総称であり、SAP HANAもそのひとつだ
■10万倍は「あたりまえ」
前回は「HDDはメモリに比べてアクセス速度が10万倍くらい遅い。それならHDDをやめて全部メモリにすれば、速くなるんじゃないの？」というところまで話を進めた。
そのとおり。そしてその考え方を「インメモリ・コンピューティング」と呼ぶ。すべてのデータをメモリに持っておき、読み書きをメモリ上だけで処理することにより、圧倒的な速度を実現する技術であり、SAP HANAもそのひとつだ。
インメモリで処理することにより、データに対するアクセス速度は圧倒的に速くなる。前回の「倉庫と作業机」の例でいえば、「0.5秒 vs 50,000秒（13時間52分）の違い」、つまり10万倍の速度差があるのだから、ある意味、速くなって当然なのである。
実際SAP HANAのユーザー事例では、従来のHDDベースのシステムと比較して、1,000倍、1万倍、10万倍といった「ケタ違い」な処理時間の短縮を記録した例が次々と報告されている。
※IT畑以外の方にはちょっと想像しにくいかもしれないが、企業システムでは、現在でも、1回につき何十分も、あるいは十数時間もかかる“重い”処理、というものが存在している。個人がPCを使っている感覚だとなかなか理解しづらいが、一度Enterキーを押してから答えが返ってくるまでに十数時間かかる（がそれで正常）、ということだ。HDDに格納されている膨大なデータを順に読みだして突き合わせたりするような処理だとそうなる。
これが、インメモリ・コンピューティングに切り替えることで、たとえば従来13時間52分かかっていた処理が0.5秒で終わる、といったことが実際に起きているのである。
しかし、ちょっと待った。前回、メモリの特徴は「容量が相対的に小さい、単価は高い、電力が切れると消えてしまう、読み書きは速い」と書いた。ということは、すぐに3つの疑問が来るはずだ。
■1. メモリを大きくすると、高いんじゃないの？
そのとおり。長いこと、メモリは非常に高価だったから、大量に積むことは高くついた。それが可能になったのは、ひとえに、メモリ単価の劇的な下落による。
DRAMの価格が常に下がり続けているのはご存じのとおりと思うが、たとえば下記の参考記事： What Causes Semiconductor Cycles? の図表
（出典：Forbes.com http://blogs-images.forbes.com/jimhandy/files/2011/12/DRAM-GB-Price.jpg）
によれば、1991年から2011年の20年間に、DRAMのギガバイト単価はざっと$50,000から$20以下へ、ざっと数千分の1に下がっている。1991年に5000万円で買えたマンションが、現在2万円以下で買える、という計算だ(笑)。この20年間の物価の安定（あるいはデフレによる下落）を考えると、すさまじい。
その結果、メモリはかなり安くなった。たとえば下記は、国内主要IAサーバー各社（日立、富士通、HP、IBM、Dell）から出荷されているHANAサーバー用の（つまりもっともハイスペックな）メモリを128GB（16GB×8枚）購入した場合の、Webサイトに掲載されている定価だ。（※各社ごとに実勢価格（値引き率）が異なるし、各社の定価を比較することが目的ではないので、ここでは順不同とする。）
68万、72万、115万、152万、240万。
これで超高速のインメモリ処理を動かすことができる。企業向け基幹サーバーにおいて68万～240万は、もはや足かせとなるような金額感ではないことはあきらかだ。
＃逆に、もし今が’91年で、上記の2,500倍の値段だったとすると、サーバーに積むメモリだけの価格が17億～60億となる。これは確かに、簡単には買えない(笑)
■2. 電源が切れたらデータ消えちゃうんじゃないの？
そのとおり。インメモリ製品であるかぎりこれは避けられないので、当然ながら確実な対策が必要である。SAP HANAの場合は、インメモリではあるが同時にHDDも持っており、処理をしながら並行してデータおよびアクセスログを書き出すことでデータ保全を確実にしている。
なんだHDDもあるのかと思われるかもしれないが、SAP HANAではHDDはすべてデータの保全用、いわばバックアップだ。したがって通常の製品と違って、HDDの遅さによって処理の足を引っ張られることはない。さらにSAP HANAではログストレージにSSDを採用し、より高速にログを書き出すことで、インメモリ側の処理に影響を与えない構成としている。
要するに、処理自体はインメモリ側で超高速にこなしているが、一方でそのデータのバックアップは裏側でちゃんと取っていますよ、ということだ。
少々脇道にそれるが、実のところ、このあたりは電源断という「万が一の事態への備え」というよりは、「データベースにおけるトランザクションの完全性を保証するための仕組み」の話である。
トランザクションの完全性、などと聞くとえらく技術的な話に聞こえるが、ごく大雑把に例えれば、「銀行から1,000円引き出したら預金残高も確実に1,000円減っているようにする」というだけの話だ。
銀行は必ず、「①預金残高から1,000円を仮押えしておき（もし残高が足りなければこの時点でストップ）、②1,000円札を客に渡し、③客に渡ったことを確認してから仮押えした1,000円を預金残高から減らす（もし何らかの理由で客に渡せなかったときは仮押えを解除し残高は元のままにする）」という処理手順になっている。こうしておかないと、処理手順の途中でなんらかのトラブルが起こった場合、残高が正しい実態を表さなくなる＝データの完全性を保証できなくなるからだ。
こうしたデータの完全性の保証は、インメモリかHDDベースかに関係なく、すべてのデータベースが実装している必須要件であり、その実装方法に各社独自の工夫による違いがあるだけだ。
■3.容量が相対的に小さいんじゃないの？
こちらは半分Yes、半分Noである。たしかに現状、インメモリ・データベース製品の容量はHDDベースの製品にくらべれば相対的には小さい。たとえばSAP HANAでは、積んでいるメモリの実サイズは128GB～16TB程度。HDDベースの製品であればその数百倍を積むこともできる。
しかし一方で、では16TBは小さいか？というと、、、どう説明するべきか迷うが、莫大な量であるには違いない。少なくとも、普通の企業システムを考えれば、そうそう簡単に一杯にできるような大きさではない。
＃16兆円は少額か？日本（国および地方）の債務残高1,200兆円に比べれば確かに小さいが、、、みたいな話かと。
今回はだいぶ話が拡散したが、インメモリ・コンピューティングがなぜ今実用化されつつあるのか？その概要についてはご理解いただけたものと思う。
次回からは事例紹介に戻り、この「10万倍パワー」をブン回しているゲームチェンジャーたちを、いくつかご紹介してみたい。
メモリとHDD、SSDについての参考情報
■Wikipedia－Flash SSD
http://ja.wikipedia.org/wiki/Flash_SSD■初心者のための「SSD」講座。HDDとSSDの違いを教えて！【第1回】
http://hddnavi.jp/ssd/ssd_hdd1.html