Майбутнє реляційних СУБД в епоху Big Data

Database Management / SQL / Корпоративна архітектура

Чому поширення Big Data не означає завершення епохи реляційних баз даних

Упродовж останніх років технологічний ринок активно обговорює розвиток NoSQL, розподілених файлових систем, хмарних сховищ та платформ Big Data.

Apache Hadoop дозволяє накопичувати великі масиви різнорідної інформації. Apache Spark забезпечує розподілену аналітичну обробку. MongoDB і Apache Cassandra пропонують інші моделі зберігання, а хмарні постачальники дедалі активніше розвивають керовані бази даних. На цьому тлі виникає закономірне запитання: чи залишаться традиційні реляційні системи управління базами даних основою корпоративної ІТ-інфраструктури?

Для підприємств відповідь має не лише технологічне, а й економічне значення.

ERP, CRM, фінансові, кадрові та виробничі системи протягом десятиліть будувалися навколо реляційних моделей.

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

Тому оцінювати перспективи реляційних СУБД необхідно з урахуванням їхніх реальних функцій.

Головна перевага реляційних баз даних полягає не тільки у використанні SQL, а в поєднанні зрілої моделі даних, транзакційної цілісності, механізмів безпеки та розвинених засобів експлуатації.

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

Реляційна модель та її значення для підприємств

Основи реляційної моделі були запропоновані Едгаром Коддом у 1970 році. Згодом вони стали фундаментом промислових СУБД, які використовуються в корпоративному середовищі.

Реляційний підхід дозволяє представляти інформацію через таблиці та встановлювати між ними логічні зв’язки. Наприклад, система управління замовленнями може містити таблиці клієнтів, замовлень, товарів і товарних позицій. Для кожного об’єкта визначаються ключі та правила цілісності.

Первинні та зовнішні ключі

Первинний ключ дозволяє однозначно ідентифікувати запис. Зовнішній ключ забезпечує зв’язок між таблицями. Наприклад, замовлення може посилатися на клієнта через відповідний ідентифікатор.

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

Нормалізація

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

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

ACID-транзакції залишаються основою корпоративних операцій

Однією з найважливіших характеристик реляційних СУБД є підтримка транзакцій.

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

Якщо одна частина операції виконалася, а друга завершилася помилкою, підприємство може отримати неправильний залишок.

Транзакційні механізми дозволяють запобігати таким ситуаціям.

Atomicity

Атомарність означає, що транзакція розглядається як єдина логічна операція.

Якщо її не можна завершити відповідно до визначених умов, зміни можуть бути відкочені.

Consistency

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

Вона не може самостійно визначити всі бізнесові вимоги.

Isolation

Ізоляція дозволяє контролювати взаємодію одночасних транзакцій.

У різних СУБД використовуються відповідні рівні ізоляції та механізми блокування або багатоверсійності.

Durability

Довговічність означає збереження підтвердженої транзакції відповідно до гарантій СУБД і конфігурації її зберігання. Проте необхідно правильно налаштовувати журнали транзакцій, дискову підсистему та резервування.

Сам факт використання реляційної СУБД не усуває наслідків фізичної відмови обладнання без належної інфраструктури.

SQL Server 2016: нові можливості традиційної платформи

Одним із важливих релізів року став Microsoft SQL Server 2016.

1 червня Microsoft оголосила про його загальну доступність.

Платформа отримала додаткові можливості безпеки, обробки інформації та аналітики.

Always Encrypted

Always Encrypted дозволяє захищати визначені стовпці з використанням криптографічних механізмів на клієнтському боці.

Це створює додаткові можливості захисту конфіденційних значень від окремих категорій доступу на сервері. Проте технологія має обмеження щодо підтримуваних типів запитів і операцій.

Тому її використання необхідно враховувати під час проєктування застосунку.

Row-Level Security

Row-Level Security дозволяє реалізовувати фільтрацію доступу до рядків відповідно до встановлених правил. Наприклад, корпоративний застосунок може використовувати єдину таблицю замовлень, але надавати співробітникам доступ лише до відповідних записів.

Однак правила повинні бути правильно пов’язані з контекстом автентифікованого користувача.

Temporal Tables

Системно-версійовані temporal tables підтримують історію змін визначених записів. Це може бути корисним для аналізу попередніх станів інформації.

Наприклад, підприємство може встановити, які значення певних атрибутів були актуальними в минулому. Водночас temporal tables не замінюють усіх вимог до юридично значущого аудиту чи корпоративного архівування.

R Services

