В отношении Azure Cosmos DB у администраторов традиционных баз данных возникают вопросы, связанные с карьерными и техническими аспектами, так как Cosmos DB отличает от SQL Server использование горизонтального масштабирования вместо вертикального.nnAzure Cosmos DB — решение DaaS (база данных как услуга) от Microsoft типа NoSQL (не только SQL), в котором в полной мере реализованы преимущества эластичности и гибкости для удовлетворения потребностей систем, функционирующих в пространстве Интернета вещей (lоТ), и глобальных «облачных» приложений. Реализованные в Cosmos DB методы доступа, модели согласованности, структуры затрат и способы анализа данных отличаются от тех, что используются реляционными системами управления базами данных (РСУБД), такими как SQL Server.nnОднако в отношении Cosmos DB у специалистов по администрированию серверов возникает ряд вопросов. Помимо технических аспектов Cosmos DB, возникают и более общие вопросы, касающиеся профессиональной деятельности администратора базы данных. Надо ли специалисту по РСУБД становиться универсальным? Это позволило бы ему лучше ориентироваться в решениях NoSQL и Cosmos DB, но за счет меньшей глубины знаний в сфере РСУБД.nn
nnВ этой статье аспекты Azure Cosmos DB разъясняются с позиции администратора SQL Server, она нацелена на то, чтобы помочь специалисту по РСУБД в принятии решений. Мы будем говорить о том, что собой представляет эта технология и что она означает для того, кто большую часть своей профессиональной деятельности провел в работе с реляционными базами данных. Разобравшись в основных составных элементах этой новой технологии, вы сможете решить, стоит ли связывать с ней свое будущее.nnПрежде всего следует понимать, что Cosmos DB — не альтернатива SQL Server. Очень маловероятно, что вам когда-либо придется переносить данные из существующей базы данных SQL Server в Cosmos DB.nnЕдинственный сценарий, при котором это имело бы смысл, — изначально неправильное использование SQL Server, например сохранение огромных объемов статического XML-текста или объектов JSON (объектная нотация JavaScript) в базе данных SQL Server либо попытка использовать SQLServer в качестве серверной части для глобально распределенного приложения с высоким числом транзакций.nnОднако даже в таких случаях я бы рекомендовал не прибегать к переносу, а переработать архитектуру и переписать код. SQL Server и Azure Cosmos DB различаются в части метода масштабирования. SQL Server преимущественно использует вертикальное масштабирование, a Cosmos DB — горизонтальное.nnИдея горизонтального масштабирования базы данных может доставить беспокойство администратору, поскольку предполагает создание многочисленных копий «истины». В конечном счете эти копии синхронизируются друг с другом, но в сознании традиционного администратора базы данных, привыкшего для обеспечения зашиты информации полагаться на единственную версию «истины» (и модель, согласно которой все изменения находятся водной области на одном сервере), горизонтальное масштабирование связано с возникновением неопределенностей и конфликтов.nnРазличие между двумя платформами в части масштабируемости обусловлено их конструктивными особенностями: при создании SQL Server решалась первоочередная задача обеспечения согласованности и целостности данных, тогда как решение Cosmos DB изначально разрабатывалось в расчете на географическое распределение и высокую скорость за счет максимального приближения данных к пользователю, а также реализацию возможностей, тесно связанных с потребностями систем, функционирующих в пространстве Интернета вещей. Как и у всех платформ баз данных класса NoSQL (не только SQL), основным принципом Cosmos DB является «согласованность в конечном счете» (eventual consistency).nnУ SQL Server согласованность и целостность данных обеспечивается за счет того, что транзакции обрабатываются последовательно и почти всегда прикреплены к одному серверу. Если необходимо увеличить производительность или пропускную способность, это реализуется путем наращивания аппаратных ресурсов (процессор, память, скорость диска, размер диска, пропускная способность сети). Достоинством такого подхода является простота. Вкладываются денежные средства, и все ускоряется.nn
nnУ SQL Server также существуют способы горизонтального масштабирования, но они позволяют повысить производительность лишь тогда, когда речь идет о действиях, предполагающих только чтение. При использовании стратегий горизонтального масштабирования SQL Server повышение производительности ограничивается уменьшением конкуренции при доступе только для чтения. В случаях использования, когда имеет смысл горизонтальное масштабирование операций доступа к данным типа «только для чтения», можно применять репликацию и группы доступности.nnОба метода задействуют один первичный узел чтения-записи и один или несколько узлов только для чтения. Такая схема хорошо работает, например, в тех случаях, когда требуется сделать глобально доступной структуру отчетности (которая по своей природе доступна только для чтения). Но если необходимо ускорить выполнение операций вставки, обновления или удаления записей, использование единственного узла как «концентратора изменений данных» не даст ощутимого результата (рисунок 1). Со своей стороны, Azure Cosmos DB не предусматривает способа вертикального масштабирования.nnРешение Cosmos DB предназначено для горизонтального масштабирования за счет использования распространенных на большом пространстве систем с последующим зеркальным отображением этой структуры для максимального приближения данных к пользователю в любой точке света. Это можно уподобить дисковому массиву RA1D10 (комбинация зеркалирования и чередования), только сегменты данных, зеркально отображаемых по совокупности географических расположений, в этом случае чередуются по всем узлам.nnКонтейнер базы данных разбивается на разделы с использованием предоставляемых вами ключей хеширования. Каждый диапазон хешированных значений хранится на определенной системе (узле). Каждый узел допускает операции чтения и записи и, в свою очередь, естественным путем реплицируется па другие узлы, как показано на рисунке 2. Это означает, что единого концентратора всех операций записи не существует. Cosmos DB — сверхбыстрое решение, но сама база данных не тратит время на отклонение изменений, нарушающих политику. Поэтому если в базе данных возникает проблема, то к ней непросто применить возврат к состоянию на предшествующий момент времени.nn(источник: Журнал «Windows IT Pro»)
