Розбираємось з реляційними та нереляційними базами даних

Я Максим Івашура, свою першу «комерційну» базу даних написав 1995 року на екзотичній навіть для тих часів СКРБД DataEase. Відтоді я пройшов складний шлях від «програміста 2-ї категорії» на виробничих підприємствах України до Senior DB/DWH Engineer у компанії Intellias, де я також інтерв’юер, ментор та тренер з БД.

Цей текст є скороченим аналогом мого вебінару для девелоперів-початківців. В ньому я розповім про те, чим є сучасні бази даних та як їх можна використовувати в різних проєктах, а також розгляну кейси та виклики, пов’язані з використанням ШІ. Стаття буде корисна всім, хто не використовує бази даних щодня, тобто не є DB Developer: студентам та інтернам, джуніор-розробникам (зокрема розробникам БД), фахівцям, які прагнуть працювати з full-stack, інженерам з якості, а також іншим працівникам ІТ, наприклад менеджерам, бізнес-аналітикам тощо.

Найцінніший ресурс: якими бувають дані

Британський математик та підприємець Клайв Гамбі 2006 року заявив: «Дані — це нова нафта». А 6 травня 2017-го The Economist видав редакційну статтю «Найцінніший ресурс світу більше не нафта, а дані». Дійсно, за останні 20 років капіталізація нафтових компаній зменшилася у порівнянні з капіталізацією IT-компаній. Достатньо згадати Nvidia, Google, Apple та Microsoft, щоб зрозуміти, що ми живемо в епоху даних. Отож майже всі читачі DOU певним чином залучені до обробки даних.

Обробка даних охоплює їхнє зберігання та операції з ними (CRUD — Create, Read, Update та Delete), зокрема конвертацію. Своєю чергою, ми можемо виокремити структуровані дані, напівструктуровані дані та неструктуровані дані.

Структуровані дані

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

Одним із прикладів введення структурованих значень є вибір варіанту відповіді з елементів Dropdown, Radio Button чи Checkbox. Для текстових значень можна використати Textbox, а для дат — елемент календаря.

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

Говорячи про структуровані дані, будемо мати на увазі реляційні БД (такі як Oracle, MS SQL Server, PostgreSQL, MySQL, SQLite, MS Access тощо). Стандартною мовою для реляційних БД (СКРБД — системи керування реляційними БД, або англійською RDBMS — Relational Database Management Systems) фактично є SQL, але ще 30–35 років тому було багато СКРБД з власними, дуже специфічними мовами програмування (наприклад, FoxPro, dBase, DataEase, Paradox та ін.).

Напівструктуровані дані

Вони вже схожі на анкету, в якій відповідь можна вписати від руки. Обмежень, як у структурованих даних, майже немає, але все ж зберігається загальна структура полів анкети. Таким чином, в одне поле можна вносити різні дані: як типу Money (або Decimal), так і Datetime або Varchar (String), — і обробка відбудеться без помилок. Якщо поля не існувало на момент введення запису, воно буде створено на ходу. Як бачите, це додає певної гнучкості, але також спричиняє деякі проблеми, пов’язані з наступною обробкою напівструктурованих даних.

Коли ми говоримо про напівструктуровані дані, то передбачаємо нереляційні БД, які ще називають NoSQL (як-от MongoDB, Redis, Cassandra, Elasticsearch, Neo4j тощо). Стандартної мови для нереляційних БД (nRDBMS — no Relational DB Management Systems) як SQL немає, і це — великий мінус. Проте існують різні способи подружити nRDBMS із SQL (що вкотре підкреслює важливість SQL). З іншого боку, зручно те, що в nRDBMS використовується JSON (або XML, або щось, дуже схоже на HTTP-протокол).

Неструктуровані дані

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

