新しいデータベースのかたち
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の主な特徴は以下の3つになります。


•スケールアウト
•処理が高速
•柔軟なデータ構造




 Page 4
特徴1
-スケールアウト


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




 Page 5
特徴1(続き)
-スケールアウト


これまでのRDBでは、DBサーバを分散させると、サーバ間で
更新データの整合性を保つのが難しくなるため、スケールアップ
で対応するのが一般的でした。
(最近では、仮想化技術により、スケールアップしたサーバ内部で
仮想的なサーバをスケールアウトするという手法も取られています)



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


 Page 6
特徴1(続き)
-スケールアウト


NoSQLでは、スケールアウト機能とレプリケーション機能を
持つことにより、DBサーバのスケールアウトを行うことが
出来るようになっています。これにより、大量アクセスや増え続
けるデータに対しても対処しやすいと言えます。(次のPage8参照)

[補足]
ちなみに、RDBでもスケールアウトが出来ないわけではありません。
RDBでは、データはテーブルに格納され、テーブル間においてリレーション(関係)
を持ちます。そのため、各テーブルが、別々のサーバに分散されると、データ
読み取り時やJOIN(結合)をしたときに、処理性能の低下を招くと言われています。
また、oracle RACなどの製品がありますが、コストは高くなります。

 Page 7
特徴1(続き)
-スケールアウト


           NoSQL              RDB




  サーバ1       サーバ2      サーバ1    サーバ2


  テーブルの関係が無いこと、        サーバを分散しても、テーブル同士
  厳密にトランザクションを管理しない、   が関係を持つため、スケールアウト
  などの理由から、スケールアウト      しにくい。
  しやすいと言える。




 Page 8
特徴2
-処理が高速


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


 Page 9
特徴3
-柔軟なデータ構造


特徴3 柔軟なデータ構造
事前にスキーマの定義をしないことによって、
多様な構造のデータを格納することが出来ます。
ただこれは、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定理を構成する3つの要素

                         •一貫性(Consistency)
                          全てのクライアントは常にデータを同一のものとして
                          扱うことが出来る。


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

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


 Page 12
トランザクション管理


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

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

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

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

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

                            更新要求の非同期処理、更新内容を
             更新の要求のみ受付
  Page 13                  分散環境へ配置する時間
NoSQLのデータモデル



NoSQLは、大きく以下の4つに分類することが出来ます。
ぞれぞれ特徴を見ていきましょう。


KVS(キー・バリュー・ストア)型
カラム指向型
グラフ型
ドキュメント指向型




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



[特徴]
キーとそれに対するバリューをペアとしてデータを保持する。
キーを指定することで、それに対応するデータを格納/取得出来る。
[利用形態]
更新、検索方法が1つに限定されている場合に向いている。
[イメージ]
            キーを指定して、バリューを特定する。



[補足]
メモリ、ディスクに格納するものや永続性を保証するもの等様々あります。
 Page 15
カラム指向型



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


[イメージ]
     行指向     カラム(列)指向




 Page 16
ドキュメント指向型



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

              {“header”:
                           {“name”: “test_user”,
                            “userID”: “001”
                           }
              }
 Page 17
グラフ型



[特徴]
グラフで表現出来るデータを格納するのに適している。
ノード、リレーションシップ、プロパティの3つの要素から成る。
[利用形態]
製品の構成情報のように親子関係を表したい場合など。


[イメージ]

            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

About NoSQL