Embed Size (px)
Citation preview
15 сентября 2015 года
Data Access Layer как страховка на случай миграции СУБД
Вячеслав МуравлевВедущий разработчик
О себе 15 лет Java-бэкграунда
JEE, прочие Spring-и и Swing-и
8 лет «кровавого Enterprise»
2/20
Краткий анамнез Расчетное приложение для банка
Трехзвенная архитектура
СУБД Oracle Специфичные данные приложения Учетная машина (таблицы и хранимые процедуры)
Невысокая нагрузка Небольшое количество пользователей Сезонная нагрузка
3/20
Процесс перевода АС Подготовка целевой инфраструктуры
Перенос данных в новую СУБД
Доработки АС
Регрессионное тестирование
Тестирование быстродействия и оптимизация
4/20
Доработки АС Один из самых затратных этапов (если не самый)
В нашем случае все прошло неплохо…
…потому что у нас были модульные тесты
…и страховой полис Data Access Layer
5/20
Коротко о Data Access Layer Уровень абстракции доступа к данным
Специфичен для каждого приложения Определяется моделью предметной области
Интенсивно используется бизнес-логикой
6/20
DAL ≥ ORM Простое использование ORM редко
повышает уровень абстракции
Остается возможность неконтролируемой работы с данными
Шаблон Repository Ограничивает доступ к сущностям Определяет четкий интерфейс
для работы с данными
7/20
Как мы готовим DAL Берем ORM
JPA 2.0 поверх Hibernate
Подключаем и настраиваем Spring Data
Создаем репозитории Объявляем интерфейс Настраиваем методы query Пишем custom реализацию, если нужно
Используем Specification с JPA Criteria API
Выделяем native queries в отдельные компоненты
8/20
DAL в приложении
9/20
Выполненные доработки АС Изменение настроек JPA
Исправление небольшого количества запросов со спецификой Oracle В расчетных полях сущностей В отчетах и некоторых компонентах
(нативные запросы)
Наличие модульных тестов помогает быстро локализовать такие места в коде
10/20
Трудности перевода переноса Целевая картина – все приложение работает
на PostgreSQL
На данный момент полный перевод не выполнен Логика учета и необходимые ей данные содержатся
в Oracle Данные приложения переезжают в PostgreSQL
Необходимо решение для гибридного доступа
11/20
Требования к решению Поддержка cross-database запросов
Доступ по JDBC
Поддержка различных СУБД
Open Source
Актуальное состояние
Зрелость
Активное сообщество пользователей
12/20
Выбор редакции – JBoss Teiid Инструмент для виртуализации данных
Унифицированный доступ к разнообразным хранилищам
JDBC драйвер
Standalone или Embedded
LGPL 2.1
13/20
Процесс подготовки виртуальной БД Установка Teiid Runtime
Подготовка Virtual Database (VDB) Установка и настройка Teiid Designer Импорт структуры таблиц в Teiid Designer «Доработка напильником»
Настройка типов данных Настройка вызовов хранимых процедур …
Настройка на физические СУБД
Установка и запуск VDB14/20
Архитектура промежуточного решения
15/20
Существенно упало быстродействие Провели тесты быстродействия наиболее
критичных функций Загрузка данных на UI Расчетные операции Составление отчетности по данным
из обеих БД
По сравнению с Oracle – медленнее в 2 раза
16/20
Оптимизация Посмотрели на:
Логи Teiid с помощью визуализатора своей разработки
Планы запросов
И сделали следующее: Вынесли ряд таблиц в кэш Teiid Оптимизировали join данных в ряде запросов
В результате показатели приблизились к Oracle
17/20
Выводы Создание и поддержка DAL на данный момент
стоят недорого
Следование принципу DAL существенно облегчает переезд на аналогичную СУБД
Если много логики АС находится в СУБД, стоит рассмотреть промежуточный вариант перевода (с гетерогенным доступом к данным)
А если DAL – и в масштабе предприятия?
18/20
Ресурсы Domain Driven Design by Eric Evans
Статья «Data Access Layer как инструмент управления хранением данных» на «Хабре»
Teiid Home
19/20
