新しいデータベースのかたち
NoSQLについて
Hideaki Honda

contents
 NoSQLとは
 NoSQLの特徴
 RDBとの比較
 トランザクション管理
 データモデル
 ミドルウェアのカテゴリ分け
 Page 2

NoSQLとは
名前だけを見ると「SQLはいらない(No SQL)」と捉えがち
ですが、正しい解釈は「SQLだけではない(Not Only SQL)」
となります。つまり、SQLを使用しないDB(非RDB)の総称
を指しています。
RDBにはRDBの良さがあり、NoSQLにはNoSQLの良さが
あるため、どちらが良いとは一概には言えません。RDB以外
に、DBの選択肢が一つ新しく増えたと考えることが出来ます。
また、TwitterやFacebookなどのwebサービス企業にも
多く採用されています。
 Page 3

NoSQLの特徴
NoSQLの主な特徴は以下の３つになります。
•スケールアウト
•処理が高速
•柔軟なデータ構造
 Page 4

特徴１
-スケールアウト
特徴１ スケールアウト
スケールアウトとは、サーバの数を増やすことで処理性能の向上を
図る手法のことを言います。別の手法として「スケールアップ」
がありますが、これは、サーバのスペックをより高機能なものに
変更することで、処理性能の向上を図るというものです。
スケールアウトであれば、サーバの数を増やし拡張し続けていくこと
が可能ですが、スケールアップは、スペックの限界が来てしまえば
それ以上の処理向上は見込めなくなってしまいます。
 Page 5

特徴１(続き)
-スケールアウト
これまでのRDBでは、DBサーバを分散させると、サーバ間で
更新データの整合性を保つのが難しくなるため、スケールアップ
で対応するのが一般的でした。
(最近では、仮想化技術により、スケールアップしたサーバ内部で
仮想的なサーバをスケールアウトするという手法も取られています)
WebサーバやAPサーバは、
スケールアウトしやすいが、
DBサーバは並列化が困難で
あるため、ボトルネックにな
る場合があった。
 Page 6

特徴１(続き)
-スケールアウト
NoSQLでは、スケールアウト機能とレプリケーション機能を
持つことにより、DBサーバのスケールアウトを行うことが
出来るようになっています。これにより、大量アクセスや増え続
けるデータに対しても対処しやすいと言えます。(次のPage8参照)
[補足]
ちなみに、RDBでもスケールアウトが出来ないわけではありません。
RDBでは、データはテーブルに格納され、テーブル間においてリレーション(関係)
を持ちます。そのため、各テーブルが、別々のサーバに分散されると、データ
読み取り時やJOIN(結合)をしたときに、処理性能の低下を招くと言われています。
また、oracle RACなどの製品がありますが、コストは高くなります。
 Page 7

特徴１(続き)
-スケールアウト
NoSQL RDB
サーバ1 サーバ2 サーバ1 サーバ2
テーブルの関係が無いこと、 サーバを分散しても、テーブル同士
厳密にトランザクションを管理しない、 が関係を持つため、スケールアウト
などの理由から、スケールアウト しにくい。
しやすいと言える。
 Page 8

特徴２
-処理が高速
特徴２ 処理が高速
NoSQLの非常に大きなメリットとして、処理が高速であることが
挙げられます。NoSQLが登場した背景としては、世界規模で運営
するWebサイトが、データ量や同時アクセス数の増大によるパフォ
ーマンス悪化にいかに対応するか？というところからきています。
GoogleのBigtableやAmazonのDynamoなど、先駆けとなった
ソフトウェアは、自社で独自に開発されたものです。
後述するRDBとの違いやNoSQLの特性を良く見極めて
設計することにより、高速なパフォーマンスを得ることが出来ます。
 Page 9

特徴３
-柔軟なデータ構造
特徴３ 柔軟なデータ構造
事前にスキーマの定義をしないことによって、
多様な構造のデータを格納することが出来ます。
ただこれは、SQLのような高度なデータ操作をサポート
出来ないことを意味しています。
データの集計や結合処理は、アプリケーション側で、
工夫する必要が出てくる場合があります。
 Page 10

RDBとの比較
NoSQL RDB
データモデル KVS型やドキュメント型など様々 リレーショナルモデル
データ操作言語 製品により様々 SQL
データ一貫性 一貫性が保たれない時がある 厳密に一貫性を保つ
スキーマ 柔軟に変更可能 固定的
拡張性 スケールアウト スケールアップ
トランザクション(※) BASEトランザクション ACIDトランザクション
※詳細は、page13を参照して下さい。
スケールアウトによる並列処理が得意 厳密にデータの一貫性を保てる
長所 大量データの高速処理が得意 構築・運用ノウハウが確立されている
データの一貫性が厳密に保持されない スケールアウトをしにくい
短所 構築・運用ノウハウが確立されてない 大量データの高速処理に工夫が必要
それぞれの短所をカバーする関係にある
 Page 11

