RDBとの違いとかあんまりわかっていなかったのでメモ
RDBの限界
スキーマの限界
- 多種仕様なデータや、ネストが深いデータのテーブルを設計するの大変
- 最近の高ベロシティの要望で、それを高頻度に変更していくのはもっと大変
- そもそもJSONやXMLでもらったデータとか、データ構造が不定だったりすると、テーブルに乗っけられない
スケールアウトの限界
- 複数マシンでRDBを管理するの大変
- レプリケーション大変
- リードレプリカつくるとか、テーブル分割とか手もなくはない
- k8sのような分散システムを想定した設計ではない
そこでNoSQLですよ
NoSQL = Not Only SQL
NoSQLの特徴
- スキーマ定義なしでデータの保持が可能(スキーマレス
- 速度やスケーラビリティ重視
- その分、 リレーションを持たない
- その分、 トランザクションがない
- 最近はトランザクションをサポートしているNoSQLも多い
NoSQLといっても色々ある
- KVS
- ドキュメントDB
- グラフDB
今回は、KVSと、ドキュメントDBについて解説
KVS
Key Value Store
- 名前の通りキーと値の1対1のデータ構造
特徴
シンプル
なので大量データ読み書きや分散システムに向いている
- データ読み書きが高速
- 水平展開が簡単
複雑なことはできない
- データ構造は、単一値か配列くらいまで
- なので、複雑なデータ処理はできない
使いみち
- webアプリのセッションストア
- RDBMSのキャッシュ(SQLをキーにする
主な製品
- redis
- memcached
- Amazon ElastiCache
- google BigTable
ドキュメントDB
保存するデータ構造が自由なデータベース
- 大抵はJSONやXMLでデータを保存する
特徴
スキーマレス
- 複雑な階層構造を意識してスキーマを設計しなくて良い
- 頻繁な構造の変更に追従しやすい
KVSよりは、複雑なデータの保持や検索ができる
使いみち
- 複雑な階層構造のデータの保持(電子カルテ、色々な情報が付く商品データなど)
- 頻繁に仕様が変わるデータの保持(API、高ベロシティのアプリ開発とか)
デメリット
- 全文検索が弱い(らしい)
- 並列展開しない場合、RDBよりも検索速度が遅い
- 結合に制約があるため、あまり複雑な検索はできない
主な製品
- MongoDB
- Amazon DynamoDB
どういうふうにRDBと使い分けるの?
それぞれ特徴を生かしている分、メリット、デメリットも明確なので、要件に応じて使い分けるのが得策
- 超大量のデータをすばやく制御したい場合は、NoSQL
- データのキャッシュはKVS、複雑なデータの保持だけドキュメントDB
- 逆に複雑なクエリ、明確なスキーマ、トランザクションが重要な場合はRDB
MySQLやPostgreSQLもドキュメントDBやKVSをサポートしているので、一部テーブルだけそちらに移行するのも良い
- NoSQLもRDBMSも、それぞれお互いの機能をどんどん追加している段階なので、最新の情報をもとに決めたほうが良い