Таким чином, коли ви копіюєте фотографії з відпустки на комп’ютер (або якийсь мережевий накопичувач) в окрему підтеку в теці «Сімейні фото», або HR зберігає CV працівників у зрозумілій йому / їй структурі тек, так само як і музичні файли відсортовані за виконавцем і далі за альбомами — це і є зберігання неструктурованих даних.

Попри те, що сучасні БД можуть зберігати доволі різні дані й у великих обсягах, гарною практикою є збереження неструктурованих даних окремо від, скажімо, структурованих, з подальшим посиланням на файлову систему замість перевантаження БД зображеннями чи відео. Це ж стосується невластивих БД функцій. Наприклад, не найкращою ідеєю може бути обробка XML за допомогою MS SQL Server (або надсилання e-mail-повідомлень, що теж можливо), якщо це не потрібно безпосередньо завданням БД для подальшої роботи.

Оскільки перші реляційні СКБД з’явилися в 70-х роках минулого століття, розуміти еволюцію БД краще в контексті наявних апаратних засобів і тенденцій відповідних часів. Спроби розробити бази даних були й раніше, але 1970 року Едгар Кодд видав статтю «A Relational Model of Data for Large Shared Data Banks», яка заклала фундамент реляційної моделі БД (тобто — СКРБД).

На підставі теорії Кодда програмісти IBM Дональд Чемберлін та Реймон Бойс почали розробляти мову керування даними, яку назвали SEQUEL (Structured English QUEry Language). З одного боку, це був сиквел до першої, не дуже успішної спроби SQUARE (Specifying Queries in A Relational Environment), а з іншого — створення мови програмування, яка б нагадувала просте спілкування з комп’ютером англійською мовою (Structured English QUEry Language). Також одним із завдань було запобігання використанню циклів для обробки даних (насправді цикли таки залишилися, але їх застосовують для певних завдань і переважно їх використання не потрібне).

У 70-ті роки XX сторіччя тогочасні комп’ютери були мейнфреймами, до яких під’єднували текстові термінали. Обслуговували їх команди програмістів. Це були дуже дорогі комп’ютери, які займали велику кімнату або машинний зал. Таку техніку могли собі дозволити великі компанії та державні установи. Тобто якщо керівництву була потрібна якась інформація, запускали довгий процес формулювання завдання, виділення машинного часу, імплементації рішення, перевірки, коригування тощо.

Створення такої мови програмування, яка б дозволяла бухгалтерам або аналітикам (фахівцям без особливого розуміння, як працює комп’ютер, змінних, циклів тощо) працювати з комп’ютером, була вкрай актуальна. Такою мовою стала SEQUEL.

Завдяки їй наявна конструкція запиту

SELECT 
FROM  
WHERE 
GROUP BY 
HAVING 
ORDER BY

більше нагадує послідовність дій англійською мовою, ніж справжній порядок запиту до БД, в якому SELECT буде передостанньою дією.

Але оскільки назва «SEQUEL» уже була зареєстрована британською компанією Hawker Siddeley, назву мови спростили до SQL — Structured Query Language. І хоча багато хто вважає, що «Сиквел» звучить крутіше за «ЕсК’юЕль», по суті це одне й те саме. Щоб нікого не ображати, я використовую в спілкуванні обидва варіанти.

У своїй теорії Едгар Кодд запропонував розбивати дані на колонки (або атрибути) та таблиці (або відношення), щоб забезпечити обмеження цілісності даних. Процес такої розбивки він назвав нормалізацією. (Детальніше про нормалізацію можна почитати в українській вікіпедії або розширеному англійському варіанті статті зі зрозумілими прикладами.)

Нормалізація дає змогу знизити кількість даних, які будуть вводитися (і, відповідно, зберігатися), а також контролює використання відповідних наявних даних з інших таблиць. Також завдяки нормалізації оновлення певних даних спрощується (наприклад, якщо видавництво змінило адресу — згідно з прикладами англійського варіанту статті).

