Как создать идентификаторы автоматического увеличения в Cassandra

Ответ 1

Создание глобальной последовательной последовательности номера на самом деле не имеет никакого смысла в распределенной системе. Используйте UUID.
(Потому что вы должны заставить всех участников согласиться и принять эволюцию последовательности - при наивной реализации)

Ответ 2

Как насчет следующего, используя Cassandra Легкие транзакции

1 - Создать таблицу идентификаторов:

CREATE TABLE ids (
  id_name varchar,
  next_id int,
  PRIMARY KEY (id_name)
)

2 - Вставьте каждый идентификатор, который вы хотите использовать глобальную последовательность с

Например:

INSERT INTO ids (id_name, next_id)
VALUES ('person_id', 1)

3 - Затем при вставке в таблицу, где вы хотите использовать автоматически увеличивающийся ключ, выполните следующие действия:

3.1 - Получите next_id из таблицы идентификаторов:

SELECT next_id FROM ids WHERE id_name = 'person_id'

Скажем, результат next_id = 1

3.2 - Приращение next_id следующим образом:

UPDATE ids SET next_id = 2 WHERE id_name = 'person_id' IF next_id = 1

Результат должен выглядеть так:

[{[applied]: True}]

Если он был успешно обновлен, OR

[{[applied]: False, next_id: 2}]

Если кто-то еще его уже обновил.

Итак, если вы получили True, используйте id '1' - он ваш. В противном случае добавьте next_id (или просто используйте возвращаемый next_id) и повторите процесс.

Ответ 3

Нет хорошего решения.

• Создайте столбец с номером, увеличьте число и сохраните его во всех репликах вместе с временным идентификатором, прочитайте все реплики и проверьте, является ли временный идентификатор "вашим", если он не повторится снова. Не отличное решение и не будет масштабироваться.

или

• Создайте свой собственный идентификатор, где вы получите свой следующий идентификатор. Эта услуга будет запускаться только в одном экземпляре и будет страшным фактором без масштабирования.

Как только что-либо выходит за рамки одного экземпляра, последовательность идентификаторов становится сложной, по крайней мере, если вы хотите, чтобы она масштабировалась. Это включает реляционные базы данных.

Ответ 4

существует счетный тип данных, который можно использовать. Рассмотрим приведенный ниже пример.

CREATE KEYSPACE counterks WITH REPLICATION =
{ 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3 };

Создайте таблицу для столбца счетчика.

CREATE TABLE counterks.page_view_counts
(counter_value counter,
url_name varchar,
page_name varchar,
PRIMARY KEY (url_name, page_name)
);

Загрузите данные в столбец счетчика.

UPDATE counterks.page_view_counts
SET counter_value = counter_value + 1
WHERE url_name='www.datastax.com' AND page_name='home';

Посмотрите на значение счетчика.

SELECT * FROM counterks.page_view_counts;

Выход:

 url_name         | page_name | counter_value
------------------+-----------+---------------
 www.datastax.com |      home |             1

Увеличьте значение счетчика.

 UPDATE counterks.page_view_counts
 SET counter_value = counter_value + 2
 WHERE url_name='www.datastax.com' AND page_name='home';

Посмотрите на значение счетчика.

 url_name         | page_name | counter_value
------------------+-----------+---------------
www.datastax.com |      home |             3  

Обратитесь к этому для более подробной информации: http://docs.datastax.com/en/cql/3.1/cql/cql_using/use_counter_t.html

Ответ 5

Этот вопрос довольно старый, но я хотел бы завершить его другим решением.

Любое решение, основанное на синхронизации узлов, необоснованно. Это наверняка сломается либо путем блокирования генерации идентификаторов, либо путем создания повторяющихся идентификаторов.

Способ MySQL

Вы можете воспроизвести способ репликации master-master mysql с параметрами auto_increment_increment и auto_increment_offset.

