このトピックでは、 cassandraがどのように配置されているか、つまり、分散型でフォールトトレラントで信頼性の高いキー値データベースについて説明します。 ストレージ自体が、 単一障害点 、サーバー障害、およびクラスターノード間のデータ分散の問題を処理します 。 さらに、サーバーを1つのデータセンター （ data center ）に配置する場合と、距離とそれに応じてネットワーク遅延で区切られた多くのデータセンターを備えた構成の両方の場合。 信頼性とは、データの最終的な一貫 性と、各リクエストの調整の一貫性を設定する機能を指します。



NoSQLデータベースでは、一般にSQLよりも内部構造をより深く理解する必要があります 。 この記事では基本的な構造について説明しますが、次の記事では検討することができます。CQLとプログラミングインターフェイス。 設計および最適化手法。 多くのデータセンターにあるクラスターの機能。

データモデル

cassandraの用語では、アプリケーションはキースペースで動作します。これは、リレーショナルモデルのデータベーススキーマの概念に対応してい ます 。 このキースペースには、リレーショナルテーブルの概念に対応するいくつかの列ファミリを含めることができます。 同様に、列ファミリには列 （ column ）が含まれ、これらはレコード （ row ）内のキー （ row key ）を使用して結合されます。 列は、 名前 （ 列名 ）、 タイムスタンプ （ タイムスタンプ ）、 値 （ 値 ）の3つの部分で構成されます 。 レコード内の列は順序付けられています。 リレーショナルデータベースとは異なり、レコード（およびデータベースに関してはこれらの行）が他のレコードと同じ名前の列を含むという事実に制限はありません-いいえ。 列ファミリにはいくつかの種類がありますが、この記事ではこの詳細を省略します。 また、cassandraの最新バージョンでは、 CQL言語を使用してデータ定義と変更要求 （ DDL 、 DML ）を実行し、 セカンダリインデックスを作成することが可能になりました。





cassandraに保存されている特定の値が識別されます。

• キースペースは、アプリケーション（ドメイン）へのバインドです。 1つのクラスターに異なるアプリケーションのデータを配置できます。
  
  
• 列ファミリ-これはリクエストへのバインドです。
  
  
• キーはクラスターノードにバインドされています。 保存された列がどのノードに入るかはキーに依存します。
  
  
• 列名は、レコード内の属性へのバインドです。 1つのレコードに複数の値を保存できます。
  
  

各値はタイムスタンプに関連付けられます-記録中の競合を解決するために使用されるユーザー定義の数値：数値が大きいほど列が新しくなり、比較すると古い列がグラインドされます。



データタイプ別：キースペースと列ファミリは文字列（名前）です。 タイムスタンプは64ビットの数値です。 キー、列名、列値はバイトの配列です。 Cassandraには、 データ型の概念もあります 。 これらのタイプは、列ファミリを作成するときに開発者がオプションで指定できます。 列名の場合、これはコンパレータと呼ばれ、値とキーの場合、 バリデーターと呼ばれます。 1つ目は、列名に有効なバイト値とその配置方法を決定します。 2番目は、列とキーの値に有効なバイト値です。 これらのデータタイプが指定されていない場合、cassandraは値を格納し、実際には内部的に格納されているため、 バイト文字列 （ BytesType ）として比較します。



データ型は次のとおりです。

• BytesType：任意のバイト文字列（検証なし）
  
  
• AsciiType：ASCII文字列
  
  
• UTF8Type：UTF-8文字列
  
  
• IntegerType：任意のサイズの数字
  
  
• Int32Type：4バイトの数値
  
  
• LongType：8バイト数
  
  
• UUIDType：第1または第4タイプのUUID
  
  
• TimeUUIDType：タイプ1 UUID
  
  
• DateType：8バイトのタイムスタンプ値
  
  
• BooleanType：2つの値：true = 1またはfalse = 0
  
  
• FloatType：4バイトの浮動小数点数
  
  
• DoubleType：8バイトの浮動小数点数
  
  
• DecimalType：任意のサイズと浮動小数点数
  
  
• CounterColumnType：8バイトのカウンター
  
  

cassandraでは、すべてのデータ書き込み操作は常に書き換え操作です。つまり、同じキーと同じ名前の列がすでに存在し、タイムスタンプが列ファミリーに保存されている列よりも大きい場合、値は上書きされます。 記録された値は変更されず、新しい値を持つ新しい列のみが表示されます。



