NoSQLとは ― キーバリュー型などの種類とRDBの違い

NoSQLとは、表の形でデータを持つRDB以外の、データベースの種類をまとめて指す呼び方です。キーバリュー型・ドキュメント型・列指向・グラフ型が代表で、型ごとにデータの持ち方と得意な読み方が違います。データが表に収まりにくいときや、台数を増やして大量に読み書きしたいときに、RDBの代わりに使ったり、RDBと組み合わせたりします。

AWSの解説は、NoSQLを、特定のデータの形に合わせて設計され、決まりのゆるい形でデータを持つデータベースと説明しています。データベースの基本は、データベースとはとRDBの記事で説明しています。

型の違いは、データの何を1件として持つかに表れます。次の図は、会員2人と注文3件という同じデータを、RDBと4つの型で持った形を示しています。タブを切り替えて、1件の単位と得意な読み方を比べられます。

{
  "_id": "C001",
  "name": "佐藤",
  "city": "東京",
  "orders": [
    { "no": 101, "item": "ノート", "qty": 2 },
    { "no": 102, "item": "ペン", "qty": 5 }
  ]
}
{
  "_id": "C002",
  "name": "鈴木",
  "city": "大阪",
  "orders": [
    { "no": 103, "item": "ノート", "qty": 1 }
  ]
}

同じデータでも、RDBは表を分けて持ち、ドキュメント型は会員1人分を1つにまとめます。どちらが良いかは、そのデータをどう読むことが多いかで決まります。

Amazon DynamoDBは、キーバリュー型とドキュメント型の両方の使い方ができるサービスです。DynamoDBの仕組みはAmazon DynamoDBの記事で説明しています。

キーバリュー型は、キーで値を出し入れする

キーバリュー型は、キーと値の組を集めてデータを持ちます。キーはその1件を見分ける印で、基本の操作はキーを指定した保存と取り出しです。作りが単純なため、キーが分かっている1件をすぐに読み書きできます。

代表的な製品のRedisは、データをメモリに置くデータベースです。Redisの公式資料は、メモリに置くので読み書きがとても速い一方、データ量はメモリの大きさを超えられないと説明しています。メモリの中身は、一定の間隔でディスクに保存することもできます。データを主にメモリに置くこの方式を、インメモリデータベースと呼びます。AWSでは、Amazon ElastiCacheが、キーと値の組をメモリに置いてデータベースのキャッシュに使うサービスです。

ドキュメント型は、JSONに似た文書を1件として持つ

ドキュメント型は、項目名と値の組を並べた文書を1件として持ちます。代表的な製品のMongoDBは、JSONを2進数の形にしたBSONで文書を保存します。値には、別の文書や配列も入れられます。

MongoDBの公式資料は、同じ集まりの文書でも、項目がそろっている必要はないとしています。設計の原則は、一緒に読むデータを一緒に保存することです。会員の中に注文を入れておけば、会員1人と注文を1回で読めます。MongoDBにも、別の集まりと結び付ける$lookupという操作はあります。

列指向は列ごとにまとめ、ワイドカラム型はキーで行を分ける

列指向は、同じ列の値をまとめて保存する方式です。この方式は、SQLで問い合わせるデータウェアハウスのAmazon Redshiftでも使われています。Redshiftの資料によると、分析の問い合わせは多くの行から少しの列だけを読むため、読む量が大きく減ります。たとえば100列の表で5列だけを使う問い合わせなら、読むのは表のデータの約5%で済みます。1件の全項目を読み書きする業務の処理は、行ごとに保存する方式が向きます。

列指向と並べて扱われるのが、Apache Cassandraに代表されるワイドカラム型です。Cassandraは行と列からなる表でデータを持ち、パーティションキーという値で、行を置く台を決めます。結合はできないため、問い合わせごとに表を作り、同じデータを複数の表に重ねて持ちます。列ごとに保存する列指向とは、仕組みが別のものです。

グラフ型は、つながりそのものをデータとして持つ

グラフ型は、データをノードとリレーションシップで持ちます。ノードは人や商品などの1つの物で、リレーションシップは2つのノードをつなぐ、向きと名前を持った線です。ノードとリレーションシップには、プロパティと呼ぶキーと値の組を付けられます。

代表的な製品のNeo4jの資料は、グラフデータベースは結合を使わないと説明しています。つながりがノードと一緒に保存されているため、線をたどれば次のノードにたどり着きます。「友達の友達」のように、何段もつながりをたどる問い合わせに向きます。