SQL Server 2016 також інтегрує засоби виконання аналітичних алгоритмів на основі R. Це демонструє важливу тенденцію: традиційні СУБД поступово поєднують транзакційну обробку з розширеними аналітичними можливостями.

Водночас для складних моделей необхідно окремо оцінювати навантаження та ізоляцію обчислень від критичних бізнесових транзакцій.

Service Pack 1

16 листопада 2016 року Microsoft випустила SQL Server 2016 Service Pack 1.

Це важливий етап розвитку платформи, зокрема щодо доступності окремих функціональних можливостей у різних редакціях.

Для підприємств це створює додаткові можливості стандартизувати середовища розроблення, тестування та продуктивної експлуатації. Проте необхідно враховувати ліцензійні та ресурсні обмеження конкретної редакції.

PostgreSQL 9.6: реляційні бази продовжують масштабуватися

29 вересня 2016 року вийшла PostgreSQL 9.6.

Одним із найважливіших нововведень стала підтримка паралельного виконання окремих типів SQL-запитів.

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

Паралельні запити

PostgreSQL 9.6 дозволяє використовувати декілька процесів для виконання частини операцій у межах одного запиту. Зокрема, це стосується визначених сценаріїв сканування таблиць, з’єднань і агрегування.

Для аналітичних навантажень така можливість може забезпечувати суттєве підвищення продуктивності. Однак не кожен SQL-запит автоматично виконуватиметься паралельно.

Ефективність залежить від плану виконання, статистики, обсягу інформації та кількості доступних ресурсів.

Синхронна реплікація

У PostgreSQL 9.6 розвиваються механізми роботи із синхронними резервними вузлами. Це дозволяє гнучкіше визначати умови підтвердження транзакцій у відповідних конфігураціях.

Проте підвищення гарантій збереження може впливати на затримку підтвердження запису.

Тому архітектура повинна враховувати вимоги до RPO, продуктивності та доступності.

JSONB та індексація

PostgreSQL також підтримує тип JSONB, який дозволяє зберігати й обробляти структуровані JSON-документи. Для відповідних запитів можуть використовуватися індекси, зокрема GIN.

Це важливий приклад зближення традиційних реляційних СУБД із деякими підходами документно-орієнтованих баз даних.

Підприємство може використовувати реляційні таблиці для транзакційної частини та JSONB для окремих змінних структур, не впроваджуючи обов’язково додаткову СУБД.

MySQL 5.7: розвиток транзакційних вебсистем

MySQL залишається однією з поширених платформ для вебзастосунків і корпоративних сервісів.

MySQL 5.7 стала загальнодоступною 21 жовтня 2015 року. Отже, протягом 2016 року підприємства вже можуть використовувати її у продуктивних системах.

Серед важливих можливостей гілки 5.7 — розвиток JSON-функціональності, вдосконалення InnoDB та засобів адміністрування.

InnoDB

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

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

JSON

Нативний тип JSON у MySQL 5.7 дозволяє зберігати JSON-документи й використовувати спеціалізовані функції роботи з ними.

Однак це не означає, що реляційна модель стає непотрібною.

Для ключових транзакційних об’єктів необхідно визначати стабільні структури, ідентифікатори та правила цілісності.

Перспективи нових версій

Важливо не переносити до 2016 року функціональність майбутньої стабільної MySQL 8.0. Станом на кінець грудня 2016 року промисловою актуальною гілкою залишається MySQL 5.7.

Використання експериментальних можливостей майбутніх версій потребує окремого тестування й не повинно підміняти планування підтримуваної корпоративної платформи.

Oracle Database та корпоративні транзакційні системи

Oracle Database залишається важливою платформою для великих підприємств. У 2016 році Oracle Database 12c використовується в критичних корпоративних системах, зокрема фінансових і виробничих комплексах.

Важливою характеристикою платформи є розвинений набір механізмів транзакційної обробки, резервування та адміністрування.

Oracle Multitenant

Архітектура Oracle Multitenant передбачає використання контейнерної бази даних і підключених баз. Це дозволяє організовувати кілька логічних середовищ у межах відповідної архітектури СУБД.

Проте необхідно враховувати ліцензійні умови та особливості експлуатації.

Oracle Data Guard

Data Guard використовується для підтримання резервних баз і реалізації сценаріїв аварійного відновлення. Для підприємств це важливо в контексті безперервності бізнес-процесів.

Однак реплікація не замінює незалежні резервні копії.

Oracle RMAN

Recovery Manager забезпечує інструменти резервного копіювання та відновлення. Для критичних систем необхідно регулярно перевіряти відповідні процедури.

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