Зворотною є денормалізація, тобто навмисне перетворення даних з нормальної форми (НФ) з вищим номером на НФ з нижчим номером (наприклад, з НФ 3-БК до 2-ї НФ).

Денормалізація збільшує кількість даних, зокрема дублювання певних даних, але дозволяє використовувати менше таблиць у запиті. Це позитивно позначається на продуктивності системи під час вибірок великої кількості даних.

Таким чином, можемо наразі підсумувати: нормалізовані дані підходять для так званої транзакційної обробки даних (OLTP — OnLine Transactional Processing), а денормалізовані — для аналітичної (OLAP — OnLine Analytical Processing).

Якомога менше даних якомога швидше. У чому суть транзакцій

У комп’ютерних науках транзакційна обробка (або процесинг) — це кілька операцій, які розділені на окремі, але разом з тим неподільні операції. Кожна транзакція має або повністю виконатися, або повністю скасуватися (відкотитися); транзакція ніколи не може бути виконана частково.

Яскравий приклад — робота банкомата (або ATM — Automated Teller Machine). Допоки ви не заберете гроші, транзакція перебуває в процесі обробки (в цей час баланс рахунку вже зменшився, і ви не зможете зняти всю суму з рахунку й водночас із того ж рахунку задонатити на ЗСУ). Якщо «щось пішло не так» і ви не отримали гроші (наприклад, змінився ваш баланс, бо дружина в супермаркеті розплатилася вашою карткою через NFC; або в банкоматі, який має видати вам 20 купюр по 200 грн, залишилося тільки 17 купюр; або стався збій на сервері чи в банкоматі), транзакція буде скасована, а гроші на вашому рахунку знову стануть доступними.

Якось моя знайома в банкоматі спочатку забрала картку і в підсумку не взяла гроші — сума була велика. З’ясувала це вже вдома, але гроші повернулися, бо транзакція не була завершена успішно.

Надійну роботу транзакцій забезпечує сумісність та відповідність ACID-концепції на рівні СКРБД. Ні, концепція ACID — це не про кислоти. Це — абревіатура: Atomicity, Consistency, Isolation, Durability. (Якщо вам цікава ця тема, рекомендую почитати статтю у Wikipedia.)

Мета транзакційного процесингу — оперувати якомога меншою кількістю даних якомога швидше. Тому зрозуміло, чому операції з нормалізованими даними — правильне рішення.

Ціллю систем обліку є отримання згрупованої інформації, щоб керівництво установи ухвалювало рішення. Транзакційні БД поховають керівника під деталями мільйонів операцій. На цьому рівні дані мають бути згруповані, агреговані та візуалізовані. Тобто керівництво має отримати аналітичні матеріали, де не буде надто багато цифр. На цьому етапі необхідна аналітична обробка даних.

Раніше ми згадували про OLAP і те, що для аналітичної обробки краще підходять денормалізовані дані. Для аналітичних же систем краще використовувати Data Warehouse (DWH, склад даних) замість звичайних БД.

Data Warehouse — це, можна сказати, розширена версія СКРБД, яка крім звичайного функціонала також підтримує додаткові інструменти роботи з великими обсягами даних. Ідеться не про Big Data, а просто про відносно великий обсяг структурованих — дуже часто денормалізованих — даних. Найбільша таблиця DWH, з якою я працював, налічувала 1,5 мільярда записів, але це радше виняток.

Існують різні підходи до проєктування Data Warehouse. Класичні рішення — методи Ральфа Кімбола та Білла Інмона. Детальніше про це можна прочитати тут.

Залежно від обраної концепції дані з OLTP СКРБД мають бути перетворені в денормалізовану OLAP СКРБД (якою може бути DWH). Для цього створюється ETL (Extract, Transform, Load) процес (або пайплайн) — зазвичай він передбачає ланцюжок складних перетворень даних з однієї структури в іншу. Велику денормалізовану таблицю називають таблицею фактів (fact table), дрібніші таблиці-довідники — дименшенами (dimensions), а числові поля з таблиці (або деяких таблиць) агрегованих фактів — метриками. Фактично ви можете використовувати дименшени, щоб згрупувати значення агрегування метрик або як фільтри.

