Каков наилучший способ объединить 2 дампа данных MySQL?

Question

Мы создали приложение с MySQL в качестве базы данных.Каждую неделю мы экспортируем дамп данных из базы данных и удаляем все данные.Теперь мы хотим объединить все эти дампы вместе для некоторых задач анализа данных.

Проблема, с которой мы сталкиваемся, заключается в том, что поле «id» для всех таблиц имеет значение Auto-Increment, поэтому оно начинается с 1 во всехдампы данных, что приводит к дублированию идентификаторов в таблице.Я уверен, что должны быть лучшие способы сделать это, так как это должно быть довольно распространенной задачей в администрировании MySQL.

Каков наилучший способ сделать это?

Answer 1

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

Например, допустим, у вас есть два файла дампа, и вы знаете, что диапазон их первичных ключей не превышает 1 000 000, вы увеличиваете первичный и внешний ключи во втором файле дампа на 1 000 000.

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

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

Удачи.

Answer 2

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

В дальнейшем вы можете установить дисциплину, в которую вы будете выгружать, а затем УДАЛИТЬ строки, которые, скажем, большеодин деньТаким образом, ваш идентификатор будет увеличиваться.

Или вы можете скопировать эти данные в таблицу, которая использует механизм хранения ARCHIVE.Это хорошо для хранения данных для анализа, поскольку они сжимают их содержимое.

Answer 3

Лучше всего, если у вас есть другая база данных, которая действует как хранилище данных, в которое вы копируете содержимое базы данных вашего приложения. После этого вы не обрезаете все таблицы, вы просто используете DELETE FROM tablename - тогда ваши auto_increments не будут сброшены.

Это уродливое решение - экспортировать что-то, затем обрезать базу данных, а затем ожидать, что импорт будет продолжаться правильно. Даже если вы решите проблему конфликтующих автоматических приращений (есть оператор ON DUPLICATE KEY, который позволяет вам что-то делать в случае сбоя ограничения уникального ключа), ничто не гарантирует сохранения отношений между таблицами (внешними ключами).

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