Чому NoSQL не замінює реляційні СУБД

NoSQL охоплює різні технологічні моделі.

MongoDB використовує документно-орієнтований підхід.

Apache Cassandra призначена для розподіленого зберігання з відповідною моделлю масштабування та узгодженості.

Redis використовується для швидкого доступу до даних у пам’яті й інших спеціалізованих сценаріїв.

Кожна платформа має власні переваги та обмеження.

Документно-орієнтовані дані

MongoDB може бути корисною для застосунків зі змінною структурою документів. Наприклад, каталог продукції може містити різні характеристики для різних категорій товарів.

Однак гнучка схема не усуває потреби в правильній інформаційній моделі.

Підприємство повинно визначати правила ідентифікації, валідації та змін документів.

Розподілене зберігання

Cassandra може бути доцільною для певних великих розподілених навантажень. Проте її модель запитів і транзакційні властивості відрізняються від традиційних реляційних СУБД.

Тому перенесення складної ERP до такої платформи може потребувати суттєвої перебудови прикладної логіки.

Кешування

Redis може використовуватися для прискорення доступу до часто запитуваної інформації. Наприклад, вебпортал може кешувати частину товарного каталогу.

Проте кеш не повинен безконтрольно ставати альтернативним авторитетним джерелом корпоративних даних. Необхідно визначати правила оновлення та допустиму застарілість інформації.

Отже, NoSQL не є наступним універсальним поколінням, яке обов’язково замінить SQL. Це набір альтернативних моделей, доцільність яких визначається конкретними вимогами.

Data Lake та реляційне DWH

Одним із найбільш поширених прогнозів останніх років є можливе витіснення реляційних аналітичних сховищ Hadoop-платформами. Проте Data Lake і DWH мають різні функції.

Data Lake забезпечує гнучке накопичення великих різнорідних наборів. DWH орієнтоване на формування узгоджених аналітичних моделей і контрольованих бізнес-показників.

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

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

Проте після відповідного очищення частина результатів може завантажуватися до корпоративного DWH.

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

SQL поступово виходить за межі традиційної СУБД

Важливою тенденцією 2016 року є розвиток SQL-інтерфейсів у системах розподіленої обробки. Apache Hive дозволяє виконувати SQL-подібні запити до інформації у Hadoop.

Spark SQL забезпечує роботу зі структурованими наборами даних у Spark. Інші інструменти також намагаються надати аналітикам знайомі засоби запитів до різнорідних джерел.

Це демонструє важливий факт: навіть під час розвитку нових моделей зберігання підприємства продовжують потребувати декларативного способу роботи з інформацією.

Чому SQL залишається корисним

SQL дозволяє описувати необхідний результат без детального визначення всіх процедур фізичного виконання. Оптимізатор СУБД може вибирати відповідні плани запитів.

Це є важливою перевагою для аналітичної та транзакційної роботи. Звичайно, різні SQL-платформи мають неоднакові можливості.

Запит, який ефективно виконується на PostgreSQL, може потребувати іншої оптимізації в Spark SQL.

Однак загальна декларативна модель залишається цінною.

Хмарні реляційні бази: зміна способу експлуатації

Окремим напрямом розвитку стають керовані хмарні СУБД.

Amazon RDS, Azure SQL Database та інші сервіси дозволяють підприємствам використовувати реляційні бази без самостійного адміністрування всієї фізичної інфраструктури.

Amazon Aurora

Aurora стала загальнодоступною як MySQL-сумісна керована база у 2015 році.

30 листопада 2016 року AWS оголосила про попередній доступ до PostgreSQL-сумісного варіанта Aurora.

Це демонструє подальше розширення хмарної реляційної моделі.

Водночас станом на грудень 2016 року PostgreSQL-сумісна Aurora перебуває в режимі preview, тому її не слід описувати як давно доступну загальновиробничу платформу.

Azure SQL Database

Azure SQL Database дозволяє використовувати SQL-сервіси в керованому хмарному середовищі. Для нових прикладних систем це може скорочувати обсяг операцій із встановлення та супроводу серверів.

Проте підприємство все одно повинно відповідати за логічну структуру бази, SQL-запити, інформаційну безпеку та правила використання даних.

Роль адміністратора баз даних

DBaaS змінює характер роботи DBA. Частина інфраструктурних операцій переходить до постачальника.

Водночас залишаються завдання продуктивності, проєктування інформаційних моделей, контролю доступу, управління витратами та перевірки відновлення.

