Введение в Azure Cosmos DB
CosmosDB — это база данных NoSQL от Azure. В этой статье мы обсудим высокоуровневое горизонтальное масштабирование, репликацию, секционирование и схему базы данных. Затем мы углубимся в некоторые модели данных, поддерживаемые Cosmos DB. Итак, приступим.
Раньше приложения были относительно простыми. У нас было бы приложение, уровень API и медленная капля данных, попадающих в нашу базу данных. Теперь время от времени нам может понадобиться просмотреть эти данные и информацию об устройстве поиска в каталоге или найти встречу в календаре. Но часто данные оставались в базе данных до тех пор, пока их не вызвали спустя много дней, месяцев или даже лет.
В эпоху больших данных, когда наборы данных выросли с нескольких гигабайт до десятков гигабайт и даже петабайт для некоторых из наших самых требовательных приложений. Данные вливаются в наши базы данных, и приложения требуют, чтобы данные отображались быстро и часто, чтобы удовлетворить ожидания пользователей в отношении персонализированного и быстрого взаимодействия с приложениями.
Теперь Azure Cosmos DB быстро стала ответом на потребность в больших данных облачных приложений. Поскольку нереляционные базы данных или базы данных NoSQL, такие как Azure Cosmos DB, масштабируются горизонтально, а не вертикально, мы можем существенно снизить пропускную способность и объем данных в нашей базе данных. Вместо обновления оборудования на одном узле для более быстрого обслуживания запросов Cosmos DB распределяет эту работу по нескольким узлам, чтобы запросы могли обслуживаться одновременно. Горизонтальное масштабирование — это самая большая разница между реляционными базами данных и нереляционными базами данных, такими как Cosmos DB.
Горизонтальное масштабирование или горизонтальное масштабирование является следствием двух методов: секционирования и репликации . Сейчас в Azure Cosmos DB есть два вида разделов: логические и физические .
Физический раздел — это фактическая единица хранения, которая физически находится в заданном нами регионе Azure. Это часть оборудования, где хранятся наши данные где-то в облаке. Логические секции — это логические группы элементов в нашем наборе данных, и мы ссылаемся на эти группы с помощью так называемого ключа секции . Ключ раздела важен, потому что он сообщает нашей базе данных, где искать наши данные. Выбор правильного ключа раздела — простая, но важная часть оптимизации нашей базы данных, и, если все сделано правильно, мы можем ожидать увеличения производительности, пропорционального дополнительному количеству узлов, обслуживающих наши запросы. Проще говоря, разделение наших данных по узлам улучшает задержку и пропускную способность базы данных.
Теперь, как и в случае с разделами, в Cosmos DB также есть два типа репликации: репликация внутри региона и георепликация за пределами региона . Теперь внутри региона наши данные реплицируются четыре раза в качестве меры избыточности, что повышает отказоустойчивость. За пределами региона наши данные геореплицируются в любые дополнительные регионы Azure, которые мы выбираем, что повышает доступность. Репликация в пределах одного региона повышает отказоустойчивость. Георепликация в дополнительные регионы Azure повышает доступность. Теперь эти два метода, репликация и разделение, в значительной степени делают возможным горизонтальное масштабирование.
Что делает NoSQL привлекательным для современных операционных разработчиков, помимо повышения производительности и доступности, так это ослабление ограничений, связанных с сохранением реляционных данных. Cosmos DB не имеет схемы, то есть структура не применяется ни к каким данным, поступающим в базу данных. Два документа в одной коллекции могут иметь совершенно разную структуру без каких-либо проблем. В результате разработчики могут вносить структурно переменные данные в базу данных, а затем создавать, изменять или добавлять функциональные возможности по мере развития использования этих данных. Сочетание гибкой схемы и горизонтального масштабирования — вот что отличает NoSQL.
Cosmos DB упрощает прием и повторное использование больших объемов переменных данных без ущерба для производительности или доступности. В дополнение к гибкой схеме Cosmos также поддерживает несколько моделей данных. Cosmos был создан, чтобы быть центром для всех типов данных NoSQL.
Cosmos имеет SQL API со встроенной поддержкой документов и ключей-значений. Документы и пары ключ-значение идут рука об руку в большинстве баз данных NoSQL, потому что документы — это просто пары ключ-значение, в которых ключ — это документ, а значение — это объект JSON, который мы просто называем документом. Теперь, чтобы воспользоваться преимуществами производительности настоящего хранилища «ключ-значение», с помощью SQL API мы можем выполнять быстрое и экономичное чтение точек, если нам известны идентификатор документа и ключ секции для элемента, который мы хотим прочитать. Это отличный инструмент оптимизации для приложений. Следующая модель данных, модель данных графа, доступна через API Gremlin, который использует ребра и вершины, а также обход для моделирования сложных систем с отношениями «многие ко многим». Думайте о графе как о сети или сети узлов. API для Mongo DB и Cassandra соответственно созданы для того, чтобы разработчики, знакомые с обеими базами данных с открытым исходным кодом, могли работать с инструментами, пакетами SDK и драйверами, к которым они уже привыкли. API для Mongo DB также использует документы, а Cassandra API — это хранилище с широкими столбцами, которое эффективно ориентирует данные в столбцах, а не в строках, чтобы оптимизировать их для аналитики. Вот и все для нашего первого эпизода. Cosmos DB — это наша горизонтально масштабируемая база данных NoSQL. Разделение делает его быстрым, репликация делает его доступным, а гибкая схема упрощает работу.