SQL — повноцінна мова розробки чи примітивний інструмент для вибірки даних? У чому різниця між SQL та NoSQL? Чи є актуальною ця технологія для сучасної аналітики, у якій одна таблиця може важити петабайти? Та чому знати конструкції та селекти не дорівнює знати SQL. Катерина Медведська, Data Engineer в Boosters з екосистеми Genesis, спростовує найпоширеніші міфи в цій сфері.
МІФ №1
Я вивчив увесь SQL.
Більшість людей, які починають опановувати SQL, навіть не підозрюють, що насправді вивчають діалект. Є певні стандарти SQL, які кожна СУБД (система управління базою даних) бере за основу й чимось доповнює. Діалекти відрізняються у процедурній частині, у написанні функцій, різному процесингу, командах. У деяких СУБД написання процедури навіть підтримується на різних мовах: наприклад, в PL/pgSQL можна писати на стандартному SQL, а можна на С++. Корисно вивчати різні діалекти, адже швидко перейти з одного на інший доволі важко.
Деякі діалекти SQL:
SQL/PSM (SQL/Persistent Stored Modules) — стандарт процедурного програмування;
PL/SQL (Procedural Language / Structured Query Language) — розширення для Oracle;
PSQL (Procedural SQL) — розширення для Firebird та Interbase;
T-SQL (Transact-SQL) — розширення для Microsoft SQL Server та Sybase;
PL/pgSQL (Procedural Language/PostGres Structured Query Language) — розширення для PostGres).
МІФ №2.
SQL потрібен тільки для вибірки даних та роботи з селектами.
Насправді SQL вміщає кілька наборів команд — для маніпуляцій даними, структурами, транзакціями, правами доступу тощо. Їх поділяють на пʼять груп:
DDL — Data Definition Language.
DQL — Data Query Language.
DML — Data Manipulation Language.
DCL — Data Control Language.
TCL — Transaction Control Language.
Селекти — найпоширеніший тип команд у роботі з базами даних. Але це не означає, що всі інші групи команд — лише для бекенду. Аналітики менше займаються обробкою, майже не розробляють структури (команди DDL) і не користуються транзакціями. Але маніпуляція даними — мастхев для всіх, хто працює з SQL. Дата-інженери, дата-аналітики, продакт-аналітики працюють із даними, часто неточними, неякісними, які треба очищувати, обробляти та підганяти під свої стандарти. Тому вони мають знати SQL на досить хорошому рівні.
МІФ №3.
SQL за функціоналом — повноцінна мова розробки, аналогічна Python.
SQL часто потрапляє в рейтинги найпоширеніших мов поряд із JavaScript та випереджає Java, Python, PHP, C# та інші. Це спричиняє багато суперечок. На SQL багато чого можна зробити, особливо, якщо використовувати діалекти в конкретних базах даних. Наприклад, навіть написати HTTP запити. Але ця мова має обмежений функціонал і створена для конкретних задач.
МІФ №4.
В NoSQL немає SQL.
SQL передбачає роботу з реляційними базами даних. Наприклад, Microsoft SQL Server, Oracle, MySQL. У них інформація зберігається в рядках: кожен із них — одна одиниця памʼяті. Вважається, що цей тип баз даних можна масштабувати тільки вертикально, вони працюють на одному сервері, із часом вимагаючи все більше місця та розростаючись до величезних розмірів. Хоча насправді правильно побудована база даних може мати розмір у 8 терабайтів та стабільно працювати.
Пізніше зʼявилися нереляційні бази даних — NoSQL. Це ціла сукупність різноманітних СУБД які обʼєднані єдиною ідеєю легкого масштабування на кластер серверів та максимальною відмовостійкістю. Існують різні моделі NoSQL баз даних для вирішення різних завдань. Наприклад, дуже поширені: стовпчикові, документні, ключ-значення та графові БД.
Частина з них справді не підтримує стандарт SQL, але є і такі які підтримують його практично на 100%, наприклад, популярні в аналітиці стовпчикові бази даних. Вони розраховані на великі обсяги інформації — тисячі петабайтів.
Тому насправді «NoSQL» не означає, що там немає SQL. Оригінальна розшифровка — «not only SQL» або «non relational SQL». Спеціаліст, який знає SQL, може зайти в нереляційну базу й повноцінно працювати — там підтримуються практично всі команди (створення, дроп, зміна, DML). Вони можуть дещо відрізнятися за синтаксисом, але мінімально.
МІФ №5.
Щоби писати ефективні запити, достатньо знати конструкції мови.
Люди часто вивчають конструкції, але не розуміють, що лежить в основі. Для ефективної роботи треба розуміти, як працює база даних під капотом.
Кожна СУБД має певний оптимізатор, який працює по-своєму. Фактично запит — це набір інструкцій. У реляційних базах даних ефективність виконання запиту залежить від індексів та статистики (розраховується СУБД на основі попередніх запитів). На основі цієї статистики оптимізатор оцінює, чого йому очікувати від кожної частинки запиту і як це ефективно поєднати. Це великий обсяг інформації: як база даних зберігає інформацію, як обирає в певних конструкціях і як обробляє.
Якщо статистика або індекс змінюються, оптимізатор може перестати знаходити правильний план запиту. І конструкція, яка раніше працювала нормально, починає перевантажувати сервер та обробляється дуже довго.
У «стовпчикових» базах даних теж є нюанси: наприклад, тут відсутні індекси, а ще можна вибирати та обробляти окремі колонки, що значно економить ресурси сервера.
МІФ №6.
SQL для аналітики: застаріле рішення, має надто обмежені можливості.
Це упередження випливає з тих далеких часів, коли існували тільки реляційні бази даних із суто вертикальним масштабуванням. Зараз воно популярне серед людей, які насправді не дуже добре знають SQL — лише базові конструкції селектів та сучасні інструменти обробки даних.
Сьогодні ж для різних завдань аналітики потрібні різні види баз даних, наприклад, вище згадані «стовпчикові» для легкого масштабування системи.
SQL — досить потужна мова, яка для деяких завдань навіть зручніша за Python (для обробки даних, дедублікації, збагачення тощо). Велика кількість інструментів побудовані саме на базі ідеології SQL. Знаючи цю мову, можна швидко опанувати Spark SQL чи бібліотеку Pandas в Python — у них під капотом схожі команди. Тому SQL точно не застаріла для аналітики, просто треба використовувати нові продукти.
МІФ № 7.
Дані — абсолютно точні, з нульовою ймовірністю збою.
Усі, хто працюють із великими даними, знають, що проблем із ними дуже багато: неточності, помилки, невідповідність формату, дублі. Як не буває програмного забезпечення без помилок, так і не буває абсолютно точної бази даних. В аналітиці вважають, що похибка у 2-3% — допустима й не має високого впливу на результат.