NoSQL Distilledからの要点

弊社書籍「NoSQL Distilled」では、多くの章を簡潔な要点でまとめています。クイックリファレンスとして、ここに要点を含めました。

すべて展開 | すべて折りたたみ

Pramod Sadalage & Martin Fowler: 2012年9月12日

第1章

なぜNoSQLか？

  • リレーショナルデータベースは20年間成功した技術であり、永続性、同時実行制御、および統合メカニズムを提供してきました。
  • アプリケーション開発者は、リレーショナルモデルとインメモリデータ構造間のインピーダンスミスマッチに悩まされてきました。
  • データベースを統合ポイントとして使用することから、アプリケーション内にデータベースをカプセル化し、サービスを通じて統合するという動きがあります。
  • データストレージの変化の重要な要因は、クラスタ上で実行することで大量のデータに対応する必要性でした。リレーショナルデータベースは、クラスタ上で効率的に実行されるように設計されていません。
  • NoSQLは偶然生まれた造語です。規定された定義はなく、共通の特徴を観察することしかできません。

  • NoSQLデータベースの共通の特徴は次のとおりです。

    • リレーショナルモデルを使用しない
    • クラスタ上で良好に動作する
    • オープンソース
    • 21世紀のウェブ環境向けに構築されている
    • スキーマレス
  • NoSQLの台頭によって最も重要な結果となったのは、ポリグロットパーシスタンスです。

第2章

集約データモデル

  • 集約とは、単一単位として操作するデータの集合です。集約は、データベースとのACID操作の境界を形成します。
  • キーバリュー、ドキュメント、カラムファミリーデータベースはすべて、集約指向データベースの一種と見なすことができます。
  • 集約により、データベースはクラスタ全体でのデータストレージの管理を容易にします。
  • 集約指向データベースは、ほとんどのデータ操作が同じ集約で行われる場合に最適です。集約非依存のデータベースは、多くの異なる形式で整理されたデータを使用する操作の方が優れています。

第3章

データモデルの詳細

  • 集約指向データベースでは、集約間の関係を、集約内の関係よりも処理が困難になります。
  • グラフデータベースはデータをノードとエッジのグラフに編成します。複雑な関係構造を持つデータに最適です。
  • スキーマレスデータベースでは、レコードに自由にフィールドを追加できますが、通常、データのユーザーによって暗黙的に期待されるスキーマがあります。
  • 集約指向データベースは、多くの場合、マテリアライズドビューを計算して、主要な集約とは異なる方法で整理されたデータを提供します。これは、多くの場合、MapReduce計算によって行われます。

第4章

分散モデル

  • データ分散には2つのスタイルがあります。

    • シャーディングは、異なるデータを複数のサーバーに分散するため、各サーバーはデータのサブセットの単一ソースとして機能します。
    • レプリケーションはデータを複数のサーバーにコピーするため、データの各ビットは複数の場所に見つけることができます。

    システムは、どちらか一方または両方のテクニックを使用できます。

  • レプリケーションには2つの形式があります。

    • リーダーフォロワーレプリケーションでは、1つのノードが書き込みを処理する権威のあるコピーになり、フォロワーはリーダーと同期し、読み取りを処理する場合があります。
    • ピアツーピアレプリケーションでは、任意のノードに書き込むことができます。ノードはデータのコピーを同期するために調整します。

    リーダーフォロワーレプリケーションは更新の競合の可能性を減らしますが、ピアツーピアレプリケーションは単一障害点へのすべての書き込みの負荷を回避します。

第5章

一貫性

  • 書き込み書き込み競合は、2つのクライアントが同時に同じデータの書き込みを試行する場合に発生します。読み取り書き込み競合は、あるクライアントが別のクライアントの書き込みの途中で不整合なデータを読み取る場合に発生します。
  • 悲観的なアプローチはデータレコードをロックして競合を防ぎます。楽観的なアプローチは競合を検出して修正します。
  • 分散システムでは、一部のノードが更新を受信し、他のノードが受信していないために、読み取り書き込み競合が発生します。最終的な一貫性とは、すべての書き込みがすべてのノードに伝播されると、システムが最終的に一貫性を持つことを意味します。
  • クライアントは通常、書き込み済みデータの読み取りの一貫性を求めます。これは、書き込みと読み取りが異なるノードで行われる場合、困難になる可能性があります。
  • 良好な一貫性を確保するには、多くのノードをデータ操作に含める必要がありますが、これによりレイテンシが増加します。そのため、多くの場合、一貫性とレイテンシのトレードオフを行う必要があります。
  • CAP定理は、ネットワークパーティションが発生した場合、データの可用性と一貫性のトレードオフを行う必要があると述べています。
  • 特にレプリケートされたデータで障害から回復したい場合、耐久性とレイテンシのトレードオフを行うこともできます。
  • レプリケーションで強い一貫性を維持するために、すべてのレプリカに連絡する必要はありません。十分なクォーラムが必要なだけです。