cassandraへの書き込みは、読み取りよりも速く動作します。 これにより、設計で使用されるアプローチが変わります。 データモデルの設計の観点からcassandraを検討する場合、カラムファミリーをテーブルとしてではなく、 マテリアライズドビューとして想像する方が簡単です。これは、複雑なクエリのデータを表すがディスクに格納する構造です。 何らかの方法でクエリを使用してデータを作成しようとする代わりに、このクエリに必要なすべてのものを最終的なファミリに保存することをお勧めします。 つまり、エンティティ間の関係やオブジェクト間の関係の側面からではなく、クエリの側面からアプローチする必要があります。どのフィールドを選択する必要があるか。 記録はどの順番で行くべきか; 主要なデータに関連するデータを共同で要求する必要があります-これらはすべて列ファミリに既に保存されている必要があります。 レコード内の列の数は、理論的には20億に制限されています。 これは簡単な余談ですが、詳細は、設計と最適化の手法に関する記事に記載されています。 それでは、cassandraにデータを保存して読み取るプロセスを詳しく見ていきましょう。

データ配信

クラスタノード間のキーに応じてデータがどのように分散されるかを検討します 。 Cassandraでは、データ配布戦略を定義できます。 最初のこのような戦略は、md5キー値に応じてデータを配布します- ランダムパーティショナー （ random partitioner ）。 2番目は、キー自体のビット表現- 順序マークアップ （ バイト順パーティショナー ）を考慮に入れます。 ほとんどの場合、最初の戦略はより多くの利点を提供します。サーバー間でのデータの均等な分散や同様の問題を心配する必要がないためです。 2番目の戦略は、まれに、たとえば範囲スキャンが必要な場合に使用されます。 この戦略の選択はクラスターを作成する前に行われ、実際には完全なデータの再読み込みなしでは変更できないことに注意することが重要です。



Cassanderは、 一貫性のあるハッシュと呼ばれる手法を使用してデータを配布します。 このアプローチにより、ノード間でデータを分散し、新しいノードを追加および削除するときに送信されるデータの量が少なくなるようにすることができます。 これを行うには、各ノードにラベル （ token ）が割り当てられます。これにより、すべてのmd5キー値のセットが細分化されます。 ほとんどの場合、RandomPartitionerが使用されるため、考慮してください。 前述したように、RandomPartitionerは各キーに対して128ビットのmd5を計算します。 データを保存するノードを決定するために、ノードのすべてのラベルが最小から最大に並べ替えられ、ラベル値がキーのmd5値より大きくなると、このノードとそれに続くいくつかのノード（ラベルの順序で）が保存用に選択されます。 選択したノードの総数は、 複製係数と等しくなければなりません。 レプリケーションレベルはキースペースごとに設定され、 データの冗長性を調整できます 。







クラスターにノードを追加する前に、ノードのラベルを設定する必要があります。 このラベルと次のラベルの間のギャップをカバーするキーの割合は、ノードに保存されるデータの量によって異なります。 クラスタのラベルのセット全体をリングと呼びます。



これは、 nodetoolユーティリティを使用して均等に分散されたラベルを持つ6つのノードのクラスターリングを示す図です。

データの一貫性

cassandraクラスターのノードは同等であり、クライアントは書き込みと読み取りの両方のためにそれらのいずれかに接続できます。 要求は調整段階を通過します。この段階で、キーとスクライブの助けを借りて、データを配置するノードを見つけ、サーバーはこれらのノードに要求を送信します。 調整を実行するノードをコーディネーターと呼び、このキーでレコードを保存するために選択されるノードはレプリカノードです。 物理的には、レプリカノードの1つがコーディネーターになることができます。これは、キー、マークアップ、ラベルのみに依存します。



読み取りと書き込みの両方のリクエストごとに、データの一貫性のレベルを設定できます。



記録の場合、このレベルは、ユーザーに制御を戻す前に、正常な操作の確認が期待される（データが記録されている）レプリカノードの数に影響します。 記録には、次のような一貫性のレベルがあります。

