NoSQLを勉強した

ちょっとかじった程度で曖昧にNoSQLを理解していたので勉強した。
SQL（というかRDBMS）については、これまでそれなりに実務でもやっていたので理解しているつもりではあった。

これまでのイメージでは、NoSQLとは、

1. ACIDを保証しない。
2. リレーショナルな関連付けとデータの最適な保持（正規化）ができない。
3. 便利なSQLを使えない。
4. ただし高速らしい。

とわりとマイナスのイメージから理解していた。当初は、Hadoopあたりから発展した技術と勝手に考えていた。すなわち巨大データを（ペタバイトとか）をつかって分析を行うためによみ出しを重視して、ACIDを保証しないという理解をしていた。

今回勉強してもその理解は、あまり変わっていなくて「本当ならRDBMS(SQL)で間に合わせたいが、データが巨大すぎ、そのうえで高速な処理を求められるため泣く泣くRDBMSの利点をすてて、要件を満たす技術を作り出した。」

という理解です。

近年、クラウド技術が発展して、かつRDBMSもインメモリで動くようになっています。1クライアント（トランザクションといったほうがいいのかな）が1データ（ROW）を読み書きするだけならば、そして、蓄積された巨大データは別途分析するという要件ならば、

NoSQLという選択になるのかもしれませんが、上記のようなクラウドやRDBMS自体の発展に伴い、使用する局面は少なくなってくるのではないかと考えました。（複雑に絡み合うデータを取り扱うケースのほうが圧倒的に多いと考える）

ちなみにポケモンGoはGoogle Cloud Platformで動いているとので、選択したデータベースは、MySQLの派生DB(Google Cloud SQL)かなあと想像する（カスタムで全然別のデータベースも導入できるとは思うがスケールさせるのが大変そう）

NoSQLも大別すると４種類くらいのタイプがありそれぞれ得意不得意がある。

1. キーバリュー型：とにかく早い
2. カラム型：列単位でのデータ操作が得意
3. グラフ型：グラフというのは、関係性の意味で、複雑な関係性の検索・分析などリレーショナルデータベースで表現できないぐらいの関連付けをデータに紐づけられる（例としては道路網における最短ルート探索とか）
4. ドキュメント型：定型的な構造を持たないデータベース（Row毎にデータ構造を変えることができる）

なので要件によってNoSQLを使用していくことも十分考えられるが、既存のRDBMSがNoSQLの機能をどんどん取り込んでいっているので、先行き不透明という印象を持った。

しかしながら、調べていくうちに例えば、Radis（キーバリュー型にちょっとドキュメント型風味）、Cassandra（カラム型）、CouchDB（ドキュメント型）とかに興味を持った。

あとMongoDB（ドキュメント型）も人気があるようだ。

自分は元々オラクルやサイベース（懐かしい）を使ってたのでやはりSQLに親しみがあるが、上記のDBたちも少しづつ触ってみて評価できるようになりたいと思う。