Преобразование количества виртуальных ядер или виртуальных ЦП в нереляционной базе данных в единицы запросов в секунду Azure Cosmos DB

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

Область применения: MongoDB

В этой статье объясняется, как оценить приблизительное количество единиц запросов Azure Cosmos DB при планировании переноса данных, если единственное, что известно, — это общее число виртуальных ядер или виртуальных ЦП в существующих наборах реплик базы данных. При переносе одного или нескольких наборов реплик в Azure Cosmos DB каждая коллекция, хранящаяся в этих наборах, будет храниться как коллекция Azure Cosmos DB, состоящая из сегментированного кластера с коэффициентом репликации 4. Дополнительные сведения об архитектуре см. в этомРуководстве по секционированию и масштабированию. Единицы запросов отражают скорость подготовки пропускной способности для коллекции. Чтобы узнать больше, ознакомьтесь с руководством по работе с единицами запросов и руководством по подготовке запросов в секунду. При миграции коллекции Azure Cosmos DB подготавливает достаточное количество сегментов для обслуживания подготовленных единиц запросов и хранения данных. Таким образом, оценка количества единиц запросов в секунду для коллекций является важным шагом при определения масштаба планируемых данных Azure Cosmos DB перед миграцией. Благодаря опыту работы с тысячами клиентов мы смогли определить эту формулу, которая поможет нам оценить количество единиц запросов в секунду с виртуальных ядер или виртуальных ЦП.

Provisioned RU/s = C*T/R

• T: общее число виртуальных ядер и/или виртуальных ЦП в существующих наборах реплик, содержащих данные в базе данных.
• R: коэффициент репликации для существующих наборов реплик, содержащих данные.
• С: рекомендуемые подготовленные единицы запросов в секунду для каждого виртуального ядра или виртуального ЦП. Это значение является производным от архитектуры Azure Cosmos DB:
  • C = 600 ЕЗ/с/vCore* для Azure Cosmos DB для NoSQL
  • C = 1000 ЕЗ/с/vCore* для Azure Cosmos DB для MongoDB версии 4.0
  • Оценки C для API для Cassandra, Gremlin или других API в настоящее время недоступны

Значения С приведены выше. Значение T необходимо определить путем проверки количества виртуальных ядер или виртуальных ЦП в каждом наборе реплики, содержащем данные, в существующей базе данных и суммирования для получения итогового значения. Если вы не можете приблизительно вычислить значение T, воспользуйтесь нашим руководством по приблизительному вычислению единиц запросов в секунду с помощью планировщика емкости Azure Cosmos DB вместо этого руководства. T не должно включать виртуальные ядра или виртуальные ЦП, связанные с существующим сервером маршрутизации базы данных или кластером конфигурации, если он содержит указанные компоненты.

Для значения R рекомендуется подключить средний коэффициент репликации для наборов реплик базы данных; если эта информация недоступна, то в этом случае лучше всего использовать значение R = 3.

API взаимодействия Azure Cosmos DB выполняются поверх API noSQL и реализуют собственные уникальные архитектуры; Таким образом, Azure Cosmos DB для MongoDB версии 4.0 имеет другое значение, чем API Azure Cosmos DB для NoSQL.

Рабочий пример: оценка приблизительного количества единиц запросов в секунду для миграции одного набора реплик

Рассмотрим один набор реплик с коэффициентом репликации R = 3 с учетом номера SKU с 4 ядрами. Следующее действие

• Т = 12 виртуальных ядер
• R = 3

Затем рекомендуемые единицы запросов для API Azure Cosmos DB для NoSQL

Provisioned RU/s, API for NoSQL = (600 RU/s/vCore) * (12 vCores) / (3) = 2,400 RU/s

Рекомендуемые единицы запросов для Azure Cosmos DB для MongoDB

Provisioned RU/s, API for MongoDB = (1,000 RU/s/vCore) * (12 vCores) / (3) = 4,000 RU/s

Рабочий пример: оценка приблизительного числа единиц запросов в секунду при переносе кластера однородных наборов реплик

Рассмотрим сегментированный и реплицируемый кластер, состоящий из трех наборов реплик, каждый из которых имеет фактор репликации 3, где каждый сервер является номером SKU с четырьмя ядрами. Следующее действие

• Т = 36 виртуальных ядер
• R = 3

Затем рекомендуемые единицы запросов для API Azure Cosmos DB для NoSQL

