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

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

Provisioned RU/s = C*T/R

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

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

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

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

Рабочий пример: оценка RU/s для миграции одного репликационного набора

Рассмотрим один набор реплик с коэффициентом репликации R = 3, на основе четырехъядерного сервера SKU. Затем

• Т = 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

Рабочий пример: оценка 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

Рабочий пример: оценка 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

Рекомендации для получения максимально точной оценки RU/s

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

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

Сводка

Оценка RU/s по виртуальным ядрам или виртуальным ЦП требует сбора информации о суммарном количестве виртуальных ядер/виртуальных ЦП и факторе репликации из вашего существующего набора реплик базы данных. Затем можно использовать известные отношения между виртуальными ядрами/виртуальными ЦП и пропускной способностью, чтобы оценить количество единиц запросов 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. Этот документ содержит ссылки на различные средства миграции, которые можно использовать по завершении планирования.