モチベーション

NoSQLの生まれた背景、分類、実装について説明できるようになりたい

NoSQLとは

NoSQLはNot Only SQLの略語で、RDB以外のデータベースの総称。従来はデータベースの操作に使う言語はSQLであり、その対象はリレーショナル・データベースであるというのが暗黙の認識であったが、データベースの操作をする言語はSQLだけじゃないし、リレーショナル・データベース以外のデータベースも必要であるという意味が込められている。つまるところ、SQL = RDBと解釈すればRDB以外のデータベースの総称がNoSQLの定義と言える。

NoSQLの特徴と生まれた背景

NoSQLの特徴を掴むには、クラウディアン社の河野達也さんのスライドと書籍を読むのがお勧め。この記事でもスライドと書籍を大いに参考にさせて頂いている。

NOSQLの基礎知識 (ビッグデータを活かすデータベース技術)
  • Author: 本橋信也
  • Manufacturer: リックテレコム
  • Publish date: 2012-04-25

    • 上記の資料を読むとNoSQLは以下のような傾向があるとわかる。

    • スキーマレスであること
    • リレーションナルモデルの結合操作を利用しないこと
    • 水平スケーラビリティが確保しやすい事が多いこと(スケールアウトに適している)
    • トランザクションを利用できないものが多いこと

    NoSQLが生まれた背景にはデータの量と質が変わってきたことに関係がある。多様な種類のデータが取得出来るようになるにつれて、そのデータの量が莫大に増えてきており、またその種類の豊富さからスキーマの定義が容易ではなくなっているからだ。これを今風の言葉で表現するとビッグデータというのだろうが、このビッグデータ時代のデータの管理や処理を従来のRDBだけで行うのが困難になってきている。

    実際に、Google、Amazon、Facebookなど大量のデータを扱う名だたるIT企業がNoSQLを利用した基盤を開発しており、彼らのサービスを支えている。

    しかし、有名どころで使われているからという理由で手を出すと泣きを見る。我々がこのNoSQLを使いこなすには、種類、特性、用途を理解して適切に使い分ける必要がある。本記事ではNoSQLのデータ構造、アーキテクチャの観点での分類について説明する。

    NoSQLとKVSの関係

    色々なNoSQLの説明に入る前に、NoSQLとKVS(Key Value Store)の違いを言及しておきたいと思う。KVSはあるKeyとValueを1対1で紐付けて管理するデータ構造で、NoSQLにもKVSタイプのDynamoDB、Redis、memcachedなどが存在する。しかし、ことNoSQLの文脈の中で出て来るKVSという単語が純粋なKVSを指しているとは限らない。例えば、Google社のBigTableやApache HBaseはKeyに対してValueは複数のカラムであり多少複雑な構造がとれるわけだが、これも分散KVSなどと呼ばれていたりする。これを踏まえるとKVSの定義は非常に曖昧で、他の人がKVSと言っているときに、あるデータ構造を指しているとは思わない方がいい。

    データ構造とアーキテクチャから見るNoSQLの分類

    NOSQLの基礎知識 (ビッグデータを活かすデータベース技術)によると、NoSQLは以下のように分類出来る。

    20150907_データ構造とアーキテクチャによる分類

    見ての通りデータ構造とデータベースのアーキテクチャ観点で分類されている。以下ではそれぞれの特徴を説明する。

    データ構造上の分類

    Key/Value型

    Key/Value型は保存するデータをValueとした時にそれとペアとなる一意のKeyを使ってValueの追加、呼出しを行うタイプ。

    20150903_Key_Value_type

    新しいデータが追加去れるにつれて図の行部分が追加されるので立てに表が縦方向に伸びていくイメージ。

    このデータ構造はシンプルである点が特徴であり、RDBよりもはるかにスケールアウトしやすい。データの分割を考えるとき、RDBはテーブル間のリレーションが定義されているため、整合性を保つための排他制御なども必要だが、Key/Value型のNoSQLはどのKeyがどのサーバに保存されているかを管理する(シャーディング)だけで良く、ややこしいことを考える必要がない。

    カラム指向型

    カラム指向型はKey/Value型のValue部分を高度にしたものである。一意の行Keyに対して複数のカラムを持てるのが特徴。ここで言うカラムははKey/Valueからなっているっため1つの行Keyに対して複数のKey/Valueが格納される。

    20150903_Column_oriented_type

    使い方としては、

    20150903_column_oriented_user_family

    20150907_column_oriented_user_blog_family

    20150907_column_oriented_blog_entry_family

    カラム指向型はKey/Value型と同様にスケールアウトを得意としており、複数のサーバにデータを分割、複製することでデータ間の関係性を容易に管理できる。

    ドキュメント指向型

    ドキュメント指向型はJSON、XMLなどのフォーマットで記述されたドキュメントを管理する。各ドキュメントはネストしない形で保存されるためドキュメント間での親子関係はもたない。それぞれのドキュメントはユニークなIDを持っておりそれを利用してドキュメントを特定する。

    20150903_Document_oriented_type

    ドキュメント指向型の特徴はRDBのように固定されたデータスキーマが無くスキーマレスであること。しかし、実運用ではパフォーマンスの向上を狙って敢えてスキーマを定義することはある。Elasticsearchをマスターデータストアにする時はこのタイプに該当する。

    グラフ型

    データ間の関連性を管理出来るデータ構造で、グラフ理論に基づくNoSQL。SNSで良くあるフレンドリストにおいてある人の友だちの友達など互いの関連性を管理する時に用いる。

    20150907_Graph_type

    アーキテクチャ上の分類

    アーキテクチャによる分類は大きく分けて2つ。

    マスタ型

    マスタ型のアーキテクチャは1つのマスタノードが複数のノードを管理する構造で、GoogleのBigtableなんかはこれにあたる。この方はマスタノードがシステム全体の状態を管理しているため、マスタノードが停止するとシステムも停止する。そのためマスタの冗長化をしたり、マスタ停止時にその役割を他のノードに譲渡するなどして備えて置く必要がある。

    20150907_Master型

    P2P型

    P2P型はその名の通り、データを管理するノードが全て対当に互いを管理する。この方式だとマスタ型のように1つのノードが停止しても他のノードが互いの情報を持っているためシステム停止につながらない（SPOFが回避できる）。

    20150907_P2P型

    まとめ

    NoSQLとその分類について説明した。最近使ったSensuなんかもJob QueueとしてRedisを使っていたというように、Rubyで実装されたMiddlewareを使うと、そのbackendはRedisというシチュエーションは多々ある。プライベートでは流行ってるから使うってのもいいけどやっぱりその技術の概念や生まれた背景をきちんと理解しないと気持ち悪いし、使った時に負の遺産にしたくはない。

    NoSQLが良いとか、やっぱりRDBが良いとか色々な意見はあると思うけど、自分で触って、理解して、RDBとKVSのそれぞれの強み、弱みを理解して使い分けられるようにしたい。

    参考

    NOSQLの基礎知識 (ビッグデータを活かすデータベース技術)
  • Author: 本橋信也
  • Manufacturer: リックテレコム
  • Publish date: 2012-04-25

    • NoSQLとは

    NoSQLの分類