Первичный ключ postgres synchornized

Question

У меня есть две базы данных postgres, одни и те же таблицы должны быть синхронизированы между этими базами данных (не все из них, только некоторые из них).

Это создает проблему с синхронизацией, если у меня есть таблица A и таблица B (такая же структура, только в разных базах данных), если кто-то вставляет в таблицу A, идентификатор pk может быть 5, но тогда кто-то может вставить таблицу B, получив идентификатор pk 5.

Во время синхронизации обеих таблиц я могу найти два регистра с одним и тем же pk, но с другим содержимым.

Я уверен, что для этого должны быть решения. Должен быть умный способ синхронизации ids.

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

1-Это замедлит процесс 2-Он просто перемещает проблему в webservice, как веб-служба найдет, какой из них является следующим действительным идентификатором?

Неужели кто-нибудь сталкивался с аналогичной проблемой в прошлом?

Среда Postgres 9.1

Answer 1

Да, люди столкнулись с этим много. Вопрос, который вам нужно задать, - это не «как это сделать», но «какой из существующих хорошо понятых и установленных методов наилучшим образом соответствует моим потребностям».

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

Варианты включают:

• Выделяет неперекрывающиеся диапазоны идентификаторов на каждую машину. Один общий подход состоит в том, чтобы установить последовательности до увеличения в блоках (скажем) 100 и дать каждой машине уникальное смещение, поэтому машина A генерирует 101, 201, 301, 401 и т. Д., А машина B генерирует 102, 202, 302, 402 , .... Работы отличные, пока вам не понадобится добавить машину № 101. Вы можете использовать ключ bigint и оставить пространство для 100 000 машин; таким образом, к тому времени, когда вы достигнете этого ограничения, вы все равно будете перепроектировать всю систему три раза.

  (Перед тем как сказать «Я побегу из ключей» ... Макс BIGINT является 9223372036854775807 так с диапазоном 10000 машины вы смотрите на около 10 или 2 ключей в таблице на машину , что составляет около 21 петабайт таблицы по 25 байт на запись, включая накладные расходы, т.е. действительно очень крошечные записи).

• Использовать составной первичный ключ, например (machine_id, locally_generated_sequence_id). Идеально, если вы не имеете дело с ORM Braindead, которые настаивают на однозначных первичных ключах.

• Используйте huge random primary keys (UUIDs) с типом данных uuid, что дает 128-битное пространство и абсолютно крошечную вероятность столкновения. Работает нормально в большинстве случаев и, несмотря на то, что столкновение birthday paradox довольно необычно. Параноик может иметь планы для борьбы с столкновениями.

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

• ... возможно, больше я не помнил или никогда не слышал.

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