Отже, хмарні сервіси не усувають професійну потребу в адмініструванні даних, а змінюють розподіл відповідальності.

Поєднання реляційних і нереляційних технологій

Для великих підприємств найбільш практичним може бути використання кількох спеціалізованих платформ. Розглянемо умовну архітектуру торговельної компанії.

• ERP / CRM / Документообіг
• Oracle · SQL Server · PostgreSQL · MySQL
• Транзакції та авторитетні корпоративні записи
• Інтеграційний рівень
• REST · SOAP · ETL · Kafka
• Data Lake
• HDFS, Spark, великі різнорідні набори
• DWH / BI
• Узгоджені показники та звітність

Концептуальна архітектура співіснування реляційних СУБД, корпоративних інтеграцій і платформ Big Data. У такій архітектурі кожний компонент виконує визначену функцію.

Реляційні СУБД забезпечують операційну цілісність. Kafka або інші механізми передають події.

Data Lake накопичує різнорідні джерела. DWH формує узгоджені показники для корпоративної звітності.

При цьому необхідно визначати авторитетні джерела та контролювати інформаційні перетворення.

Data Governance як основа технологічного вибору

Незалежно від СУБД підприємство повинно забезпечувати корпоративне управління даними. Для цього необхідно визначати Data Owner, Data Steward, правила якості та інформаційні контракти.

Наприклад, якщо клієнтський довідник розподілений між ERP, CRM і документною базою, необхідно встановити, яка система відповідає за кожен атрибут. Саме це питання визначатиме архітектуру синхронізації.

Технологічний вибір не повинен підміняти бізнесове рішення. Наприклад, перенесення довідника контрагентів із SQL Server до MongoDB не вирішить проблему дублікатів, якщо підприємство не визначило правила їхнього виявлення.

Аналогічно використання Spark не виправить некоректну методику розрахунку фінансового показника.

Тому Data Governance і Data Quality повинні розглядатися як постійні функції корпоративного управління.

Критерії вибору технології зберігання

Для нового корпоративного проєкту доцільно оцінювати кілька характеристик.

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

Тому вибір необхідно виконувати на основі конкретного робочого навантаження.

Практичні рекомендації для підприємств на 2017 рік

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

Якщо основна проблема пов’язана з повільними SQL-запитами, доцільно спочатку оцінити індекси, статистику та інформаційну модель. Якщо підприємство накопичує великі журнали подій, можливо, варто додати спеціалізоване файлове сховище.

Якщо необхідна оперативна інтеграція між системами, можуть застосовуватися API або брокери повідомлень. Якщо бізнес хоче використовувати Machine Learning, потрібно почати з підготовки якісних історичних даних.

Технологічна модернізація повинна бути послідовною.

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

Компетенції Intecracy Group у розвитку корпоративних платформ даних

Розвиток корпоративних систем зберігання потребує узгодженої роботи кількох технологічних напрямів. Data Management IG спеціалізується на управлінні корпоративними даними, ETL, MDM, Data Quality, DWH та аналітиці. Ці компетенції важливі для визначення інформаційних моделей, інтеграції різних СУБД та забезпечення якості даних.

IQusion IT працює у сферах системної інтеграції, електронного документообігу та BPM. Відповідні компетенції мають значення для забезпечення взаємодії прикладних систем із корпоративними інформаційними платформами. Softline IT спеціалізується на серверній та мережевій інфраструктурі, системах зберігання й корпоративних інфраструктурних проєктах. Вони визначають продуктивність, надійність і можливості масштабування локальних СУБД.

SL Global Service має компетенції у сфері хмарної інтеграції, віртуалізації та гібридної інфраструктури. Ці напрями можуть використовуватися для розміщення керованих баз даних та інтеграції локальних і хмарних середовищ.

Вибір відповідної технології повинен здійснюватися з урахуванням бізнесових вимог, інформаційних ризиків і сукупної вартості експлуатації.

Практичні орієнтири для впровадження

Розвиток Big Data, Data Lake, NoSQL і хмарних сервісів не означає завершення епохи реляційних баз даних.

Oracle Database, Microsoft SQL Server, PostgreSQL і MySQL продовжують розвиватися та забезпечувати критичні корпоративні операції.

SQL Server 2016 отримав нові засоби безпеки й аналітики, PostgreSQL 9.6 — можливості паралельного виконання запитів, а хмарні сервіси розширили доступні моделі експлуатації реляційних платформ.

Водночас Hadoop, Spark, Kafka й альтернативні СУБД дозволяють вирішувати завдання, для яких традиційна реляційна модель не завжди є оптимальною.

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

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