NoSQL
Overview
NoSQL（Not Only SQL）と呼ぶ。
NoSQL 歴史
私たちは過去数年間にわたって，従来のデータベース技術の代替となる，いわゆる NoSQL をめぐる議論が日増しに高まっていくのを目の当たりにしてきた。高性能トランザクションに関するワークショップでも，あるいはこの InfoSQL でも，NoSQL は今や REST や SOA などと同じように無視しがたい存在となっている。2009年の議論や，さらに以前の 2007 年に Postgres と Ingres のオリジナル開発者のひとりである Mike Stonebraker 氏による RDBMS 終焉の予想に見られるように，初期の議論は従来の RDBMS を NoSQL 実装で置き換えることを目指していた。しかし Twitter や Amazon といった REST ベース の企業が NoSQL の強力な擁護者となるにつれ，REST と NoSQL という２つの技術の併用が必然的な流れとなったのだ。
NoSQL メリット
NoSQLのメリットとして、処理速度が速い。
NoSQL デメリット
- データの一貫性が保証されていないため、データの更新や削 除処理が頻繁に発生すると、データの整合性が保証されない場合もある。
- NoSQLはSQLを使用しないため、複雑な検索ができない。単純なデータを高速で登録および読み取りは得意だが、複雑な処理は不向き
RDBMSとNoSQLの違い
- RDBMS
- データの一貫性やSQLにより、更新処理や複雑な検索処理が可能
- NoSQL
- データの整合性を犠牲に、拡張性と分散処理に優れ、大容量データの高速処理が可能
パフォーマンスを維持するには
キーと値のペアではキーは一意でなければいけない。
パフォーマンス上の理由から短いキーがより効果的。
NoSQLの種類
いくつか種類がある。
- キーバリュー型: Redisやmemcached
- 列指向型（カラム指向型）: CassandraやHBase
- グラフ型
- ドキュメント型
キーバリュー型
キーバリュー型はキー・バリュー2つの要素を組み合わせたシンプルなデータモデル。 キーとバリューは1対1で管理されており、単純な格納と抽出のみの構造 構造上、キーバリューは結合処理ができない 複雑な検索処理には不向き
列指向型(カラム指向型)
カラム指向型は、キーバリュー型に列（カラム）の概念を追加したデータモデル 行に付与されたキーが複数のカラムを保持し、必要に応じてカラムを追加することも可能
ドキュメント型
各NoSQL 深堀
参考URL
NoSQL
NoSQLが生まれた背景
ビックデータの登場により、従来のRDBだけでは充分な処理ができなくなってきたことがNoSQL登場の背景にある。
ビッグデータの定義は色々ありますが、ここでは3V(Volume/Velocity/Variety)を満たすものをビッグデータと呼びます。
VolumeとVelocityの問題を解決するためにNoSQLが必要
Volume(大量データ)とVelocity(秒単位で大量データ)に関する問題を対処する場合、スケールアップ(メモリ増加、コア数増加、SSD化)とスケールアウトの2通りの方法がある。 しかしながら、スケールアップは物理的な限界があるし、RDBのスケールアウトは一般的に難しい。 NoSQLは一般的にRDBよりもスケールアウトが容易に行える
Varietyの問題を解決するためにNoSQLが必要
Variety(非リレーショナルな多様なデータ)をRDBで扱うのはそもそも辛い。
NoSQLとRDBの使い分け
サービスはビッグデータを扱う性能が求められるものか？データはNoSQLで扱えるものか？を自問自答する。YesならNoSQLを採用する。 どうしてもリレーショナルデータにできないデータなのか トランザクション管理する必要のないデータなのか 最悪揮発しても問題ないデータなのか そうでなければRDBで管理する。RDBで管理できるものは極力RDBに寄せちゃう。 ここは個人によって考え方が違うと思う 不必要にNoSQLを採用するとシステムの複雑性がぐんと上がるので慎重に採用すること。