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

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

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

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

Если я сделаю этот запрос перед началом создания каждого виджета:

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

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

Спасибо...


person kmelvn    schedule 09.01.2014    source источник


Ответы (2)


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

person Joe Doliner    schedule 09.01.2014

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

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

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

person Tracker1    schedule 14.11.2015
comment
Для меня слишком долго иметь <website.com>/profile/9d1c0945-c627-4b79-a7e7-c998c0fc5d7e, было бы лучше иметь 8-символьный идентификатор. Я искал способ иметь более короткие идентификаторы в RethinkDB, но не нашел хорошего способа. - person Qasim; 20.08.2018