Високопродуктивний доступ до шару даних вимагає багато знань про пристрій бази даних, JDBC, JPA, Hibernate, і цей пост містить найважливіші техніки, які Ви можете використовувати для оптимізації вашого enterprise програми.
1. Логування SQL виразів
Якщо Ви використовуєте фреймворк, який генерує вираження від вашого обличчя, Ви повинні завжди валідувати кожен вираз на ефективність і продуктивність.
2. Управління сполуками
З'єднання до бази даних дорого обходяться, тому Ви повинні завжди використовувати механізм пулу з'єднань.
Через те що кількість з'єднань задається можливостями кластеру бази даних, необхідно звільняти ресурси з'єднань якомога швидше.
При тюнінгу продуктивності Ви завжди повинні вимірювати і встановлювати правильний розмір пулу. Інструменти зразок FlexyPool можуть допомогти знайти правильний розмір навіть якщо Ви задеплоілі Ваше додаток на продакшн сервер.
3. Батчінг JDBC
JDBC батчінг дозволяє нам відправляти численні SQL виразу в одному сеансі з'єднання з базою даних. Вигода в продуктивності істотна як з боку драйвера, так і з боку бази даних. PreparedStatements є дуже підходящими кандидатами для батчінга, і так само деякі СУБД (наприклад Oracle) підтримують батчінг тільки для PreparedStatements.
З тих пір як в JDBC ввели API для батчінга (наприклад, PreparedStataement.addBatch і PreparedStatement.executeBatch), в разі якщо Ви генеруєте вираження вручну, то Ви повинні знати з самого початку, чи можете Ви використовувати пакетну обробку чи ні. З Hibernate, Ви можете переключити на батчінг всього навсього однією налаштуванням в конфігурації.
Hibernate 5.2 пропонує Session-level batching. що є ще більш гнучким рішенням в це плані.
4. Кешування виразів
Кешування виразів є одним з найменш відомих оптимізацій продуктивності, якої Ви можете скористатися. Залежно від нижчого JDBC драйвера, Ви можете кешувати PreparedStatements як з клієнтської сторони (драйвер), так і з боку бази даних (синтаксичне дерево або навіть план виконання).
5. Ідентифікатори Hibernate
Використання Hibernate IDENTITY генератора є не самим хорошим вибором, тому що він робить неможливим батчінг JDBC.
TABLE генератор ще гірше, тому що він використовує окрему транзакцію для завантаження нового ідентифікатора, яка може навантажити лог транзакцій і пул з'єднань через те що кожен раз як нам знадобиться новий ідентифікатор буде потрібно окреме з'єднання.
6. Правильно вибираємо типи даних для стовпців
7. Реляційні відносини
Hibernate надає безліч типів маппінга реляційних відносин, але все з них рівні з точки зору ефективності.
Завжди уникайте односпрямовані асоціації та @ManyToMany. Для колекцій краще використовувати двосторонню асоціацію @OneToMany.
Однак, на відміну від запитів, колекції менш гнучкі через те що вони не можуть легко піддатися розбивці на сторінки. З цієї причини Ви повинні завжди шукати відповіді на запитання чи дійсно так необхідна колекція. Маппірован на сутність запит може бути кращою альтернативою в багатьох ситуаціях.
8. Спадкування
Коли справа доходить до спадкування, відмінності між об'єктно-орієнтованими мовами і реляційними базами даних стає ще більш очевидним. JPA пропонує SINGLE_TABLE. JOIN. і TABLE_PER_CLASS для наслідування при маппинге і кожна з цих стратегій має плюси і мінуси.
SINGLE_TABLE виконує кращі з точки зору SQL виразу, але ми втрачаємо в цілісності даних через неможливість використовувати NOT NULL обмеження.
JOIN вирішує проблеми з цілісністю даних пропонуючи більш складні вирази. Поки Ви не використовуєте поліморфні запити або @OneToMany асоціації до базових типів, ця стратегія працює добре. Справжня міць виходить з поліморфних @ManyToOne асоціацій спираються на шаблон Strategy на стороні шару доступу до даних.
TABLE_PER_CLASS необхідно уникати з тих пір як ця стратегія генерує неефективні SQL виразу.
9. Розмір Persistence Context
При використанні JPA і Hibernate Ви завжди повинні тримати в голові розмір Persistence контексту. З цієї причини Ви повинні не роздувати його сотнями керованих сутностей. Зменшуючи кількість керованих сутностей, ми досягаємо значне поліпшення управління пам'яттю і дефолтовий механізм dirty checking буде працювати більш ефективно!
10. вивантажувати тільки те що дійсно необхідно
Вивантаження великих обсягів даних ймовірно причина номер один для проблем з продуктивністю шару доступу до даних. Проблема в тому, що запити для сутностей використовуються виключно, навіть для операцій читання.
DTO проекції більше підходять для вивантаження кастомних views, в той час як сутності повинні розвантажуватися тільки коли потік дій бізнес-логіки вимагає змінити їх.
EAGER вивантаження найгірша і Ви повинні уникати анти-патерни такі як Open-Session in View.
11.Кешірованіе
Реляційні СУБД використовують безліч in-memory буферів для економії ресурсів дисків. Кешування СУБД дуже часто не беруть до уваги. Ми можемо значно зменшити час відповіді налаштуванням движка СУБД так що робочі набори даних знаходяться в пам'яті і не вивантажуються з диска постійно.
Кешування на рівні програми не є обов'язковим для багатьох enterprise додатків. Кешування на рівні додатку може зменшити час відгуку, одночасно надаючи вторинне сховище для читання даних в момент коли база даних знаходиться на техобслуговуванні або коли стався серйозний системний збій.
Кеш другого рівня дуже корисний для зменшення часу відповіді для транзакції на читання-запис, особливо при архітектурі реплікації Master-Slave. Залежно від вимог, Hibernate пропонує наступні стратегії: READ_ONLY. NONSTRICT_READ_WRITE. READ_WRITE. і TRANSACTIONAL.
12. Контроль concurrency
Вибір рівня ізольованості транзакцій має першорядний пріоритет, коли справа доходить до швидкодії і цілісності даних. Для потоків з численними викликами, щоб уникнути втрати оновлених даних, Ви повинні використовувати оптимістичну блокування або EXTENDED Persistence Context.
13. Вертикальне і горизонтальне масштабування
Реляційні СУБД добре піддаються масштабування. Якщо Facebook. Twitter. Pinterest або StackOverflow можуть масштабувати свої СУБД, то є хороший шанс для того щоб Ви змогли масштабувати enterprise додаток відповідаючи бізнес вимогам.
Реплікація і сегментування БД - це дуже хороші варіанти для збільшення пропускної спроможності і Ви повинні повністю скористатися перевагами цих архітектурних шаблонів для масштабування Вашого застосування.
(Visited 358 times, 1 visits today)