Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Служба на основе виртуальных ядер для Azure Cosmos DB для MongoDB предоставляет возможность масштабирования кластеров как по вертикали, так и по горизонтали. Хотя уровень вычислительных кластеров и диск хранилища функционально зависят друг от друга, масштабируемость и стоимость вычислительных ресурсов и хранилища отделяются.
Вертикальное масштабирование
Вертикальное масштабирование обеспечивает следующие преимущества:
- Команды приложений могут не всегда иметь четкий путь для логического сегментирования своих данных. Кроме того, логическая сегментирование определяется для каждой коллекции. В наборе данных с несколькими неразделёнными коллекциями моделирование данных для секционирования может быстро стать трудоемким. Простое масштабирование кластера может обойти необходимость логического сегментирования при удовлетворении растущих потребностей хранилища и вычислений приложения.
- Вертикальное масштабирование не требует перебалансирования данных. Количество физических сегментов остается неизменным, и только емкость кластера увеличивается без влияния на приложение.
- Масштабирование вверх и вниз — это операции, не требующие времени простоя и без сбоев в работе службы. Никакие изменения в приложении не требуются, и стабильные операции могут продолжаться без помех.
- Вычислительные ресурсы также могут быть уменьшены во время известных периодов времени низкой активности. Повторное уменьшение масштаба позволяет избежать необходимости перебалансировки данных по меньшему количеству физических шардов и является операцией без простоев, не нарушающей работу сервиса. Кроме того, после масштабирования кластера изменения приложения не требуются.
- Самое главное, вычислительные ресурсы и хранилище можно масштабировать независимо. Если требуется больше ядер и памяти, размер диска можно оставить как есть, а уровень кластера можно масштабировать. Если требуется больше места и IOPS, уровень кластера можно оставить неизменным, а размер хранилища можно масштабировать отдельно. При необходимости можно масштабировать вычислительные ресурсы и хранилище независимо для оптимизации требований каждого компонента по отдельности без требований эластичности любого компонента, влияющих на другой.
Горизонтальное масштабирование
В конечном итоге приложение растет до точки, где масштабирование по вертикали недостаточно. Требования к рабочей нагрузке могут увеличиваться за пределы емкости крупнейшего уровня кластера и в конечном итоге требуются дополнительные сегменты. Горизонтальное масштабирование в предложении на основе виртуальных ядер для Azure Cosmos DB для MongoDB обеспечивает следующие преимущества:
- Логически сегментированные наборы данных не требуют вмешательства пользователя для балансировки данных между базовыми физическими сегментами. Служба автоматически сопоставляет логические сегменты с физическими сегментами. При добавлении или удалении узлов данные автоматически перебалансируются внутри базы данных в фоновом режиме.
- Запросы автоматически направляются в соответствующий физический сегмент, который владеет хэш-диапазоном для запрашиваемых данных.
- Геораспределенные кластеры имеют однородную конфигурацию с несколькими узлами. Соответствие логических шардов их физическим аналогам является согласованным между основными и репликами регионами кластера.
Масштабирование вычислений и хранилища
Ресурсы вычислений и памяти оказывают большее влияние на операции чтения в службе, основанной на виртуальных ядрах для Azure Cosmos DB for MongoDB, чем дисковые операции ввода-вывода.
- Операции чтения сначала обращаются к кэшу в вычислительном слое и возвращаются на диск, когда данные не удалось получить из кэша. Для рабочих нагрузок с более высокой скоростью операций чтения в секунду масштабирование уровня кластера для получения дополнительных ресурсов ЦП и памяти приводит к повышению пропускной способности.
- Помимо пропускной способности чтения рабочие нагрузки с большим объемом данных на операцию чтения также получают преимущества масштабирования вычислительных ресурсов кластера. Например, уровни кластеров с большим объемом памяти позволяют больший размер полезной нагрузки на документ и большее количество небольших документов на ответ.
IOPS диска влияет на операции записи в службе, использующей виртуальные ядра Azure Cosmos DB для MongoDB больше, чем производительность ЦП и памяти вычислительных ресурсов.
- Операции записи всегда сохраняют данные на диск (помимо сохранения данных в памяти для оптимизации операций чтения). Более крупные диски с большим количеством операций ввода-вывода в секунду обеспечивают более высокую пропускную способность записи, особенно при выполнении в большом масштабе.
- Служба поддерживает до 32 ТБ дисков на сегмент, с большим количеством операций ввода-вывода в секунду на сегмент, чтобы воспользоваться большими рабочими нагрузками, особенно при масштабировании.
Тяжелые рабочие нагрузки хранилища и большие диски
Отсутствие минимальных требований к хранилищу на уровне кластера
Как упоминалось ранее, ресурсы хранилища и вычислительных ресурсов отделены для выставления счетов и подготовки. Хотя они работают как сплоченная единица, их можно масштабировать независимо. На уровне кластера M30 может быть подготовлено 32 ТБ дисков. Аналогичным образом уровень кластера M200 может иметь 32 ГБ дисков, подготовленных для оптимизации затрат на хранение и вычисление.
Более низкий уровень TCO с большими дисками (32 ТБ и выше)
Как правило, базы данных NoSQL с моделью на основе виртуальных ядер ограничивают хранилище на физический сегмент до 4 ТБ. Служба для Azure Cosmos DB для MongoDB, основанная на виртуальных ядрах, предоставляет до 8 раз большую емкость с дисками объемом 32 ТБ. Для нагрузок, требующих много памяти, емкость хранилища в 4 ТБ на физический сегмент требует обширного флота вычислительных ресурсов только для соблюдения требований к объему рабочего хранилища. Вычислительные ресурсы дороже, чем хранилище и перебор вычислительных ресурсов из-за ограничений емкости в службе, могут быстро увеличивать затраты.
Рассмотрим тяжелую рабочую нагрузку хранилища с 200 ТБ данных.
| Размер хранилища на сегмент | Минимальное количество шардов, необходимое для поддержания 200 ТБ |
|---|---|
| 4 ТиБ | 50 |
| 32 ТиБ | 7 |
Требования к вычислительным ресурсам резко уменьшаются с увеличением размера дисков. Хотя для поддержания требований к пропускной способности рабочей нагрузки может потребоваться больше минимального количества физических сегментов, даже удвоение или утраивание числа сегментов является более экономичным решением, чем кластер из 50 сегментов с меньшими дисками.
Пропуск распределения по уровням хранилища с большими дисками
Немедленный ответ на затраты на вычисления в сценариях с большим объемом хранения — это "распределение уровней" данных. Данные в транзакционной базе данных ограничены наиболее часто используемыми "горячими" данными, в то время как более объемные "холодные" данные переносятся в холодное хранилище. Это приводит к сложности работы. Производительность также непредсказуема и зависит от уровня данных, доступ к которому осуществляется. Кроме того, доступность всей системы зависит от устойчивости объединенных горячих и холодных хранилищ данных. С большими дисками в службе vCore не требуется многоуровневое хранилище, так как стоимость интенсивных рабочих нагрузок сводится к минимуму.