Оптимизация затрат на хранение в Azure Cosmos DB
Область применения: Nosql Mongodb Кассандра Гремлин Таблица
В Azure Cosmos DB нет ограничений на объем хранилища и пропускную способность. В отличие от пропускной способности, которую необходимо подготовить и настроить в контейнерах или базах данных Azure Cosmos DB, плата за хранение взимается на основе потребления. Счета выставляются только за используемое логическое хранилище, и вам не нужно заранее резервировать объем. Хранилище автоматически масштабируется в зависимости от объема данных, которые вы добавляете в контейнер Azure Cosmos DB или удаляете из него.
Стоимость хранения
Плата за хранилище начисляется с точностью до гигабайта. Локальное хранилище на основе твердотельных накопителей используется для хранения данных и индексирования. Общий используемый объем хранилища равен объему всех данных и индексов по всем регионам, где вы используете Azure Cosmos DB. Если вы глобально реплицируете учетную запись Azure Cosmos DB в трех регионах, вы платите за общую стоимость хранения в каждом из этих трех регионов. Чтобы оценить требования к хранилищу, воспользуйтесь планировщиком ресурсов. За хранение данных в Azure Cosmos DB взимается плата 0,25 долл. США за ГБ в месяц. Актуальные данные о ценах см. на этой странице. Вы можете настроить оповещения для определения хранилища, используемого контейнером Azure Cosmos DB, для мониторинга хранилища, см . статью "Мониторинг Azure Cosmos DB").
Оптимизация затрат с помощью изменения размера элементов
Для оптимальной производительности Azure Cosmos DB и снижения затрат желательно, чтобы размер элементов не превышал 2 МБ. Если вам требуется хранить элементы данных крупнее 2 МБ, попробуйте преобразовать схему этих элементов. В тех редких случаях, когда схему изменить невозможно, разделите такие элементы на элементы меньшего размера и создайте между ними логическую связь по общему идентификатору. Все функции Azure Cosmos DB будут стабильно работать благодаря привязке к такому логическому идентификатору.
Оптимизация затрат с помощью индексирования
По умолчанию все данные автоматически индексируются, что может увеличить общий объем используемого хранилища. Но вы можете сократить эти расходы, применив пользовательскую политику индексирования. Автоматическое индексирование, не настроенное с помощью политики, потребляет около 10–20 % от размера элементов. Удаляя или настраивая политики индексирования, вы можете избежать дополнительных затрат на операции записи и дополнительную пропускную способность. В статье Индексирование в Azure Cosmos DB есть информация о настройке пользовательских политик индексирования. Те, кто уже работал с реляционными базами данных, могут ожидать по меньшей мере удвоения требований к хранилищу при использовании политики "индексировать все". Но в среднем случае для Azure Cosmos DB это увеличение существенно ниже. Затраты на индексирование в Azure Cosmos DB обычно довольно низки (10–20 %) даже при полном автоматическом индексировании, так как база данных специально проектировалась для снижения объема данных в хранилище. Управляя политикой индексирования, вы можете еще более точно контролировать соотношение между объемом индекса и производительностью запросов.
Оптимизация затрат с помощью настройки времени жизни и канала изменений
После того как данные больше не требуются, вы можете корректно удалить их из учетной записи Azure Cosmos DB с помощью времени жизни, канала изменений или перенести старые данные в другое хранилище данных, например хранилище BLOB-объектов Azure или хранилище данных Azure. В Azure Cosmos DB можно задать срок жизни, чтобы элементы автоматически удалялись из контейнера по прошествии определенного времени. По умолчанию можно задать срок жизни на уровне контейнера и переопределить значения по элементу. После установки срока жизни на уровне контейнера или элемента Azure Cosmos DB будет автоматически удалять соответствующие элементы по прошествии указанного времени с момента их последнего изменения. С помощью канала изменений можно перенести данные в любой другой контейнер в Azure Cosmos DB или во внешнее хранилище данных. Миграция занимает нулевое время простоя, и при выполнении миграции можно удалить или настроить время для реального времени для удаления исходного контейнера Azure Cosmos DB.
Оптимизация затрат с помощью мультимедийных типов данных
Если вы намерены хранить мультимедийные данные, например видео, изображения и т. п., Azure Cosmos DB предлагает для этого несколько вариантов. Одним из вариантов является хранение этих типов мультимедиа в виде элементов Azure Cosmos DB. Для каждого такого элемента действует ограничение по размеру в 2 МБ, но это ограничение можно обойти разбиением элемента данных на цепочку вложенных элементов. Вы также можете хранить их в хранилище BLOB-объектов Azure и использовать метаданные, чтобы ссылаться на них из элементов Azure Cosmos DB. Такой подход имеет ряд преимуществ и недостатков. Первый подход обеспечивает оптимальную производительность с точки зрения задержки, обслуживания пропускной способности, а также готовых глобальных возможностей распространения для типов данных мультимедиа с широкими возможностями в дополнение к обычным элементам Azure Cosmos DB. Однако такая поддержка означает дополнительные расходы. Сохраняя мультимедиа в хранилище BLOB-объектов Azure, вы сможете снизить общие расходы. Если задержка важна, можно использовать хранилище класса Premium для файлов мультимедиа, на которые ссылаются элементы Azure Cosmos DB. Такая схема естественным образом интегрируется с сетью доставки содержимого, позволяя распространять изображения с пограничного сервера по низкой цене и обойти географические ограничения. Единственный недостаток этого сценария заключается в том, что вам придется иметь дело с двумя службами (Azure Cosmos DB и хранилище BLOB-объектов Azure), что может повысить эксплуатационные расходы.
Проверка используемого объема хранилища
Чтобы проверить потребление хранилища контейнера Azure Cosmos DB, можно запустить запрос HEAD или GET в контейнере и проверить x-ms-request-quota
x-ms-request-usage
заголовки. Кроме того, если вы используете пакет SDK для .NET, вы может узнать используемый объем хранилища из свойств DocumentSizeQuota и DocumentSizeUsage.
Использование пакета SDK
// Measure the item size usage (which includes the index size)
ResourceResponse<DocumentCollection> collectionInfo = await client.ReadDocumentCollectionAsync(UriFactory.CreateDocumentCollectionUri("db", "coll"));
Console.WriteLine("Item size quota: {0}, usage: {1}", collectionInfo.DocumentQuota, collectionInfo.DocumentUsage);
Следующие шаги
Теперь вы можете перейти к изучению оптимизации затрат в Azure Cosmos DB в следующих статьях:
- Дополнительные сведения об оптимизации для разработки и тестирования
- Дополнительные сведения о расшифровке счета Azure Cosmos DB
- Дополнительные сведения об оптимизации расходов на пропускную способность
- Дополнительные сведения об оптимизации расходов на операции чтения и записи
- Дополнительные сведения об оптимизации затрат на запросы.
- Дополнительные сведения об оптимизации затрат на учетные записи Azure Cosmos DB с несколькими регионами
- Если вы планируете ресурсы для миграции в Azure Cosmos DB, Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.
- Если вам известно только количество виртуальных ядер и серверов в существующем кластере баз данных, прочитайте об оценке единиц запроса на основе этих данных.
- Если вам известна стандартная частота запросов для текущей рабочей нагрузки базы данных, ознакомьтесь со статьей о расчете единиц запросов с помощью планировщика ресурсов Azure Cosmos DB