Преобразование огромной таблицы базы данных в другую таблицу

#java #mysql #sql #performance #jdbc

#java #mysql #sql #Производительность #jdbc

Вопрос:

Мы переносим много данных из нашей старой базы данных в новую базу данных.

В настоящее время оба они активно используются [для записи / чтения] на основе потоков / активности, поскольку выполняется миграция.

Вот настоящая проблема для меня сейчас. У нас есть старая таблица базы данных, которая все еще используется сейчас.

По крайней мере, 100 000 новых записей вставляются каждый день, и нам нужно переместить данные шестимесячной давности [01-01-2014] в новую базу данных.

Мы используем MySQL в обоих местах. Для преобразования новой таблицы в старую таблицу требуется некоторое логическое преобразование данных, которое будет осуществляться через Java-JDBC, поскольку структура и функциональность таблиц изменены.

Каковы идеальные шаги, которые мне нужно выполнить, и я позаботился о том, чтобы выполнить это преобразование как можно быстрее в обязательном порядке.

Согласно моим расчетам, мы перенесем не менее 20 000 000 записей.

Некоторая информация:

  1. В настоящее время индекс существует только для столбца ID. creation_date существует без индекса
  2. Как эффективно извлекать эти записи, лучший запрос для извлечения??
  3. Эффективный способ преобразования с использованием многопоточности
  4. Эффективный способ записи данных в новую базу данных

Комментарии:

1. Если кто-то голосует, пожалуйста, укажите причину, прежде чем делать это. Это совершенно правильный вопрос, требующий лучшего подхода, а не кода

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

3. Многопоточность не будет стоить дорого для процессов, связанных с вводом-выводом

4. Можете ли вы опубликовать обе схемы таблиц с подробными сведениями об индексе и количеством записей, которые она содержит ..?

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

Ответ №1:

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

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

Выберите данные порциями от старых к новым. Один фрагмент на поток (так что первый поток занимает неделю 1, второй занимает неделю 2 и т.д.). Если в вашей таблице нет поля даты вставки, используйте что-нибудь еще, чтобы разделить его — диапазоны идентификаторов, первая буква имени, что у вас есть. Убедитесь, что в столбце сортировки есть индекс!

Затем вы обрабатываете данные в этой форме:

  1. Откройте транзакцию для обеих баз данных.
  2. ВЫБЕРИТЕ фрагмент данных из старого
  3. преобразование информации
  4. создайте пакет для вставки на новой стороне (строка за строкой)
  5. создайте пакет для пометки для преобразования на старой стороне
  6. выполнить оба пакета
  7. фиксируйте обе транзакции, только если оба пакета выполнены правильно.

Скорее всего, узким местом здесь является сетевое подключение java <-> SQL Server, поэтому очень важно использовать достаточно большой пул соединений (я бы рекомендовал, по крайней мере, количество недель с момента запуска 2).

После того, как вы один раз преобразовали все данные, вам нужно будет часто запускать их повторно, чтобы поддерживать актуальность данных. То, что вы делаете с коллизиями, зависит от вас.

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

Комментарии:

1. Подготовленные инструкции и пакетные вставки действительно ускорят процесс.