ByteOrderedPartitioner

Cassandraは、順序指定パーティション用にこのパーティショナーを提供します。このパーティショナーは、後方互換性を維持するために含まれています。

Cassandraは、順序指定パーティション用にByteOrderedPartitionerを提供しています。このパーティショナーは、後方互換性を維持するために含まれています。このパーティショナーはキーのバイトに基づいて行を辞書順に順序付けます。パーティション・キー・データの実際の値を見て、キーの先頭の文字または文字群の16進数表現を使用してトークンを計算します。たとえば、行をアルファベット順にパーティション分割する場合は、Aのトークンを割り当てるのに、その16進数の表現である41を使用します。

順序指定パーティショナーを使用すると、プライマリ・キーに基づく順序指定スキャンを実行できます。つまり、従来のインデックスでカーソルを移動するのと同じように行をスキャンできるということです。たとえば、アプリケーションがパーティション・キーとしてユーザー名を使用する場合は、JakeとJoeの間の名前を持つユーザーを見つけるために行をスキャンできます。ランダムにパーティション分割されたパーティション・キーを使用する場合、キーがMD5ハッシュ値の順序（非連続）で格納されるため、この種のクエリーはできません。

行を対象に範囲スキャンが可能なことは、順序指定パーティションの魅力的な特徴に見えますが、テーブルのインデックスを使って同じことを実現する方法はあります。

順序指定パーティショナーの使用は、以下の理由から推奨されません。

ロード・バランスの難しさ

クラスターのロード・バランスをとるために、より多くの管理オーバーヘッドが必要になります。順序指定パーティショナーでは、管理者がパーティション・キーの分布を見積もって、それに基づいて手動でパーティション範囲を計算する必要があります。実際には、データが読み込まれた後で、実際のデータの分散に対応するために積極的なノード・トークン移動が必要です。

シーケンシャル書き込みによって生じるホット・スポット

アプリケーションが連続する行のかたまりを一度に書き込みまたは更新する傾向にある場合、書き込みはクラスター全体に分散されません。すべてが1つのノードに向けられることになります。これは、タイムスタンプ付きのデータを取り扱うアプリケーションでしばしば問題となります。

複数のテーブルの不均等なロード・バランス

アプリケーションに複数のテーブルがある場合、これらのテーブルの行キーおよびデータ分散はそれぞれに異なる可能性があります。あるテーブルではバランスが取れている順序指定パーティショナーが、同じクラスター内の別のテーブルではホット・スポットや不均等な分散を引き起こすかもしれません。