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

2010年12月21日

データベースの世界でいま注目されているのがNoSQL。特にキーバリュー型データストアは、グーグルのBigTable、FacebookやTwitterが内部で利用しているCassandraやAmazonクラウドが提供しているSimpleDBなど、すでに実際に使われ始めています。

ではそのNoSQLをリレーショナルデータベースの代わりに使ってシステムを構築するとどうなるのか? 身をもって体験したことを記したShinya Kawanaka氏によるプレゼンテーション「間違った方向にCassandraを使ってみた」が公開されています。

NoSQLを用いたシステム構築は、リレーショナルデータベースによる構築どう違うのか? とても分かりやすくまとめられています。ご本人の承諾もいただいたので、その内容を紹介しましょう。

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

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

NoSQL fig1

具体的には、イベントを告知したり参加者を募って申し込みができる開催支援ツール「PARTAKE」を、NoSQLをベースにして開発した際の体験。

バックエンドはApache Cassandra 0.6系を用い、リレーショナルデータベースは使用せず。

まずは1つめの恐ろしい事例。

NoSQL fig2

「NoSQLはスキーマレスだから、データをリレーショナルデータベースより柔軟に扱えるよね?」とよく言われるが。

「ハァ?」 「(ある意味)迷信です」

例えば、検索対象を増やしたい場合。イベントの開催日時で検索したいとか。

リレーショナルデータベースでは、その列にインデックスを設定すればオーケー。

NoSQL fig3

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

NoSQL fig4

恐ろしい事例2つ目。

NoSQL fig5

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

NoSQL fig6

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

恐ろしい事例3つ目は、数さえ数えられないCassandraさん。

NoSQL fig7

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

NoSQL fig8

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

まとめ。「NoSQL = Domain Specific Database」(目的特化型データベース)だ。

NoSQL fig9

ただし、それでも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の登場は、「データベースといえばリレーショナルデータベース」という状況を大きく変えました。InfoQの記事「NoSQLの現状」は、こうしたNoSQLの現状を俯瞰し、整理するうえで重要な情報を提供してくれる記事になっています。

あわせて読みたい

NoSQL データベース Cassandra




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本