Блог

обычно я бы решил это простым объединением. но у этого есть я. у меня есть таблица, реплицированная на два разных ядра баз данных. одна копия в postgres, одна копия на AS / 400 с DB2.

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

текущая система следует этой модели

     load postgres data into recordset prs
for each record in prs {
  search for record in db2
  compare record
  if diff, log
}
 

обычно это работает. проблема в том, что, поскольку имеется около 500 000 записей, требуется около 3 часов, прежде чем в нашей VPN появится ошибка, которая приведет к прерыванию соединения. и, конечно, вам придется начинать все сначала, и будет быстрее перепроектировать процедуру, чем исправлять ошибку VPN.

я думал о процедуре, которая переносит данные db2 во временную таблицу и затем выполняет запрос объединения, но я сталкиваюсь с проблемами безопасности при создании и удалении таблицы.

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

редактировать — извините, таблица начинает год с 3,5 миллионов записей, поэтому решение в памяти становится довольно непрактичным. есть идеи?

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

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