RDBとの比較(続き)
NoSQLとRDBの違いは、設計思想の違いから来るものとして見ることができます。
そのソフトウェアが、何を満たすべく作られているか、CAP定理という理論で考え
てみましょう。RDBは分割耐性(P)を犠牲にする代わりに、一貫性(C)、可用性(A)
を出来る限り保証します。一方、NoSQLは、分割耐性(P)、可用性(A)を第一に
考えて作られています。
CAP定理を構成する３つの要素
•一貫性(Consistency)
全てのクライアントは常にデータを同一のものとして
扱うことが出来る。
NoSQL •可用性(Availability)
各クライアントは常にデータを読み書き出来る。
•分割耐性(Partition Tolerance)
ネットワーク分断関わらずシステムが適切に稼動する。
RDB
 Page 12

トランザクション管理
ACIDトランザクション
RDBでは、ACID特性を満たすトランザクションとなっています。
データは、コミットにより、更新前か更新後かのどちらかしか有り得ません。
更新処理 データの読み取り
更新前のデータ 更新後のデータ
コミットにより更新
が確定する
BASEトランザクション
NoSQLでは、BASEトランザクションという考え方をします。これは、更新前と更新後の
どちらの状態でもない不定状態にあることを許したトランザクションモデルです。
即時反映されなくても、読み取り時までに間に合っていれば良いという考えに基づいています。
このことが、データの一貫性が緩いと言われる所以でもあります。
更新処理 データの読み取り
更新前のデータ 未確定 更新後のデータ
更新要求の非同期処理、更新内容を
更新の要求のみ受付
 Page 13 分散環境へ配置する時間

NoSQLのデータモデル
NoSQLは、大きく以下の４つに分類することが出来ます。
ぞれぞれ特徴を見ていきましょう。
KVS(キー・バリュー・ストア)型
カラム指向型
グラフ型
ドキュメント指向型
 Page 14

KVS(キー・バリュー ・ストア)型
[特徴]
キーとそれに対するバリューをペアとしてデータを保持する。
キーを指定することで、それに対応するデータを格納/取得出来る。
[利用形態]
更新、検索方法が１つに限定されている場合に向いている。
[イメージ]
キーを指定して、バリューを特定する。
[補足]
メモリ、ディスクに格納するものや永続性を保証するもの等様々あります。
 Page 15

カラム指向型
[特徴]
データを行単位で管理するのではなく、列単位に管理していく。
キーに加えカラムを指定することによってバリューを特定する。
[利用形態]
更新、検索方法は複数だが固定的である場合に向いている。
[イメージ]
行指向 カラム(列)指向
 Page 16

ドキュメント指向型
[特徴]
XMLやJSONなど構造化されたデータを格納するのに適している。
事前にデータ型を定義する必要がなく、1件ずつデータのフォーマットが
異なっていても問題は無い 。柔軟な構造でデータを扱うことが出来る。
[利用形態]
データが完全に構造化出来ずに、更新・検索に自由度が求められるデータ
を扱うのに適している。
[イメージ] 下記の様な1データが、DBに、まるまる1レコード
として格納されるイメージ。
{“header”:
{“name”: “test_user”,
“userID”: “001”
}
}
 Page 17

グラフ型
[特徴]
グラフで表現出来るデータを格納するのに適している。
ノード、リレーションシップ、プロパティの３つの要素から成る。
[利用形態]
製品の構成情報のように親子関係を表したい場合など。
[イメージ]
1 2
relation
ship Name=0001
node Type=Part property
 Page 18

ミドルウェアのカテゴリ分け
KVS型 カラム指向型 RDB
•Azure Table Storage •BigTable •Oracle
•Hibari •Cassandra •SQL Server
•Oracle Coherence •HBase •MySQL
•ROMA •Sybase IQ
•PostgreSQL
•Tokyo Cabinet
•WebSphere eXtreme Scale
ドキュメント指向型 グラフ指向型
•CouchDB
•MongoDB •Neo4j
•Sones
NoSQL ※ここにあるのは、ほんの一部です。
 Page 19

最後に
NoSQLの登場がデータベースの選択肢を広げた、
ということがお分かり頂けたでしょうか。
多くの製品は、OSSとして開発されているので、
簡単に試すことが出来るのも魅力的です。
また、今回は触れることが出来ませんでしたが、
インメモリDBの存在も見逃せないものになっています。
今後ますます重要になってくるデータベースの検討に
お役に立てたら幸いです。
以上です。
 Page 20