Cosmos DB

Azure Cosmos DB — це глобально розподілена багатомодельна служба бази даних, яку пропонує Microsoft. Він розроблений для забезпечення високої доступності, масштабованості та низької затримки доступу до даних для сучасних програм. На відміну від традиційних реляційних баз даних, Cosmos DB є NoSQL (що означає «не тільки SQL», а не «нульовий SQL») і векторною базою даних^[1], що означає, що вона може обробляти неструктуровані, напівструктуровані, структуровані та векторні типи даних.^[2]

Azure Cosmos DB

Тип	багато-модельні бази даних
Розробник	Microsoft
Перший випуск	2017; 8 років тому (2017)
Доступні мови	English
Вебсайт	learn.microsoft.com/en-us/azure/cosmos-db/introduction

Модель даних

Внутрішньо Cosmos DB зберігає «елементи» в «контейнерах»^[3], причому ці дві концепції відображаються по-різному залежно від використовуваного API (це будуть «документи» в «колекціях», якщо використовується, наприклад, сумісний з MongoDB API). Контейнери згруповані в «бази даних», які аналогічні просторам імен над контейнерами. Контейнери не залежать від схеми, що означає, що жодна схема не застосовується при додаванні елементів.

За замовчуванням кожне поле в кожному елементі автоматично індексується, що зазвичай забезпечує хорошу продуктивність без налаштування певних шаблонів запитів. Ці параметри за замовчуванням можна змінити шляхом встановлення політики індексування, яка може вказати для кожного поля тип індексу та бажану точність. Cosmos DB пропонує два типи індексів:

• ранговий, підтримка діапазону та запитів ORDER BY
• просторовий, що підтримує просторові запити з точок, багатокутників і рядків ліній, закодованих у стандартних фрагментах GeoJSON

Контейнери також можуть застосовувати унікальні ключові обмеження для забезпечення цілісності даних.^[4]

Кожен контейнер Cosmos DB надає канал змін, на який клієнти можуть підписатися, щоб отримувати сповіщення про нові елементи, які додаються або оновлюються в контейнері.^[5] Станом на 2021 рік видалення елементів наразі не відображається в каналі змін. Зміни зберігаються в Cosmos DB, що дає змогу запитувати зміни з будь-якого моменту часу з моменту створення контейнера.

«Час життя» (або TTL) можна вказати на рівні контейнера, щоб дозволити Cosmos DB автоматично видаляти елементи через певний проміжок часу, виражений у секундах. Цей відлік починається після останнього оновлення елемента. Якщо необхідно, TTL також можна перевантажити на рівні елемента.

Багатомодельні API

Внутрішня модель даних, описана в попередньому розділі, представлена через:

• власницький SQL API.
• п’ять різних API сумісності, що відкривають з'єднання, які частково сумісні з протоколами MongoDB, Gremlin, Cassandra, Azure Table Storage тощо; ці API сумісності дають змогу будь-якій сумісній програмі підключатися до Cosmos DB і використовувати її через стандартні драйвери або SDK, а також отримувати переваги від основних функцій Cosmos DB, таких як розділення та глобальне поширення.

API	Внутрішнє покриття		Статус сумісності та зауваження
	Контейнери	Елементи
MongoDB	Колекції	Документи	Сумісний із провідним протоколом версії 6 і сервером версії 3.6 MongoDB.[6]
Gremlin	Графи	Вузли та вершини	Сумісний із версією 3.2 специфікації Gremlin.
Cassandra	Таблиці	Рядки	Сумісний із версією 4 протоколу мови запитів Cassandra (CQL).
Azure Table Storage	Таблиці	Елемент
etcd	Ключ	Значення	Сумісний із версією 3 etcd.[7]

SQL API

SQL API дозволяє клієнтам створювати, оновлювати та видаляти контейнери та елементи. Елементи можна запитувати за допомогою діалекту SQL, який доступний лише для читання й підтримує JSON.^[8] Оскільки в Cosmos DB вбудовано механізм JavaScript, API SQL також дозволяє:

