высокопроизводительное обновление базы данных (оракул)

Question

У меня есть несколько сервисов, которые выгружают данные в базу данных (оракул) после обработки различных форматов входных файлов (XML, простые файлы и т. Д.).Мне было интересно, могу ли я заставить их генерировать операторы SQL вместо этого и регистрировать их в некоторой файловой системе, и иметь один процессор SQL (что-то вроде java hibernet), который будет обрабатывать эти файлы SQL и загружать в БД.Какой самый быстрый способ выполнить огромный набор операторов SQL (распределенных по файловой системе и записанных несколькими авторами) в оракуловую БД?Я думал о разделении БД и пакетных обновлений.Тем не менее, я хочу знать лучшие практики здесь.Похоже, что это распространенная проблема, и кто-то уже должен был решить эту проблему.Спасибо Атану

Answer 1

Atanu, худшее, что нужно сделать, - это создать огромные списки операторов вставки. Если вам нужна скорость и вы знаете расположение ваших данных, используйте внешние таблицы для загрузки данных в базу данных Oracle. Это похоже на использование sql * loader, но вы можете получить доступ к своим данным с помощью таблицы. В определении таблицы ваши поля данных отображаются на имена столбцов и типы данных. Это будет самый быстрый способ выполнить массовую загрузку в вашу базу данных, это точно.

См. Управление внешними таблицами для некоторой документации.

Answer 2

Последнее, что вам нужно, это куча операторов вставки ... СУПЕР медленный подход (не имеет значения, сколько процессов вы запускаете, поверьте мне).Получить все файлы в формате с разделителями и выполнить НЕПОСРЕДСТВЕННУЮ загрузку в Oracle через sqlldr - это самый простой (и очень быстрый) подход.

Answer 3

То, что является лучшей практикой, скорее зависит от ваших критериев определения «лучших».Во многих местах подход, используемый во многих местах, заключается в использовании инструмента ETL, возможно Oracle Warehouse Builder, возможно, стороннего продукта.Это не должно быть дорогим продуктом: Pentaho предлагает Kettle в бесплатной «самостоятельной» общественной версии .

Когда дело доходит до проката, я не думаю, что Hibernate - это то, что нужно.Особенно, если ваша главная задача - производительность.Я также думаю, что изменение ваших каналов для генерации операторов SQL является слишком сложным решением.Что не так с модулями PL / SQL для чтения файлов и собственного выполнения SQL?

Конечно, когда я делал подобные вещи раньше, чем это было с PL / SQL.Хитрость заключается в том, чтобы отделить входной слой чтения от слоя записи данных.Это связано с тем, что для файлов, вероятно, потребуется много написанного на заказ кода, тогда как материал для написания часто довольно общий (очевидно, это зависит от точных деталей вашего приложения).

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

Когда дело доходит до производительности, старайтесь максимально использовать массовую обработку.Это основная причина, по которой PL / SQL предпочтительнее файлов с отдельными операторами SQL. Узнайте больше .

Answer 4

Если вам нужна максимальная производительность, вам не нужны тонны SQL-операторов. Вместо этого взгляните на Oracle Data Pump.

И не делайте никакой предварительной обработки для плоских файлов. Вместо этого передайте их напрямую в impdp (импортер Oracle Data Pump).

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

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

Answer 5

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

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

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

insert into my_table values(...);
insert into my_table values(...);
...

И замените его одним оператором, объединяющим несколько строк:

insert into my_table
select ... from dual union all
select ... from dual union all
...

Вторая версия будет работать в несколько раз быстрее.

Однако подобрать правильный размер довольно сложно.Большое количество маленьких вставок будет тратить много времени на связь и другие накладные расходы.Но время разбора Oracle растет в геометрической прогрессии с очень большими размерами.По моему опыту 100 обычно хорошее число.Разбор становится действительно медленным около тысячи.Кроме того, используйте метод union all, избегайте трюка со вставкой из нескольких таблиц.По какой-то причине многостоловая вставка выполняется намного медленнее, а в некоторых версиях Oracle есть ошибки, из-за которых ваш запрос зависает на 501 таблице.

(Вы также можете создать похожий сценарий, используя PL / SQL. A 1Мегабайтная PL / SQL-процедура будет компилироваться гораздо быстрее, чем 1-мегабайтный оператор SQL, но создать сценарий сложно: коллекции, динамический sql, правильная обработка всех типов, создание временного объекта вместо анонимного блока, поскольку большие анонимные блоки вызываютОшибки узла Дианы и т. Д. Я создал процедуру, подобную этой, и она работала хорошо, но, вероятно, это не стоило усилий.)