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

Майк Уоссон, Рик Андерсон (, том Dykstra)

Скачивание решения ИТ-проекта или Загрузка электронной книги

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

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

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

Три и более хранилища данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При наличии одного и того же набора данных другой вариант заключается в хранении различных диапазонов имен клиентов в разных базах данных.

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

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

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

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

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

Гибридная секционированная таблица данных

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

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

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

Сводка

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

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

Ресурсы

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

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

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

Пример кода: