Разделение базы данных — это процесс разделения базы данных на несколько компьютеров для повышения масштабируемости приложения. Он включает в себя разбиение данных на две или более мелкие части, называемые логическими осколками. Затем логические сегменты распределяются по отдельным узлам базы данных, называемым физическими сегментами, которые могут содержать несколько логических сегментов.
Этот подход помогает избежать узких мест производительности, вызванных одной перегруженной машиной, и обеспечивает более экономичное и осуществимое масштабирование. По мере увеличения объема данных и трафика становится все более необходимым горизонтальное масштабирование путем добавления большего количества машин, а не вертикальное путем обновления одного большого сервера.
Почему Шардинг?
Возьмем пример Facebook. Facebook — яркий пример того, как небольшая нишевая платформа может быстро превратиться в глобальное явление. В первые дни сайт в основном использовался студентами Гарварда в качестве онлайн-ежегодника, а требования к хранилищу и запросы к базе данных могли обрабатываться одним сервером. Однако по мере роста популярности платформы объем данных и трафика резко увеличивался. К 2008 году Facebook получал 14 миллиардов просмотров страниц в месяц, и для выполнения каждого запроса требовалось несколько внутренних запросов.
Беспокоит не только нагрузка запросов, но и емкость хранилища. Поскольку Facebook продолжал расти и развиваться, компания неизбежно достигла точки, когда физическая мощность ее сервера базы данных была превышена. Когда служба имеет большой объем быстро меняющихся данных (много операций записи) или часто запрашивается многими пользователями таким образом, что рабочий набор превышает доступную память (много операций чтения), основным узким местом часто является ввод-вывод. .
В этот момент компания столкнулась с критическим выбором: масштабироваться ли вертикально, инвестируя в более мощный и дорогой сервер с увеличенным объемом ОЗУ, ЦП, дисковым вводом-выводом и емкостью хранилища, или масштабировать горизонтально, распределяя свои данные по нескольким, более доступные серверы. Оба варианта имели свои плюсы и минусы, и в конечном итоге решение сводится к тому, какой подход будет наиболее рентабельным и эффективным с точки зрения масштабирования платформы для удовлетворения растущих потребностей ее пользователей. В такой ситуации сегментирование базы данных может быть очень экономичным и масштабируемым решением, но компромиссом является повышенная сложность системы.
Шардинг архитектуры
После того, как вы приняли решение разделить свою базу данных, следующим шагом будет выяснить, как это сделать. Это включает в себя понимание различных типов сегментирования и того, как они используются для распространения данных. В этом разделе мы обсудим некоторые из наиболее часто используемых типов сегментирования и их методы распределения данных.
1-Вертикальное разделение
Одним из простых способов сегментации базы данных вашего приложения является перемещение таблиц, связанных с определенными функциями, на их собственные серверы. Например, вы можете разместить информацию о профиле пользователя на одном сервере, списки друзей — на другом, а третий — для пользовательского контента, такого как фотографии.
Этот подход относительно прост в реализации и оказывает минимальное влияние на приложение в целом. Однако, если сайт продолжает расти, может потребоваться дальнейшее разбиение баз данных для конкретных функций на несколько серверов.
Разбиение на 2 диапазона
Сегментирование на основе диапазона — это метод, который включает в себя разделение данных на основе диапазонов определенного значения. Например, рассмотрим базу данных каталогов розничного продавца, в которой хранится информация обо всех продуктах. Одним из способов разделения этих данных может быть создание нескольких сегментов и разделение информации о продуктах в зависимости от их ценового диапазона.
Такой подход обеспечивает более организованное и эффективное распределение данных, упрощая управление базой данных и запросы к ней. Однако основная проблема с этим подходом заключается в том, что если значение, используемое для секционирования, выбрано неосторожно, это может привести к неравномерному распределению данных по серверам. Например, если определенный ценовой диапазон содержит большее количество продуктов, это может привести к тому, что один шард будет перегружен, а другие недогружены.
Разделение на основе 3 ключей
Шардинг на основе ключей, также известный как сегментирование на основе хэшей. Он работает, используя уникальное значение, такое как идентификатор пользователя, в качестве входных данных для хэш-функции. Затем хеш-функция вычисляет выходные данные, которые используются для определения того, на каком сервере должны храниться данные. Одним из примеров этого является использование идентификаторов пользователей в качестве входного значения и использование операции по модулю над идентификатором пользователя с количеством доступных серверов, чтобы определить, на каком сервере хранить информацию о пользователе.
Этот подход направлен на обеспечение равномерного распределения данных по серверам. Однако одна из основных проблем этого метода заключается в том, что он ограничивает гибкость добавления дополнительных серверов в систему, поскольку это потребует изменения хеш-функции, а это может быть сложно выполнить без простоя.
Разделение на основе 4-х каталогов
Разделение на основе каталогов предполагает наличие таблицы поиска, которая использует ключ сегмента для отслеживания того, какой сегмент содержит какие данные. Этот ключ сегмента обычно является уникальным идентификатором для каждой части данных, например идентификатора пользователя или идентификатора продукта. Таблица поиска используется для определения того, к какому сегменту принадлежит конкретный фрагмент данных, что позволяет системе эффективно извлекать и обновлять данные по мере необходимости.
Этот подход обеспечивает большую гибкость с точки зрения добавления или удаления серверов или изменения схемы разбиения, не затрагивая остальную часть приложения. Например, если в настоящее время имеется десять серверов, а хеш-функция является операцией по модулю, добавление в пул еще пяти серверов может быть выполнено без простоя. Сценарий может быть запущен для копирования данных с исходных десяти серверов на новые пять серверов на основе новой хэш-функции с использованием нового количества серверов, равного пятнадцати. Как только данные скопированы, таблица поиска может измениться на использование новой хэш-функции.
Преимущества шардинга
1-Высокая доступность
Если один ящик выходит из строя, остальные продолжают работать. Разделение базы данных повышает доступность приложения. В случае сбоя в одном шарде пользователям станет недоступна только определенная часть приложения. Однако другие сегменты могут продолжать работать без перерыва. С другой стороны, если база данных не сегментирована, сбой может привести к недоступности всего приложения.
2 быстрых запроса
Разделение базы данных сокращает время ответа на запросы за счет разделения данных на более мелкие группы. Когда запрос отправляется в несегментированной базе данных, ему может потребоваться выполнить поиск по каждой строке таблицы, прежде чем будет найден желаемый набор результатов. Напротив, в случае сегментированной базы данных запрос должен проходить только по меньшему количеству строк, что приводит к более быстрому времени ответа на запрос.
3-одновременная запись
Распределяя операции записи по нескольким сегментам, система может обрабатывать больше одновременных операций записи, в результате чего база данных становится более эффективной и надежной.
4-Дополнительная работа
Разделение обеспечивает горизонтальное масштабирование, также известное как масштабирование. С параллельным бэкендом система может выполнять больше работы одновременно, что позволяет ей справляться с высокой пользовательской нагрузкой. Параллельные пути в системе также позволяют выполнять более быстрые операции записи, поскольку данные распределяются по нескольким сегментам. Веб-серверы с балансировкой нагрузки также можно использовать для доступа к сегментам по разным сетевым путям, которые обрабатываются отдельными ЦП и используют отдельные кэши ОЗУ и дисковые пути ввода-вывода. Это уменьшает узкие места и повышает общую производительность и надежность системы.
Недостатки
1-присоединяется
Разделение базы данных может вызвать проблемы, когда речь идет о выполнении объединений в нескольких таблицах. До сегментирования эти запросы выполнялись на одном сервере, но когда база данных распределена по нескольким серверам, выполнение соединений, охватывающих сегменты базы данных, становится более сложным и сложным. Это связано с тем, что данные должны быть скомпилированы с нескольких серверов, что может привести к значительным накладным расходам и отрицательно сказаться на производительности.
Однако есть способы смягчить эту проблему. Использование кэширования и быстрых сетей может помочь ускорить процесс и обеспечить быструю загрузку страниц. Кроме того, жизнеспособным решением может быть денормализация базы данных путем объединения связанных данных в одну таблицу, поскольку она позволяет выполнять ранее сложные запросы на соединение в одной таблице.
2-Ссылочная целостность
Поддержание целостности данных, например использование внешних ключей, может быть проблемой при использовании сегментированной базы данных. Большинство систем управления реляционными базами данных не поддерживают внешние ключи на разных серверах, что затрудняет обеспечение ссылочной целостности. Это означает, что приложениям, которые полагаются на эту функцию, может потребоваться реализовать ее в своем коде и выполнять обычные задания SQL для обеспечения согласованности данных. Это может добавить дополнительную сложность и обслуживание к приложению.
3-Поддержание баланса данных
При использовании сегментированной базы данных важно следить за распределением данных по сегментам, поскольку один сегмент может стать больше, чем другие, что называется горячей точкой. Это может свести на нет преимущества сегментирования и вызвать проблемы с производительностью. Чтобы предотвратить это, может потребоваться повторное сегментирование базы данных, чтобы обеспечить равномерное распределение данных по всем сегментам. Лучше с самого начала предусмотреть такую возможность, так как повторный шардинг может привести к простою, если он не будет выполнен должным образом.
4-ограниченная поддержка баз данных
Не все ядра баз данных имеют встроенную поддержку сегментирования, а это означает, что для этого может потребоваться специальная реализация. Это может затруднить поиск документации и решений по устранению неполадок.
Спасибо за чтение. Я надеюсь, что этот пост будет полезен для вас. Если у вас есть дополнительные вопросы, не стесняйтесь обращаться к нам. Я всегда рад помочь.
