Преобразование количества виртуальных ядер или виртуальных ЦП в нереляционной базе данных в единицы запросов в секунду 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:
| Количество виртуальных ядер | ЕЗ/с (API для NoSQL) (коэффициент репликации = 3) |
Единиц запросов в секунду (API для MongoDB версии 4.0) (коэффициент репликации = 3) |
|---|---|---|
| 3 | 600 | 1000 |
| 6 | 1200 | 2000 |
| 12 | 2400 | 4000 |
| 24 | 4800 | 8000 |
| 48 | 9600 | 16 000 |
| 96 | 19 200 | 32000 |
| 192 | 38400 | 64 000 |
| 384 | 76 800 | 128 000 |
Следующие шаги
- Сведения о ценах на Azure Cosmos DB
- Сведения о планировании затрат на Azure Cosmos DB и управлении ими
- Планирование миграции в Azure Cosmos DB для MongoDB. Этот документ содержит ссылки на различные средства миграции, которые можно использовать по завершении планирования.