#java #mysql #sql #performance #jdbc
#java #mysql #sql #Производительность #jdbc
Вопрос:
Мы переносим много данных из нашей старой базы данных в новую базу данных.
В настоящее время оба они активно используются [для записи / чтения] на основе потоков / активности, поскольку выполняется миграция.
Вот настоящая проблема для меня сейчас. У нас есть старая таблица базы данных, которая все еще используется сейчас.
По крайней мере, 100 000 новых записей вставляются каждый день, и нам нужно переместить данные шестимесячной давности [01-01-2014] в новую базу данных.
Мы используем MySQL в обоих местах. Для преобразования новой таблицы в старую таблицу требуется некоторое логическое преобразование данных, которое будет осуществляться через Java-JDBC, поскольку структура и функциональность таблиц изменены.
Каковы идеальные шаги, которые мне нужно выполнить, и я позаботился о том, чтобы выполнить это преобразование как можно быстрее в обязательном порядке.
Согласно моим расчетам, мы перенесем не менее 20 000 000 записей.
Некоторая информация:
- В настоящее время индекс существует только для столбца ID. creation_date существует без индекса
- Как эффективно извлекать эти записи, лучший запрос для извлечения??
- Эффективный способ преобразования с использованием многопоточности
- Эффективный способ записи данных в новую базу данных
Комментарии:
1. Если кто-то голосует, пожалуйста, укажите причину, прежде чем делать это. Это совершенно правильный вопрос, требующий лучшего подхода, а не кода
2. Обратные галочки предназначены для выделения кода. Ваш вопрос не содержит кода, поэтому они не подходят. В любом случае, это действительно вопрос к администраторам баз данных
3. Многопоточность не будет стоить дорого для процессов, связанных с вводом-выводом
4. Можете ли вы опубликовать обе схемы таблиц с подробными сведениями об индексе и количеством записей, которые она содержит ..?
5. Асинхронное выполнение @AngeloNeuschitzer будет иметь тот же эффект, что и несколько потоков. Тем не менее, вы сделали хороший вывод. Теперь, предполагая, что данные отправляются пакетами, сервер БД, вероятно, может быть перегружен выполнением операций ввода-вывода, обновлением структур данных и так далее. Таким образом, использования пары потоков может оказаться более чем достаточно, чтобы сервер был полностью занят.
Ответ №1:
Я ожидаю, что вы сможете изменять обе базы данных. Как вы написали, данные изменяются во время обработки миграции, не должно быть так важно, сколько времени это займет, поскольку миграцию в любом случае необходимо запускать более одного раза. Он должен справляться с изменением наборов данных, не беспокоиться о производительности, беспокоиться о правильности.
Начните с добавления индексированного логического столбца в старую базу данных, чтобы отметить перенесенные данные, поэтому вам не нужно переносить их более одного раза. Если данные в старой базе данных обновляются (а не только вставляются) во время процесса миграции, вместо этого используйте столбец timestamp. Отметьте момент времени, когда она была сдвинута в последний раз, и момент, когда она была отредактирована в последний раз — таким образом, вы можете увидеть, что нужно преобразовать, а что уже было.
Выберите данные порциями от старых к новым. Один фрагмент на поток (так что первый поток занимает неделю 1, второй занимает неделю 2 и т.д.). Если в вашей таблице нет поля даты вставки, используйте что-нибудь еще, чтобы разделить его — диапазоны идентификаторов, первая буква имени, что у вас есть. Убедитесь, что в столбце сортировки есть индекс!
Затем вы обрабатываете данные в этой форме:
- Откройте транзакцию для обеих баз данных.
- ВЫБЕРИТЕ фрагмент данных из старого
- преобразование информации
- создайте пакет для вставки на новой стороне (строка за строкой)
- создайте пакет для пометки для преобразования на старой стороне
- выполнить оба пакета
- фиксируйте обе транзакции, только если оба пакета выполнены правильно.
Скорее всего, узким местом здесь является сетевое подключение java <-> SQL Server, поэтому очень важно использовать достаточно большой пул соединений (я бы рекомендовал, по крайней мере, количество недель с момента запуска 2).
После того, как вы один раз преобразовали все данные, вам нужно будет часто запускать их повторно, чтобы поддерживать актуальность данных. То, что вы делаете с коллизиями, зависит от вас.
Если вы можете выполнить выбор между базами данных из старой базы данных, триггер вставки в сочетании с представлением между базами данных избавит вас от многих проблем и смягчит преобразование.
Комментарии:
1. Подготовленные инструкции и пакетные вставки действительно ускорят процесс.