巨大テーブル活用術1

前々回のコラム「Google の巨大テーブル」を受けて、実際普通の企業で「巨大」テーブルを活用できる方法を模索しているので、その過程で見つけたことなどを紹介したいと思います。

まず、「巨大」というのはどれぐらいか、ということですが、Google のように何万台のサーバーにまたがる何十億件というデータははまさに「巨大」ですが、普通の企業にとってはどうでしょう？

例えば1テーブルのデータの件数で言えば、100万件ぐらいなら「大きい」、1,000万件なら「巨大」と呼んでいいでしょう。

それでは、どこにそんなに「巨大」なテーブルを使う機会があるでしょうか？　そもそも使う機会がなかったら調べる意味もありませんから。

まず思いつくのはタグです。

Web 上ではユーザーが任意のタグをコンテンツにつけて、そのタグの傾向などから、同じような嗜好を持つユーザーのコンテンツを紹介するような仕組みが、一般的になっています。

もちろん、「この顧客データにアクセスしている人は、こんな顧客データにもアクセスしています」というような機能が必要かどうかは疑問ですが、少なくとも自由にタグ付けして検索できる機能もあったら便利でしょう。

次に思いつくのは、履歴です。

更新を上書きで行うのではなく、更新の度に追加追加でバージョン管理していけば、履歴を遡って確認することが可能です。

タグは指数関数的に、履歴は時間に比例して増加していきますので、「巨大」になるのはまさに時間の問題です。

さて、「巨大」というのはどれくらいか、またどのような使い方をするのかについてはいくらか見えてきましたが、テストするにあたってひとつ問題がありました。

「巨大」なテーブルにどうやってデータを満たしたらよいか？

最初は郵便番号を使って、と思ったのですが、全国で高々30万件前後だと、33倍に膨らまさないと「巨大」にならないので、都道府県や市区町村のタグをつけたところで焼け石に水です。

無作為に抽出した文字列を使った完全に人工的なデータを作ることはできますが、できれば実際のデータのほうがいいのです。

そこで見つけたのが、Wikipedia のデータでした。Wikipedia では、データがダウンロードできるようになっているだけでなく、Wikipedia のサイトを構成するソースコードや、これまでにどのようにハードウェアを増設してきたか、何から何まで公開されているのです。

ちなみにその Wikipedia のデータ、今回は日本語版を使用します。それでも十分「巨大」で実用的なデータで、履歴を含んだものだと、2GB の圧縮データで小さく見えたのですが、250GB の空きディスク上でも容量不足で解凍することさえできなかったほどです。

これまでテストしたところでは、MySQL でかなりのところまで実現できてしまいます。一方 Google の BigTable 思想で設計される Hypertable や Hbase は、MySQL と比べるとないもの尽くしに見えます。

もちろん BigTable は「巨大」がかわいく見える規模までカバーできるように、実質無制限に拡張できるよう設計されています。

しかし全国600万中小企業にとって、そこまでの規模まで拡張できるというメリットは無意味でしょう。規模が小さければ、「データを取り出して作業するよりも、データの側で作業をしたほうがいい」という、BigTable の思想もまたほとんど意味不明です。もちろん私の事務所でテストができないことも言うまではありません。

MySQL のすごさを改めて実感する結果になりそうですが、限定されたシナリオでは BigTable 勢が圧倒的なパワーを見せてくれることを期待しつつ、引き続きテストを続け、次回結果をご報告しますので、お楽しみに。