РИТ++ 2017, Web-scale IT Сonference Зал Владивосток, 6 июня, 18:00 Тезисы: http://webscaleconf.ru/2017/abstracts/2833.html Вводные: 1) Необходимо переносить данные с минимальным простоем БД. 2) Необходимо произвести трансформацию данных из-за отличий между DB2 и PG и перемещением BLOB'ов в Ceph. 3) Перенос должен быть произведен за приемлемое время. 4) Нужно учесть зависимости между таблицами. Технологии: 1) Отслеживание изменений с помощью триггеров. 2) Анализ зависимостей с помощью доработанного SchemaSpy. 3) Перенос с помощью Spring Batch. 4) Разбиение на партиции (два подхода: деление диапазона id между min и max на равные части; деление на диапазоны с равным числом строк).

1. Миграция больших БД без
остановки
Как перевести БД с DB2 for z/OS на PostgreSQL с
минимальным временем простоя
Дмитрий Погибенко

2. Требования к процессу миграции
Преобразование данных
Перенос данных без остановки БД
Зависимости между таблицами
Сжатые сроки перехода на PostgreSQL
Возможность мигрировать другие БД с минимальными
доработками

3. Требования к процессу миграции
Преобразование данных
В процессе переноса большие бинарные объекты(BLOB) сохраняются в
Ceph, а в БД сохраняются только их идентификаторы.

4. Требования к процессу миграции
Преобразование данных
Перенос данных без остановки БД
Нужно отслеживать и обрабатывать изменения в данных

5. Требования к процессу миграции
Преобразование данных
Перенос данных без остановки БД
Зависимости между таблицами
Во время переноса в целевой БД существуют все внешние ключи

6. Требования к процессу миграции
Преобразование данных
Перенос данных без остановки БД
Зависимости между таблицами
Сжатые сроки перехода на PostgreSQL
Возможность мигрировать другие БД с минимальными
доработками

7. Как жить с зависимостями

8. Порядок переноса данных с учетом
зависимостей
Порядок переноса
данных

9. Обратный порядок расчета диапазонов
Расчет диапазонов
Перенос данных

10. Реальный граф зависимостей

11. Автоматизируем анализ зависимостей
SchemaSpy (http://schemaspy.sourceforge.net/)
Анализирует зависимости
Ищет циклические зависимости
Упорядочивает таблицы от независимых к зависимым
Через обертку встраивается в java-приложение и отдает информацию в
удобном виде

12. Переносим данные
Spring Batch (http://projects.spring.io/spring-batch/)
Управление транзакциями
Обработка по частям
Декларативная конфигурация
Запуск/останов/перезапуск
Гибкие стратегии пропуска/повтора при ошибках

13. Декларативная конфигурация Spring Batch
<batch:job id="sampleJob" job-repository="jobRepository">
<batch:step id="data_step">
<batch:tasklet>
<batch:chunk reader="data_reader"
processor="data_processor"
writer="data_writer"
commit-interval="100"/>
</batch:tasklet>
</batch:step>
</batch:job>

14. Центральные интерфейсы Spring Batch
public interface ItemReader<T> {
T read() throws Exception;
}
public interface ItemProcessor<I, O> {
O process(I item) throws Exception;
}
public interface ItemWriter<T> {
void write(List<? extends T> items) throws Exception;
}

15. Item-ориентированная обработка в Spring Batch

16. Chunk-ориентированная обработка в Spring Batch

17. Chunk-ориентированная обработка в Spring Batch

18. Партиционирование в Spring Batch

19. Процесс миграции

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

21. Упрощенная диаграмма работы системы

22. Разбиение данных на диапазоны(простое)
SELECT MIN(id), MAX(id) FROM tablename;
long targetSize = ((max - min) / partitions) + 1;
while (start <= max) {
if (end >= max) { end = max;}
ranges.add(new Range<>(start, end));
start += targetSize;
end += targetSize;
}

23. Разбиение на диапазоны с равным числом строк
SELECT COUNT(*), MIN(id), MAX(Id)
FROM tablename;
partitionSize = (count / partitions);
SELECT id FROM tablename
WHERE id >= ? ORDER BY id
LIMIT 1 OFFSET partitionSize;

24. Решения
Изменения данных отслеживаются триггерами
Зависимости анализируются SchemaSpy
Данные переносятся Spring Batch

25. Каждая миграция имеет свои особенности
Снести индексы и восстановить после переноса.
Быстрее или нет?
В нашем случае нет.
Размер коммита и количество потоков нужно подбирать
экспериментально.
В нашем случае оптимальным оказалось 16 потоков(по числу ядер на
сервере Эльбрус) и 1000 строк в каждой транзакции.

26. Базы данных, которые легко мигрировать
Нет бизнес-логики в хранимых процедурах
Во всех таблицах есть первичный ключ
Нет циклических зависимостей
Основная операция - INSERT