Деякі аналітичні системи (наприклад, MS SSAS — Microsoft SQL Server Analysis Services) формують так звані аналітичні куби (analytical cubes), в яких вимірами є дименшени, а значеннями виступають попередньо агреговані значення (власне метрики). Таблиця Піфагора, знайома нам зі школи, — приклад двомірного «куба», в якому можемо зробити «зріз» за двома координатами та знайти результат. Але, звичайно, говорячи про аналітичні куби, ми не маємо на увазі щось суто тримірне — таких вимірів може бути доволі багато. Таким чином, маючи попередньо розраховані (агреговані) будь-які варіанти метрик відносно дименшенів, ми отримуємо швидку відповідь від сервера, а підготовчі процеси (такі як ETL та прорахунок аналітичного куба) можна зробити в період, коли система завантажена найменше, наприклад вночі.

Тож в аналітичних системах можна констатувати певну затримку результату, що допустимо для більшості замовників. Системи, які дозволяють обробляти аналітичні дані онлайн, особливо цікаві (вважаю, з часом їх більшатиме).

Тож знову можемо зробити проміжний підсумок.

OLTP-процесинг:

• використовують у застосунках, які взаємодіють із БД
• багато транзакцій можуть виконуватися (бути відкритими) одночасно різними сесіями
• БД орієнтована на записи й зберігає їх по одному

OLAP-процесинг:

• використовують разом з аналітичною БД (часто DWH)
• призначення — читання та агрегування даних
• БД орієнтована на колонки
• паралелізація процесів

СКРБД мають кілька концептуальних проблем:

• порівняно невисока продуктивність
• не дуже велика кількість даних може бути збережена
• чутливість до змін типу даних
• масштабування може бути дуже дорогим
• створення і підтримка розподілених рішень доволі складне.

Як дешевшали комп’ютери: екскурс в історію

80-ті роки XX сторіччя здешевили комп’ютери, і тепер вони були не тільки в дрібних підприємств, але навіть у приватних осіб. Так з’явилися СКРБД для персональних комп’ютерів (десктопні БД), які потім трансформувалися в БД для портативних пристроїв (яскравим зразком є SQLite, який по суті є маленькою бібліотекою, а не окремим продуктом). На згадку про цю епоху Microsoft усе ще додає декстопну СКРБД MS Access (який був презентований 1992 року та став першою СКРБД для Windows) в редакції MS Office Pro.

Наприкінці 80-х та 90-х років комп’ютери почали об’єднуватися в локальні мережі як без окремих серверів (так звані однорангові мережі, в яких можливо було працювати з десктопними БД тим же чином, як і редагувати документи на диску з загальним доступом), так і з виділеними серверами (для яких були розроблені клієнт-серверні рішення, зокрема БД, які продуктивніші за десктопні БД).

90-ті роки зробили інтернет доступним для всіх охочих, тож локальні мережі почали активно об’єднуватися в приватні або загальні мережі та надавати послуги широкому загалу користувачів, що збільшило навантаження, зокрема, на on-premises сервери БД. Технологія «тонкий клієнт» перенесла максимум обчислень на сервер, отож стало можливим мати тільки один потужний сервер, а інші комп’ютери не апгрейдити і використовувати їх як термінали (ці «клієнти» часто не мали жорсткого диска і завантажувалися з ROM-чипа в мережевій карті).

У нульових роках XXI століття з’явилися доступні хмарні сервіси, які додали нову парадигму до роботи з БД та зберігання даних (тут варто згадати велику «хмарну» трійку — Amazon, Microsoft та Google). А 20-ті роки XXI століття стрясає штучний інтелект.

Увесь цей час відбувалося здешевлення обчислювальних потужностей, чипів пам’яті та зберігання інформації.

