Поделиться через

Стратегии секционирования данных (создание облачных приложений Real-World с помощью Azure)

  • Статья

Рик Андерсон(Rick Anderson),Том Дайкстра (Tom Dykstra)

Скачать проект Fix It или скачать электронную книгу

Электронная книга "Создание реальных облачных приложений с помощью Azure " основана на презентации, разработанной Скоттом Гатри. В нем объясняется 13 шаблонов и методик, которые помогут вам успешно разрабатывать веб-приложения для облака. Сведения о серии см. в первой главе.

Ранее мы узнали, насколько легко масштабировать веб-уровень облачного приложения, добавляя и удаляя веб-серверы. Но если все они попадают в одно и то же хранилище данных, узкое место приложения перемещается от внешнего интерфейса к серверной части, а уровень данных сложнее всего масштабировать. В этой главе мы рассмотрим, как сделать уровень данных масштабируемым путем секционирования данных на несколько реляционных баз данных или путем объединения хранилища реляционных баз данных с другими вариантами хранения данных.

Настройка схемы секционирования лучше всего выполнять заранее по той же причине, упомянутой ранее: очень трудно изменить стратегию хранения данных после того, как приложение находится в рабочей среде. Если вы задумались о различных подходах, вы можете избежать "момент Twitter", когда ваше приложение аварийно завершает работу или выходит из строя в течение длительного времени, пока вы реорганизуете данные приложения и код доступа к данным.

Три vs хранилища данных

Чтобы определить, нужна ли вам стратегия секционирования и какой она должна быть, рассмотрите три вопроса о ваших данных:

  • Объем — сколько данных вы в конечном итоге будете хранить? Пару гигабайт? Пару сотен гигабайт? Терабайт? Петабайт?
  • Скорость — с какой скоростью будут расти ваши данные? Это внутреннее приложение, которое не создает много данных? Внешнее приложение, в которое клиенты будут отправлять изображения и видео?
  • Разнообразие — какой тип данных вы будете хранить? Реляционные, изображения, пары "ключ-значение", социальные графы?

Если вы считаете, что у вас будет большой объем, скорость или разнообразие, необходимо тщательно продумать, какая схема секционирования лучше всего позволит вашему приложению эффективно и эффективно масштабироваться по мере его роста, а также не столкнуться с узкими местами.

Существует три подхода к секционированиям:

  • Вертикальное секционирование
  • Горизонтальное секционирование
  • Гибридное секционирование

Вертикальное секционирование

Вертикальное секциоирование похоже на разделение таблицы по столбцам: один набор столбцов попадает в одно хранилище данных, а другой набор столбцов — в другое хранилище данных.

Например, предположим, что мое приложение хранит данные о людях, включая изображения:

Таблица данных

Если представить эти данные в виде таблицы и посмотреть на различные разновидности данных, можно увидеть, что три столбца слева содержат строковые данные, которые могут эффективно храниться реляционной базой данных, а два столбца справа по сути являются массивами байтов, поступающими из файлов изображений. Данные файла изображений можно хранить в реляционной базе данных, и многие люди делают это, потому что не хотят сохранять данные в файловой системе. Возможно, у них нет файловой системы, способной хранить необходимые тома данных, или они не хотят управлять отдельной системой резервного копирования и восстановления. Этот подход хорошо подходит для локальных баз данных и небольших объемов данных в облачных базах данных. В локальной среде может быть проще просто позволить DBA позаботиться обо всем.

Но в облачной базе данных хранилище является относительно дорогостоящим, и большой объем образов может привести к тому, что размер базы данных может превысить пределы, при которых она может эффективно работать. Эти проблемы можно решить, разделив данные по вертикали. Это означает, что вы выбираете наиболее подходящее хранилище данных для каждого столбца в таблице данных. В этом примере лучше всего поместить строковые данные в реляционную базу данных, а образы — в хранилище BLOB-объектов.

Таблица данных с вертикальным секционированием

Хранение образов в хранилище BLOB-объектов, а не в базе данных в облаке, чем в локальной среде, так как вам не нужно беспокоиться о настройке файловых серверов или управлении резервным копированием и восстановлением данных, хранящихся за пределами реляционной базы данных. Все, что автоматически обрабатывается службой хранилища BLOB-объектов.

Это подход к секционирования, который мы реализовали в приложении Fix It, и мы рассмотрим код для этого в разделе Хранилище BLOB-объектов. Без этой схемы секционирования и при условии, что средний размер изображения составляет 3 мегабайта, приложение Fix It сможет хранить только около 40 000 задач до достижения максимального размера базы данных в 150 гигабайт. После удаления образов в базе данных может храниться в 10 раз больше задач; Вы можете пойти гораздо дольше, прежде чем придется думать о реализации схемы горизонтального секционирования. А по мере масштабирования приложения ваши расходы растут медленнее, так как основная часть ваших потребностей в хранилище собирается в очень недорогое хранилище BLOB-объектов.

