предложение по пакетной обработке записей БД

Question

Я работаю над разработкой веб-приложения (visual jsf, ejb3, hibernate на glassfish / mysql), которое работает с существующей устаревшей системой.

У меня есть таблица 'employee' (с такими полями, как name (String), location (String) и т. Д.), Которая отделена от таблицы employee на устаревшей стороне db2. Я делаю всю обработку веб-приложений с моей служащей таблицей. Однако каждую неделю мне нужно планировать задачу, чтобы просмотреть всех сотрудников в моей таблице и сравнить их с сотрудниками в устаревшей таблице db2. Если местоположение сотрудника изменилось в устаревшей таблице, мне нужно обновить таблицу сотрудников, чтобы отразить новое местоположение.

Что бы вы предложили как лучший способ сделать это?

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

Поскольку у меня в таблице сотрудников около 50000 записей, первоначальная сборка ArrayList занимает около 5 минут, и это число сотрудников будет только увеличиваться.

Answer 1

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

Answer 2

Я подумываю об использовании jpa-запросов "setMaxResults ()" и "setFirstResults ()" для получения данных о сотрудниках в чанках Эти методы используются для разбиения на страницы отображаемых данных в пользовательском интерфейсе, поэтому я не вижу причин, по которым я не могу сделать то же самое. Таким образом, я могу обрабатывать куски одновременно. И я, вероятно, мог бы добавить очередь и mdb для параллельной обработки чанков, поскольку не могу создавать потоки в контейнере ejb.

Answer 3

Я бы создал dblink (dblink действительно существует в DB2, верно?) И сделал бы что-то вроде:

 select 
     a.id, a.location 
 from 
      empl a, empl@link b 
 where 
     a.id = b.id 
     and a.location <> b.location

Затем выполните итерацию набора результатов, в котором будут все те, чье местоположение изменилось.

Answer 4

Если у вас есть возможность каким-либо образом изменить устаревшую таблицу, вы можете добавить в нее столбец needs_sync. Затем, используя триггер или изменяя код, который обновляет местоположение, установите needs_sync = 1, когда вы делаете обновление. (Добавьте индекс и к этому столбцу.)

Затем, чтобы найти записи для обновления

select id, location
from legacy.employee
where needs_sync = 1

После успешной синхронизации

update employee
set needs_sync = 0
where needs_sync = 1

Сделайте все это в транзакции, чтобы избежать условия гонки.

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

Answer 5

Есть ли причина, по которой он должен синхронизироваться только один раз в неделю? Если нет, вы можете распространить операцию на неделю - выполнять 1/7 работы каждый день. Вы также можете рассмотреть возможность добавления таблицы на своей стороне, чтобы отслеживать, какая запись была синхронизирована, когда.