DataStaxドライバーのベスト・プラクティス

これらのルールと推奨事項に従うことより、DataStaxドライバーを使用するアプリケーションのパフォーマンスが向上し、リソース使用率を最小限に抑えることができます。

これらのルールと推奨事項に従うことより、DataStaxドライバーを使用するアプリケーションのパフォーマンスが向上し、リソース使用率を最小限に抑えることができます。

アプリケーションごとに1つのセッション・オブジェクトを使用する

アプリケーションの有効期間に対して1つのセッションを作成し、それを再利用します。セッションは、クラスター内のすべてのノードへの接続プールを初期化および維持するため、作成の負荷が高くなります。1つのドライバー・セッションで数千のクエリを同時に処理できます。1つのドライバー・セッションを使用して、アプリケーション内のすべてのクエリを実行してください。クラスターごとに1つのセッションを使用すると、ドライバーは同じノード宛てのクエリーを結合できるため、システムコールのオーバーヘッドを大幅に削減できます。

注: キースペースごとにセッションを作成することは推奨されません。アプリケーションは、クエリー文字列で完全修飾キースペースを使用するか、ステートメント・オブジェクトに明示的にキースペースを設定する必要があります。アプリケーションは、クエリー文字列で完全修飾キースペースを使用するか、ステートメント・オブジェクトに明示的にキースペースを設定する必要があります。
表 1. セッションのAPIリファレンス
C/C++ C# Java Node.js PHP Python Ruby

物理クラスターごとに1つのクラスター・オブジェクトを使用する

物理クラスターごとに1つのクラスター・オブジェクトを作成するクラスター・オブジェクトは、特定のクラスターへのコントロール接続を維持するため、作成することは、比較的負荷が高くなります。物理クラスターごとに複数のクラスター・オブジェクトを作成すると、これらのリソースが不必要に複製されます。
重要: 各セッションが独自のクラスター状態を維持するため、このルールは、C/C++およびOSS Java 4.X / DSE Java 2.xドライバーには適用されません。ただし、アプリケーションごとに1つのセッションという規則は、適用されます。
注: Node.jsドライバーは、セッションとクラスターの概念を1つのクライアント・インタフェースに組み合わせます。
表 2. クラスターのAPIリファレンス
C/C++ C# Java Node.js PHP Python Ruby

スループットを高めるために非同期でクエリーを実行する

最大のスループットを得るには、非同期APIを使用します。非同期APIは、アプリケーションの進行を阻害せずにすぐに戻る実行メソッドを提供し、1つのアプリケーション・スレッドが多数のクエリーを同時に実行できるようにします。非同期実行メソッドは、クエリー結果とエラーが発生した場合にアプリケーションでエラーを取得するために使用できる将来のオブジェクトを返します。多くのクエリーを同時に実行することにより、アプリケーションはクエリー処理を最適化し、ドライバーがクエリー要求を結合する能力を向上させ、サーバー側リソースの使用を最大化します。

図 1. 非同期クエリー

非同期クエリー

頻繁に実行するクエリーにプリペアド・ステートメントを使用する

複数回使用されるクエリーを準備します。クエリーを準備することで、サーバーとドライバーはクエリーの実行に必要な処理とネットワークデータの量を減らすことができます。プリペアド・ステートメントの場合、サーバーはクエリーを1回解析し、それがアプリケーションの存続期間中、キャッシュに格納されます。サーバーは、最初の準備ステップ後に応答メタデータを送信することも避けます。これにより、ネットワークを介して送信されるデータと、対応するクライアント側の処理が削減されます。

表 3. プリペアド・ステートメントのAPIリファレンス
C/C++ C# Java Node.js PHP Python Ruby

データ・センター認識ロード・バランス機能を使用する場合にローカル・データ・センターを明示的に設定する

データ・センター認識ロード・バランス・ポリシーを使用する場合、ドライバーがコンタクト・ポイントからローカル・データ・センターを推測することを許可せずに、アプリケーションでローカルデータ・センターを明示的に設定する必要があります。ドライバーが間違ったローカル・データ・センターを選択した場合、データ・センター間のトラフィックが増加します。これは、多くの場合、データ・センター間のトラフィックよりも待ち時間が長く、金銭的コストを増加させます。ローカル・データ・センターを明示的に設定すると、ドライバーが間違ったローカル・データ・センターを選択する可能性がなくなります。

ドライバー接続を構成する場合、リモート・データ・センターまたは無効なデータ・センターにコンタクト・ポイントを簡単に含めることができます。たとえば、アプリケーションに、テスト中に使用される内部データ・センターのコンタクト・ポイントを含める場合があります。ローカル・データ・センターを明示的に設定することで、上記のエラーを回避できます。

表 4. ロード・バランス機能のためのAPIリファレンス
C/C++ C# Java Node.js PHP Python Ruby

ワークロードの削除とnullの書き込みを避ける

DSEおよびCassandraでは、トゥームストーンはテーブル・データが論理的に削除されたことを示すマーカーです。DSEとCassandraは、更新を不変のSSTableファイルに保存して、スループットを維持し、古いデータの読み取りを防ぎます。削除されたデータ、Time To Live（TTL）データ、およびnull値は廃棄標識を作成します。これにより、データベースは論理的に削除されたデータをクラスター全体で新しいクエリーと調整できます。トゥームストーンは分散データベースの必要な副産物ですが、トゥームストーンの数を制限し、トゥームストーンの作成を回避することで、データベースとアプリケーションのパフォーマンスが向上させることができます。

多くの場合、データ・モデリング手法を使用して削除を回避できます。適切なクエリー構築により、nullを回避できます。トゥームストーンの詳細については、DataStax Academyのこの記事を参照してください。

大量の削除とnullは追加のディスク領域を使用し、読み取りのパフォーマンスを低下させます。トゥームストーンは警告を発生させ、エラーを記録する可能性があります。

たとえば、以下のスキーマについて考えます。

CREATE TABLE test_ks.my_table_compound_key (
        primary_key text,
        clustering_key text,
        regular_col text,
        PRIMARY KEY (primary_key, clustering_key)
        )

このクエリーでは、regular_colのトゥームストーンは作成されません。

INSERT INTO my_table_compound_key (primary_key, clustering_key) 
        VALUES ('pk1', 'ck1');

しかし、このクエリーでは、regular_colのトゥームストーンが作成されます。

INSERT INTO my_table_compound_key (primary_key, clustering_key, regular_col) 
        VALUES ('pk1', 'ck1', null);