「RDB技術者のためのNoSQLガイド」を読んだ

Qiita ぐらいの規模のサイトを開発していると、どうしてもデータ量の上限はたかが知れてくる。圧倒的なトラフィックをさばくために日夜格闘するということはないし、データベースが厳しくなってきても RDS のスケールアップで十分に対応できてしまう。そんな感じなので NoSQL といっても Redis をキャッシュ目的で使うくらいのことしかしたことがない。

僕はエンジニアは知っていることが大事だと思っている。ハンマーしか持っていない人は全ての問題を釘だと思ってしまうように、ブラウザ上でのプログラミングしか知らない人は何でもブラウザで解決しようとしてしまうかも知れない。

そういう観点で言えばデータベースとして RDB しか知らないのは非常にまずいことだと思う。簡単な話がデータを永続化するとなったら何も考えずに RDB を選んでしまうのではないか、ということだ。もちろん RDB の向き不向きはある程度把握できているつもりなので、向いていないことに RDB を使うことはないと思うが、RDB でも悪くはないけど…というような場面でより better な選択肢を選択できないのではないか。一度 RDB の外の世界を包括的に学んでみるべきなのでは？

そんな感じのことを考えて、この本を読んだ。

RDB技術者のためのNoSQLガイド

NoSQL はバズワードであり、その実態は多種多様だ。本書では大雑把に KVS, ドキュメント DB, グラフ DB という分類を扱っているが、これらを

• ターンアラウンドタイム重視なのかスループット重視なのか
• スケールするのかしないのか（≒扱っているデータモデルの複雑さ）

という 2 軸で分類することで RDB との関係性を説明している。ここは「RDB技術者のための」とうたうだけあって、結構分かりやすかった気がする。

特に関心したのが、各種 NoSQL プロダクトが機能拡張で今までできなかったことができるようになり境界線が曖昧になってきていることを指摘したうえで

このように、実際のデータベースは生まれたエリアから出ようと必死です。（略）しかし忘れてはいけないのは、それぞれのデータベースの根幹がどの分野にあるかです。どんなに枝葉を広げて着飾っても、アーキテクチャの根幹を変えることはできないため、枝葉の機能は中途半端になるでしょう。

p.87

という箇所。これは本当にその通りで、RDB で言えば B+ 木というデータ構造をインデックスを使っている限り、 B+ 木でできないことはどんなに頑張ってもできないのだ。それと同じで、各種 NoSQL がもともともっているデータモデルの限界は、それ自体を捨てない限りやはり大きな課題としてついてまわる。逆に言えば、そういう基礎的なところの理論を抑えれば、息の長い知識になるということでもある。

みたいな抽象的な話があったあとで、

• Redis
• Cassandra
• HBase
• Amazon DynamoDB
• MongoDB
• Couchbase
• Microsoft Azure DocumentDB
• Neo4j

という各種データベースの具体的なデータモデルについて 1 プロダクト 1 章という分量でひたすら紹介されていく。そもそも本書はこれまで RDB しか触ったことがない SIer の人が技術選定する助けになることが主題となっている。一人の著者が全部紹介しているのではなく章ごとに対応するデータベースのスペシャリストの人が担当していたり、機能要求だけでなく非機能要求にも着眼して全てのプロダクトで同じ項目について言及していたりと、 NoSQL を銀の弾丸として扱わない誠実な印象を受けた。

1 つのプロダクトについて詳しく知りたいのであれば、それのドキュメントを読むのが一番いいが、この本では一段抽象化された立場から各種データベースを横串で比較できるように書いてくれているので、それぞれの違いが際立って見えてくる。気がする。

簡単な CRUD 操作のやりかたも解説されているが、この点に関しては中途半端なのでだいたい読み飛ばした。

2016年出版なので多少の陳腐化は始まっているはず。しかし、↑でも書いたように、大事なのはそのコアになっているデータモデルやアーキテクチャだと思う。そういう意味で、深く知るには足りないが、概要を把握するにはいい本だと思った。

ひとまず、データベースを選定する必要がでてきても、何も考えずに「RDB にしとくか」とはならない程度の知識は得られたと思う。