7つの悪習慣業務システムとSIの未来

2009年04月20日

クラウド時代のデータベース

というお題で原稿を書きませんか? というメールがこの週末に某誌の某編集さんから来たのですが、技術的なことについては正直なまくらになっているので原稿料を頂けるレベルではちょっと書けないなぁ、と腰が引けています。とはいえ、何も思いがないわけでもないので、戯れ言を垂れ流してみます。尚、本当に垂れ流しであって結論も何もないので予めご了承ください。

まず、データベースについて考える場合には、次の3つについてそれぞれ切り離して考えてみることが大切です。

・データモデル
・アーキテクチャ
・操作言語

最初のデータモデルというのは、RDBMSだとリレーショナルモデルである、というものです。ネットワーク型データベースとか階層型データベースとかオブジェクト指向データベースとかXMLデータベースとか色々とありますが、要するにどういう概念に基づいてデータを扱うのかという考え方についての話です。よく「データモデリング」という言葉がありますが、あれはモデリング言語(図言語)を利用したデータベースのスキーマ設計手法の話であって、ここでいうデータモデルとは違います。

ふたつめはデータモデルを実際にどのように実装するのかということです。トランザクションやロック機構などはこのアーキテクチャにおけるポリシーやフィロソフィで決定されます。

最後の操作言語というのは、RDBMSだとSQLが一般的ですがRDBMSでもSQLを使わないものもあります。XQueryなどもこの操作言語に該当します。あるいはホスト言語でがりっと書いてしまうというのも多数存在します。ODBMSなどはこの辺のシームレス性がアピールされたりもします。

さて、クラウド時代の、ということで挙がってくるのはGoogleのBigTableでしょう。ぶっちゃけそれ以外を考慮して話をされているケースは見かけません。そしてBigTableイコールkey-value型ということで話がされているようです。何故、CouchDBが出てこないのか全くもって残念だよ、華麗にスルーされてしまっててそれでクラウド時代とか言っちゃっうのってどうなのよ、とか思ったりもしますが、要するに目立つものに乗っかるのがポイントなのだろうと思うので、ここではkey-valueイコールクラウド時代なんだろうと思っておきます。

ここで考えるのは、ではkey-value型というのは、データモデルなのかアーキテクチャなのか、ということです。BigTableを扱える環境として先日も少しここで触れたGAEというのがあります。GAEというのはGoogle App Engineの略です。このGAEはBigTableを扱うための仕組みが提供されています。

このGAE、Python版とJava版とがあっていずれもBigTableを利用できるのですが、その場合のデータモデルには差があります。といってもドキュメントの斜め読みなので間違っていたらごめんなさいなのですが、Python版のDatastoreではExpandoというのがあって可変プロパティを実現しています。一方でJava版ではやはりがっちりと型を決めていく形のようです(ここがよくわからんのです。ほんとに? っていう。だったらPython版のほうがよっぽど面白いし、つーかJava版だせー! ってなるだろjkとか思うんですけど、そういうのは見かけないのできっと何かあるに違いないと思ってるのですが、いかんせん調査不足)。要するに、実装(=アーキテクチャ)としてはkey-valueなのですが、それをプログラムで扱う際の考え方即ちデータモデルは言語ごとに異なっているのです。

となると、クラウド時代のデータベース=key-valueということであれば、それは実装の話であってデータモデルはまた別の話なのかな? とか思ったりもするのですが、key-valueというデータモデルがクラウド時代の象徴だというような風情も見えて、頭の悪い私には正直よく分からないというのが実感です。だから原稿を書くということが出来ないのですけど。

個人的には、次世代のデータベースを考えるに際しては「第一正規形の呪縛からの解放と、one fact in one placeの両立」と「事前に型を決めない可変プロパティ」というのがテーマになると思っていて、だからこその第6正規形の話なんだろうと思ったりもするのですが(あぁ、あと「はいはい、それ何てMDM」みたいな話もありますね)、プログラミング言語からの扱いやすさ(=操作言語のシームレス性と型のシームレス性)だけが一人歩きしちゃうのは、それはどうなのかな、とか思ったりもするのです。データベースの型が可変であるとして、ではそれと紐付く画面はどうなるのか。その画面はつまりテキストボックスの否定をしなきゃならんのではないか。そんなことを思ったりするのです。

key-value型のインスタンス群に対して集合操作ってのは、例えばJoSQLみたいなのもあって、いやいやそもそもデータ量がねって話に対して、でもGAEってクォータきつくないっけ?(これもよく分かってないんですけど、調査不足で書いちゃって申し訳ないです)ってことを考えると、BigTableが使えるって言ってもほんとの意味で大量データをブン回せるわけでもないのかな、とか、いやそもそも集合操作無用でござるっていうなら、HTMLのフォームをPOSTされたらそのままテキストファイルとして保存しちゃってLucene頑張れってほうが良くね? とか、そもそも何だよその「明細」ってスキーマ(クラスでもテーブルでもエンティティでも呼び名はどーでもいいけどさ)はよぉ、とか色々と思うのです。

この勢いなら書ける! のノリでもう少し書くと、ERDレッスンではさらっと流しましたけど、結果を記録するのがイベント系であるのであれば、全てのイベント系には参照しているリソース系の項目も持たせておいてコピーするって方法だってあるわけです。何だよリソース系なんて所詮バリデーションのツールかよ的アプローチ。でもコピーだけしちゃうと名寄せで困る問題に逆戻りで、とか。だったらどうするの、という。ディメンジョナルモデルなるほどねーっていう。この辺の話が、mark-wadaさんが期待しているSOAなデータモデリング(ここでのモデリングというのはスキーマ設計手法の話)の話になるんでしょうけど、実装をkey-valueにするとしてそもそものデータモデル(これは冒頭の考え方としてのデータモデル)はどうするの? っていうことになるんです。

…こうやって垂れ流してみると、なるほどやっぱりこれは記事として書けるもんではないなぁと改めて感じるので、編集さんにはごめんなさいのお返事を書くことにします。自分でもまとまってないのがよく分かります。データベースの今後については非常に関心も興味もありますが、それ以前に要件定義とユーザインターフェイスの問題をクリアしないといかんと思ってるので、しばらくはRDBMSを前提でまだまだ進めていくつもりです。



追記:
この記事を公開して数10分後に、某誌の最新号であるVol.50の見本誌が届きました。特集3として「key-valueストア入門」という記事が掲載されていました。ざっと斜め読みした状態ですが良記事だと感じます。私の上の記事を読むよりも某誌を読む方がずっと良いと思います。

某誌↓

WEB+DB PRESS Vol.50
WEB+DB PRESS Vol.50
クチコミを見る



さらに追記(4/28):
社内の某メンバーから「ドキュメントちゃんと嫁」と言われて改めて見るとLow-level APIというのがあって、それを使えばJavaであってもExpandoと同等のことが出来るっぽいことがわかりました。そりゃそうですね。ほっとしたと同時に調査不足で恥を晒して寂しい気分ですが、それもまた人生ということでこのままにしておきます。石投げないでくださいm(__)m

habuakihiro at 13:49│TrackBack(1) 仕事 このエントリーを含むはてなブックマーク

トラックバックURL

この記事へのトラックバック

1. Jungle Java - Hadoop / hBase 関連情報メモ  [ Jungle Java ]   2009年05月13日 21:06
非リレーショナル・データベースの代表といえば、やはり Google の大規模分散ファイルシステム 「Google File System」 上に構築された 「BigTable」 でしょうか。これに倣ったオープンソースギ..