データベース - 第4部 : NoSQL

概要

前述のRDBMSのACIDモデルとは対照的に、NoSQLの一貫性モデルはBASEと表現されます。

トランザクションにおけるACID

  • Atomic (原子性)
    • 作業は実行途中で中断されません。中断された場合は、以前の状態に戻らなければなりません。
  • Consistency (一貫性)
    • トランザクション成功時には、常にすべてのデータが一貫性を維持しなければなりません。整合性制約がかかっている場合、その制約に違反するトランザクションはキャンセルされます。
  • Isolation (独立性)
    • トランザクションの途中に他のトランザクションが介入することはできません。
  • Durability (永続性)
    • 成功したトランザクションは、システムに問題が発生しても永続的に反映されなければなりません。

BASE

  • BA ( Basic Availability : 基本的な可用性 )
    • データベースは基本的にいつでも動作します。
  • Soft-state ( ソフトステート )
    • ストレージが書き込み一貫性を持つ必要はなく、異なるレプリカ同士が常に相互に一貫性を持つ必要もありません。
  • Eventual consistency ( 結果整合性 )
    • ストレージは最終的には一貫性を持ちます。

上記の特性を記憶に留めつつ、以下のNoSQLデータベースについて話してみましょう。

NoSQL データベース

Redis ( Remote Dictionary Server )

  • オープンソース
  • インメモリデータ構造ストア
  • NoSQL/キャッシュソリューション ( データベースとしても使用される )
  • スナップショット ( RDB ) / AOF (Append on file) バックアップをサポート
    • RDB : Redisデータ全体のスナップショット ( SAVE, BGSAVE )
      • Good : 高速。スナップショットをそのままロードする形なので再起動が速い。
      • Bad : 消失。スナップショット時点以降のデータが失われる可能性がある。
    • AOF : すべての書き込み/更新操作をログに記録
      • Good : ロスレス (Lossless)。マシンがダウンする直前までの操作を記録するため、データの消失がない。
      • Bad : 低速。書き込み/更新のすべての操作を記録するため、RDBタイプより多くのスペースが必要となり、再起動時に記録された操作をすべて実行する必要があるため遅い。
    • Hybrid (推奨) 両方を混ぜて使うことを推奨する。
      • RDB + AOF : ~ スナップショット (+ スナップショット以降からは AOF )
  • Pub/Sub モデル
    • 1:1 キュー、1:N メッセージング形式をすべてサポートする。
    • 1つのトピックに対して複数のメッセージを受け取ることができる。
      • 例) music.jazz, music.classic > music トピック -> jazz, classic

memcached ( NoSQLではない )

  • オープンソース
  • 分散メモリキャッシングシステム
  • (注意) もしメモリに保存容量がない場合、MemcachedはLRUアルゴリズムを利用して既存のデータを削除し、メモリを再利用する。

cassandra

Apache Cassandraは大規模に拡張可能な分散NoSQL DBで、Facebook内部で始まりオープンソースとしてリリースされました。 特徴としては、P2Pプロトコル(Gossip)を利用して1秒ごとにクラスタ内の最大3つのノードと状態メッセージを交換します。そしてこれを利用して、すべてのノードはクラスタ内の他のノードについて迅速に学習します。注意すべき点は、複数のデータセンタークラスタを使用する場合、耐障害性のためにデータセンターごとに2つ以上のシードノードを指定することが推奨されます。

  • 分散化 : 物理的に離れているデータセンター間でも単一のCassandraクラスタを運用できる。
  • 非集中化 : すべてのノードが完全に等価である。
  • 拡張性 : クラスタを停止することなく拡大および縮小が可能である。
  • 高性能 : マルチプロセッサ/マルチコアマシンを最大限に活用し、複数のデータセンターに設置された数百台のマシン間で実行されるように設計されている。
  • 行 (Row) 指向
    • Cassandraはリレーショナル構造ではなく、疎な多次元ハッシュテーブルとして構造を表現する。
    • 「疎」とは、行が1つ以上の列を持つことができるが、各行が他の行とまったく同じ列をすべて持つ必要はないという意味である。
  • 使用している企業
    • Twitter : 分析用途で使用
    • Facebook : 受信トレイの検索に使用
    • Reddit : 永続的なキャッシュとして使用
    • Ooyala : ほぼリアルタイムに近いビデオ分析データサービスと保存に使用
  • デメリット
    • JoinやTransactionをサポートしていない
    • RDBMSのようなページング (Paging) を実装するのが難しく、KeyspaceやTableなどを過度に生成した場合、Memory Overflowが発生する可能性がある

さらに、Cassandraクラスタの設定および構成は、HBaseクラスタの構成よりもはるかに簡単です。 Cassandraは一般的に書き込み時に5倍以上の優れたパフォーマンス、読み取り時に4倍以上のパフォーマンスを示します。

考察

NoSQLの大部分は、大容量処理を念頭に置いています。そのためか、RDBMSで保証されているConsistency(一貫性)を、多くの場合完全にはサポートしていません。このためにはトレードオフとなる設定を行う必要があると考えられます。

Appendix