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

Hideaki Honda

Page 2

contents

NoSQLとは

NoSQLの特徴

RDBとの比較

トランザクション管理

データモデル

ミドルウェアのカテゴリ分け

Page 3

NoSQLとは

名前だけを見ると「SQLはいらない(No SQL)」と捉えがち

ですが、正しい解釈は「SQLだけではない(Not Only SQL)」

となります。つまり、SQLを使用しないDB(非RDB)の総称

を指しています。

RDBにはRDBの良さがあり、NoSQLにはNoSQLの良さが

あるため、どちらが良いとは一概には言えません。RDB以外

に、DBの選択肢が一つ新しく増えたと考えることが出来ます。

また、TwitterやFacebookなどのwebサービス企業にも

多く採用されています。

Page 4

NoSQLの特徴

NoSQLの主な特徴は以下の３つになります。

•スケールアウト

•処理が高速

•柔軟なデータ構造

Page 5

特徴１ -スケールアウト

特徴１ スケールアウト

スケールアウトとは、サーバの数を増やすことで処理性能の向上を

図る手法のことを言います。別の手法として「スケールアップ」

がありますが、これは、サーバのスペックをより高機能なものに

変更することで、処理性能の向上を図るというものです。

スケールアウトであれば、サーバの数を増やし拡張し続けていくこと

が可能ですが、スケールアップは、スペックの限界が来てしまえば

それ以上の処理向上は見込めなくなってしまいます。

Page 6

特徴１(続き) -スケールアウト

これまでのRDBでは、DBサーバを分散させると、サーバ間で

更新データの整合性を保つのが難しくなるため、スケールアップ

で対応するのが一般的でした。

(最近では、仮想化技術により、スケールアップしたサーバ内部で

仮想的なサーバをスケールアウトするという手法も取られています)

WebサーバやAPサーバは、スケールアウトしやすいが、DBサーバは並列化が困難であるため、ボトルネックになる場合があった。

Page 7

特徴１(続き) -スケールアウト

NoSQLでは、スケールアウト機能とレプリケーション機能を

持つことにより、DBサーバのスケールアウトを行うことが

出来るようになっています。これにより、大量アクセスや増え続

けるデータに対しても対処しやすいと言えます。(次のPage8参照)

[補足]

ちなみに、RDBでもスケールアウトが出来ないわけではありません。

RDBでは、データはテーブルに格納され、テーブル間においてリレーション(関係)

を持ちます。そのため、各テーブルが、別々のサーバに分散されると、データ

読み取り時やJOIN(結合)をしたときに、処理性能の低下を招くと言われています。

また、oracle RACなどの製品がありますが、コストは高くなります。

Page 8

特徴１(続き) -スケールアウト

RDB

サーバ1 サーバ2

サーバを分散しても、テーブル同士

が関係を持つため、スケールアウト

しにくい。

NoSQL

サーバ1 サーバ2

テーブルの関係が無いこと、

厳密にトランザクションを管理しない、

などの理由から、スケールアウト

しやすいと言える。

Page 9

特徴２ -処理が高速

特徴２ 処理が高速

NoSQLの非常に大きなメリットとして、処理が高速であることが

挙げられます。NoSQLが登場した背景としては、世界規模で運営

するWebサイトが、データ量や同時アクセス数の増大によるパフォ

ーマンス悪化にいかに対応するか？というところからきています。

GoogleのBigtableやAmazonのDynamoなど、先駆けとなった

ソフトウェアは、自社で独自に開発されたものです。

後述するRDBとの違いやNoSQLの特性を良く見極めて

設計することにより、高速なパフォーマンスを得ることが出来ます。

Page 10

特徴３ -柔軟なデータ構造

特徴３ 柔軟なデータ構造

事前にスキーマの定義をしないことによって、

多様な構造のデータを格納することが出来ます。

ただこれは、SQLのような高度なデータ操作をサポート

出来ないことを意味しています。

データの集計や結合処理は、アプリケーション側で、

工夫する必要が出てくる場合があります。

Page 11

RDBとの比較

NoSQL RDB

データモデル KVS型やドキュメント型など様々 リレーショナルモデル

データ操作言語 製品により様々 SQL

データ一貫性 一貫性が保たれない時がある 厳密に一貫性を保つ

スキーマ 柔軟に変更可能 固定的

拡張性 スケールアウト スケールアップ

トランザクション(※) BASEトランザクション ACIDトランザクション

厳密にデータの一貫性を保てる

構築・運用ノウハウが確立されている

データの一貫性が厳密に保持されない

構築・運用ノウハウが確立されてない

長所

短所 スケールアウトをしにくい