• Збережені процедури. Функції, які об’єднують довільно складний набір операцій і логіки в транзакцію, сумісну з ACID. Вони ізольовані від змін, внесених під час виконання збереженої процедури, і або всі операції запису виконуються успішно, або всі вони не вдаються, залишаючи базу даних у узгодженому стані. Збережені процедури виконуються в одному розділі. Таким чином, абонент повинен надати ключ розділу під час виклику розділеної колекції. Збережені процедури можна використовувати, щоб компенсувати відсутність певної функціональності. Наприклад, відсутність можливості агрегування компенсується реалізацією куба OLAP як збереженої процедури в проекті documentdb-lumenize^[9] з відкритим кодом.
• Тригери. Функції, які виконуються до або після певних операцій (наприклад, під час вставки документа), які можуть або змінити операцію, або скасувати її. Тригери виконуються лише за запитом.
• Визначені користувачем функції (UDF). Функції, які можна викликати та розширити мову запитів SQL, компенсуючи обмежені функції SQL.

SQL API представлений як REST API, який сам реалізований у різних SDK, які офіційно підтримуються Microsoft і доступні для .NET Framework, .NET,^[10] Node.js (JavaScript), Java і Python.

Секційність

У 2016 році Cosmos DB додав можливість автоматичного секційності, представивши розділені контейнери. За лаштунками розділені контейнери охоплюють кілька фізичних розділів з елементами, розподіленими за допомогою наданого клієнтом ключа розділу. Cosmos DB автоматично вирішує, на скільки розділів розподілити дані залежно від розміру та потреб у пропускній здатності. Коли розділи додаються або видаляються, операція виконується без будь-яких простоїв, тому дані залишаються доступними, поки вони повторно балансуються між новими або залишилися розділами.

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

Регульована пропускна здатність

Розробники можуть вказати бажану пропускну здатність відповідно до очікуваного навантаження програми. Cosmos DB резервує ресурси (пам’ять, ЦП і IOPS), щоб гарантувати необхідну пропускну здатність, зберігаючи затримку запиту нижче 10 мс як для читання, так і для запису на 99-му процентилі. Пропускна здатність вказується в одиницях запиту (Request Units, RUs) за секунду. Вартість читання елемента розміром 1 КБ становить 1 одиницю запиту (або 1 RU). Операції вибору за ідентифікатором споживають меншу кількість RU порівняно з операціями видалення, оновлення та вставки для того самого документа. Великі запити (наприклад, агрегації, такі як підрахунок) і виконання збережених процедур можуть споживати від сотень до тисяч RU залежно від складності необхідних операцій.^[11] Мінімальна тарифікація за годину.

Пропускну здатність можна надати на рівні контейнера або бази даних. Якщо надати на рівні бази даних, пропускна здатність розподіляється між усіма контейнерами в цій базі даних, з додатковою можливістю мати виділену пропускну здатність для деяких контейнерів. Пропускна здатність, передбачена для контейнера Azure Cosmos, зарезервована виключно для цього контейнера.^[12] За замовчуванням максимальна кількість RU, яку можна надати для бази даних і контейнера, становить 1 000 000 RU, але клієнти можуть збільшити це обмеження, звернувшись до служби підтримки клієнтів.

Як приклад розрахунку вартості, використовуючи екземпляр одного регіону, підрахунок 1 000 000 записів по 1k кожен за 5 секунд потребує 1 000 000 RU за 0,008 $/год, що дорівнюватиме 800 $. Дві області вдвічі подорожчають.

Глобальне поширення

Бази даних Cosmos DB можна налаштувати так, щоб вони були доступні в будь-якому регіоні Microsoft Azure (понад 60 кріїн та регіонів станом на 2025 рік, включно з Україною), дозволяючи розробникам програм розміщувати свої дані ближче до місця, де перебувають їхні користувачі.^[13] Дані кожного контейнера прозоро копіюються в усіх налаштованих регіонах. Додавання або видалення регіонів виконується без будь-яких простоїв або впливу на продуктивність. Завдяки використанню багатоадресного API Cosmos DB програми не потрібно оновлювати чи повторно розгортати, коли додаються чи видаляються регіони, оскільки Cosmos DB автоматично направлятиме їхні запити до доступних і найближчих до їх розташування регіонів.

Рівні узгодженості

Узгодженість даних можна налаштувати в Cosmos DB, дозволяючи розробникам застосунків вибирати один із п’яти різних рівнів:^[14]

• Eventual не гарантує жодного впорядкування, а лише гарантує, що репліки в кінцевому підсумку зійдуться
• Consistent prefix додає гарантії впорядкування на додаток до Eventual
• Session призначений для одного клієнтського з’єднання та забезпечує послідовність читання власного запису для кожного клієнта; це стандартний рівень узгодженості^[15]
• Bounded staleness (Обмежена застарілість) доповнює послідовний префікс, гарантуючи, що читання не буде затримуватися за x версій елемента або деяке визначене часове вікно
• Strong consistency — строга узгодженість (або Лінеаризовність) гарантує, що клієнти завжди читатимуть останні глобально прийняті записи.

