Сегодня многие базы данных стремятся обеспечить высокую производительность, масштабируемость и доступность при минимизации сложности и затрат на поддержку.
Azure Cosmos DB — отличный пример СУБД, которая может легко обеспечить эти качества.
В данной статье описаны ее возможности вместе с ограничениями, которые могут быть не очевидны на первый взгляд, но могут стать серьезной проблемой в будущем, если они не будут учтены при проектировании системы.
Далее в статье некоторые факты будут отмечены специальными символами: 
Функции, которые могут оказаться очень полезными на практике.
Есть ограничения, о которых следует помнить, но если вы о них не знаете и обнаружите их во время разработки, это не проблема, их можно обойти.
Ограничения, которые могут стать большой проблемой, если не принять их во внимание на этапе проектирования.
Cosmos DB поддерживает несколько API: SQL, Cassandra, MongoDB, Gremlin, Table. Здесь под SQL подразумевается документо-ориентированный API, который раньше назывался DocumentDB, и он существенно отличается от привычных нам реляционных баз данных.
Эта статья основана на опыте работы с SQL API. .
Хочу обратить ваше внимание на то, что тип API выбирается при создании экземпляра хранилища; невозможно будет работать с данными из одного и того же экземпляра через разные API. Модель документа Cosmos DB хранит данные в контейнерах, состоящих из элементов.
Раньше в документации они назывались коллекциями и документами соответственно.
Все настройки масштабирования, пропускной способности и индексации задаются на уровне контейнера (за некоторыми исключениями, о которых мы поговорим позже).
База данных, по большому счету, представляет собой именованный союз контейнеров.
И здесь стоит упомянуть первое ограничение:
Максимальный размер элемента в контейнере — 2 МБ.
В большинстве случаев это не должно быть проблемой, но имейте в виду, что размер ограничен, и хранение медиаконтента в элементах контейнера — не лучшая идея.
Более подробную информацию об ограничениях ресурсов можно найти Здесь .
Масштабирование на лету
Cosmos DB позволяет управлять метрикой производительности (пропускной способностью) для каждого контейнера индивидуально.Пропускная способность измеряется в единицах запросов в секунду ( Запросить единицы в секунду или сокращенно RU/сек).
Приблизительным эквивалентом единицы запроса является чтение элемента размером 1 КБ по его идентификатору.
Например, требуемая пропускная способность контейнера, допускающего 500 операций чтения и 100 операций записи однокилобайтных элементов в секунду, будет примерно равна 500*1+100*5 = 1000 RU. Однако в общем случае точно рассчитать требуемую пропускную способность практически невозможно, поскольку сложность запросов и размеры элементов могут сильно различаться.
Любая операция, совершаемая базой данных, имеет свою «цену» в пересчете на RU. Пропускная способность, указанная на контейнере, — это предел, который Cosmos DB позволяет «тратить» в секунду.
База данных отслеживает общую «цену» запросов в течение секунды, и если лимит уже исчерпан, последующие запросы не принимаются к исполнению до тех пор, пока количество в секунду не вернется к значению меньше указанного лимита.
Минимально возможная пропускная способность контейнера составляет 400 RU и обойдется примерно в 25$ в месяц.
Стоимость увеличивается линейно с увеличением RU — контейнер с 800 RU уже будет стоить около 50$ в месяц.
Пропускная способность задается на уровне контейнера и может быть изменена в любой момент без каких-либо дополнительных процедур.
Пропускную способность можно указать на уровне базы данных.
В этом случае все контейнеры будут использовать одинаковую «емкость».
Также имеется режим «автопилота» (пока в предварительной версии), который позволяет автоматически увеличивать или уменьшать заявленную пропускную способность в зависимости от нагрузки на базу данных.
Минус в том, что минимальное и максимальное значения, которые вы можете настроить, находятся в соотношении 1:10, т.е.
вы не можете сделать так, чтобы в часы пик метрика устанавливалась на уровне 40 000 RU, а в состоянии покоя - 400 RU.
Если заявленная пропускная способность превышена, Cosmos DB просто не принимает новые запросы на выполнение и возвращает в ответ специальный HTTP-статус 429 («Частота запросов слишком велика»).
Чтобы переключиться между конфигурацией пропускной способности на уровне базы данных и конфигурацией пропускной способности на уровне контейнера, базу данных необходимо создать заново; более плавный переход пока не предусмотрен.
Разделение для бесконечной масштабируемости
Раньше в Cosmo DB было два варианта контейнеров: секционированные и несекционированные.Бесраздельные контейнеры были ограничены максимальной пропускной способностью 10 000 RU и размером 10 гигабайт. На данный момент все контейнеры могут иметь разделы, поэтому при их создании необходимо указать ключ разделения.
Важным моментом является понимание разницы между логические и физические разделы : логический раздел состоит из набора элементов, имеющих одинаковое значение ключа секционирования, а физический раздел — это «вычислительная единица» Cosmo DB, узел в его физической инфраструктуре, который может обрабатывать несколько логических разделов.
В зависимости от объема данных и распределения записей по ключу секционирования система может создавать новые физические разделы и перераспределять между ними логические разделы.
Вся пропускная способность, выделенная контейнеру, равномерно распределяется между его физическими разделами.
Представим, что изначально контейнер пропускной способностью 1000 RU имеет одну партицию.
Когда его размер достигнет предела в 10 ГБ, система разделит его на две части.
Это будет означать, что если изначально любой запрос, выполняемый на этом контейнере, имел в своем распоряжении 1000 RU в секунду, то теперь запросы, относящиеся к этому же разделу, уже будут ограничены пропускной способностью в 500 RU.
Хотя количество разделов не ограничено, максимальный объем данных на один физический раздел составляет 10 ГБ, а максимальная пропускная способность — 10 000 RU. Ключ разделения необходимо выбирать так, чтобы вероятность достижения этих пределов была минимальной.
Следует отметить, что один и тот же логический раздел не может быть разделен между несколькими физическими.
Автоиндексация
Вместо создания индексов для отдельных полей или их комбинаций Cosmos DB позволяет настраивать политика индексации Для пути внутри объекта .Политика — это набор атрибутов: какие пути включить в индексацию, какие исключить, какие типы индексов использовать и т. д. Интересным моментом является то, что в отличие от большинства других СУБД Cosmos DB использует инвертированный индекс вместо классического B-дерева, что делает его очень эффективным для многокритериального поиска и не требует создания составных индексов для поиска по множеству полей.
Более подробную информацию по этой теме можно найти в статье эта ссылка .
Политика индексирования может измениться в любое время.
Доступны два режима индексации: последовательный и ленивый.
Lazy ускоряет запись, но ухудшает согласованность записи и чтения, поскольку индексация выполняется в фоновом режиме после завершения операции записи.
Во время обновления индекса запросы могут возвращать устаревшие данные.
Вы можете создавать составные индексы, чтобы ускорить операцию ORDER BY для нескольких полей; в противном случае составные индексы бесполезны.
Есть поддержка пространственных индексов.
Политика индексирования по умолчанию, созданная в контейнере («индексировать все поля»), может привести к большому потреблению RU при записи элементов с большим количеством полей.
Отслеживать изменения
Отслеживание изменений в Cosmos DB возможно благодаря механизму под названием Изменить ленту .Он возвращает документы, измененные с определенного момента времени, в том порядке, в котором они были изменены.
Этот начальный момент времени можно гибко контролировать: это может быть либо момент инициализации самого потока изменений, либо фиксированная временная метка, либо момент создания контейнера.
Изменения могут обрабатываться асинхронно и инкрементально, а результат может быть распределен между одним или несколькими потребителями для параллельной обработки.
Все это дает очень большую гибкость в различных сценариях интеграции.
Если вы используете низкоуровневый API-интерфейс канала изменений, обязательно учтите разделение разделов, которое может произойти, когда раздел достигает своего предельного размера.
Этот механизм не отслеживает удаления, поэтому лучше использовать мягкое удаление, чтобы иметь возможность реагировать на удаления элементов.
Хранимые процедуры и транзакции
Cosmos DB поддерживает хранимые процедуры и триггеры, написанные на JavaScript.Операции ввода-вывода в JavaScript полностью асинхронны, а поскольку async/await пока не поддерживается в Cosmos DB, вам придется писать немалое количество обратных вызовов, что не сильно способствует читабельности кода.
Удобных способов вернуть дополнительную информацию при ошибках из хранимых процедур нет. Единственный способ решить проблему — добавить информацию в сообщение об ошибке, а затем «вырезать» эту информацию из сообщения на клиенте.
Транзакции работают только внутри хранимых процедур и функций или пакеты транзакций , которые доступны начиная с .
NET SDK версии 3.4 и выше.
В одну транзакцию могут быть включены только документы из одного логического раздела.
Соответственно, операции записи в разные контейнеры не могут выполняться транзакционно.
Время выполнения одной хранимой процедуры ограничено (5 секунд), и если продолжительность транзакции превысит этот лимит, она будет отменена.
Существуют способы реализации «долгоживущих» транзакций за счет нескольких обращений к серверу, но они нарушают атомарность.
Выполнение запросов
Хотя Microsoft называет API документов «SQL», его язык лишь похож на SQL и имеет множество отличий от того, что мы привыкли видеть в реляционных базах данных.
В API есть параметры, которые помогают предотвратить выполнение «дорогих» запросов: EnableCrossPartitionQuery, EnableScanInQuery (см.
класс Параметры фида в документации).
Запросы между разделами получаются, когда условие не содержит фиксированного значения ключа разделения.
Сканирование набора данных может произойти, если условие запроса содержит неиндексированные поля.
Установка для обоих параметров значения false — хороший способ борьбы с чрезмерным потреблением RU. Однако в некоторых случаях может оказаться полезным выполнение запроса к нескольким разделам.
Оператор GROUP BY уже поддерживается (добавлен в ноябре 2019 г.
).
Агрегатные функции MIN и MAX, похоже, не используют индексы.
Ключевое слово JOIN присутствует в языке, но используется для «расширения» вложенных коллекций.
Вы не сможете объединять элементы из разных контейнеров в одном запросе, как обычный SQL.
Поскольку Cosmos DB не предполагает строгой схемы данных, поля, указанные в условии, могут отсутствовать в некоторых элементах.
Следовательно, любой запрос, который накладывает условия на необязательные поля, также должен проверять их существование с помощью функции IS_DEFINED. Проверки NULL может быть недостаточно.
Дополнительные советы по выполнению запросов можно найти в шпаргалки , опубликованный Microsoft.
Другие полезные функции
- Срок службы элемента — может быть указано либо по умолчанию на уровне контейнера, либо приложение может установить время жизни для каждого элемента индивидуально.
- Пять уровни целостности : ограниченное устаревание, сеанс (по умолчанию), согласованный префикс, возможный.
- Уникальные ключи (обратите внимание, что для изменения структуры уникального ключа вам придется пересоздать контейнер).
- Оптимистичный замок — у каждого элемента есть специальное поле «_etag», обновляемое самой СУБД.
При обновлении элемента код приложения может указать условие — разрешать запись только в том случае, если значение поля «_etag» в передаваемом приложением объекте равно значению, хранящемуся для этого элемента в базе данных.
- Георепликация — очень легко настроить для любого количества регионов.
В конфигурации с одним мастером вы можете в любой момент переключить основной регион, либо это переключение будет автоматическим в случае сбоя на уровне центра обработки данных.
Клиент SDK автоматически реагирует на эти переключения, не требуя от разработчиков каких-либо дополнительных действий для обработки таких ситуаций.
- Шифрование данных
- Запись в нескольких регионах — позволяет масштабировать операции записи.
Следует помнить, что наличие нескольких копий данных с возможностью записи почти всегда подразумевает возможные конфликты: один и тот же элемент изменяется в двух регионах одновременно, несколько элементов с одинаковым первичным ключом добавляются в разные регионы и т. д. К счастью, Cosmos БД предоставляет два способа разрешения конфликтов: автоматический (побеждает последняя операция записи) или «кастомный», при котором вы можете реализовать алгоритм, подходящий под ваши условия.
Но ничто не идеально, и некоторые ограничения могут стать серьезным препятствием для использования этой технологии: если вам нужны транзакции, состоящие из действий над несколькими контейнерами, или нужны длинные транзакции, включающие сотни или тысячи объектов, если данные не могут быть эффективно секционированы и в этом если они могут превышать 10 ГБ и т. д. Если ни одно из ограничений, упомянутых в этой статье, не кажется большой проблемой для вашего проекта, возможно, имеет смысл рассмотреть Azure Cosmo DB. Я выражаю свою благодарность л0ндра за помощь в подготовке статьи.
P.S. Ээту статью я уже опубликовано ранее в английской версии, но на другом ресурсе.
Теги: #Хранилища данных #Microsoft Azure #NoSQL #azure #cosmos db #DocumentDB
-
Выбор Подходящего Мобильного Телефона
19 Oct, 24 -
Осторожно, Радиация!
19 Oct, 24 -
Нужно Ли Мне Регистрировать Свой Бренд?
19 Oct, 24 -
Лебедев Запускает Новый Проект «Бизнес-Линч»
19 Oct, 24
