「RDB技術者のためのNoSQL」を読んだ
最近NoSQLを使う機会があり、適当に使っています。ただいままでRDBを中心にデータベースに触れてきたためできることの違いで混乱しています。
webで情報を集めていますが、なかなか体系的に理解できなかったため書籍を購入しました。
最初のNoSQLの説明から個人的には衝撃的で学びの多い本になったと思います。
NoSQLはバズワード
NoSQLという言葉を気にせず仕様してきましたが、厳密には定義がないことに衝撃を受けましたね。
スキーマを定義しなくてもいいデータベースに関してNoSQLと判断して言葉を使っていましたが、定義が広いものでした。
KVSやドキュメントDB,グラフDBという単語を使用するほうが適切という感じだったため、今後の呼び方にちょっと困っています。
KVSはよくみる単語ですが、他はあまり見ない気がします。
速度がでるらしいから移行するは間違い
アンチパターンにはまりかけているところかもしれないです。
ユースケースとして、有効なパターンはありRDBより大量のデータを扱う速度が早いケースはあるが、管理システム系はRDBのほうがSQLでのアクセスを含め機能が豊富なことを理解する必要があります。
ユースケースをちゃんと理解してRDBではパフォーマンスを担保できない場合に利用を考えるところから始めた方がいいと思いました。
モックで活躍
サンプルを作るスピードが早くなる。という部分で、なぜ？？と思いましたが、RDBのスキーマを考えるところがない状態で進められることはたしかにメリットだと感じました。
ただサンプルの場合、直接データを入れた状態でつくるためDB周りまでつくるか疑問ではありましたが、DBまでやろうとする場合には固定されていない設計はありがたいですね。
それぞれのミドルウェアの特徴の説明がある
ミドルウェアをいくつか紹介しており、特徴や機能の説明が記載されています。
こういうミドルウェアの紹介はかなりありがたく、いままで知らないミドルウェアを多く知る機会になることが多いです。
ユースケースを理解する
ユースケースを理解して使えれば有用。と言ってしまえばすべてのことに当てはまってしまいますが、まず理解が必要な分野だと思いました。
RDBはある意味汎用性が高いためデータを保存していろんな条件で抽出したい場合に使えばいいため理解することが簡単でした。
ユースケースの例示もいくつか理由を添えてしっかりと書かれているため、理解する上で体系化しやすいと感じました。
早めに読んでおけばよかったです。
読んでなかったことは仕方がないことですが、定期的に知らない分野の本を読んでおくときっかけが作れそうです。まぁ、苦労しているからこそ内容について熟読しているわけですが、ざっと本の内容を把握しておけば必要な時にしっかり読むことができると久々に実感しました。
データの設計についても思うところが出てきたので、一回システムを作り直すと思います。さぁ、がんばろう。
