Способы обработки огромных транзакций в любой базе данных?

Question

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

Это обрабатывается в текущем продукте (верстак и механизм на основе Java) путем одновременной обработки 1000 строк и параллельного выполнения 10 потоков. Этот подход прекрасно работает на небольших наборах данных. Но когда мне нужно преобразовать огромные наборы данных (скажем, около X миллионов записей) за один раз - этот подход все еще работает, но

• ЦП хост-машины, на котором работает мой продукт, находится под большой нагрузкой.
• Исходная база данных и целевая база данных имеют слишком много транзакций, которые начинают замедляться. (Теперь это может быть связано с тем, что сервер базы данных, вероятно, работает на более медленном оборудовании.)

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

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

Approach1

1. Чтение данных из исходной базы данных и сохранение их на временном носителе (файле).
2. Преобразуйте данные в постоянный файл, запустив его в распределенной среде (более дешевые одноядерные машины) и обработав «компромиссный шаг» перехода к сохранению файла. (Использование чего-то вроде Apache Hadoop для обработки части распределенных вычислений)
3. Запись данных в базу данных назначения.

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

Answer 1

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

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

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

В в этом случае я смог помочь кому-то сократить время загрузки с 10 часов до 6 минут :)

Answer 2

Разделяй и властвуй!

Если исходная БД не может обрабатывать обе задачи одновременно (ETL и «обычные» транзакции), то не заставляйте ее страдать:

• Скопируйте исходные данные в"зеркало".
• Выполните ETL на «зеркале».

Примечание: когда я говорю «зеркало», я просто имею в виду копию, которая позволяет быстро и эффективно копировать данные (немного похоже на«промежуточная» база данных) - не еще один большой / медленный / неприятный процесс ETL.Идея здесь состоит в том, чтобы оптимизировать процесс в интересах исходной БД.

Затем вы можете оптимизировать ETL для целевой БД, чтобы получить выгоду для целевой БД;потому что вы дразнили источник и цель отдельно, вам будет легче оптимизировать части чтения / вставки общего процесса.

Возможно, вы могли бы сделать аналогичную вещь и на конце цели (используя другое "зеркало""/ staging DB).

Этот подход не сильно отличается от того, что вы предложили, но я предполагаю, что при прямом копировании данных между двумя идентичными БД одного типа будет и самым простым в управлении, и самым эффективным.

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

И последнее: вы можете поэкспериментировать сИнструмент ETL - если вы работаете

Answer 3

используйте oracle sql loader (импорт / экспорт).импортируйте данные в промежуточную таблицу и, как только все пойдет хорошо, переименуйте таблицу в основную таблицу после переименования основной таблицы в резервнуюПомните, что вы должны применять ограничения только после каждого импорта / загрузки.Вы можете вызвать загрузчик sql из Java-программы.

Answer 4

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

Answer 5

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

Правка (в дополнение к комментариям): я думаю, что самый удачный вариант (вSQL Server в любом случае) будет устанавливать целевую базу данных в простой режим восстановления на время операции.Фактически, если бы вы это сделали, скорее всего, вам не пришлось бы вносить какие-либо другие изменения в код.

Однако это уместно, только если целевая база данных не используется одновременно для других целей.,Я бы сказал, что это основное требование.Это фундаментальная ошибка базы данных - пытаться вставить 25 миллионов записей в базу данных, пока она работает с транзакциями OLAP.Если это строго необходимо, то я думаю, что решение состоит в том, чтобы сделать процесс очень медленным (со значительными паузами), чтобы освободить ресурсы, чтобы базы данных могли продолжать работать.