• ONE-コーディネーターはすべてのレプリカノードに要求を送信しますが、最初のノードからの確認を待った後、ユーザーに制御を返します。
  
  
• TWOも同じですが、コーディネーターは最初の2つのノードからの確認を待ってから制御を返します。
  
  
• THREE-同様に、コーディネーターは最初の3つのノードからの確認を待ってから制御を返します。
  
  
• QUORUM-クォーラムが収集されています。コーディネーターは、レプリカノードの半分以上、つまりラウンド（N / 2）+ 1からのレコードの確認を待機しています。Nはレプリケーションのレベルです。
  
  
• LOCAL_QUORUM-コーディネーターは、コーディネーターが配置されている同じデータセンター内のレプリカノードの半分以上からの確認を待機しています（各リクエストに対して）。 他のデータセンターへのデータ送信に関連する遅延を取り除くことができます。 この記事では、多くのデータセンターで作業する際の問題について説明しています。
  
  
• EACH_QUORUM-コーディネーターは、各データセンターのレプリカノードの半数以上からの確認を個別に待機しています。
  
  
• ALL-コーディネーターは、すべてのレプリカノードからの確認を待っています。
  
  
• ANY-すべてのレプリカノードが応答しない場合でも、データを書き込むことができます。 コーディネーターは、レプリカノードの1つからの最初の応答を待つか、コーディネーターのヒント付きハンドオフを使用してデータが保存されると待機します。
  
  

読み取りの場合、一貫性のレベルは、読み取られるレプリカノードの数に影響します。 読むために、そのような一貫性のレベルがあります：

• ONE-コーディネーターは、最も近いレプリカノードにリクエストを送信します。 残りのレプリカも、cassandra構成で指定された確率で読み取り修復のために読み取られます。
  
  
• TWOも同じですが、コーディネーターはリクエストを最も近い2つのノードに送信します。 大きなタイムスタンプを持つ値が選択されます。
  
  
• THREE-前のオプションに似ていますが、3つのノードがあります。
  
  
• QUORUM-クォーラムが収集されています。つまり、コーディネーターはレプリカノードの半分以上、つまりラウンド（N / 2）+ 1に要求を送信します。Nはレプリケーションのレベルです。
  
  
• LOCAL_QUORUM-クォーラムは、調整が行われるデータセンターで収集され、最後のタイムスタンプを持つデータが返されます。
  
  
• EACH_QUORUM-コーディネーターは、各データセンターでの定足数会議の後、データを返します。
  
  
• ALL-コーディネーターは、すべてのレプリカノードから読み取った後にデータを返します。
  
  

したがって、読み取り、書き込み操作の遅延時間を調整し、 整合性を調整 （ 整合性を調整 ）するだけでなく、各タイプの操作の可用性 （ 可用性 ）を調整することもできます 。 実際、アクセシビリティは、読み書き操作の一貫性のレベルに直接依存します。これは、障害が発生する可能性のあるレプリカノードの数を決定し、同時にこれらの操作が確認されるためです。



読み取り確認が行われたノードの数と合わせて書き込み確認が受信されたノードの数がレプリケーションレベルよりも大きい場合、書き込み後に新しい値が常に読み取られるという保証があり、これは厳密な整合性 （ strong一貫性 ）。 厳密な一貫性がない場合、読み取り操作で古いデータが返される可能性があります。



いずれにせよ、値は最終的にレプリカ間で広がりますが、調整待機が終了した後にのみです。 この分布は、 結果整合性と呼ばれます。 記録中にすべてのレプリカノードが使用できない場合、遅かれ早かれ、読み取り修復やアンチエントロピーノード修復などの回復ツールが使用されます。 これについては後で詳しく説明します。



したがって、QUORUMの読み取りおよび書き込みの一貫性レベルでは、厳密な一貫性が常に維持されます。これは、読み取り操作と書き込み操作の遅延の一種のバランスになります。 ALLを書き込むとき、1つを読み取りながら、厳密な一貫性があり、読み取り操作はより速く、よりアクセスしやすくなります。つまり、読み取りがまだ実行される障害ノードの数は、QUORUMよりも多くなります。 書き込み操作には、すべてのレプリカ作業ノードが必要です。 ONEを書き込み、ALLを読み取る場合も、厳密な一貫性があり、書き込み操作が高速になり、書き込みアクセシビリティが大きくなります。これは、少なくとも1つのサーバーで書き込み操作がパスしたことを確認するだけで十分であり、読み取りが遅くなり、すべてのレプリカノードが必要になるためです。 アプリケーションが厳密な一貫性を必要としない場合、読み取りおよび書き込みの両方の操作を高速化し、一貫性を低く設定することでアクセシビリティを向上させることが可能になります。

データ復旧

Cassandraは、3つのデータ回復メカニズムをサポートしています。

• 読み取り修復 -すべてのレプリカからデータの読み取りが要求され、調整が完了した後に比較されます。 最新のタイムスタンプを持つ列は、ラベルが古いノードに拡張されます。
  
  
• 方向送信 （ ヒント付きハンドオフ ）-いずれかのノードでの記録が失敗した場合に、コーディネーターでの書き込み操作に関する情報を保存できます。 後で、可能であれば、記録が繰り返されます。 クラスター内にノードが短期的に存在しない場合に、データ回復を迅速に実行できます。 さらに、一貫性のレベルでは、ANYはすべてのレプリカノードが使用不可になり、書き込み操作が確認され、データがコーディネーターノードに保存されるときに、 絶対書き込み可用性を考慮します。
  
  
• アンチ エントロピーノード修復は、すべてのレプリカを回復する特定のプロセスであり、「nodetool repair」コマンドを使用して定期的に手動で開始する必要があり、最初の2つの方法で復元されなかったすべてのデータのレプリカの数を維持できます。必要な複製レベル。
  
  

ディスクへの書き込み

書き込みのためにノードに直接調整した後、データが到着すると、 メモリ内のテーブル （ memtable ）とコミットログの 2つのデータ構造に分類されます 。 カラムファミリごとにメモリテーブルが存在し、値をすぐに覚えることができます。 技術的には、 skip listと呼ばれるデータ構造に基づいた同時アクセスを伴うハッシュマップです。 ピンログは、キースペース全体に対するものであり、ディスクに保存されます。 ジャーナルは一連の変更操作です。 また、特定のサイズに達すると断片になります。



このような構成により、ハードディスクへのシーケンシャル書き込み速度によって記録速度を制限すると同時に、 データの耐久性を保証できます 。 ノードの緊急停止の場合、pinログはcassandraサービスの開始時に読み取られ、メモリ内のすべてのテーブルを復元します。 ディスクへの順次記録中は速度が停止し、最新のハードドライブの場合は約100MB /秒です。 このため、ピンログは別のディスクドライブに配置することをお勧めします。



遅かれ早かれ、メモリがいっぱいになる可能性があることは明らかです。 したがって、メモリ内のテーブルもディスクに保存する必要があります。 保存の瞬間を決定するために、 メモリ内の占有テーブルのサイズ （ memtable_total_spacein_mb ）には制限があります。デフォルトでは、 Javaヒープ （ Java ヒープ スペース ）の最大サイズです。 この制限を超えるメモリでテーブルを埋めると、cassandraは新しいテーブルを作成し、メモリ内の古いテーブルを保存されたテーブル （ SSTable ）としてディスクに書き込みます 。 作成後に保存されたテーブルは変更されません（ 不変です ）。 ディスクへの保存が発生すると、ピンログの一部が空きとしてマークされるため、ジャーナルが占有するディスク領域が解放されます。 ログはキースペースの異なる列ファミリーのデータから織り交ぜられた構造を持ち、一部の領域はメモリ内のテーブルにある他のデータに対応するため、一部が解放されない可能性があることを考慮する必要があります。







その結果、各列ファミリはメモリ内の1つのテーブルと一定数の保存されたテーブルに対応します。 ノードは読み取り要求を処理しているため、これらの構造をすべて要求し、最新のタイムスタンプ値を選択する必要があります。 このプロセスを高速化するには、 ブルーム フィルター 、 キーキャッシュ、 レコードキャッシュの 3つのメカニズムがあります。

• ブルームフィルターは、ほとんどスペースをとらないデータ構造であり、質問に答えることができます。含まれている要素であり、この場合は、セット内のキーであるかどうかです。 さらに、答えが「いいえ」の場合、それは100％であり、答えが「はい」の場合、これはおそらく偽陽性の答えです。 これにより、保存されたテーブルからの読み取り値の数を減らすことができます。
  
  
• キーキャッシュは各キーの記録ディスク上の位置を維持するため、保存されたテーブルの検索中にシーク操作の回数が減ります。
  
  
• 書き込みキャッシュは記録全体を保存するため、ディスクの読み取り操作を完全に取り除くことができます。
  
  

シール