Якщо мало часу. Коли потрібна СКРБД, а коли — Big Data

На вебінарах я зазвичай демонструю дві картинки:

• На першій продавець у магазині уважно роздивляється банкноту, щоби зрозуміти, чи вона справжня. Це важливо: якщо він прийме від покупця підробку, то в кращому разі матиме проблеми з керівництвом магазину, а в гіршому — з поліцією.
• На другій — пограбування банку: дівчина тримає сумку, чоловік туди пхає пачки купюр та золоті злитки. Їм важливо витратити якомога менше часу, щоб покинути банк до того, як приїде поліція. Чи впевнені грабіжники, що злитки дійсно з золота, а купюри справжні? Вони грабують банк, але що, як він схитрував або став жертвою інших злодіїв?

Продавець з першої картинки ретельно роздивляється 20-фунтову купюру, а скільки вкрадуть грабіжники з другої картинки — ще невідомо. Вони про це дізнаються набагато пізніше, коли пересвідчаться, що вони в безпечному місці та мають час для підрахунків.

Ви, мабуть, здогадалися, що перша картинка символізує роботу зі СКРБД, а друга — з BigData. Для біг-дата й інтернету речей (IoT — Internet of Things) характерні так звані три V: Volume, High Velocity та Variety (кількість, висока швидкість, розмаїття). Кількість IoT-пристроїв постійно збільшується, так само як і їхній загальний трафік. Тож завданням BigData-систем є зберігання даних, що постійно надходять, і їхня подальша обробка (на відміну від СКРБД, які перевіряють дані перед тим, як їх записати).

Зрозуміло, не усі ці дані мають якусь цінність в історичній перспективі. Вони можуть бути корисні в певний момент, наприклад ІоТ у вмиканні кондиціонера віддалено. Уявіть, ви повертаєтеся додому і хочете зайти в прохолодну кімнату, тож було б добре пересвідчитися, що вікна в кімнаті зачинені. Нас цікавить поточний статус датчика вікна, але з погляду зберігання більше важливий момент зміни статусу датчика зачинено/відчинено. Усі інші поточні дані можна проігнорувати.

IoT-пристрої — це не тільки про «розумний будинок». Бізнес також зацікавлений в IoT: GPS-трекери автомобілів логістичної компанії або літаків авіакомпанії, стан обладнання виробничої лінії чи ретрансляторів мобільного оператора, тиск на різних ділянках у системі магістральних трубопроводів чи навіть дані про порушення ПДР з камер спостереження поліції.

На допомогу прийдуть СКнРБД (системи керування нереляційними БД, nRDBMS — no Relational DB Management Systems), які ще називають NoSQL. Відразу згадується анекдот про адмінів БД: two DBAs walk into a NoSQL-bar and leave rather hurriedly when they can’t find a table.

Навіть якщо ви ніколи раніше не мали справи з NoSQL, з анекдоту зрозуміло, що в таких БД таблиць там немає. І це лякає людей, які раніше працювали зі СКРБД і близько до серця взяли їхню концепцію. В принципі, NoSQL іноді пояснюють як «Not only SQL».

Усі СКБД до появи реляційних баз були NoSQL. Вони існували з кінця 1960-х років, але потім їх замінили СКРБД. Сам термін NoSQL запропонував у 1998 році Карл Строцці для його СКРБД: вона не використовувала SQL, але все одно була реляційною (таким чином фактично не була NoSQL в сучасному розумінні). А на початку 2009-го Юан Оскарссон знову повернувся до цього терміна на семінарі «open-source distributed, non-relational databases». Відтоді кількість розробок нереляційних СКБД швидко зростає.

У 2009 році вже існували YouTube, Facebook, LinkedIn та багато інших компаній, чия діяльність потребувала постійного масштабування ресурсів, що можливе за допомогою СКРБД. Але такі рішення складно обслуговувати.

