CAP定理とデータベース
この記事はMikeTOKYO Advent Calendar 2013の3日目です。
年の瀬に何か面白い内容のブログを書いてと言われて書けるほどネタを持っていませんが，今年は何かとデータベース周りで調べることが多かったので，最近流行りのデータベースを紹介したいと思います．
０．CAP定理とは
整合性（Consistency），可用性（Availability），分断体制（Partition Tolerance）は，分散型データベースシステムの三大要件であり，頭文字をとってCAPと総称されています．
分散システムにおいては「３つのうち最大２つしか満たすことができない」という定理です．
※ここでは分かりやすさを優先したいのでCAP定理自体の正当性の話はしません．
１．RDBMS
CAP定理でいうとCAを満たすデータベース群であり，関係モデルに基づいたデータベースです．
データベース＝リレーショナルデータベースを指すことが多いです．
MySQL，PostgreSQL，DB2，Oracle Databaseなど多くのデータベース管理システムがあります．
１−１．MySQL
世界で最も普及しているオープンソース・データベースと言われているデータベースです．
CAP定理でいうとCAを満たしているデータベースです．
他のRDBに比べてMySQLのユニークなのは検索が高速なMyISAMストレージエンジンです．
最近ではInnoDBも高速化されてあまり選択されないことも多いようですが，個人的にはトランザクションがないのでシーケンシャルなIDを発行するテーブルなどに使えて非常に助かっています．
使用例は上げるとキリがないですが，ウィキペディアやモバゲー（DeNA）などかなりアクセス数が多いアプリケーションでも利用されています．
参考：http://www-jp.mysql.com/:MySQL
１−２．PostgreSQL
MySQLと同じくCAP定理でいうとCAを満たしているデータベースです．
オープンソース・データベースであったりすることからMySQLとよく比較されています．
数年前までは，MySQL以上のシェアを超えていましたが，ここ数年で抜かれてしまいました．
個人的には，あまり使ったことがないので魅力を伝えきれませんが，PostageSQLの豊富なデータ型や再帰クエリなどはちょっと使ってみたいです．
参考：http://www.postgresql.jp/:PostgreSQL
２．NoSQL
最近，RDBMS以外のデータベース管理システムとして登場したデータベースの総称としてNoSQLと呼ばれるデータベースが多く登場してきました．
一言にNoSQLといってもその構造や特徴などは大きく違います．
ここでは，それぞれの特徴を簡単に説明します．
２−０−１．データモデル
NoSQLには様々なデータモデルが存在します．
実際のデータベースの紹介をする前に，簡単にデータモデルの紹介をします．
２−０−１−１．ドキュメント指向型
ドキュメント指向型は，JSONやXMLのようなデータ記述を用いてデータを管理しています．
２−０−１−２．キー・バリュー型
そのままですが，「キー」とバリューという組み合わせでデータを管理しています．
２−０−１−３．カラム指向型
行キーが複数のカラムを持つようなデータ管理をしています．
イメージしにくいかもしれませんが，強引にイメージする方法としては，いわゆるRDBでいうところのカラムが行によって異なるような形です．
２−０−２．アーキテクチャ
NoSQLはデータモデルも違いますが，アーキテクチャも様々です．
２−０−１−１．マスタ型
マスタノードがその他のノードを管理するようなアーキテクチャです．
２−０−１−２．P2P型
全てのノードがお互いに管理するようなアーキテクチャです．
マスタ型と大きく違うのは単一障害点がないという点です．
２−１．CP型
一言で説明するとシステム全体の可用性よりも整合性を担保するデータベースです．
２−１−１．mongoDB
ドキュメント指向で，マスタ型アーキテクチャのデータベースです．
ドキュメント指向なので固定的なスキーマを持つことがなく，柔軟なデータベース設計を行うことができます．
ただ，RDBMSのような複雑な結合操作などは行うことができません．
参考：http://www.mongodb.org/:mongoDB
２−１−２．BigTable
カラム指向型で，マスタ型アーキテクチャのデータベースです．
Googleが自社のデータを管理するために設計されたデータベースです．
Google App Engineのデータベースとして利用することができます．
RDBMSのようなJOINなどは出来ませんが，サーバのスケーラビリティなどはGAE管理画面から簡単に行うことができます．
参考：https://developers.google.com/appengine/?hl=ja:Google App Engine
２−１−３．redis
キーバリュー型で，メモリ上にデータを扱うデータベースです．
特徴としては，メモリ上でデータを扱う為，読み書きが高速にできるというメリットがありますが，サーバの電源が落ちてしまったりするとデータは失われてしまいます．
ただ，redisではデータの永続化のために，非同期でハードディスクにデータを保存する機能もサポートしています．
ユニークな点として，Pub/Subの機能があります．
参考：http://redis.io/:redis
２−２．AP型
一言で説明するとシステム全体の整合性よりも可用性を担保するデータベースです．
２−２−１．CouchDB
ドキュメント指向で，P2P型アーキテクチャのデータベースです．
同じドキュメント指向のmonboDBとの違いとして，アーキテクチャが異なります．
また，整合性を担保していないので，異なるノード間ではデータが一致しないこともあります．
ユニークな点として，JavaScriptをクエリーに扱うことができたり，データをバージョンでマージしたり，過去のバージョンに戻すといったこともできます．
参考：http://couchdb.apache.org/:CouchDB
２−２−２．Cassandra
カラム指向型で，P2P型アーキテクチャのデータベースです．
CassandraはFacebook社で開発されたデータベースで，現在はApacheのプロジェクトの１つとして開発されています．
BigTableと同じカラム指向型ですが，アーキテクチャがP2Pである点が大きく異なります．
書き込み性能に特化され，整合性レベルを調整することが可能です．
参考：http://cassandra.apache.org/:Cassandra
２−２−３．Dynamo
キー・バリュー型でP2P型アーキテクチャのデータベースです．
P2P型アーキテクチャの特徴である，単一障害点の排除により停止しにくく，書き込み性能に特化したデータベースです．
Amazon DynamoDBではDynamoをキー・バリュー方式ではなく，スキーマレスなデータベースとして利用することができます．
参考：http://aws.amazon.com/jp/dynamodb//:Amazon DynamoDB
２−３．他のNoSQL
ここでは大きく紹介しませんでしたが，他にも国産のhttp://cloudian.jp/technologies/hibari-nosql-database.html:Hibariや同じく国産のhttp://fallabs.com/tokyotyrant/:TokyoTyrant/Cabinet，その他にもhttp://hbase.apache.org/:Apache HBase，http://memcached.org/:Memchacedなど様々なデータベースが存在します．
３．まとめ
今回は様々なデータベースを紹介しました．最近では，RDBMSがNoSQLに取って代わられるなど様々な話がありますが，個人的には同じNoSQLでもメリット・デメリットがあるので容易に比較することは出来ないと感じています．
自分はアプリケーションエンジニアなので，対象のアプリケーションの性質に合わせて最適なデータベースを選択・組み合わせて使っていこうと改めて思いました．
この記事を見て下さった型が，少しでも現在使っているデータベース以外のデータベースに興味を持って貰えれば幸いです．
もしかすると今使っているデータベースの問題点を解決してくれるかもしれないし，逆に今使っているデータベースを改めて素晴らしいと思うかもしれません．
少なくとも自分は，普段使用しているMySQLは凄いなと改めて感嘆しました．
４．参考図書
NOSQLの基礎知識 (ビッグデータを活かすデータベース技術)
- 作者: 本橋信也,河野達也,鶴見利章,太田洋
- 出版社/メーカー: リックテレコム
- 発売日: 2012/04/25
- メディア: 単行本（ソフトカバー）
- 購入: 7人 クリック: 81回
- この商品を含むブログ (7件) を見る
最後になりましたが，最後まで見ていただき有難う御座います．
※自分の説明に不備などありましたら，ご指摘頂ければ幸いです．
