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

Використовувати БД тільки для складування даних — це все одно, що назвати 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, а у других — повноцінна.

Читайте також  Про одну задачу, яку більше не пропонують на співбесіді

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Читайте також  Приклади конфігурації RouteComposer

 

Foreign Data Wrapper

 

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

 

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

 

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

 

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

 

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

 

Логування

 

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

Читайте також  Аутентифікація asp .net core через IdentityServer4

 

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

 

Статистика

 

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

 

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

 

Кінець

 

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

Степан Лютий

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

You may also like...

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

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