4.1 説明

Apache Cassandraは、NoSQL システムのクラスに属する分散データベース管理システムであり、ハッシュの形式で提示される巨大なデータ配列の拡張性と信頼性の高いストレージを作成するように設計されています。

当初、このプロジェクトは Facebook の内部で開発され、2009 年に Apache Software Foundation の傘下に移管され、この組織がプロジェクトの開発を続けています。Cassandra に基づく産業用ソリューションは、Cisco、IBM、Cloudkick、Reddit、Digg、Rackspace、Huawei、Netflix、Apple、Instagram、GitHub、Twitter、Spotify などの企業にサービスを提供するために展開されています。2011 年までに、Cassandra の下で単一のデータベースにサービスを提供する最大のサーバー クラスターには 400 台を超えるマシンがあり、300 TB を超えるデータが含まれていました。

Java 言語で書かれており、DynamoDB に似た分散ハッシュ システムを実装しており、データ量の増加に対してほぼ線形のスケーラビリティを提供します。これは、列のファミリーに基づくデータ ストレージ モデルを使用します。これは、キーと値のペアのみでデータを保存する MemcacheDB のようなシステムとは異なり、複数レベルのネストでハッシュを保存できます。

フォールト トレラント DBMS のカテゴリに属します。データベースに配置されたデータは、分散ネットワークの複数のノードに自動的に複製され、さらには複数のデータ センターに均等に分散されます。ノードに障害が発生すると、その機能は他のノードによってオンザフライで引き継がれ、クラスタに新しいノードが追加され、Cassandra バージョンの更新がオンザフライで行われます。追加の手動介入や他のノードの再構成は必要ありません。

ただし、負荷分散の品質を維持するために、既存のものも含めて各ノードのキー (ラベル) を再生成することを強くお勧めします。ノード数が複数回(2 回、3 回など)増加する場合、既存のノードに対する鍵の生成を回避できます。

4.2 データモデル

Cassandra の用語では、アプリケーションはキースペースを使用して動作します。キースペースは、リレーショナル モデルのデータベース スキーマの概念に対応します。このキースペースには、リレーショナル テーブルの概念に対応する複数の列ファミリーを含めることができます。

さらに、列ファミリーには列 (列) が含まれており、レコード (行) 内のキー (行キー) を使用して結合されます。列は、名前 (列名)、タイムスタンプ (タイムスタンプ)、および値 (値) の 3 つの部分で構成されます。レコード内の列は順序付けされています。リレーショナル データベースとは異なり、レコード (データベースの観点からは行) に他のレコードと同じ名前の列が含まれるかどうかに関する制限はありません。

列ファミリーにはいくつかの種類がありますが、この記事では詳細を省略します。また、Cassandraの最新バージョンでは、CQL言語を使用したデータの定義や変更(DDL、DML)のクエリの実行や、セカンダリインデックスの作成が可能になりました。

cassandra に保存されている特定の値は次のように識別されます。

  • キースペースはアプリケーション (ドメイン) へのバインディングです。同じクラスター上で異なるアプリケーションからのデータをホストできます。
  • 列ファミリーはクエリへのバインディングです。
  • key はクラスター ノードへのバインディングです。キーは、保存された列が最終的にどのノードに配置されるかを決定します。
  • 列名はレコード内の属性へのバインディングです。1 つのエントリに複数の値を保存できます。

各値は、記録中の競合を解決するために使用されるユーザー指定の数値であるタイムスタンプに関連付けられています。数値が大きいほど、新しい列が考慮され、比較されると古い列が上書きされます。

4.3 データ型

データ型別: キースペースと列ファミリーは文字列 (名前) です。タイムスタンプは 64 ビットの数値です。キー、列名、および列値はバイトの配列です。Cassandra にはデータ型の概念もあります。これらのタイプは、開発者が列ファミリーを作成するときに (オプションで) 指定できます。

列名の場合はコンパレータと呼ばれ、値とキーの場合はバリデータと呼ばれます。1 つ目は、列名に許可されるバイト値とその順序付け方法を定義します。2 つ目は、列とキーの値として有効なバイト値です。

これらのデータ型が設定されていない場合、実際には内部的に保存されているため、cassandra は値を保存し、バイト文字列 (BytesType) として比較します。

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

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

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

cassandra への書き込みは読み取りよりも高速です。これにより、設計で採用されるアプローチが変わります。データモデルの設計という観点からcassandraを考えると、列ファミリーをテーブルとしてではなく、マテリアライズドビュー(複雑なクエリのデータを表すが、それを保存する構造)として想像するのが簡単です。ディスク。

クエリを使用して何らかの方法でデータを構成しようとするのではなく、このクエリに必要になる可能性のあるすべてのものをターゲット ファミリに保存することを試みる方が良いでしょう。つまり、エンティティ間の関係やオブジェクト間の関係の側からではなく、クエリの側からアプローチする必要があります。つまり、どのフィールドを選択する必要があるのか​​。レコードをどのような順序で並べるか。主要なデータに関連するどのデータを一緒にリクエストする必要があるか - これらすべてはすでに列ファミリーに格納されている必要があります。

レコード内の列数は理論的には 20 億に制限されています。これは簡単な余談であり、詳細については、設計と最適化テクニックに関する記事を参照してください。次に、データを cassandra に保存して読み取るプロセスを詳しく見てみましょう。