Розгляньмо переваги нереляційного підходу до збереження та обробки даних:

• відносно малий розмір ядра (або двигуна, бо англійською — engine)
• швидка обробка даних (що підходить для BigData-рішень)
• масштабування (реплікація та шардинг)
• використання JSON для зберігання (динамічна схема)
• інтегроване кешування.

Але при цьому нереляційні СКБД мають суттєві обмеження, які потрібно враховувати під час розробки архітектурного рішення. NoSQL-системи не підтримують або не повністю підтримують ACID-концепцію, таким чином не завжди підходять для транзакційних систем. Останнім часом розробники декількох NoSQL-систем декларують відповідність ACID (саме тому я кажу «не завжди»).

Немає єдиної мови програмування, як SQL (хоча існує декілька спроб адаптувати SQL для NoSQL або створити мови, що концептуально нагадують SQL). Також NoSQL складно використовувати для розрахунків.

Отож може виникнути питання, чи взагалі потрібні NoSQL БД?

Так, для певних завдань ви зможете суттєво підняти продуктивність усієї системи, наприклад, для зберігання даних для блогів і CMS (Content Management System), електронних каталогів, соціальних мереж, BigData та DataHub тощо. Як бачите, випадки, де потрібна БД, а математичні розрахунки не критичні, якраз і є юзкейсами для впровадження NoSQL БД.

Є 12 типів NoSQL БД, але цей список можна скоротити до чотирьох найбільш характерних:

• Key-value (Key pair) БД найпростіші, але завдяки мінімальному функціоналу (підходять для кешування та зберігання Big Data).
• Document store БД нагадують дані в 1-й НФ, таблиці звуться колекціями, а записи — документами (тобто виходить колекція документів, присвячених певній тематиці). Можуть бути впроваджені для електронних каталогів, ЗМІ, блогів тощо.
• Graph database мають специфічну логіку, бо використовують поняття вузлів (nodes) та відношень (relations) між вузлами. Підходять для рекомендаційних систем, соціальних мереж, систем із розпізнавання фінансового шахрайства.
• Column store БД можна уявити як щось подібне до DWH.

Наведу простий порівняльний приклад: блог має статтю, теги та коментарі. Зі СКРБД функціонал можна реалізувати за допомогою трьох умовних таблиць: статті, теги та коментарі.Теги та коментарі будуть посилатися на ідентифікатор статті (яка також може мати посилання на певний розділ блогу). Як бачите, маємо реляційну модель. Якщо в нас є 10 000 статей та по 100 коментарів до кожної, таблиця коментарів буде мати 1 000 000 записів, які треба бути обробити, щоб відобразити окремо коментарі до певної статті (доволі часто саме БД є так званим bottleneck — «шийкою пляшки», тобто слабкою ланкою всієї системи). За допомогою документо-орієнтованої NoSQL БД будемо мати документ у колекції, який охоплюватиме всі теги (можливо, як nested-поля) та коментарі (як піддокументи). Оскільки NoSQL-документ має «все в одному», він швидше завантажуватиметься, а користувач не чекатиме жахливі 2+ секунди.

Оскільки ми пригадали динамічну схему даних, це прямо вказує на те, що ми маємо справу з напівструктурованими даними.Також ми говорили про обмеження NoSQL з підтримкою ACID-концепції. Замість неї варто згадати про BASE-концепцію (акронім від Basically Available, Soft State та Eventually Consistent), яка є протилежністю ACID. Порівняння обох концепцій можна переглянути тут.

Коли ми говоримо про масштабування NoSQL, то зважаємо, що ACID-системи (які можуть бути NoSQL) масштабуються вертикально (тобто додаються ресурси до наявного сервера), а BASE — горизонтально (тобто додаються додаткові сервери, на яких реалізується шардинг, або сегментування, — горизонтальне партиціонування, про яке більше можна почитати тут). BASE-системи часто використовують у розподілених обчисленнях. Вони підпадають під дію CAP-теореми (Consistency — цілісність, Availability — доступність, Partition tolerance — часткова толерантність), яка каже, що водночас можна виконати тільки будь-які дві з трьох умов.