Provisioned RU/s, API for NoSQL = (600 RU/s/vCore) * (36 vCores) / (3) = 7,200 RU/s

Рекомендуемые единицы запросов для Azure Cosmos DB для MongoDB

Provisioned RU/s, API for MongoDB = (1,000 RU/s/vCore) * (36 vCores) / (3) = 12,000 RU/s

Рабочий пример: оценка приблизительного числа единиц запросов в секунду при переносе кластера неоднородных наборов реплик

Рассмотрим сегментированный и реплицируемый кластер, состоящий из трех наборов реплик, в которых каждый сервер создан на основе номера SKU с четырьмя ядрами. Наборы реплик являются "неоднородными" в том смысле, что каждая из них имеет разные коэффициенты репликации: 3, 1 и 5 соответственно. Рекомендуется использовать средний коэффициента репликации при вычислении единиц запросов. Следующее действие

• Т = 36 виртуальных ядер
• Ravg = (3+1+5)/3 = 3

Затем рекомендуемые единицы запросов для API Azure Cosmos DB для NoSQL

Provisioned RU/s, API for NoSQL = (600 RU/s/vCore) * (36 vCores) / (3) = 7,200 RU/s

Рекомендуемые единицы запросов для Azure Cosmos DB для MongoDB

Provisioned RU/s, API for MongoDB = (1,000 RU/s/vCore) * (36 vCores) / (3) = 12,000 RU/s

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

Миграция из управляемой облачной базы данных: если в настоящее время используется управляемая облачная база данных, то эти службы зачастую можно подготовить в единицах виртуальных ядер или виртуальных ЦП (иными словами, T), но на самом деле, количество подготовленных ядер задает значение виртуальные ядра/реплика или виртуальные ЦП/реплика (T/R) для набора реплик R-узла; истинное количество ядер вR раз больше, чем вы подготовили явным образом. Мы рекомендуем определить, применимо ли это описание к текущей управляемой облачной базе данных. Если да, то необходимо умножить номинальное количество подготовленных виртуальных ядер или виртуальных ЦП на R, чтобы получить точное приблизительное число T.

Сравнение виртуальных ядер с виртуальными ЦП: в этой статье мы рассматриваем "виртуальное ядро" как синоним "виртуальных ЦП", таким образом, в C единицы запросов/виртуальное ядро или единицы запросов/виртуальные ЦП не различаются. Однако на практике такое упрощение может в отдельных случаях влиять на точность. Эти термины могут иметь разные значения; Например, если физические ЦП поддерживают гиперпоточность, возможно, что 2 виртуальных ЦП = 1 vCore w/HT или что-то другое. Как правило, отношение виртуального ядра/к виртуальным ЦП является аппаратно-зависимым, и мы рекомендуем изучить это отношение на имеющемся оборудовании кластера, а также определить, подготавливается ли кластер к вычислению с использованием виртуальных ядер или виртуальных ЦП. Если термины виртуальных ЦП и виртуальное ядро используются в разных значениях для вашего оборудования, мы рекомендуем рассматривать указанные выше приблизительные значения C как содержащие единицы запросов секунду/виртуальное ядро и при необходимости преобразовать T из виртуального ЦП в виртуальное ядро, используя коэффициент преобразования, подходящий для вашего оборудования.

Итоги

Примерный расчет количества единиц запроса из виртуальных ядер или виртуальных ЦП требует сбора информации об общем числе виртуальных ядер/виртуальных ЦП и коэффициента репликации из существующего набора реплик базы данных. Затем можно использовать известные отношения между виртуальными ядрами/виртуальными ЦП и пропускной способностью, чтобы оценить количество единиц запросов Azure Cosmos DB (единиц запроса в секунду). Поиск этой этого примерного значения числа единиц запроса будет важным шагом при оценке масштаба объема данных Azure Cosmos DB после миграции.

В таблице ниже приведены сведения о связи между виртуальными ядрами и виртуальными ЦП для API Azure Cosmos DB для NoSQL и API для MongoDB версии 4.0:

Следующие шаги

• Сведения о ценах на Azure Cosmos DB
• Сведения о планировании затрат на Azure Cosmos DB и управлении ими
• Планирование миграции в Azure Cosmos DB для MongoDB. Этот документ содержит ссылки на различные средства миграции, которые можно использовать по завершении планирования.