RDBとNoSQLの違いは、データを持つ前にどこまで形を決めるかと、規模をどう広げるかに表れます。次の表は、AWSの解説をもとに、RDBと多くのNoSQLの製品の違いをまとめたものです。

RDBは、表・列・表どうしの関係を先に決めておくので、どの列を条件にしても正しく探せます。NoSQLは、よく使う読み方に合わせて1件の形を決めます。その読み方には速く答えられますが、想定していない読み方には弱くなります。

規模の広げ方も違います。RDBは1台のサーバの性能を上げて対応するのが基本で、NoSQLの多くは台数を増やしてデータを分けて持ちます。1台を強くするか台数を増やすかの違いは、スケールアップとスケールアウトの記事で比べています。RDBでも、AWSのAmazon Auroraは、書き込む1台と同じストレージを読む読み取り用の台を、最大15台まで足せます。

台数を増やせるのは、キーから置き場所が決まるからです。Cassandraは、パーティションキーの値をもとに、どのノードにデータを置くかを決めます。要求はキーから決まったノードに向かうので、ノードを足せば、データと処理を分けて持てます。図では省きましたが、Cassandraは同じデータの写しを複数のノードに持つこともできます。データを複数の台に分けたり写したりする考え方は、分散データベースの記事にまとめました。

RDBのトランザクションは、ACID特性を保証します。ACIDの4つの性質はトランザクションとACID特性の記事で説明しています。AWSの解説によると、多くのNoSQLは、このACID特性の一部をゆるめています。その代わりに、決まりのゆるいデータの形と、台数を増やして広げやすい作りを選んでいます。

ACIDと対比される考え方がBASEです。BASEは、Basically Available、Soft-state、Eventual consistencyの頭文字です。Eric Brewerが2000年の講演で、ACIDと並べて示しました。

講演のスライドによると、BASEは一貫性を弱め、使える状態を保つことを優先する考え方で、古いデータが返ってもよいとしています。BASEのEにあたる結果整合性は、更新の直後は古い値が返ることがあっても、時間がたてば新しい値が返るようになる性質です。

ただし、NoSQLなら必ずBASEというわけではありません。Brewer自身が、2つは両端の間に幅がある考え方だとスライドに書いています。MongoDBは複数の文書にまたがるACIDのトランザクションに対応し、DynamoDBにもACIDを保証するトランザクションがあります。DynamoDBで結果整合性の読み取りと強い整合性の読み取りを選ぶ方法は、DynamoDBの記事で見られます。

型を選ぶ手がかりは、そのデータを何で探し、何と一緒に読むかです。次の表は、用途の例と向く型の対応です。

どの型も、得意な読み方に合わせてデータの形を決めています。読み方がまだ決まっていないデータや、どの項目でも探したいデータは、RDBのほうが扱いやすくなります。

1つのシステムで、RDBとNoSQLのどちらか一方だけを選ぶ必要はありません。注文や在庫のように正確さが大事なデータはRDBに置き、一部のデータだけをNoSQLに置く組み合わせ方があります。

Redisの公式資料は、よくある設計として2つの使い方を挙げています。1つは、書き込みの多い小さなデータをRedisに置き、大きなデータをSQLのデータベースに置く使い方です。もう1つは、ディスクのデータベースにあるデータの一部を、写しとしてRedisのメモリに持つ使い方です。

集めたデータを分析する用途では、業務のデータベースとは別に、分析用のデータベースを持つことがあります。その役割の分け方は、データウェアハウスの記事で説明しています。

• AWS「What is NoSQL?」（NoSQLの定義、RDBとの違い）
• Redis Docs「Redis FAQ」（メモリに置く仕組み、ディスクのデータベースとの組み合わせ）
• MongoDB Manual「Data Modeling」（項目のそろわない文書、一緒に読むデータを一緒に保存する原則）
• MongoDB Manual「Transactions」（複数の文書にまたがるACIDのトランザクション）
• Amazon Redshift Database Developer Guide「Columnar storage」（列ごとの保存と、読む量の違い）
• Apache Cassandra Documentation「Data Modeling: Introduction」（パーティションキー、結合を使わない設計）
• Neo4j「What is a graph database」（ノード・リレーションシップ・プロパティ）
• Amazon DynamoDB Developer Guide「Amazon DynamoDB Transactions: How it works」（DynamoDBのトランザクション）
• Amazon DynamoDB Developer Guide「DynamoDB read consistency」（結果整合性のある読み取り）
• Eric Brewer「Towards Robust Distributed Systems」PODC Keynote, 2000（ACIDとBASEの対比）