Облако и масштабирование – понятия, зачастую идущие рядом. И первоначальный вариант SQL Azure содержал некоторые функции масштабирования. Мы могли легко создать новую базу данных в считанные секунды, нам не нужно было задумываться о сервере для новой базы данных и прочих вещах. Но это конечно не то масштабирование, которое нужно высоконагруженным проектам и большим базам данных (напомню что максимальный объём базы данных в SQL Azure равняется 50 Гб). Высоконагруженным приложениям нужна репликация, для часто считываемых данных, и нужен шардинг данных для того, чтобы распределить нагрузку между несколькими базами данных (и преодолеть лимит в 50 Гб на размер базы данных). Тема шардинга в SQL Azure мне кажется очень интересной и перспективной, особенно в свете появления новой концепции SQL Azure Federations. В этом и следующих постах я собираюсь раскрыть тему шардинга данных в SQL Azure.
Перед тем, как перейти к SQL Azure Federations я вкратце расскажу про то, что такое шардинг. Шардинг - это разделение базы данных на несколько баз данных по какому-то признаку. При этом данные баз не дублируются как в репликации, и каждая база в отдельности содержит свой кусок данных. Что нам это даёт? Каждый шард (базу данных) мы можем разместить на отдельном сервере, задействовав вычислительные мощности нескольких машин. Кроме этого, работая с конкретным шардом уменьшается объём обрабатываемой информации, и как следствие запросы работают быстрее.
Рассмотрим шардинг и его альтернативы на конкретном примере. У нас есть база данных электронного магазина. Данные о продажах растут очень быстро и в определённый момент времени запросы к базе начинают тормозить из-за большого объёма обрабатываемых данных. В этот момент возникает необходимость маштабироваться. Вертикально (наращивая мощности сервера баз данных) или горизонтально (разбивая базу данных на шарды по определённому признаку). Первый вариант хорош тем, что не нужно менять существующую инфраструктуру и код. Но есть и минусы. Какой бы мощный ни был сервер, его ресурсы не безграничны, и если вы растёте действительно быстро, то в определённый момент времени ресурсов железки вам может не хватить. Горизонтальное масштабирование обычно предполагает серьёзные изменения в коде для поддержки шардинга (если код с самого начала не писался с ориентацией на шардинг) и изменения инфраструктуры. Минусы очевидны – время, затрачиваемое на изменение кода и закупку/настройку новых серверов. Плюсы – неограниченное масштабирование + несколько маленьких серверов дешевле одного большого, а работают они очень быстро. Итак, мы рассмотрели масштабирование и шардинг в целом, а при чём здесь, собственно, SQL Azure? SQL Azure облегчает процесс горизонтального масштабирования, делая его более простым и интуитивно понятным.
Во-первых, это быстрое создание новых баз. Вам не нужно закупать новые сервера и размещать на них новые базы. Вам достаточно просто кликнуть и база будет создана.
Справедливости ради, стоит заметить, что база данных в SQL Azure не является физической базой данных SQL Server. Это только часть конечной, физической базы данных.
Эта возможность была доступна ещё на старте SQL Azure, и некоторые компании не преминули ею воспользоваться для реализации горизонтального масштабирования своего решения в SQL Azure. Я знаю, что компания TicketDirect использовала SQL Azure именно потому, что при пиковых нагрузках сегодня можно создать сотни новых баз данных, а завтра, когда нагрузка спадёт удалить ненужные более базы. С SQL Azure им не приходится заботиться о том куда деть неиспользуемые мощности и о том как выдержать пиковые нагрузки. Почитать про их продукт и их решение можно в следующем Case Study. TicketDirect использовали шардинг в своём решении. Они писали код, основываясь на мировых паттернах и практиках в этой области. И у них это получилось. И если вы сейчас не используете шардинг базы в своём проекте и попробуете закрыть глаза и представить себе как это можно сделать и насколько это просто, вы поймёте что это непросто и не быстро. Есть ряд стандартных проблем, встречающихся при реализации подобного решения. Часть из них решается уже сейчас в текущей версии SQL Azure, часть будет решаться при помощи SQL Azure Federations (возможно не в первом релизе).
Итак, что же это за проблемы?
- Рост и уменьшение базы данных – решается в текущей версии SQL Azure, благодаря моментальному созданию базы данных и выделению ресурсов
- Обеспечение высокой доступности – для каждой базы данных в SQL Azure существует 2 реплики, синхронизированные с первичной базой данных
- Обновление – для доступа к новому функционалу SQL Azure вам не нужно ставить обновления и останавливать сервер, все обновления проходят прозрачно для пользователя и без остановки сервиса
- Маршрутизация (определение того, на каком шарде лежат нужные данные) – сейчас это нужно реализовывать самому. В первом релизе SQL Azure Federations это будет покрыто.
- Управление секциями (разбиение и слияние, распределение данных) – будет покрыто в первом релизе SQL Azure Federations
- Распределённые запросы (собирающие данные с нескольких шардов) – не будет покрыто в первом релизе SQL Azure Federations, но работы над этим ведутся.
В следующих постах я более подробно расскажу про SQL Azure Federations и о принципах и практиках, используемых для шардинга данных.
Продолжение статьи - Знакомимся с SQL Azure Federations
Ссылки по теме: