RDBMSとNoSQLの周辺技術や考え方の整理
RDBMSとNoSQLの比較
RDBMSはACIDという考えに基づいて設計されている。
対して、NoSQLはBASEという考えに基づいて設計されている。
■ACID
| 項目 | 説明 |
|---|---|
| Atomicity（原子性） | トランザクションが実行されたか、まったく実行されてないかという状態を保つこと |
| Consistency（一貫性） | トランザクションがDB内で整合性が保たれること |
| Isolation（独立性） | トランザクションが他のトランザクションに割り込まれないこと |
| Durability（耐久性） | 障害時などにトランザクション前か後に整合性を持って保たれること |
■BASE
| 項目 | 説明 |
|---|---|
| Basically Available | いつでもデータにアクセスできること |
| Soft-state （※） | 状態の厳密さを追求しない緩い状態・データ管理 |
| Eventually consistent | 途中はともかく最終的に一貫性・整合性をとること |
※Soft-stateに対してHard-stateがあり、これはマスタ側の更新は確実にレプリカに同期で反映されること。
※Soft-stateは、マスタ側の更新はレプリカに非同期で反映されること。マスタ・レプリカ間にキューがあったり、レプリカ側が定期的にマスタに更新を問い合わせたり。高負荷時の耐性が高くなる。
大量のデータを扱うシステムにおいてRDBMSには
・可用性
・データ量増加に伴う性能劣化
・スケーラビリティ
という課題があった。
そこでRDBMSのACID特性からCとIを緩めたBASEという考えで上記の課題解決を図ったものがNoSQL。
全ていいとこどりはできないのか？
■CAP定理
分散システムは
- Consistency（一貫性）
- Availability（可用性）
- サービスがいつでも利用できる事
- クライアントは必ずデータにアクセスできる
- Partition Tolerant（NW分断耐性）
- 全面的なNW障害以外の障害が発生しても全体が間違った結果を返さない
- データを複数サーバに分散して保存できる
の3つの内、2つまでしか満たせないという定理。（証明済みらしい）
つまりCAP定理によるとシステムは「CA型」「CP型」「AP型」の3タイプに分類できる。
また、RDBMSは「CA型」、NoSQLは「CP型」か「AP型」になる。
※ただ、（筆者も最近思っていたが）「CAPから2つしか満たせないと考えるのはミスリード」という考えもある。
※CAPそれぞれを「できる」「できない」に明確に分けられるほど単純ではない→参照：http://www.slideshare.net/takahikosato/dbtechshowcaseosaka2014
※NoSQL製品によって様々な設定が可能ので、CAPそれぞれのレベルを「トレードオフ的に」変更が可能だというのが筆者の体感。
■CAP定理による分類
| タイプ | 説明 |
|---|---|
| CA型 | データはいつでも利用可能で一貫している |
| 単一データベースサーバ | |
| CP型 | データを分散しつつも整合性を保持 |
| 整合性保持のため、複製中はすべてのノードでデータ更新されるまでロックをかけて不整合を阻止 | |
| ロックがかかっている最中はAvailableではない | |
| AP型 | データは分散され、いつでもデータにアクセスできる |
| データ複製中は不整合な状態になりえる | |
| 大規模分散システムはAPを満たすことが重要 | |
| Cはある程度妥協（Eventual consistency） |
Consistencyについては３つの考え方がある。
- Eventual Consistency
- 結果整合性
- 更新処理の後、即時にマスタ‐レプリカ間で整合性を取らないが、非同期で後々、整合性・一貫性を取るという考え方
- 更新されていない古い値を読み出してしまう可能性がある（スループット大、レイテンシ小）
- Strong Consistency
- 強い整合性
- 常に最新の書き込みを反映した値を読み出せる（スループット小、レイテンシ大）
- Causal Consistency
- 因果一貫性
- レコード（CRUDの最小単位の意味）単位でCURD命令の順序関係がコントロールされ、マスタ‐レプリカ横断で保障されるモデル
■各分類の得意分野
| タイプ | 得意分野 |
|---|---|
| CA型 | トランザクション処理（金融分野、在庫管理、マスター原本） |
| CP型 | バックエンド/Batch処理（給与計算、会計計算、各種BI、Hadoop、OLAP） |
| AP型 | Webフロント寄り（商品情報、ユーザ情報、権限情報、各種Log、OLTP） |
■各分類の製品
| タイプ | 製品 |
|---|---|
| CA型 | Oracle、MySQL、PostgreSQL、AsterData、Greenplum、Vertica |
| CP型 | BigTable、HBase、Hypertable、MongoDB、Terrastone、Scalaris、Oracle NoSQL、Memcached、Redis |
| AP型 | Voldemort、KAI、TokyoTyrant/Cabinet、CouchDB、Cassandra、DynamoDB、Riak、Couchbase |
※WikiによるとCouchbaseはCA型らしい。。。
- 未分類
- Flare、ROMA
- メモ
- Voldemort、KAIはDynamoのクローンらしい
■RDBMSとNoSQLの比較
| 観点 | RDBMS | NoSQL | NoSQLの強み |
|---|---|---|---|
| モデル | リレーショナル、行指向 | KVS、列指向、ドキュメント型、グラフ型等 | ？ |
| スキーマ | 定義固定 | スキーマレス | ○ |
| 一貫性 | 厳密 | 緩い | × |
| 拡張性 | スケールアップ、性能劣化大 | スケールアウト、性能劣化小 | ○ |
| 耐障害性 | 向上が高コスト | SPOFがなく、向上が低コスト | ○ |
| IF | SQL | API | ？ |
※SPOF・・・Single Point Of Failure。単一障害点。
データモデル
データベースのモデルには「行指向」「KVS」「列指向」「ドキュメント型」「グラフ型」等様々ある。
「行指向」はRDBMSで、その他はNoSQLに該当する。
行指向
内部で行単位でデータを保持するモデル。
- 少数の行に対する多くの列取得に効果的
- 行あたりのサイズが小さい場合は、行全体を1度のディスクシークで読み取ることができる
- 少数の行に対する多くの列更新に効果的
- 1行全体の書き出しを1度のディスクシークで行うことができる
- 製品
- Oracle、MySQL、PostgreSQL、AsterData、Greenplum
列指向
内部で列単位でデータを保持するモデル。
- 大量の行に対する少数の列の集約処理が効果的
- 列数が少ないほど読み込むデータ量を減らすことができる
- 全行に対する少数の列の一括更新が効果的
- 新規に列を作成し、以前の列データと置換することで他の列へのアクセスを回避できる
- データが列ごとにまとまっているので、列の追加が容易
- 製品
KVS
Key-Value Store。その名の通り、Key-Value形式でデータを保持するモデル。
- Key指定のみの検索機能しかない分CRUD性能は圧倒的
- 製品
- Oracle NoSQL、Memcached、Redis、DynamoDB、Voldemort、Flare、ROMA、KAI、TokyoTyrant/Cabinet、Scalaris、Riak
ドキュメント型
- フィールドの数や長さに特に制限はない
- JSONの各項目指定で検索やインデックスを張る機能を持つものがある
- 登録・更新性能はKVSに劣り、検索性能はRDBMSと同等？
- 製品
- Terrastone、MongoDB、CouchDB、Couchbase
NoSQL一覧
http://nosql-database.org/
参考：
http://www.slideshare.net/yutuki/cassandrah-baseno-sql
http://www.slideshare.net/mizzy/no-sql-23136978
http://tagamidaiki.com/nosql-thorough-dissection-at-hikarie/
http://www.infoq.com/jp/news/2013/04/NoSQL-Benchmark
http://d.hatena.ne.jp/cypher256/20121013/p1
http://gihyo.jp/dev/clip/01/orangenews/vol61/0003
http://www.slideshare.net/ShinyaKawanaka/nosql3
http://hivecolor.com/id/12
