Автономная синхронизация (Performance UUID в качестве первичного ключа)

Question

Я работаю над проектом, где у некоторых клиентов возникают проблемы с интернет-соединением.

Когда интернет-соединение не работает, мы храним информацию в базе данных, расположенной на клиентском ПК.Когда мы снова получаем соединение, мы синхронизируем локальную БД с центральной.

Чтобы избежать конфликтов в идентификаторах записей между двумя базами данных, мы будем использовать UUID [char (36)] вместо автоинкрементов.

Базы данных Mysql с движком InnoDB.

Мой вопрос: это повлияет на производительность для селектов, объединений и т. Д.?Должны ли мы использовать varbinary (16) вместо char (36) для повышения производительности?

примечание: у нас уже есть база данных с данными 4 Go. Мы также открыты для других предложений по решению этой проблемы в автономном / онлайн-режиме.

Спасибо

Answer 1

Поскольку вы не сказали, какой механизм базы данных используется (MyISAM или InnoDB), трудно сказать, какова величина влияния на производительность.

Однако, если коротко, то да, естьбудет влиять на производительность для больших наборов данных.Это связано с тем, что для индекса первичного ключа требуется 36 байтов, а для целого - 4 (8, если bigint).

Я дам вам подсказку, как избежать конфликтов:

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

Во-вторых, это составной первичный ключ.Если вы определите свой первичный ключ как PRIMARY KEY(id, server_id), то вы не столкнетесь с конфликтами, если скопируете данные в центральную БД.Вы также будете знать, откуда это.Недостатком является то, что вам нужно указывать server_id для каждого запроса, который вы делаете.