Та все ж варто перевіряти свої припущення. Наприклад, роками нам казали, що підприємства не можуть замінити Oracle Database або SQL Server на PostgreSQL. Для багатьох робочих навантажень це сьогодні просто неправда, і майже напевно це було не так «правдиво» й раніше, як дехто хотів би нас переконати.
Хоча PostgreSQL завжди мала велику спільноту, у неї також був хор критиків. Тим часом кожен великий хмарний провайдер має службу баз даних PostgreSQL. Ідучи далі, у 2021 році AWS запустила Babelfish — проєкт із відкритим кодом, який спрощує додавання PostgreSQL до застосунків, написаних для SQL Server.
Так само є причина, чому кожен великий хмарний провайдер пропонує MongoDB у тій чи іншій формі, а базу даних за останні 12 місяців завантажували частіше, ніж за попередні 12 років разом узяті (загалом на сьогодні її завантажили 265 мільйонів разів).
І PostgreSQL, і MongoDB значно зросли в популярності порівняно з Oracle і SQL Server. Тепер MongoDB є лідером галузі в галузі безпеки завдяки випуску Queryable Encryption.
Атомарність, транзакції та інше.
Компанія завжди була улюбленицею розробників завдяки своїй зручності, але приблизно тоді ж MongoDB оголосила про придбання WiredTiger, що проклало шлях до керування паралелізмом і стиснення на рівні документів, починаючи з MongoDB 3.0 (WiredTiger як опція) і розвиваючись у MongoDB 3.2 (WiredTiger за замовчуванням).
Більшу частину роботи з глибокої інтеграції WiredTiger у MongoDB виконали у 2015 році, забезпечивши стабільний барабанний бій покращень бази даних на наступні кілька років; одна з моїх безумовних улюблениць — ACID-транзакції з кількома документами — з’явилася в MongoDB 4.0.
Як іронічно написав співзасновник MongoDB Еліот Горовіц у 2018 році: «MongoDB відмовляється від ACID», і після цього світ MongoDB вже ніколи не був таким, як раніше. У MongoDB 5.0 компанія представила версійований API, що дозволив розробникам оновлювати базу даних без потреби змінювати свій застосунок, функціональність для часових рядів, нову безсерверну пропозицію, динамічне шардування та багато іншого.
Зовсім нещодавно на MongoDB World компанія оголосила про низку речей, які полегшують життя розробникам: Atlas Data API, безсерверні екземпляри, Atlas CLI та багато іншого. Для мене двома найцікавішими тематичними анонсами були аналітика й безпека. А, і відкритий код.
Аналітика у світі MongoDB дає розробникам змогу створювати кращі застосунки, а не аналітикам даних — виконувати аналіз в автономному режимі. У сучасному світі потреба розуміти стан бізнесу в реальному часі наближає аналіз даних і потреби звітування до застосунків, які генерують ці дані.
MongoDB чітко усвідомила цю зростаючу потребу й оголосила про кілька нових способів спростити аналітику операційних даних, зокрема про новий інтерфейс SQL, рівні вузлів Atlas Analytics, федерацію даних Atlas і озеро даних Atlas.
Та мене вражає, що ключовим анонсом компанії щодо застосування аналітики до даних у реальному часі стало індексування Columnstore. Оскільки стовпцеві формати ідеально підходять для виконання аналітичних робочих навантажень, цей варіант індексування дає розробникам змогу легко зберігати документи в правильній для їхніх застосунків моделі, не переміщуючи дані, і виконувати ефективні аналітичні запити до цих даних у реальному часі для своїх застосунків.
Якщо все це стало несподіванкою для тих, хто вважає, що MongoDB — це вебмасштаб, то Queryable Encryption шокує ще більше.
Підвищуємо ставки у сфері безпеки даних
Усе, що випускає MongoDB (чи будь-яка інша компанія, що працює з базами даних), було б не надто корисним, якби функції й можливості не поєднувалися з безпекою. MongoDB уже давно пропонує чудовий захист, але запровадження структурованого шифрування для шифрування на рівні полів виводить ситуацію на новий рівень. Більшість баз даних навчилися захищати дані в стані спокою або під час передавання, але не можуть захистити дані під час використання, коли вони вразливі до доступу зсередини та активних атак на бази даних. Зустрічайте шифрування на рівні полів.
Шифрування на рівні полів захищає дані в пам’яті та на диску сервера. Це найвищий рівень захисту від зламів, але є й зворотний бік: він не дає змоги виконувати складні, виразні запити до зашифрованих даних. Так, можна шукати точну відповідність, але для цього доведеться використовувати детерміноване шифрування.
Дослідники працюють над цією проблемою з 2001 року, але цього тижня MongoDB анонсувала першу в історії комерційно доступну модель структурованого шифрування під назвою Queryable Encryption. Завдяки такому структурованому шифруванню MongoDB може криптографічно безпечним способом перетворювати зашифроване поле, щоб зберігати анонімні метадані, які дають змогу виконувати виразні й ефективні запити. Наприклад, структуроване шифрування дає розробнику змогу створити банківський застосунок, який може знаходити транзакції за діапазоном дат або сумою в доларах для розслідування шахрайства.
Це найкраще у своїй галузі рішення, яке не залишає позаду спільноту розробників MongoDB. Коротко кажучи, використання Queryable Encryption у MongoDB допомагає розробникам зосередитися на створенні привабливих застосунків, керованих даними, водночас розв’язуючи найскладніші в галузі проблеми конфіденційності даних. Докторський ступінь із криптографії не потрібен.
Це вже було б цікаво саме по собі, але MongoDB зайняла особливо примітну позицію щодо Queryable Encryption: вона буде на 100% відкритою. Як заявив Портер у своїй промові: «Ми публікуватимемо код, алгоритми й математику, що лежать в основі, бо віримо в безпеку білого ящика, а не чорного».
Це може здивувати тих, хто досі чіпляється до зміни ліцензії MongoDB у 2019 році. (Схоже, розробників це не дуже турбує, з огляду на їхні вищі пріоритети.) Але дивуватися не варто. MongoDB бере участь у розробці Apache Lucene, випускає WiredTiger під ліцензією з відкритим кодом і також пропонує своє мобільне сховище даних Realm із відкритим кодом.
Зводити компанії до бінарного вибору легко, але зазвичай це неправильно — як і в цьому випадку.
Підсумуймо
Усе це — довгий спосіб сказати, що, можливо, настав час натиснути «оновити» у своїх поглядах на MongoDB. Ні, ця платформа даних не підійде для всіх ваших робочих навантажень. Жодна не підійде. Але краще ухвалювати таке рішення, спираючись на реальність сьогодення, а не на застарілі міфи.
