NoSQLをRDBの代わりに使うと、どういう恐ろしいことが起こるか。PARTAKEの作者が語る

2010年12月21日

データベースの世界でいま注目されているのがNoSQL。特にキーバリュー型データストアは、グーグルのBigTable、FacebookやTwitterが内部で利用しているCassandraやAmazonクラウドが提供しているSimpleDBなど、すでに実際に使われ始めています。ではそのNoSQLをリレーショナルデータベースの代わりに使ってシステムを構築するとどうなるのか？身をもって体験したことを記したShinya Kawanaka氏によるプレゼンテーション﹁間違った方向にCassandraを使ってみた﹂が公開されています。 NoSQLを用いたシステム構築は、リレーショナルデータベースによる構築どう違うのか？とても分かりやすくまとめられています。ご本人の承諾もいただいたので、その内容を紹介しましょう。

NoSQLを使ったときに起こる恐ろしい事例

プレゼンテーションのテーマは﹁NoSQLをRDBの代わりに使うと、どういう恐ろしいことが起こるかを身をもって示す﹂

具体的には、イベントを告知したり参加者を募って申し込みができる開催支援ツール﹁PARTAKE﹂を、NoSQLをベースにして開発した際の体験。バックエンドはApache Cassandra 0.6系を用い、リレーショナルデータベースは使用せず。まずは1つめの恐ろしい事例。

﹁NoSQLはスキーマレスだから、データをリレーショナルデータベースより柔軟に扱えるよね？﹂とよく言われるが。﹁ハァ？﹂﹁︵ある意味︶迷信です﹂例えば、検索対象を増やしたい場合。イベントの開催日時で検索したいとか。リレーショナルデータベースでは、その列にインデックスを設定すればオーケー。

Cassandraでは、新しいKeyの追加が必要。インデックスを増やす代わりに、新しくテーブルを増やすようなもの（Cassandra 0.7ではSecondary Indexにより若干改善されている）。

恐ろしい事例2つ目。

2つ以上のキーを同時に更新したい場合。片方を更新後にクラッシュしたとする。

CassandraはCommitもRollbackも当然ないため、一貫性がくずれてしまう。途中でクラッシュしても大丈夫なようにするには、Cassandraに先行書き込みログを残して再起動時にReplayするという手が考えられるが、全部﹁自分で！﹂実装しなければならない。恐ろしい事例3つ目は、数さえ数えられないCassandraさん。

複数のクライアントからほぼ同時にカウントアップの処理がきたとき、Cassandra内できちんと整合性を保証することは難しい。本当に必要なら、分散ロックを導入し、速度を犠牲にする実装を自分でしなければならない。

ただし0.8系でやっと数が数えられるというウワサも。

まとめ。「NoSQL ＝ Domain Specific Database」（目的特化型データベース）だ。

ただし、それでもPARTAKEは動いている。そして実は簡単にリレーショナルデータベースに置き換えられるように作ってある。ぜひPARTAKEを使ってみていただきたい。イベント募集中！

作者にコメントをもらいました

このプレゼンテーションの作者であり、PARTAKEの開発者でもあるShinya Kawanaka氏に、NoSQLについてのコメントをもらいました。 ―― NoSQLによる恐ろしい事例を紹介されていたが、こうした制限についてどう受け止めているか？﹁NoSQL = Domain Specific Database﹂だと主張したように、パフォーマンスを求めるNoSQLの都合上、Cassandraの制限はしかたないものだと思っている。しかし、パフォーマンスを落とさない範囲でもまだ機能を追加することもできると思っていて、例えば、0.7系で導入予定のSecondary Indexも、もっと柔軟な指定ができるような実装が可能だと思っている。 ―― こうした恐ろしい事例は知っていたのか？その上でPARTAKEを実装する方法はどうやって学習されたのか？今回取り上げたNoSQLの制限は、理論としては知っていたがこれが実際のアプリケーションを作る上でどういう障害になるのかは身を持って経験したことはなかった。苦難の道であることはよく分かっていた。しかし制限があるとはいえ、その制限は考えれば色々と逃げ道があるということもPARTAKEを開発したことによって初めて分かってきた。最近は NoSQL がパフォーマンスが出ないRDBを代替するものとして、あたかも銀の弾丸であるかのような誤解が広がっているのではないかと思っており︵NoSQLを使うほどデータがある人はそんなにいないはずなのに、勉強会などはやたら人気があったり、NoSQLをdissる記事があんまりなかったりなど︶、そんなうまい話はないんだよということを示したかった。何度も同じことをくり返し言うが、NoSQLは一部のCriticalな問題領域を解くために作られたものであり、その問題領域に自分の問題が入っていないのであれば、研究以外の目的で手を出すべきではない。ほとんどの問題はRDBでも十分うまく行くし、おそらくRDBが一番うまく行く。 ―― 実際にNoSQLを使って実装したPARTAKEについて。 PARTAKEは、そんな制限の中でもアプリケーションとして成立するようにさまざまな工夫を加えている。特に、既存のイベント開催ツールに対する自分の不満点を補うことを中心に機能を開発した。まだ至らない点はたくさんあるが、非常にユニークな機能を持つアプリケーションになっていると思う。これは多数の人に使ってもらうことで、運用上の問題も見つけられればと思ってのことである。したがって、研究用に作ったとはいえToy Applicationにならないように作り込んである。今後の研究としては、バックエンドをGoogle App Engine︵BigTable︶やRDBにしたバージョンも作成し、比較をしていければ、と思っている。 PARTAKEはオープンソースでもある。これは、Cassandraを用いたアプリケーションの1つとして参照してもらいたいと思ってのことだ。また、現状つけたい機能に対して開発工数が取れていないため、共同開発者を募集している。ぜひ@mayahjpまでご一報を。

NoSQL3 from Shinya Kawanaka ︵追記 2017/12/5‥Partakeのサービスは終了しているので、リンクを外しました︶

参考記事

アジャイルソフトウェア開発手法やデザインパターンなど、ソフトウェア開発の分野の先進的な取り組みで知られるKent Beck氏はNoSQLが普及し始めた背景、そして今後の課題について触れています。 ●NoSQL登場の背景、CAP定理、データモデルの分類 NoSQLの登場は、﹁データベースといえばリレーショナルデータベース﹂という状況を大きく変えました。InfoQの記事﹁NoSQLの現状﹂は、こうしたNoSQLの現状を俯瞰し、整理するうえで重要な情報を提供してくれる記事になっています。