Бажаний рівень узгодженості визначається на рівні облікового запису, але його можна змінити на основі кожного запиту за допомогою спеціального заголовка HTTP або відповідної функції, наданої SDK. Усі п’ять рівнів узгодженості були визначені та перевірені за допомогою мови специфікації TLA+, а модель TLA+ є відкритою на GitHub.^[16]

Multi-master

Оригінальна модель розподілу Cosmos DB включає одну єдину область запису, а всі інші області є репліками лише для читання. У березні 2018 року корпорація Майкрософт анонсувала нову функцію кількох майстрів для Azure Cosmos DB, що дозволяє кільком регіонам служити репліками для запису. Ця функція ввела значне вдосконалення в оригінальну модель єдиної області запису, де інші області були лише для читання. З кількома майстрами одночасний запис із різних регіонів може призвести до потенційних конфліктів, які можна вирішити за допомогою політики за замовчуванням «Останній запис перемагає» (LWW) або спеціального механізму вирішення конфліктів, наприклад функції JavaScript. Політика LWW покладається на мітки часу для визначення переможного запису, тоді як спеціальна опція дозволяє розробникам вирішувати конфлікти за допомогою правила, визначеного програмою.^[17]

Аналітичне сховище

Ця функція, анонсована в травні 2020 року^[18], є повністю ізольованим сховищем стовпців для забезпечення широкомасштабної аналітики оперативних даних у базі даних Azure Cosmos DB без жодного впливу на її транзакційне навантаження. Ця функція вирішує проблеми зі складністю та затримкою, які виникають із традиційними конвеєрами ETL, необхідними для оптимізації сховища даних для виконання онлайн-аналітичної обробки шляхом автоматичної синхронізації операційних даних в окреме сховище стовпців, придатне для великомасштабних аналітичних запитів, які виконуються в оптимізованому режимі. таким чином, що призведе до покращення затримки таких запитів.

Використовуючи Microsoft Azure Synapse Link^[19] для Cosmos DB, можна створювати гібридні транзакційні/аналітичні рішення без ETL шляхом прямого підключення до аналітичного сховища Azure Cosmos DB із Synapse Analytics. Це дозволяє виконувати широкомасштабну аналітику майже в реальному часі безпосередньо на оперативних даних.

Реальне використання

Microsoft використовує Cosmos DB у багатьох своїх програмах^[20], включаючи Microsoft Office, Skype, Active Directory, Xbox і MSN.

У створенні більш глобально стійкої програми/системи Cosmos DB поєднується з іншими службами Azure, такими як Azure App Services та Azure Traffic Manager.^[21]

Профайлер Cosmos DB

Хмарний інструмент оптимізації витрат Cosmos DB Profiler виявляє неефективні запити даних у взаємодії між програмою та її базою даних Cosmos DB. Профайлер попереджає користувачів про зайву продуктивність і надмірні витрати на хмару. Він також рекомендує, як їх вирішити, виділивши та проаналізувавши код і спрямувавши його користувачів до точного місця в коді.^[22]

Обмеження

• SQL обмежений. Агрегації обмежені функціями COUNT, SUM, MIN, MAX, AVG, але в системах баз даних немає підтримки для GROUP BY або інших функцій агрегації. Однак збережені процедури можна використовувати для реалізації можливості агрегування в базі даних.^[23]
• Об'єднання SQL (JOIN) між "таблицями" неможливе,
• Підтримка лише чистих типів даних JSON. Зокрема, Cosmos DB не підтримує дані про дату й час, що вимагає збереження цих даних за допомогою доступних типів даних. Наприклад, його можна зберегти як рядок ISO-8601 або ціле число епохи. MongoDB, база даних, з якою найчастіше порівнюють Cosmos DB, розширила JSON у своїй специфікації двійкової серіалізації BSON, щоб охопити дані дати й часу, а також традиційні типи чисел, регулярні вирази та Undefined. Однак багато хто сперечається, що вибір Cosmos DB чистого JSON насправді є перевагою, оскільки він краще підходить для REST API на основі JSON і рушія JavaScript, вбудованого в базу даних.