2007 年に開発されて以来、 Apache Cassandra は、世界最大級の企業で使用されている、堅牢でスケーラビリティと信頼性に優れた NoSQL データ ストアとしての評判を築いてきました。ただし、Cassandra を使用するには、ある程度の経験と専門知識も必要です。したがって、このオープン ソース データベースについて学ぶときに多くの疑問が生じることは理解できます。
この記事では、さまざまなコミュニティ フォーラムで開発者から寄せられるよくある質問について説明します。
ワイドカラム データベースの主キーがリレーショナル主キーとどのように異なるかを理解することは、Cassandra の能力を活用することを学ぶ上で重要なステップです。
Cassandra のような幅の広い列のストアでは、従来のリレーショナル データベース テーブルと同様に、一緒に使用される関連データの複数の列を含むデータベース オブジェクトである列ファミリーの概念が使用されます。特定の列ファミリ内では、すべてのデータが行ごとに格納され、各列が個別に格納されるのではなく、特定の行の列が一緒に格納されます。
別の言い方をすれば、列ファミリーはキーと値のペアであり、キーは列のセットである値にマップされます。リレーショナル データベースに例えると、列ファミリーは「テーブル」のようなもので、各キーと値のペアが「行」です。開発者にとって、幅の広い列のテーブルは、コードまたは API を介して、慣れていて操作しやすい行と列のテーブルとして表示できます。
概念を実現するのに役立つコード例をいくつか見てみましょう。
上記のコードには、キースペースと、「都市」、「姓」、「名」などのフィールドがあります。主キーは一番下にあります。ちなみに、Cassandra のすべてのテーブルには、少なくとも 1 つのパーティション キーが含まれている必要があります。上の画像で強調表示されている例では、「都市」で分割します。
それ以外はクラスター列です。 「city」を囲む括弧に注目してください。これは、これがパーティション キーであることを示しています。パーティション キーが複合型で複数の列がある場合は、かっこを使用してパーティション キーを示します。次に、どの列が主キー用で、どの列がクラスタリング列であるかが明確になります。
主キーの主な目的は、行が一意であることを確認することです。また、並べ替えを制御できる 0 個以上のクラスタリング列を含めることもできます。ただし、主キーは「複合」または「複合」にすることもできます。これは、2 つ以上の列があることを意味します。
パーティション キーは行を分割するために使用され、1 つ以上の列があります。
一部の人々は、ドライバー クライアントがランダムなノードにデータを送信するだけだと考えているようです。しかし、実際には、ドライバーが対話するノードを選択する非ランダムな方法があります。このノードは、コーディネーター ノードと呼ばれます。最も近いため、通常は選択されます。
クライアント要求は任意のノードに送信できます。最初は、ドライバーが認識しているノードに送信されます。しかし、ドライバー ソフトウェアが接続してクラスターのトポロジーを理解すると、より近いコーディネーターに変わる可能性があります。オープンソース エコシステム プロジェクトのStargateを調べて、スケーラビリティのためにコンピューティングとストレージを分離する方法を確認してください。
オープン ソースの Cassandra クラスター内のノードは、ゴシップ プロトコルを使用して相互にトポロジー情報を交換します。 gossiper は毎秒実行され、設定したスニッチからのデータですべてのノードが最新の状態に保たれます。スニッチは、各ノードが属するデータ センターとラックを追跡します。このように、コーディネーターノードは、各トークン範囲を担当するノードに関するデータも持っています。
この情報は、コマンド ラインからノード ツール「リング」を実行することで確認できますが、仮想ノードまたは「vnode」を使用している場合は、256 個すべての仮想ノードのデータとして確認するのが少し難しくなります (デフォルトでは量) が画面のそばですばやく点滅します。
K8ssandra.ioでは、この動作はより Kubernetes ネイティブであり、Gossip プロトコルの代わりに Etcd が使用されて、クラスター メタデータと安全なスキーマ更新が伝達されます。
索引付けはかなり微妙です。データベースの内部構造を理解するのに役立ちます。このクエリは、Cassandra の内部でどのように機能しますか?次のコード例を見てください。
このクエリは、Cassandra の内部でどのように機能しますか?
基本的に、スコープ ID が 35 でフォーム ID が 78005 のパーティションのすべてのデータが返され、レコード リンク ID インデックスによってフィルター処理されます。 9897 のレコード インデックス ID エントリを検索し、返されたスコープ ID が 35 でフォーム ID が 78005 の行に一致するエントリを照合しようとします。パーティション キーとインデックス キーの行の共通部分が返されます。 .
レコード リンク ID インデックスのようなカーディナリティの高い列がそのクエリのパフォーマンスに影響を与えるかどうかを疑問に思うかもしれません。基本的に、カーディナリティの高いインデックスでは、メイン テーブルのほとんどのエントリごとに行が作成されます。 Cassandra はクエリ結果の順次読み取り用に設計されているため、パフォーマンスが影響を受ける可能性があります。インデックス クエリは基本的に、インデックスのカーディナリティが増加するにつれて、Cassandra にランダムな読み取りを実行させるため、クエリされた値を見つけるのにかかる時間も増加します。
では、Cassandra は上記のクエリのすべてのノードにアクセスするでしょうか?いいえ、スコープ ID が 35 で、フォーム ID が 78005 パーティションであるノードにのみ接続する必要があります。同様に、インデックスはローカルに保存され、ローカル ノードで有効なエントリのみが含まれます。
Cassandra はオープン ソースの NoSQL データベースであり、おそらく毎日使用している分散アプリケーションを大規模に強化します。ただし、自己管理はあなたとあなたのチーム次第です。
一方、 Astra DBはサーバーレスのサービスとしてのデータベースです。これは、Cassandra 上に構築されたフル マネージドの自動スケーリング クラウド サービスであり、選択したパブリック クラウド プロバイダー上で実行されます。
オープン ソース データ API ゲートウェイStargateの追加により、Cassandra と Astra DB の両方が、ドキュメント、列、およびキーと値の NoSQL ワークロードを処理します。また、Astra DB を使用すると、Stargate が自動的にセットアップされます。
カサンドラについてもっと知りたいですか? 3 月 14 日に開催される無料のデジタル イベント、 Cassandra Forwardにご参加ください。
ここにも掲載されています。