3

Cassandras のドキュメントをたくさん読み、カウンターの変更などを確認しました。しかし、Cassandra には、その場でインクリメンタル シーケンスを生成するデフォルトの標準的な方法が同梱されていないようです。

私が見つけたのは、比較と設定を行ってIFステートメント/句を使用することだけです。

このようにして、ドキュメントの存在を確認し、存在しない場合はドキュメントを生成できます。これはクラスターと見なされるクォーラム アルゴリズムによって行われるため、使いやすく安全ですが、待ち時間が長くなります。

この待ち時間を回避するために、nextSequenceId を 1 ではなく 1000 ずつインクリメントすることで、1000 の ID を生成 (予約) できます。この方法では、最初の 1000 が生成されたときにのみレイテンシーの支払いが発生します (または、時期尚早に行われた場合、レイテンシーはほとんどありません)。

ホットスポットや混雑が発生することを理解しています。

この輻輳を回避する 1 つの方法は、より多くのシーケンス番号ジェネレーターをすべて異なるオフセット (モジュロ) で使用し、モジュロを選択して特定のシーケンス ジェネレーターをランダムに選択することで衝突の可能性を制限することです。

したがって、これは私の素朴な実装になります。

Cassandra 3.0 が登場して以来、私は次の 3 つのことを疑問に思います。

  1. Cassandra は、シーケンスを実装するよりスマートな方法を提供しますか?
  2. Cassandra は、これを実装する際の苦痛を和らげるものを提供していますか? つまり、比較して設定するよりも、読み取りを行うということです。もっと賢いものはありますか？
  3. ある種のシーケンス番号をすでに提供しているライブラリはありますか?
4

1 に答える 1

2

Jonathan は、このトピックの Jira をオープンしました - https://issues.apache.org/jira/browse/CASSANDRA-9200

3.0 はまだリリースされていませんが、コミッターは 3.0 の機能を最終決定しているようで、9200 が 3.1 に設定されているようです (これは、「3.0 の後のいつか」という意味です。おそらく 3.1、おそらく 3.2、おそらく 4.0)。

ご質問について:

1) いいえ、現時点では Cassandra でシーケンス処理を行う組み込みの方法はありません。

2）いいえ、厳密に増加していないシーケンスを許容できる場合は、読み取り前書き込みを行うか、ノードごとにシーケンスのセクションをブロックする必要があります

3) Twitter は Snowflake を一時的に公開しましたが ( https://github.com/twitter/snowflake )、現在は廃止されています。一般的に、私はタイプ 1 の UUID を使用する傾向があります。これは、タイムスタンプに基づいたランダムなコンポーネントです。UUID でさえ絶対確実というわけではありませんが、私たちのワークロードでは「十分」である傾向があります。Simpleflake ( http://engineering.custommade.com/simpleflake-distributed-id-generation-for-the-lazy/ ) は、私が提供したリンクでトレードオフについて説明し、独自のジェネレーターも提供しています。

于 2015-04-27T04:06:03.070 に答える