第6章

バージョンスタンプ

  • バージョンスタンプは、同時実行の競合を検出するのに役立ちます。データを読み取って更新するときは、バージョンスタンプを確認して、読み取りと書き込みの間に誰もデータに更新していないことを確認できます。
  • バージョンスタンプは、カウンタ、GUID、コンテンツハッシュ、タイムスタンプ、またはこれらの組み合わせを使用して実装できます。
  • 分散システムでは、バージョンスタンプのベクトルにより、異なるノードに競合する更新があるかどうかを検出できます。

第7章

MapReduce

  • MapReduceは、計算をクラスタ全体に並列化するためのパターンです。
  • マップタスクは集約からデータを読み取り、関連するキーバリューペアに絞り込みます。マップは一度に1つのレコードしか読み取らないため、並列化してレコードを格納するノードで実行できます。
  • リデュースタスクは、マップタスクから出力された単一キーの多くの値を受け取り、それらを単一出力に要約します。各リデューサは単一キーの結果に対して動作するため、キーごとに並列化できます。
  • 入力と出力が同じ形式のリデューサは、パイプラインに結合できます。これにより、並列処理が向上し、転送されるデータ量が削減されます。
  • MapReduce操作は、あるリデューサの出力が別の操作のマップへの入力となるパイプラインに構成できます。
  • MapReduce計算の結果が広く使用されている場合、マテリアライズドビューとして保存できます。
  • マテリアライズドビューは、すべてを最初から再計算するのではなく、ビューへの変更のみを計算する増分MapReduce操作によって更新できます。

第12章

スキーマ移行

  • リレーショナルデータベースなどの強いスキーマを持つデータベースは、各スキーマ変更とそのデータ移行をバージョン管理されたシーケンスで保存することで移行できます。
  • スキーマレスデータベースでも、データにアクセスするコードの暗黙的なスキーマのために、慎重な移行が必要です。
  • スキーマレスデータベースは、強いスキーマを持つデータベースと同じ移行テクニックを使用できます。
  • スキーマレスデータベースは、データの暗黙的なスキーマの変更に耐性のある方法でデータを読み取り、増分移行を使用してデータを更新することもできます。

第13章

ポリグロットパーシスタンス

  • ポリグロットパーシスタンスとは、さまざまなデータストレージニーズに対応するために、異なるデータストレージテクノロジーを使用することです。
  • ポリグロットパーシスタンスは、エンタープライズ全体または単一のアプリケーション内で適用できます。
  • データアクセスをサービスにカプセル化すると、データストレージの選択がシステムの他の部分に与える影響を軽減できます。
  • データストレージテクノロジーを追加すると、プログラミングと運用が複雑になるため、適切なデータストレージの適合性による利点をこの複雑さと比較検討する必要があります。

第14章

NoSQLを超えて

  • NoSQLは、データストレージテクノロジーの1つのセットに過ぎません。ポリグロットパーシスタンスへの慣れが増すにつれて、NoSQLラベルが付いているかどうかにかかわらず、他のデータストレージテクノロジーを検討する必要があります。

第15章

データベースの選択

  • NoSQLテクノロジーを使用する主な理由は2つあります。

    • アプリケーションのニーズに最適に適合するデータベースを使用することで、プログラマの生産性を向上させるため。
    • より大きなデータ量の処理、レイテンシの削減、スループットの向上を組み合わせることで、データアクセスのパフォーマンスを向上させるため。
  • NoSQLテクノロジーの使用を決定する前に、プログラマの生産性やパフォーマンスに関する期待をテストすることが不可欠です。
  • サービスのカプセル化は、ニーズとテクノロジーの進化に合わせてデータストレージテクノロジーを変更することをサポートします。アプリケーションの一部をサービスに分離することで、既存のアプリケーションにNoSQLを導入することもできます。
  • 特に戦略的ではないほとんどのアプリケーションでは、少なくともNoSQLエコシステムが成熟するまでは、リレーショナルテクノロジーを使用する必要があります。

第8章から第11章はデータベースの使用例であるため、要点はありません。