На прошлой неделе я написал первый пост о шардинге в SQL Azure, в котором я рассказал о том, что такое шардинг, почему он так важен для масштабирования, и почему SQL Azure является хорошим выбором хранилища данные, если мы собираемся использовать шардинг. Со своей стратегией pay as you go, SQL Azure подходит как нельзя лучше в качестве хранилища данных, но этого мало. Организация шардинга дело непростое, особенно если ваша база данных и ваше приложение изначально не было к этому готово. В этом случае придётся много чего ломать и перестраивать заново. Операции с данными довольно сложны и весь функционал работы с масштабируемым хранилищем приходится писать самому. Но скоро эта ситуация должна измениться. Это произойдёт с приходом SQL Azure Federations.
[More]
Облако и масштабирование – понятия, зачастую идущие рядом. И первоначальный вариант SQL Azure содержал некоторые функции масштабирования. Мы могли легко создать новую базу данных в считанные секунды, нам не нужно было задумываться о сервере для новой базы данных и прочих вещах. Но это конечно не то масштабирование, которое нужно высоконагруженным проектам и большим базам данных (напомню что максимальный объём базы данных в SQL Azure равняется 50 Гб). Высоконагруженным приложениям нужна репликация, для часто считываемых данных, и нужен шардинг данных для того, чтобы распределить нагрузку между несколькими базами данных (и преодолеть лимит в 50 Гб на размер базы данных). Тема шардинга в SQL Azure мне кажется очень интересной и перспективной, особенно в свете появления новой концепции SQL Azure Federations. В этом и следующих постах я собираюсь раскрыть тему шардинга данных в SQL Azure .
[More]
16 марта (как раз накануне моего дня рождения :)) в Харькове прошло традиционное мероприятие Макрософт: Дни разработчика. Темами докладов были основные тренды сегодняшнего дня: Windows и SQL Azure, Silverlight и Windows Phone.
[More]