MySQL開発者が予測するRAMデータベースの可能性
すでに随分前から、完全にRAMだけで動作しているアプリケーションもある。Palm Pilotはメジャーなプラットフォームの1つだが、電池式のRAM以外に記憶装置を備えていない。ディスクはリモートバックアップの際に時折使用されるだけだ。
RAMの容量を増やせば、データベース全体をRAMに格納することも可能になる。そうすれば、すべての処理を高速かつ簡単に実行できる。ディスクの回転速度が5400や7200であろうと関係ない。
本当に巨大な 集合データベースでは明らかにまだ不可能であるものの、大きめのデータベースなら無理と決め付けることはない。
Slashdotを例に考えてみよう。このサイトでは毎日およそ20の話題と、各話題ごとに500ものコメントが公開される。1つのコメントを１キロバイトとして計算すると、1日に合計10メガバイト、1年でおよそ3.65ギガバイトである。数年前のRAMであればとてつもない容量だが、今ならサーバに追加しても700ドル足らずだろう。
あるいは、1日におよそ2,800便のフライトがある Southwest
Airlines はどうだろうか。737型機の座席数が140だとすると、1年で約1億4300万シート、ひと月で約1200万シートである。1つのシートにつき10バイトを使用しても、2ギガバイトに満たないRAMデータベースでまるまる1年は賄える計算だ。DB管理者はおそらく、2か月分のレコードだけをRAMに格納しようと考えるだろう。1つのシートにつき60バイトなら、少し工夫すれば豊富な情報を扱うことができる。
とりわけ興味深いのが、データベースソフトウェアのアーキテクチャに与える影響である。データベース設計では、情報をハードディスクに注意深く書き込み、データに素早く永続性を与える部分が最も難しいとされる。優れたデータベースほど、最も頻繁にアクセスされるデータをRAMに保持しながら、すべての変更内容をハードディスクに書き出すためのキャッシングの仕組みが、念入りに作り込まれているものだ。
このキャッシングの仕組みを精巧にプログラミングするには、ディスクへの処理に厳重な注意を払い、さらにそのデータが正しいかどうかをもう一度確認する必要がある。まずデータベースがデータを書き込んだ後、データがディスクに存在するかを再度チェックするのだ。正常に書き込まれていれば、データベースは新しい情報をコミットし、問題があればロールバックする。このような概念を一般に「ACIDの原則」と呼ぶ。つまり、データベースの処理にはAtomic（原子性）、Consistent（一貫性）、Isolated（独立性）、Durable（耐久性）が要求されるという意味だ。
だが、すべての情報をRAMに保持するとなると話は一変する。ディスクを使わないのだから、RAMとディスクで矛盾を確認する必要はない。データベースの設計が簡単になる上、処理がかなり高速になる。
永続性を持つRAMデータベースの可能性についてさらに考えてみるため、Montyに以下の質問に答えてもらった。
Q：永続的なRAMだけを使用するコンピュータでは、バッテリーバックアップで保護されたRAMにすべての情報を格納します。データをディスクに書き込む際の遅延がなくなるため、データベースのアーキテクチャは確実に変化するでしょう。すべてのデータをRAMに保持すると、データベースの構築は簡単になるのでしょうか。
A：ポイントとなるのはRAMの永続性です。つまりコンピュータの電源がいつ切れたとしても、データを失うことなく再び処理を開始できるかが重要なのです。これが可能なら、非常に高速で安全なデータベースを、まったく新しい方法で開発することができます。現在のデータベースで最も厄介なのは、コンピュータがダウンした場合でもデータを失うことのないような方法で、トランザクションを扱うことです。これには多くのリソースが必要であり、ほとんどのデータベースで重大なボトルネックを発生させる原因となっています。永続的なRAMを使えば、この問題はずっと簡単に解決できます。
また、RAMに格納するのとディスクに格納するのとでは、データベースの処理方法がまったく変わってしまうため、RAMのメリットを十分に活かすには、データベースを大幅に変更する必要があります。
ACIDの原則を守ることも簡単になるのでしょうか。
はい。ほとんど何もしなくてよいでしょう。
コミットやロールバックのアルゴリズムの代わりに、モニタやセマフォを利用できますか。簡単なセマンティクスを選んでかまわないでしょうか。
コミットやロールバックはやはり必要です。この機能はアプリケーションレベルで非常に便利だからです。ただし、ロールバックが必要ない場合には、これにモニタとセマフォを組み合わせるのがいいでしょう。
リジッドなテーブルモデルから柔軟なオブジェクトモデルへ移行することについてどのようにお考えですか。メモリ内でレイアウトが一定している方が、アクセスや検索は高速なのでしょうか。
オブジェクトモデルには、ルックアップが高速であるなどいくつかメリットがありますが、データの操作や管理、および長期のバックアップはかなり複雑になります。また、何か問題が起きたときの修復も非常に困難です。
レイアウトが一定していれば理解や確認が簡単になり、使いやすくなります。オブジェクトモデルが普及するのはもうしばらく先だと思います。
RAMを使用する場合、パフォーマンスに何か別のボトルネックが発生するのでしょうか。たとえば、スラッシングはRAMというよりもディスクに左右される問題だと思うのですが。
RAMはある意味でディスクと似ています。ひとたびメモリ領域にアクセスすると、それに続く数バイトを探すのは早いのですが、少し離れた場所を探すのには時間がかかります。これはディスクのシークも同じです。
ですから、RAMを使用する場合には、ディスクのスラッシングというよりも、データの格納や検索のためのアルゴリズムが主なボトルネックとなるでしょう。
複数のテーブルを管理する方法も変わるのでしょうか。RAM内の検索が非常に高速だとすると、インデックスの設計に時間をかけてもあまり意味がないのでしょうか。
確かに、RAMはかなり高速に検索することができます。しかし、規模の大きいデータベースではそれほど速くありません。これまでと同様、インデックスには効率的な手段を用いることが必要です。
ディスクへの書き込みはどのくらいの頻度で行うのでしょうか。バッテリを信頼して、ディスクへのバックアップをまったく行わなくても大丈夫ですか。
私が心待ちにしているのは、ディスクレスなコンピュータです。PDAに少し似ているが、はるかに高い処理能力を備えるものです。ハードディスクは大容量のバックアップデバイスとして、普段必要としないデータを格納するために使います。
別の言い方をすれば、ディスクへの書き込みは必要ないということです。
データをディスクに書き込む処理で、これまでと同様にデータの同期や順序を考慮し、ACIDの原則に沿って開発することが必要になりますか。
ディスクをバックアップのためだけに使用するなら、アルゴリズムは以前よりもずっと簡単になります。ただし、データをディスクに格納した後もそのデータを操作するつもりなら、ACIDの原則に従うことが必要です。
Peter Wayner：『Translucent Databases』 および『Disappearing Cryptography』の著者。MySQLのコース「 Storing Sensitive Information with MySQL Databases」の講師を勤める。