特定の時点で、列ファミリのデータは上書きされます。同じ名前とキーを持つ列が来ます。 つまり、古いデータと新しいデータが、保存されている古いテーブルと新しいテーブルに含まれる状況が発生します。 整合性を保証するために、cassandraはこれらすべての保存されたテーブルを読み取り、最新のタイムスタンプを持つデータを選択する必要があります。 読み取り時にハードドライブを配置する操作の数は、保存されているテーブルの数に比例することがわかりました。 したがって、上書きされたデータを解放し、格納されるテーブルの数を減らすために、 圧縮プロセスがあります 。 いくつかの保存されたテーブルを順番に読み取り、タイムスタンプによってデータを結合する新しい保存されたテーブルを書き込みます。 テーブルが完全に記録され、使用されると、cassandraはソーステーブルを（テーブルを形成したテーブルによって）解放できます。 したがって、テーブルに上書きデータが含まれている場合、この冗長性は排除されます。 このような操作の間、冗長性の量が増加することは明らかです。新しい保存されたテーブルがソーステーブルと共にディスク上に存在します。つまり、ディスク領域の量は常に圧縮できる程度でなければなりません。







Kassandraでは、圧縮を実行するための2つの戦略のいずれかを選択できます。

• サイズによってリンクされた格納テーブルを要約するための戦略（ サイズ階層圧縮 ）-この戦略は、選択された2つのテーブルを特定の方法で圧縮します。 バックグラウンドコンパクション （ マイナーコンパクション ）の形式で、および完全コンパクション （ メジャーコンパクション ）のために手動モードで自動的に適用されます。 これにより、多くのテーブルでキーを見つけることができるため、そのようなテーブルごとに検索操作が必要になります。
  
  
• レベル圧縮戦略 -最初は小さく作成された保存済みテーブルを圧縮します-5 MB、レベルにグループ化します。 各レベルは、前のレベルの10倍です。 さらに、そのような保証があります：読み取り要求の90％が1つの保存されたテーブルに対して発生し、ディスク領域の10％のみが古いデータに使用されます。 この場合、一時テーブルの下で圧縮を実行するには、テーブルのサイズの10倍、つまり50 MBで十分です。 詳しくは、この記事をご覧ください。
  
  

削除操作

内部構造の観点から見ると、列削除操作は特別な値- 廃棄（tombstone）を書き込む操作です。 読み取りの結果としてそのような値が取得されると、そのような値は存在しないかのようにスキップされます。 圧縮の結果として、そのような値は、古い実際の値を徐々に置き換え、場合によっては完全に消えます。 実際のデータを持つ列がさらに新しいタイムスタンプで表示される場合、それらは最終的にこれらの上書きされた値を粉砕します。

トランザクション

Cassandraは、1つのレコードのレベル、つまり1つのキーを持つ列のセットでトランザクション性をサポートします。 4つのACID要件を満たす方法は次のとおりです。

• 原子性-1つの操作で1つのレコードのすべての列が記録されるかどうか。
  
  
• 一貫性 （ 一貫性 ）-既に上記で述べたように、可用性の代わりに厳密な一貫性を持つ要求を使用することが可能であり、それによりこの要件を満たします。
  
  
• 分離 -cassandraバージョン1.1以降、1つのレコードの列の記録中に同じレコードを読み取る別のユーザーが、レコードの完全に古いバージョン、または操作が完了した後、一部ではなく新しいバージョンを見ると、分離のサポートが現れました1番目の列と2番目の列。
  
  
• 定着ジャーナルが存在することにより、 耐久性が確保されます。定着ジャーナルは、障害が発生した場合にノードを望ましい状態に複製および復元します。
  
  

あとがき

そこで、基本的な操作がどのように配置されているかを調べました-cassandraへの値の読み取りと書き込み。



さらに、私の意見では、重要なリンクは次のとおりです。

• apache.orgのページcassandra.apache.org
  
  
• datastax.comのドキュメントwww.datastax.com/docs/1.1/index#apache-cassandra-1-1-documentation
  
  
• BigTableについてresearch.google.com/archive/bigtable.html
  
  
• Amazon Dynamo Pro www.allthingsdistributed.com/2007/10/amazons_dynamo.html
  
  
• データモデルmaxgrinev.com/2010/07/09/a-quick-introduction-to-the-cassandra-data-modelに関するブログの1つ
  
  

リクエスト：スペルに関するコメントと記事を改善するためのアイデアを個人的なメッセージで表現します。