Яку базу обрати

Правильніше обирати не тип СКБД (RDBMS vs. NoSQL), а концепцію ACID чи BASE, враховуючи подальше масштабування та можливість застосування розподілених обчислень. Для ACID можна сказати, що цей концепт краще підходить, коли потрібно забезпечити цілісність, передбачуваність та надійність. Ті, хто прагне більшої гнучкості та простішого масштабування, попри відсутність якостей, гарантованих ACID, можуть обирати BASE.

Але ніхто не забороняє використовувати комбіновані системи, в яких певні завдання будуть відповідати ACID, а інші — BASE. Ба більше, сучасні системи успішно комбінують кілька різних СКБД. Наприклад, система замовлень електронного магазину може базуватися на реляційній БД, для кошика кожного сеансу та кешування даних може бути використана key-value NoSQL, а в ролі електронного каталогу — швидка документо-орієнтована БД. Звісно, такий підхід потребує кваліфікованих розробників, можливо, фахівців з розробки БД та дата-інженерів. Але й кінцевий продукт вийде надійнішим.

NoSQL приваблюють розробників простотою створення БД, тож пізніше ці розробники можуть стикнутися з непродуманими, з погляду збереження та обробки даних, рішеннями (динамічна схема надає не тільки гнучкість, але й може принести певний хаос у кінцеву структуру даних). Навпаки, розробники, що приділяють велику увагу реляційним БД і згори дивляться на «несправжні» NoSQL БД, застрягають у минулому і втрачають можливості (я сам, вперше стикнувшись з NoSQL БД у 2010 році, подумав, що це не варте мого часу. Згодом я змінив-таки ставлення та з задоволенням вивчив роботу кількох нереляційних СКБД). Істина — посередині. Microsoft додав у версію MS SQL Server 2017 роботу з графовими об’єктами. А раніше в MS SQL Server 2016 була додана підтримка JSON, яку Microsoft анонсував як місток між реляційними та NoSQL БД. Ще раніше, в MS SQL Server 2012, була додана підтримка XML.Така інтеграція стосується й інших СКРБД, а NoSQL БД мають тенденцію стандартизуватися і підтримувати SQL або SQL-подібні мови.

Жахастики про штучний інтелект

У цій статті ми не охоплюємо машинного навчання (ML — Machine Learning), яке також пов’язане з БД, але не стосується їх прямо. Оскільки зараз багато хайпу щодо штучного інтелекту, це хотілося б обговорити окремо.

Сучасний жахастик — ШІ скоро замінить програмістів. Тож досить бавитися кнопочками, треба займатися реальними речами, які прогодують в майбутньому. ШІ створюватиме новий ШІ — й так до нескінченності.

Доступність персональних комп’ютерів, принтерів та розвиток БД в 90-х роках породили кілька міфів, наприклад про безпаперовий офіс. Згідно з цією теорією, різні підприємства та установи повністю позбудуться паперу, бо усе зберігатиметься в комп’ютері, нові документи можна згенерувати на екрані в будь-який момент, а старі будуть відскановані і їх буде просто відшукати (і за потреби роздрукувати). По факту, дані часто втрачали (навіть зараз можна з’ясувати, що ваша флешка не відкривається, а в 90-х роках люди носили дискети, які взагалі відкривалися через раз, були чуттєві до перепадів температури і їхня місткість обмежувалася 1,44 МБ), тож надійніше було роздрукувати певні звіти. Державні органи не брали до уваги непаперові документи, а оскільки комп’ютери могли згенерувати велику кількість звітів, фактично тих самих даних у різних розрізах (в різних вимірах, або дименшенах), кількість паперу в офісах почала зростати.

