NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance - CNET Japan（情報元のブックマーク数）
SQLとNoSQLの話。これからの技術の芽を摘むのは良くない。だけど多分クラウドらしいとかAjaxらしい、ソーシャルゲームらしいアプリってのはNoSQLとか使わないとやってられないんだろうなぁ・・・って最近思った。
OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance - CNET Japan
時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによる追い出しや再起動でデータが失われるという、まさにキャッシュとしての性質自体の弱点から、マイルドな永続化による最低限のデータ保全と平準化されたウォームアップ性能が求められるようになってきました。
NoSQLの流行は、これら二つの流れの結節点に生まれたものであるために、さまざまな誤解を生み、議論を巻き起こしてきました。
よくNoSQLを持ち上げる理由に「SQLデータベースは性能が低い」というものがあります。
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance - CNET Japan
これは、多くの場合、まったくの間違いです。驚くなかれ、何一つディスクに書かないはずのMemcachedでさえ、用途（データサイズ）や使用条件（クライアントライブラリなど）によっては、きちんとチューニングされたMySQLに及ばないケースは珍しくありません。もしデータベースサーバが一台しかない環境なら、そのマシンにはMemcachedを乗せず、ありったけのメモリをMySQLに割り当てるほうが、メモリ容量あたりの性能向上効果は高いでしょう。
では、NoSQLを採用することのメリットとはなんでしょうか？
そもそも、なぜ、我々はデータベースを必要としているのでしょうか？データベースがないと、何が困るのでしょうか？
データの保全というのはもちろんですが、実はそんなことよりもっと原始的で、基本的な要求があるはずです。
それは、プログラミングにおける「グローバル変数」としての用途です。
現状の一般的なウェブ・アプリケーションのアーキテクチャでは、たった一個の変数（たとえばアクセスカウンター）を複数のサーバ・インスタンスから共有したい、というような簡単なことでさえ、データベースを経由しなくてはならず、スキーマの追加・変更を伴ないます。このことに業を煮やした経験はないでしょうか？
この問題を解決するために、Memcachedを使っている人たちがいます。しかし、Memcachedはキャッシュですから、いつそのデータが消えてもいいように配慮したコーディングをする必要があります。その結果、アプリケーションコードが複雑になるだけでなく、結局は同時にデータベースにもデータを書くはめになり、それだったらそのままデータベース使ったほうがいいじゃん、ということになりがちです。一見簡単そうなんだけど、実用レベルでは全然気軽じゃなかった、というオチです。
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance - CNET Japan
つまり、Memcachedだと「データを書くときにはMemcachedとDBの両方に書く」「データを読むときにはまずMemcachedを読み、なければDBに問い合わせてMemcachedにも書く」という、まるでデータベースの実装がアプリケーション側にはみだしてるような状況で、あまり幸せになれなかったのが、そのへんの面倒をみてくれるエンジンがあれば、ようやく「Memcached的なシンプルな入れ物」をグローバル変数のプライマリストレージとして気軽に使える現実味が出てきたのです。
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance - CNET Japan
