使用Cassandra 3.0進行序列生成器/自動增量

Question

我閱讀了很多Cassandras文檔並檢查了Counter的變化等。 但它的接縫是Cassandra沒有提供默認和標准的方式來動態生成增量序列。

我發現只是通過比較和設置來使用IF語句/子句。

通過這種方式，可以檢查文檔是否存在，如果不存在則生成文檔。 由於這是通過被視為群集的仲裁算法來完成的，因此它應該易於使用且安全但具有高延遲。

為了避免這種延遲，可以通過將nextSequenceId遞增千而不是1來生成（保留）一千個ID。 這種方式只有在生成千位中的第一個時才支付延遲（或者如果它過早地完成它將幾乎沒有延遲）。

我知道這樣做會造成熱點或擁堵。

避免這種擁塞的一種方法是使用更多的序列號生成器，所有序列號生成器都通過不同的偏移量（模數）並通過選擇模來隨機選擇某個序列生成器來限制沖突的可能性。

所以這將是我天真的實施。

自從Cassandra 3.0上街以來，我只想知道三件事：

1. Cassandra是否提供了一種更智能的序列實現方式。
2. Cassandra是否提供了一些緩解實現這一目標的痛苦？ 我的意思是我做了一個閱讀，而不是比較和設置。 還有更聰明的東西嗎？
3. 是否存在任何庫已經給我一種序列號？

Answer 1

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/ ）討論了我提供的鏈接的權衡，並提供了自己的生成器。