Понимание шардинга базы данных

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

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

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

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

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

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

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

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

Основная привлекательность сегментирования базы данных заключается в том, что он может помочь облегчитьhorizontal scaling, также известный какscaling out. Горизонтальное масштабирование - это практика добавления большего количества машин к существующему стеку, чтобы распределить нагрузку и обеспечить больший трафик и более быструю обработку. Это часто противопоставляетсяvertical scaling, иначе известному какscaling up, который включает в себя обновление оборудования существующего сервера, обычно путем добавления дополнительной оперативной памяти или процессора.

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

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

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

Хотя ограждение базы данных может облегчить масштабирование и повысить производительность, оно также может накладывать определенные ограничения. Здесь мы обсудим некоторые из них и почему они могут быть причинами, чтобы вообще не использовать шардинг.

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

Одна проблема, с которой пользователи иногда сталкиваются после разделения базы данных, заключается в том, что фрагменты в конечном итоге становятся несбалансированными. Например, предположим, у вас есть база данных с двумя отдельными сегментами: одна для клиентов, чьи фамилии начинаются с букв от A до M, а другая для тех, чьи имена начинаются с букв от N до Z. Однако ваше заявление обслуживает чрезмерное количество людей, чьи фамилии начинаются с буквы G. Соответственно, в сегменте A-M постепенно накапливается больше данных, чем в сегменте N-Z, в результате чего приложение замедляется и блокируется для значительной части ваших пользователей. Осколок A-M стал известен какdatabase hotspot. В этом случае любые преимущества шардинга базы данных сводятся на нет замедлениями и сбоями. Скорее всего, базу данных необходимо будет отремонтировать и перенастроить, чтобы обеспечить более равномерное распределение данных.

Другим существенным недостатком является то, что после того, как база данных была очищена, может быть очень трудно вернуть ее к неохраняемой архитектуре. Любые резервные копии базы данных, сделанные до ее обработки, не будут содержать данные, записанные после разбиения. Следовательно, для восстановления исходной неохраняемой архитектуры потребуется объединить новые многораздельные данные со старыми резервными копиями или, наоборот, преобразовать многораздельные БД обратно в одну БД, что потребует больших затрат и времени.

Последний недостаток, который следует учитывать, заключается в том, что разделение не поддерживается изначально каждым механизмом базы данных. Например, PostgreSQL не включает автоматическое разбиение как функцию, хотя есть возможность вручную разделить базу данных PostgreSQL. Существует ряд форков Postgres, которые включают автоматическое разбиение, но они часто отстают от последнего выпуска PostgreSQL и не имеют определенных других функций. Некоторые специализированные технологии баз данных, такие как MySQL Cluster или некоторые продукты базы данных как услуга, такие как MongoDB Atlas, действительно включают в себя функцию автоматического разделения, но ванильные версии этих систем управления базами данных этого не делают. Из-за этого шардинг часто требует подхода «покатись сам». Это означает, что зачастую трудно найти документацию по шардингу или советы по устранению неполадок.

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

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

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

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

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

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

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

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

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