Документ описывает процесс создания и оптимизации слоя доступа к данным (DAL) для банковского расчетного приложения с использованием JPA и Hibernate, а также миграцию данных из Oracle в PostgreSQL через JBoss Teiid. Основное внимание уделяется подготовке целевой инфраструктуры, доработкам и тестированию, а также решению проблем производительности при использовании новых технологий. Автор заключает, что соблюдение принципов DAL облегчает переход на аналогичные системы управления базами данных.

1. 15 сентября 2015 года
Data Access Layer как страховка
на случай миграции СУБД
Вячеслав Муравлев
Ведущий разработчик

2. О себе
 15 лет Java-бэкграунда
 JEE, прочие Spring-и и Swing-и
 8 лет «кровавого Enterprise»
2/20

3. Краткий анамнез
 Расчетное приложение для банка
 Трехзвенная архитектура
 СУБД Oracle
 Специфичные данные приложения
 Учетная машина (таблицы и хранимые процедуры)
 Невысокая нагрузка
 Небольшое количество пользователей
 Сезонная нагрузка
3/20

4. Процесс перевода АС
 Подготовка целевой инфраструктуры
 Перенос данных в новую СУБД
 Доработки АС
 Регрессионное тестирование
 Тестирование быстродействия и оптимизация
4/20

5. Доработки АС
 Один из самых затратных этапов (если не самый)
 В нашем случае все прошло неплохо…
 …потому что у нас были модульные тесты
 …и страховой полис Data Access Layer
5/20

6. Коротко о Data Access Layer
 Уровень абстракции доступа к данным
 Специфичен для каждого приложения
 Определяется моделью предметной области
 Интенсивно используется бизнес-логикой
6/20

7. DAL ≥ ORM
 Простое использование ORM редко
повышает уровень абстракции
 Остается возможность неконтролируемой
работы с данными
 Шаблон Repository
 Ограничивает доступ к сущностям
 Определяет четкий интерфейс
для работы с данными
7/20

8. Как мы готовим DAL
 Берем ORM
 JPA 2.0 поверх Hibernate
 Подключаем и настраиваем Spring Data
 Создаем репозитории
 Объявляем интерфейс
 Настраиваем методы query
 Пишем custom реализацию, если нужно
 Используем Specification с JPA Criteria API
 Выделяем native queries в отдельные компоненты
8/20

9. DAL в приложении
9/20

10. Выполненные доработки АС
 Изменение настроек JPA
 Исправление небольшого количества
запросов со спецификой Oracle
 В расчетных полях сущностей
 В отчетах и некоторых компонентах
(нативные запросы)
 Наличие модульных тестов помогает
быстро локализовать такие места в коде
10/20

11. Трудности перевода переноса
 Целевая картина – все приложение работает
на PostgreSQL
 На данный момент полный перевод не выполнен
 Логика учета и необходимые ей данные
содержатся в Oracle
 Данные приложения переезжают в PostgreSQL
 Необходимо решение для гибридного доступа
11/20

12. Требования к решению
 Поддержка cross-database запросов
 Доступ по JDBC
 Поддержка различных СУБД
 Open Source
 Актуальное состояние
 Зрелость
 Активное сообщество пользователей
12/20

13. Выбор редакции – JBoss Teiid
 Инструмент для виртуализации данных
 Унифицированный доступ
к разнообразным хранилищам
 JDBC драйвер
 Standalone или Embedded
 LGPL 2.1
13/20

14. Процесс подготовки виртуальной БД
 Установка Teiid Runtime
 Подготовка Virtual Database (VDB)
 Установка и настройка Teiid Designer
 Импорт структуры таблиц в Teiid Designer
 «Доработка напильником»
 Настройка типов данных
 Настройка вызовов хранимых процедур
 …
 Настройка на физические СУБД
 Установка и запуск VDB
14/20

15. Архитектура промежуточного решения
15/20

16. Существенно упало быстродействие
 Провели тесты быстродействия наиболее
критичных функций
 Загрузка данных на UI
 Расчетные операции
 Составление отчетности по данным
из обеих БД
 По сравнению с Oracle – медленнее в 2 раза
16/20

17. Оптимизация
 Посмотрели на:
 Логи Teiid с помощью визуализатора
своей разработки
 Планы запросов
 И сделали следующее:
 Вынесли ряд таблиц в кэш Teiid
 Оптимизировали join данных в ряде запросов
 В результате показатели приблизились к Oracle
17/20

18. Выводы
 Создание и поддержка DAL на данный момент
стоят недорого
 Следование принципу DAL существенно
облегчает переезд на аналогичную СУБД
 Если много логики АС находится в СУБД,
стоит рассмотреть промежуточный вариант
перевода (с гетерогенным доступом к данным)
 А если DAL – и в масштабе предприятия?
18/20

19. Ресурсы
 Domain Driven Design by Eric Evans
 Статья «Data Access Layer как инструмент
управления хранением данных» на «Хабре»
 Teiid Home
19/20

20. Спасибо!
Вопросы?
Вячеслав Муравлев
vmuravlev@gmail.com
20/20