NoSQLの種類とNoSQLのアプリケーションの例について

NoSQLは、一人のユーザーが書き込んでから他の人が参照するデータに反映される間には少し時差があるけどいいだろうというゆるい整合性(結果整合性)で動いているんだ、といった話をこちらあたりで読んでなんか面白かったので少しだけメモします。

RDBMSとNoSQL

RDBMSは即時での一貫性を求められる基幹システムや在庫管理システムなどをはじめとしてWebアプリケーションのデータベースとして広く採用されています。RDBMSはデータの整合性を保証する代わりにトランザクションのコミット前に通信や待ちが発生するため、アプリケーションがたくさんのリクエストに応える必要が生じるにつれ、パフォーマンス的に厳しいものが出てきました。

NoSQLはこのRDBMSの状況の対抗策として登場したものとなります。ざっくりいうと、ネットワーク上でデータを分散して管理するシステムにおいて、RDBMSの整合性を保証する代わりに遅い、という部分の逆をいく、みたいな形で作られたものであって、じゃあ逆ってなんなのだ、という話になります。

CAP定理

ネットワーク上の分散システムの性質に関して「CAP定理」*1があります。CAPのそれぞれの文字は

Cが Consistency（整合性） = 複数のシステムのノード間で読み書き結果が矛盾しない
Aが Availability（可用性） = (特に更新)停止しない
Pが Partition Tolerance（ネットワーク分割耐性） = ネットワークの一部に障害が起きても動作可能(SPOF（単一故障点）を持たない)

から来ています。

CAP定理は、ネットワーク上の分散システムは、この三つのうち二つしか満たすことができないというものです。後に、提唱者のBrewer氏自身により、CAP定理の過度な単純化は問題であるとされ、割合やバランスの問題であるという具合に訂正されています *2 。

しかし、ここでは単純のため、RDBMSを含むデータベースがどの性質を満たすのか、どういったアプリケーションがあるのかを考えてみます。

C, A, P	アプリケーションの例	データベースの種類
C(整合性), A(可用性)	銀行口座など，データの矛盾が許されないリアルタイム処理	RDBMS, Vertica(Column-Oriented)
C(整合性), P(ネットワーク分割耐性)	検索エンジンのインデックス処理など，データの矛盾が許されない非リアルタイム処理	MongoDB(Document-Oriented), memcached(K-V), redis(K-V)
A(可用性), P(ネットワーク分割耐性)	ユーザーに近く、ダウンタイムがないビジネスで利用する。ショッピングカートやSony PlayStationネットワークなど	Cassandra(Column-Oriented)

CA以外、正直、データベース=RDBMS脳の自分にとってはわかりにくいですが、たとえば、Googleの検索エンジンの更新処理やソシャゲのランキング処理がユーザーの私達から見て秒単位でリアルタイムである必要はなさそうです*3。

また、APについては、整合性より、書き込めることが重視されていますが、ゲームのネットワークであるSony PlayStationネットワークが銀行のネットワークシステムより整合性を捨てて速さを優先する、と言われたら、そこ速さがなかったらゲームにならないもんなーと納得したりしますが、実際は個々のものについて触れたり触れなかったりしてその折に考えることになるのでしょう。

現場からは以上です。