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