Чтобы воспроизвести его, вам нужно знать количество узлов или максимальное количество ожидаемых узлов, и вам нужно создать счетчик (не-кассандра) (файл на пример) на каждом node.

Каждый раз, когда вы хотите сгенерировать новый номер, вы найдете текущее значение, добавьте приращение и сохраните его. Если он еще не существует, это смещение.

Итак, для 10 узлов вы должны иметь приращение 10 и смещение 1 для первого node, 2 для второго node и т.д. Node 1 создаст идентификаторы 1, 11, 21. Node 2 создаст идентификаторы 2, 21, 22.

Если вы хотите, чтобы ваши идентификаторы были (приблизительно) упорядочены между узлами, вам необходимо поддерживать общий счетчик и убедиться, что каждый сгенерированный идентификатор выше общего счетчика. Таким образом, если ваши узлы/датацентры не синхронизированы в течение длительного времени, вы не должны заметить большой разницы.

Префикс

Вы можете сделать в основном то же самое, префикс ID (если это приемлемое решение) с номером Node (или именем). И вам не нужно знать количество узлов. Node 1 создаст 1_1, 1_2, 1_3. Node 2 создаст 2_1, 2_2, 2_3.

Ответ 6

Изменить: это решение неверно. См. Первый комментарий.

Мое решение:

1 - Создать таблицу идентификаторов:

CREATE TABLE ids (
  id_name varchar,
  next_id counter,
  PRIMARY KEY (id_name)
)

2 - При вставке в таблицу, в которой вы хотите использовать автоматически увеличивающийся ключ, выполните следующие действия:

2.1 - Счетчик нарастания (он будет создан, если не существует), используя самый высокий уровень согласованности

UPDATE ids
  SET next_id = next_id + 1
  WHERE id_name = $AUTO_INCREMENTED_ID
  USING CONSISTENCY ALL

2.2 - Получить новое значение id:

SELECT next_id
  FROM ids
  WHERE id_name = $AUTO_INCREMENTED_ID

2.3 - Вставьте значение с помощью автоматического увеличения id

INSERT INTO some_table ($AUTO_INCREMENTED_ID, ...)
  VALUES ($RESULT_FROM_PREVIOUS_QUERY, ...)

Слова, начинающиеся с '$' в моем ответе, ясны (я надеюсь) заполнители...

Конечно, это не рекомендуемый метод. Используйте его, только если вам нужно.

Ответ 7

Действительно ли они должны быть последовательными или вам просто нужно подсчитывать числа, которые намного меньше UUID, которые легко ввести человеком?

Если вам действительно нужны последовательные номера, вам нужно будет сделать одно из следующих.

• У вас есть таблица в cassandra, где ключ /id является полем для генератора, а значение - числом... выполняет условные обновления в цикле, пока вы не увеличите счетчик. (плохая идея)

• У вас есть служба генератора, которая даст вам следующий номер. Это может работать только на одной системе и быть единственной точкой отказа, но в зависимости от ваших потребностей это может быть лучше.

В качестве альтернативы... Подобно первой, но одновременно получайте партии по 100 или около того, и обрабатывайте их внутри вашего процесса/потока... У этого будет меньше конфликтов, но нет гарантии последовательного заказа, только уникальность... Если вам нужны только более короткие номера, которые уникальны для отображения, это может быть вашим лучшим выбором.

Ответ 8

Я думаю, что IMHO ожидает, что Cassandra автоматически предоставит автоинкремент.

Cassandra - это децентрализованная база данных, поэтому для ее создания поле для автоматического инкрементного контроля является облаганием налогом и побеждает цель, поскольку это значение должно быть затем сохранено в центральном месте

Следовательно, не делайте никаких решений, основанных на базе БД, для получения числа с автоматическим увеличением

Экземпляр создает идентификационный код или службу в вашем приложении, которые могут генерировать случайные уникальные идентификаторы и использовать их для сохранения в вашей базе данных, таким образом, цель и преимущество Cassandra не будут побеждены