大量データの高速処理に工夫が必要

スケールアウトによる並列処理が得意

大量データの高速処理が得意

それぞれの短所をカバーする関係にある

※詳細は、page13を参照して下さい。

Page 12

RDBとの比較(続き)

•一貫性(Consistency) 全てのクライアントは常にデータを同一のものとして

扱うことが出来る。

•可用性(Availability) 各クライアントは常にデータを読み書き出来る。

•分割耐性(Partition Tolerance) ネットワーク分断関わらずシステムが適切に稼動する。

CAP定理を構成する３つの要素

NoSQLとRDBの違いは、設計思想の違いから来るものとして見ることができます。 そのソフトウェアが、何を満たすべく作られているか、CAP定理という理論で考え てみましょう。RDBは分割耐性(P)を犠牲にする代わりに、一貫性(C)、可用性(A) を出来る限り保証します。一方、NoSQLは、分割耐性(P)、可用性(A)を第一に 考えて作られています。

RDB

NoSQL

Page 13

トランザクション管理

ACIDトランザクション

BASEトランザクション

更新前のデータ 更新後のデータ

更新処理 データの読み取り

更新処理 データの読み取り

更新前のデータ 更新後のデータ 未確定

NoSQLでは、BASEトランザクションという考え方をします。これは、更新前と更新後の どちらの状態でもない不定状態にあることを許したトランザクションモデルです。 即時反映されなくても、読み取り時までに間に合っていれば良いという考えに基づいています。 このことが、データの一貫性が緩いと言われる所以でもあります。

更新要求の非同期処理、更新内容を

分散環境へ配置する時間

RDBでは、ACID特性を満たすトランザクションとなっています。 データは、コミットにより、更新前か更新後かのどちらかしか有り得ません。

更新の要求のみ受付

コミットにより更新が確定する

Page 14

NoSQLのデータモデル

NoSQLは、大きく以下の４つに分類することが出来ます。

ぞれぞれ特徴を見ていきましょう。

KVS(キー・バリュー・ストア)型

カラム指向型

グラフ型

ドキュメント指向型

Page 15

KVS(キー・バリュー ・ストア)型

[特徴]

キーとそれに対するバリューをペアとしてデータを保持する。

キーを指定することで、それに対応するデータを格納/取得出来る。

[利用形態]

更新、検索方法が１つに限定されている場合に向いている。

[イメージ]

[補足]

メモリ、ディスクに格納するものや永続性を保証するもの等様々あります。

キーを指定して、バリューを特定する。

Page 16

カラム指向型

[特徴]

データを行単位で管理するのではなく、列単位に管理していく。

キーに加えカラムを指定することによってバリューを特定する。

[利用形態]

更新、検索方法は複数だが固定的である場合に向いている。

[イメージ]

行指向 カラム(列)指向

Page 17

ドキュメント指向型

[特徴]

XMLやJSONなど構造化されたデータを格納するのに適している。

事前にデータ型を定義する必要がなく、1件ずつデータのフォーマットが

異なっていても問題は無い 。柔軟な構造でデータを扱うことが出来る。

[利用形態]

データが完全に構造化出来ずに、更新・検索に自由度が求められるデータ

を扱うのに適している。

[イメージ]

下記の様な1データが、DBに、まるまる1レコードとして格納されるイメージ。 {“header”: {“name”: “test_user”, “userID”: “001” } }

Page 18

グラフ型

[特徴]

グラフで表現出来るデータを格納するのに適している。

ノード、リレーションシップ、プロパティの３つの要素から成る。

[利用形態]

製品の構成情報のように親子関係を表したい場合など。

[イメージ]

1 2

node Name=0001 Type=Part

relationship

property

Page 19

ミドルウェアのカテゴリ分け

RDB KVS型 カラム指向型

グラフ指向型 ドキュメント指向型

•Oracle •SQL Server •MySQL •PostgreSQL

•CouchDB •MongoDB

•Neo4j •Sones

•BigTable •Cassandra •HBase

•Sybase IQ

•Azure Table Storage •Hibari •Oracle Coherence •ROMA •Tokyo Cabinet •WebSphere eXtreme Scale

NoSQL ※ここにあるのは、ほんの一部です。

Page 20

最後に

NoSQLの登場がデータベースの選択肢を広げた、

ということがお分かり頂けたでしょうか。

多くの製品は、OSSとして開発されているので、

簡単に試すことが出来るのも魅力的です。

また、今回は触れることが出来ませんでしたが、

インメモリDBの存在も見逃せないものになっています。

今後ますます重要になってくるデータベースの検討に

お役に立てたら幸いです。

以上です。