Уникальный целочисленный счетчик в RethinkDb

Question

Предположим, я хочу создать модель для создания некоторых виджетов в RethinkDB. Процесс сборки начинается, get имеет уникальный идентификатор, работает некоторое время, а затем, когда он записывает данные в базу данных под идентификатором, который был указан. Существует много типов виджетов, и идентификатор должен быть уникальным для всех.

Если бы я делал это в Postgres, я бы, наверное, один основной widget стола, с одной таблицей для каждого типа виджета (widget_x, widget_y и т.д.) наследуемого от этого основной таблицы. Идентификатор будет иметь тип SERIAL в основной таблице widget. Когда начнется процесс строительства, я бы вставлял некоторые данные, получал свой уникальный идентификатор, начинал работать, и когда здание завершено, обновите таблицу. Я, вероятно, не буду использовать транзакции во всем процессе, потому что здание может занять много времени.

Как сделать это в RethinkDB? Мне действительно нужен идентификатор, который будет увеличиваться, поэтому я не могу использовать ключи UUID по умолчанию. Я хочу, чтобы каждый вид виджетов находился в собственной таблице.

Если я сделать этот запрос до начала каждый виджет здания:

r.table("counters") 
    .get("some-uuid-key") 
    .update({ widget_counter: r.row("widget_counter").add(1) }, {return_vals: true}) 

будет эта работа, как я надеюсь, что это будет, давая мне базу данных широкий уникальный идентификатор, без какой-либо возможности в ID конфликта?

Благодаря ...

Answer 1

Что там у вас будет работать и как можно ближе к каноническому решению этой проблемы, как я думаю, что есть. Глобально уникальные восходящие идентификаторы более или менее невозможны в кластерной среде, поэтому мы по умолчанию не имеем их как опцию. То, что у вас здесь, работает, потому что каждый отдельный запрос должен пройти через одну машину, чтобы получить свой идентификатор (мастер-машина для таблицы "counters". Это имеет недостаток, что если эта машина умирает, каждый запрос, который должен получить идентификатор, начнет сбой.

Answer 2

Имея таблицу счетчики в БД имеет гарантию последовательности по стоимости лучшей HA (высокой доступности).

Если вам не нужны абсолютные добавочные номера, просто предпочитают короткое целое число записей, которые вы также можете настроить набор серверных билетов. Каждый из них выдаст каждый номер N. Вы получите избыточность и более низкие номера, но у вас не будет гарантии заказа и может иметь значительный дрейф с течением времени Я думал о такой системе, где каждый клиент может также передать последний идентификатор, который он получил ... таким образом, если дрейф больше X, он может пропустить вперед, чтобы держать дрифт в проверке.

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