複合主キーの一意のキーとして文字列 (約 6 ～ 7 文字程度) を使用したいと考えています。
主キーに文字列を使用するとパフォーマンスが低下するかどうかをグーグルで検索しましたが、Cassandraが一意のキーの検索にハッシュを使用しているため、そうではないことがわかりました.(誰かがこれを確認してください)
それで、Cassandraが一意のキーを検索するためにどの手法を使用するかを知りたいのですが、ハッシュを使用する場合、どのハッシュアルゴリズムを使用しますか? また、ハッシュでは常に衝突の可能性があるため、衝突の場合に Cassandra が何をするかを知りたいです。
Cassandra は、パーティション キーの操作に murmur3 ハッシュを使用します。一意のキーを検索するために同じものを使用しますか? では、衝突はどうでしょうか。
複合キーについて言及したので、このような PK があると仮定しています。PRIMARY KEY(PartionKey, StringVal) の StringVal は 6 ～ 7 文字で、C* がこの PK を効率的に記録する方法を知りたいと思います。これがあなたの質問なら、答えは C* がデータを保管する方法にあります。この例では、特定のパーティション キーのすべてのデータが、'StringVal' を並べ替え順序として使用して、1 つの物理行として格納されます。したがって、特定の PartionKey 値に対して 100 万個の一意の「StringVal」がある場合、それらはすべて (ディスク上の) 1 つの物理行としてノード (Partionkey のハッシュによって決定) に格納され、デフォルトの昇順で並べ替えられます。 「StringVal」の順序。パーティション キー以外の PK 内のすべての列は、クラスタリングの順序を決定するため、「クラスタリング」列と呼ばれます。したがって、この例では、複合キーの最初の列はパーティション キーで、2 番目の列はパーティション キーのすべてのレコードのクラスタリング順序を決定するクラスタリング列です。特定の PK レコードを取得したい場合、C* は主キーのオフセットをインデックス ファイル (-列ファミリーの Index.db ファイル) PK の特定のレコードに到達することは、その場所へのシークを伴うため、非常に効率的です。また、これにより、Cで効率的な範囲クエリを実行することもできます。たとえば、'nnn' > sv < 'mmm' のように 'StringVal' の範囲を指定することで、パーティション キーに対応する物理行のスライスを取得できます。字句順序の比較。しかしポイントは、ディスク上の特定の順序であり、C* は 'StringVal' の値に対応するさまざまなレコードにオフセットしているため、非常に効率的なシークを実行できるということです。