職場で使うかは未定ですが知識は入れておかないとと思って。

※スケールアウトについて書きますが、NOSQLと書いてあるとおり、データストレージに関する話です。 APサーバー側は触れません。

http://qcontokyo.com/tokyo-2009/pdf/GeneralSession-Day2-Maruyama.pdf

既存の手法（RDB）の問題点

多数のアクセス（書き込み）を効率的に捌けない。

なんとかさばこうとすると、かなり高いマシンを用意する必要がある。 （スケールアップ）

解決策

複数の汎用機で代替させる。 （スケールアウト）

ハードに頼るのではなく、ソフトで対応する。

その際に生じる問題

マシンの台数が増えると、マシン・ネットワークエラーの確率が無視できなくなる。

解決策

→NOSQLと分散技術

複数台でデータの整合性を保つのが難しくなる。

解決策

→NOSQLとCAP定理

NOSQLとは？

厳密には、RDB以外。

ざっくりというと、複数台前提の用途特化型DB

シンプルで十分な場合。

CAP定理とは？

C・・・Consistency

A・・・Availability

P・・・Partition-tolerance

CA・・・全てのデータはいつでも矛盾がなくアクセスできる。ただしスケールアウトしない。（RDBなど）

AP・・・エラーが起きても常にアクセスできるが、データの整合性は保証しない（Dynamoなど）

CP・・・マスターで複数台を管理し、大量に捌ける。マスターから外されたらアクセスできない。（Google Tableなど）

acidとbase

RDBがacidと思えば良いかな。

ACID・・・Atomic Consistency Isolation Durability

クラウドでは、可用性も分散も必須。 すると整合性を弱めるしかない。

BASE・・・Basically Available Soft-state Eventual Consistency

そもそも、物理的に距離が離れていたら結果整合性に頼らざるを得なくなる。 （東京で書き込みを行う際にアメリカまでLockの命令を飛ばして帰ってきてから更新して、それが終わったらまたアメリカへ完了を通知して、、、なんてやってられない。）

※BASEの実現方法として、書き込みをQueueに積んでおく。読み込むデータを非同期レプリケーションして古いものを許容する。の二種類があると思う。 前者はPrimary Keyを持つものなどに注意が必要。（TimeStamp VectorClockなどで処理する方法がある。）

用途別のDBMS選び方の例

整合性重視の場合

例：商品の購入処理・オンラインゲームの敵の体力など。

有用：トランザクション・CAS特性を持ったもの 単体で動くもの。

DBMS例：RDB Hibari

拡張性重視の場合

例：突発的なアクセス増・毎日数TBのデータ蓄積

有用：コンシステンスハッシング マルチデータセンター対応 シャーディング

DBMS例：Cassandra Riak Dynamo

柔軟性重視の場合

例：ユーザーが自由に配置していくようなもの？

有用：ドキュメント指向

DBMS例：MongoDB CouchDB

（後日追記する。）