読者です 読者をやめる 読者になる 読者になる

「RDBMS」と「NoSQL」の比較

【1】「RDBMS」- ACID特性

RDBMS(リレーショナルデータベース管理システム)は、ACID特性という概念に基づいて設計されている。
ACID特性とは、トランザクション処理において必要とされる4つの要素、Atomicity(原子性)、Consistency(一貫性)、Isolation(独立性)、Durability(永続性)を頭字語で表したもの。

■ACID特性
要素 説明
A:原子性
(Atomicity)
トランザクションに含まれるタスクが全て実行されるか、あるいは全く実行されないことを保証する性質。
C:一貫性
(Consistency)
トランザクション開始と終了時に予め与えられた整合性を満たすことを保証する性質 。
Consistencyは日本語では「一貫性」あるいは「整合性」とも呼ばれる。
I:独立性
(Isolation)
トランザクション中に行われる操作の過程が他の操作から隠蔽されることを指し、日本語では分離性、独立性または隔離性ともいう。より形式的には、独立性とはトランザクション履歴が直列化されていることと言える。この性質と性能はトレードオフの関係にあるため、一般的にはこの性質の一部を緩和して実装される場合が多い。
D:永続性
(Durability)
トランザクション操作の完了通知をユーザが受けた時点で、その操作は永続的となり、結果が失われないことを指す。

【2】「NoSQL」 - BASE特性とCAP定理

NoSQLはBASE特性という概念に基づいて設計されている。
クラウドビッグデータ処理において、中心的な概念となるのが「BASE特性」と「CAP定理」。

BASE特性とは、「基本的には常に利用可能で、常に整合性を保っている必要はなく、一時的に一貫性のない状態を許容して、結果的には整合性が取れている状態に至る」という特性。
インクトミの創業者、カリフォルニア大学バークレー校の計算機科学の教授エリック・ブリュワー氏が、
「ACID」とは対照的に、可用性や性能を重視した特性を持つ分散システムの特性を「BASE」という文字で表した。

CAP定理はブリュワーの定理とも呼ばれる。分散コンピュータシステムのマシン間の情報複製に関する定理。
ウェブサービスを想定して作られた定理。
2000年にエリック・ブリュワー氏によって提案され、その後、2002年にマサチューセッツ工科大学のセス・ギルバート氏、ナンシー・リンチ氏によって証明されており、定理として確立されている。(CAP定理 - Wikipedia)

■NoSQLのデータモデル
①Key-Valueストア ②Key-Valueストア ③ドキュメントDB
データ
モデル
Key-Value カラム指向(ワイドカラム) ドキュメント指向(JSON)
特徴 ・データアクセスが高速 
・小さい多数のデータの
 蓄積が得意
・一部のものは
 スキーマ定義が必要
・カラム指定での範囲検索、
 集計処理が得意
・ドキュメント毎に
 異なるデータ構造を持てる
・属性に対する検索・集計が可能
活用例 ・キャッシュサーバ
・ログ蓄積
・大規模データ処理
・ログ蓄積
・ログ分析
・ログ分析
・Webシステム
・オンラインゲーム
OSS memcached
・Redis
・Cassandra
・HBase
・MongoDB
■BASE特性
要素 説明
(BA)
Basically Available
基本的にいつでも利用できる。
(S)
Soft-State
常に整合性を保っている必要はない。
(E)
Eventual Consistency
結果的には整合性が保証される。

NoSQLの特徴を表している概念として覚えておきたいところ。上記3つの工夫をして、性能をスケールさせていることにより、ビッグデータを扱えるようになっている。

■CAP定理

定義:ノード間のデータ複製において、同時に次の3つの保証を提供することはできない。

保証 説明
C:一貫性
(Consistency)
全てのノードで同時に同じデータが見える。
A:可用性
(Availability)
単一障害など一部のノードで障害が起きても処理の継続性が失われない。
P:分断耐性
(Partition-tolerance)
任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。

CAP定理によると、
分散システムは「C」「A」「P」の3つの保証のうち、同時に2つの保証を満たすことはできるが、
同時に3つの保証すべてを満たすことはできないとされている。

CAP定理により、
データベース管理システムは「CA型」「CP型」「AP型」のいずれかのタイプに分類できる。
RDBMSは「CA型」、NoSQLは主に「CP型」または「AP型」となる。

■CAP定理によってデータベース管理システムのタイプを分類

タイプ 説明
CA型
(C:一貫性とA:可用性を重視)
データはいつでも利用可能で一貫している。
→単一データベースサーバ
CP型
(C:一貫性とP:分断耐性を重視)
データを分散しつつも整合性を保持する。
→整合性保持のため、複製中は全てのノードでデータ更新されるまで
 ロックをかけて不整合を阻止する。
→ロックがかかっている最中はAvailableではない。
AP型
(A:可用性とP:分断耐性を重視)
データは分散され、いつでもデータにアクセスできる
→データ複製中は不整合な状態になり得る。
→Cはある程度妥協する。(Eventual consistency)

■各タイプ別にデータベース管理システムを分類

タイプ データベース管理システム
CA型
(C:一貫性とA:可用性を重視)
リレーショナル型:OracleMySQLPostgreSQLSQLServer
カラム指向:Vertica
CP型
(C:一貫性とP:分断耐性を重視)
Key-Value:Redis、memcached、Scalaris
カラム指向:BigTable、HBase
ドキュメント指向:MongoDB
AP型
(A:可用性とP:分断耐性を重視)
Key-Value:TokyoTyrant/Cabinet、Dynamo、Voldemort
カラム指向:Cassandra
ドキュメント指向:SimpleDB、CouchDB、Riak

f:id:masawan-guitar:20160814153239p:plain

(参考文献)
RDB技術者のためのNoSQLガイド』秀和システム

(参考URL)
RDBMSとNoSQLの周辺技術や考え方の整理
http://tanakakns.hatenablog.com/entry/20140502/1399019336
NoSQL、CAP定理、BASE、Eventual Consistencyについて深く考えてみた
http://shunichi-arai.blogspot.jp/2012/09/nosqlcapbaseeventual-consistency.html
IoTに適したNoSQL・分散Key-Valueストア
https://thinkit.co.jp/story/2014/09/25/5280?page=0%2C1
Visual Guide to NoSQL Systems
http://blog.nahurst.com/visual-guide-to-nosql-systems
CAP定理-wikipedia
https://ja.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
NoSQL登場の背景、CAP定理、データモデルの分類
http://www.publickey1.jp/blog/10/nosqlcap.html
12年後のCAP定理: "法則"はどのように変わったか
https://www.infoq.com/jp/articles/cap-twelve-years-later-how-the-rules-have-changed
CAP定理
http://namihira.hatenablog.com/entry/2013/12/19/233853
クラウドでの新しいACID、そしてBASEトランザクションとCAP定理
http://jyukutyo.hatenablog.com/entry/20090430/1241174854

広告を非表示にする