Мені здається, що зараз, через 30+ років, ми наблизилися до чогось подібного. Замість роздрукованого посадкового талона на літак чи квитка на потяг можна просто просканувати QR-код або показати посвідчення водія в телефоні. Але ми все одно носимо багато паперових документів, які все ж пріоритетніші. Водночас ми отримали багато питань щодо безпеки даних та втручання в особисте життя.

Інший міф з 90-х — книжки скоро зникнуть. Коли принтери й сканери здешевилися, книговидавці забили на сполох. Мовляв, після того, як книжки оцифрують, їх просто будуть друкувати на принтері, або неоцифровані книжки копіюватимуть на домашніх пристроях. З винаходом електронних чорнил картина стала ще більш песимістичною. Звісно, що книгарні не зникли, а ось друк газет трансформувався завдяки інтернету.

Нерозуміння технологій породило бульбашку доткомів у період з 1995-го до 2000 року. Тоді вважалося, що будь-який сайт автоматично приноситиме прибуток акціонерам. З’явилося поняття millenium day — страх того, що після переходу з 1999-го на 2000-й комп’ютери дадуть збій і почнеться колапс енергетики й економік, війни тощо.

Щодо ШІ, сучасні системи все ще не є штучним інтелектом, але є LLM (Large Language Model — великою мовною моделлю). Дійсно, поточних можливостей вистачить на написання простого шаблону автотесту або якогось SQL-запиту. Та все одно будь-який результат має ретельно перевірити людина. Вона використовує стратегічне мислення, технічну професійність та комунікативні навички. ШІ умовно може підсилити технічну професійність (бо все одно потрібен контроль з боку людини, а відповідальність на себе компанії-розробники ШІ брати не хочуть), але не здатний замінити стратегічне мислення та комунікативні навички.

Мій брат — архітектор та дизайнер інтер’єрів. Нині є кілька ШІ-застосунків, які можуть згенерувати дизайн інтер’єру. Але не це важливе в роботі дизайнера, а те, що картинку треба втілити в життя: купити шпалери певного кольору, а якщо таких не існує, швидко зорієнтуватися та обрати схожі, щоб зберегти концепцію інтер’єру. Так само зі всім іншим. ШІ може намалювати що завгодно (як і замовник може сказати: «Я хочу...»), але це намальоване має також існувати на ринку і поєднуватися з іншими елементами.

Ми постійно постаємо перед викликами й адаптуємося до нових умов, технологій та обмежень. Спочатку комп’ютери відображали стан роботи кроковими реле (пам’ятаєте кіно про машину Тюрінга?). Потім стан реєстрів відображався лампочками. Далі — роздруківки і текстові термінали, поява графічних дисплеїв та персональних комп’ютерів (уявіть, у свою першу гру я грав на комп’ютері без графічної карти, а 37 років тому машинний код програм друкували в журналах та вводили з клавіатури вручну), мережі та серверні обчислення, розподілені обчислення, блокчейн, інтернет. Усе це — менш ніж за 80 років існування комп’ютерів.

Отже, щоб наша робота ставала ефективнішою, маємо знов адаптуватися, і сьогодні — під наявні ШІ-рішення. Поки ми цього не робимо, це роблять наші колеги. Відтак нам потрібно буде їх доганяти, замість того щоб самим бути лідерами. Тож необхідно вивчати доступні ШІ-рішення не тільки з огляду на написання листів чи привітань, але й на програмування (звісно, не забуваючи про безпеку даних). Такі курси масово існують на популярних освітніх платформах.

Хочу закликати розробників інвестувати час у вивчення як реляційних, так і нереляційних систем. Як мінімум — мати «джентльменський набір» з однієї СКРБД (наприклад, PostgreSQL, на яку зараз є попит, хоча я особисто її недолюблюю) та NoSQL БД (наприклад, MongoDB, з якою можна ознайомитися за вікенд, а за чотири тижні пройти повний безплатний курс від MongoDB University й отримати сертифікат).