Горизонтальное секционирование (сегментирование)

Горизонтальное разделение похоже на разделение таблицы на строки: один набор строк попадает в одно хранилище данных, а другой набор строк — в другое хранилище данных.

Учитывая тот же набор данных, другим вариантом будет хранение различных диапазонов имен клиентов в разных базах данных.

Таблица данных с горизонтальным разделением

Вы хотите быть очень осторожными в схеме сегментирования, чтобы обеспечить равномерное распределение данных, чтобы избежать горячих точек. Этот простой пример с использованием первой буквы фамилии не соответствует этому требованию, так как у многих людей есть фамилии, начинающиеся с определенных общих букв. Вы столкнетесь с ограничениями на размер таблицы раньше, чем можно было бы ожидать, так как некоторые базы данных будут очень большими, а большинство из них останутся небольшими.

В нижней части горизонтального секционирования может быть трудно выполнять запросы ко всем данным. В этом примере запросу потребуется создать до 26 разных баз данных, чтобы получить все данные, хранящиеся в приложении.

Гибридное секционирование

Можно сочетать вертикальное и горизонтальное секционирование. Например, в примере данных можно хранить изображения в хранилище BLOB-объектов и горизонтально секционирование строковых данных.

Таблица данных с гибридным секционированием

Секционирование рабочего приложения

Концептуально легко понять, как будет работать схема секционирования, но любая схема секционирования повышает сложность кода и предоставляет множество новых усложнений, с которыми вам придется столкнуться. Если вы перемещаете образы в хранилище BLOB-объектов, что делать при отключении службы хранилища? Как вы работаете с безопасностью BLOB-объектов? Что произойдет, если база данных и хранилище BLOB-объектов не синхронизированы? Как вы будете обрабатывать запросы во всех базах данных, если выполняется сегментирование?

Сложности поддаются управлению до тех пор, пока вы планируете их, прежде чем перейти к производству. Многие люди, которые не сделали это желание у них было позже. В среднем наша команда по консультированию клиентов (CAT) получает панические телефонные звонки примерно раз в месяц от клиентов, чьи приложения взлетают в очень большой путь, и они не делают этого планирования. И они говорят что-то вроде: "Помогите! Я помещаю все в одно хранилище данных, и через 45 дней у меня не будет места!" И если у вас есть много бизнес-логики, встроенной в то, как вы обращаетесь к хранилищу данных, и у вас есть клиенты, которые используют ваше приложение, нет хорошего времени, чтобы выйти из строя на день во время миграции. В конечном итоге мы будем выполнять геркулесные усилия, чтобы помочь клиенту секционировать свои данные на лету без простоя. Это очень интересно и очень страшно, а не то, что вы хотите быть вовлечены в, если вы можете избежать этого! Подумайте об этом на первый взгляд и интегрировать его в ваше приложение, что значительно упростит вашу жизнь, если приложение будет расти позже.

Итоги

Эффективная схема секционирования позволяет облачному приложению масштабироваться до петабайт данных в облаке без узких мест. Кроме того, вам не придется заранее платить за большие компьютеры или обширную инфраструктуру, как если бы вы запускали приложение в локальном центре обработки данных. В облаке вы можете добавочно добавлять емкость по мере необходимости, и вы платите только столько, сколько используете при ее использовании.

В следующей главе мы посмотрим, как приложение Fix It реализует вертикальное секционирование, сохраняя образы в хранилище BLOB-объектов.

Ресурсы

Дополнительные сведения о стратегиях секционирования см. в следующих ресурсах.

Документация.

Видеоролики:

  • FailSafe: создание масштабируемых, устойчивых Облачные службы. Серия из девяти частей Ульрих Хоманн, Марк Меркури и Марк Симмс. Представляет высокоуровневые концепции и архитектурные принципы очень доступным и интересным способом, а также истории, взятые из опыта группы microsoft customer Advisory Team (CAT) с реальными клиентами. См. обсуждение секционирования в эпизоде 7.
  • Создание больших объемов. Уроки, извлеченные от клиентов Windows Azure. Часть I. Марк Симмс обсуждает схемы секционирования, стратегии сегментирования, способы реализации сегментирования и База данных SQL федерации, начиная с 19:49. Похож на серию Failsafe, но в нем подробно описаны дополнительные инструкции.

Пример кода:

НазадВперед