БД — це не тільки сховище даних

Використовувати БД тільки для складування даних — це все одно, що назвати Unix інтерфейсом для роботи з файлами. Тому, хочу нагадати про відомих і не дуже функції БД, які хотілося б частіше зустрічати в бойових веб-додатках.

 

tl;dr

 

Нижче буде про аутентифікацію користувачів, права доступу, цілісність даних, FDW, логування та статистику. Нічого нового.

 

Примітки

 

  • Буду мати на увазі Ruby on Rails і Postgres, але більшість згадок добре нормально на інші мови і СУБД.
  • Нічого нового не скажу, все це давно описано в документації і статтях. Просто хочу ще раз нагадати про інструменти і про те, куди їх можна застосувати, щоб життя стало трохи краще.

 

Peer/ident аутентифікація

 

Абсолютно чудова штука, яку майже ніхто не користується. Вона мапає користувача юнікса на користувача БД. У першому випадку мапає локального користувача, а в другому — віддаленого. Профіт в тому, що можна викинути з конфіга хост, логін і пароль (та й ім’я БД можна викинути), але все буде працювати як раніше. Плюс, буде зручніше заходити в консоль для прямого дебага (просто psql з терміналу замість усіх цих -h -U -W -d і тд).

 

Документація PG про peer і про ident.

 

Нюанси: підходить, якщо у вас не тільки root і superuser на сервері; а у випадку з ident, ви контролюєте мережу, залізо і впевнені, що там немає засланців і саботажників.

 

Приклади використання

 

Безпека. Не можна потягти пароль від БД і підключитися до неї з локального оточення або ще звідки-небудь. Пароля немає і забирати нічого.

 

Розмежування доступу. Якщо на продакшн чи інший сервер є кілька ролей доступу і вони вже поділені на рівні unix-а, то до них зручно прив’язати і користувачів БД. В цьому випадку одна й та ж кодова база буде підключатися під різними користувачами БД. Наприклад, тех. підтримка і розробники лізуть в одну і ту ж rails console, але у одних вона readonly, а у других — повноцінна.

Читайте також  UE4 | Інвентар для Multiplayer #1 | Сховище даних на DataAsset

 

Права доступу

 

В Unix все про них думають і на роботу з-під root-а або на 'chmod 777' дуже косо дивляться. А ось в БД все якось інакше. Superuser і в шлях. Хоча там всі не менш (а навіть більш) круто.

 

Там є ієрархія наслідування ролей (трохи схоже на group в юниксе), там є доступи різного рівня: до конкретних об’єктів (зразок прав доступу до файлів), до конкретних операторів (зразок правил sudoers), навіть до конкретних рядками. Коротше, там все є. Користуйтеся.

 

Області додатки

 

У мінімальному варіанті, разом із вищезазначеними peer/ident можна розділити користувача для міграцій/деплоя і користувача для повсякденної роботи програми. Це, як мінімум, вбереже від виклику DDL в рантайме. Звичайно, є багато випадків модифікації структури БД “на гарячу”. Це і zero-downtime deploy, і різні хотфікси, і ребілди індексів з concurency (а іноді і без). Але, в загальному випадку, додаток DDL робити не повинен.

 

Ще варіант: якщо у вас “микросервисы”, але, чомусь, вони користуються однією БД, то явно розділити доступ до об’єктів БД — це дуже хороша ідея. Адже інтерфейси взаємодії повинні бути максимально локалізовані, а анархічний доступ до всіх даних сприяє розмивання логіки і відповідальності.

 

Обмеження цілісності

 

У Rails 5 хоч як почалася робота з reference і цілісністю даних. Але, в загальному випадку, багато розробники вважають, що валідації в моделі або її околицях цілком достатньо для збереження консистентного стану даних. На жаль, це зовсім не так.

 

Валідації можна пропустити, можна зайти безпосередньо в БД і навиконувати sql-я, можна при міграції накосячити. Загалом, багато чого можна зробити. Тому все, на що спирається бізнес-логіка має бути прибито констрейнтами в БД. Це єдиний спосіб зберегти цілісність даних і не отримати “сюрпризів” при черговому деплоі.

Читайте також  90 нових фіч (API) в JDK 11

 

Foreign Data Wrapper

 

Це про підключення однієї БД до іншої БД, щоб отримати доступ до віддалених таблиць як до своїх власних. Головний профіт в тому, що веб-додаток тут ніяк не бере участь, зате є багато оптимізацій, при роботі двох однакових БД (взагалі, pushdown є для різних адаптерів, але там все складно, тому простіше вважати, що зв’язка PG-PG працює добре, а все інше — як вийде).

 

Використання FDW

 

Замість конфігиу з координатами декількох БД у веб-додатку незрівнянно простіше залишити одне підключення до БД і розрулити все на рівні самої БД. Там же, сам собою вирішиться питання прав доступу і вибору об’єктів, до яких потрібен доступ.

 

Плюс до цього, в майбутньому можна замінювати external table на materialized view або просто table, але нічого не змінювати у веб-додатку.

 

А ще, можна підключатися до екзотики типу MS Access і зникають проблеми з обмеженнями на використання реляцій в моделях. Адже якщо у вас 2+ підключення, то джоин двох баз на рівні веб-додатка ви не зробите, хоча ORM (зокрема ActiveRecord) чесно спробує це зробити… і відвалиться. А на рівні БД це зробити можна, в деяких випадках, майже без оверхеда.

 

Логування

 

Про нього майже всі знають і всі використовують. Але на всяк випадок нагадаю: не соромтеся логіювати довгі запити. З коробки, PG, воно вимкнене. Треба потикати log_min_duration_statement. Стосовно його значення є багато холіваров і, можливо, мене закопають, але для початку, дайте пару секунд. Так, якщо у вас великий додаток, ви навряд чи це читаєте і самі знаєте що робити, а якщо маленький, то вам ніколи розбиратися з невеликими гальмами і вас турбують тільки фатальні речі.

Читайте також  Як вижити мисливцеві за багами: щоденна боротьба за дохід

 

Так само пам’ятайте про N+1. БД вам про це нічого не скаже. Використовуйте сторонні інструменти. Наприклад, bullet і здоровий глузд.

 

Статистика

 

Потрібно пам’ятати що вона є і що вона може стухнуть. На перших порах все добре. Але з часом, звичайно, виходить наступне: швидкість зміни даних, приблизно, однакова, а розмір таблиці все більше. Отже, vacuum/analyze таблиці починає відбуватися все рідше і в якийсь момент планувальник починає промахуватися. У кращому випадку, запит потрапляє в вищезазначене логування, в гіршому — ви просто страждаєте і не розумієте чому. Загалом, дивіться у pg_stat_user_tables і співставляйте дати вакууму/аналайза з навантаженням на таблиці.

 

А ще іноді можна використовувати статистику для зразкового count. Знадобиться рідко, але досить влучно, бо PG не Oracle і count для всієї таблиці виконується не за O(1), хоча дуже хочеться.

 

Кінець

 

Дякую, що прочитали.

Степан Лютий

Обожнюю технології в сучасному світі. Хоча частенько і замислююся над тим, як далеко вони нас заведуть. Не те, щоб я прям і знаюся на ядрах, пікселях, коллайдерах і інших парсеках. Просто приходжу в захват від того, що може в творчому пориві вигадати людський розум.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *