- Оригинальный адрес:Understanding Database Sharding
- Оригинальный автор:Mark Drake
- Перевод с:Программа перевода самородков
- Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…
- Переводчик:Romeo0906
- Корректор:HearFishle,ziyin feng
Обзор
Любому процветающему приложению или веб-сайту в конечном итоге потребуется расшириться, чтобы приспособиться к росту трафика. Для приложений и веб-сайтов, управляемых данными, особенно важно масштабирование таким образом, чтобы гарантировать безопасность и целостность данных. Очень сложно предсказать, насколько популярным будет веб-сайт или приложение в будущем и как долго оно просуществует, поэтому некоторые команды выбирают архитектуры баз данных, поддерживающие динамическое масштабирование.
В этой концептуальной статье мы обсудим архитектуру базы данных, поддерживающую динамическое масштабирование:Разделенная база данных. В последние годы технология сегментирования базы данных очень привлекательна, но многие люди не понимают, что это такое и какие сценарии можно использовать, чтобы наилучшим образом использовать сегментирование базы данных. В этой статье мы обсудим, что такое сегментирование базы данных, проанализируем его преимущества и недостатки, а также некоторые распространенные методы сегментирования базы данных.
Что такое шардирование базы данных?
Шардинг базы данных — этоГоризонтальная перегородкаТак называемая технология горизонтального разделения представляет собой практику разделения данных в таблице на несколько разных таблиц по строкам, и эти разные таблицы называются разделами. Каждый раздел имеет одну и ту же схему и одни и те же столбцы, но строки данных совершенно разные. Точно так же данные в каждом разделе уникальны и не зависят от других разделов.
комбинироватьвертикальная перегородкаМожет быть проще понять горизонтальное разбиение. В вертикально секционированной таблице столбцы данных разбиваются на отдельные новые таблицы. Данные в каждом вертикальном разделе не зависят от других разделов, а строки и столбцы каждого раздела различны. На следующей диаграмме показано, как разделить таблицу по горизонтали и по вертикали:
Разделение базы данных включает в себя разделение данных на подмножества, называемыелогический шардинг. Логические сегменты распределены по разным узлам базы данных, которые называютсяфизический шардинг. Таким образом, каждый физический сегмент можно разделить на несколько логических сегментов. Тем не менее, данные во всех этих сегментированных коллекциях вместе выглядят логически как весь набор данных.
Шардинг базы данныхНичего общего с архитектуройпример . Это означает, что поведение сегментов является автономным: никакие данные или вычислительные ресурсы не распределяются между сегментами. Однако в некоторых случаях также полезно реплицировать определенные таблицы данных в качестве справочных таблиц между осколками. Например, приложение использует фиксированный коэффициент преобразования для преобразования различных единиц веса. При проектировании базы данных дублирование таблицы, содержащей необходимые данные масштабирования, в каждый сегмент поможет гарантировать, что данные, необходимые для запросов масштабирования, будут храниться в каждом сегменте.
Разделение базы данных обычно реализуется на уровне приложения, а код в приложении определяет сегменты базы данных для чтения и записи. Однако некоторые системы управления базами данных имеют встроенные возможности сегментирования, которые позволяют выполнять операции сегментирования непосредственно на уровне базы данных.
Обладая приведенными выше базовыми знаниями о сегментировании базы данных, давайте рассмотрим преимущества и недостатки этой архитектуры базы данных.
Преимущества шардинга базы данных
Самое привлекательное в сегментировании базы данных то, что оно упрощаетМасштабированиеработа, также известная какМасштабирование. Масштабирование означает добавление большего количества машин к существующей базе для разгрузки нагрузки, тем самым увеличивая трафик и повышая скорость обработки. Часто сравнивают сУвеличить масштаб, или называетсяМасштабирование, относится к обновлению аппаратной конфигурации существующей машины, обычно с добавлением памяти и ЦП.
Мы можем легко запустить экземпляр реляционной базы данных на определенной машине и расширить ее возможности, только обновив вычислительные ресурсы машины. Однако все нераспределенные базы данных в конечном итоге ограничены емкостью хранилища и вычислительной мощностью машины, поэтому возможность свободного масштабирования сделает ваше приложение более гибким.
Еще одна причина выбрать архитектуру сегментирования базы данных — повысить скорость отклика на запросы. Если вы не сегментируете базу данных, при отправке команды запроса в базу данных вам может потребоваться запросить все строки в таблице, чтобы найти необходимые данные. Для приложений с большими отдельными базами данных запросы станут очень медленными. Благодаря технологии сегментирования данные разбрасываются по нескольким таблицам, а необходимые данные будут найдены в небольшой части данных при запросе, и при этом набор результатов может быть возвращен быстрее.
Разделение базы данных также сокращает время простоя, делая приложения более стабильными. Если ваше приложение или веб-сайт использует нераспределенную базу данных, время простоя может сделать все приложение недоступным. Но если это сегментированная база данных, время простоя затронет только один из сегментов. Хотя некоторые функции нашего приложения или веб-сайта могут быть недоступны для некоторых пользователей, общее воздействие все равно будет намного меньше, чем если бы вся база данных вышла из строя.
Недостатки сегментирования базы данных
Хотя сегментирование базы данных позволяет легко масштабировать и повышать производительность, оно имеет некоторые ограничения. В этом разделе мы обсудим некоторые его ограничения и объясним, почему не следует разбивать все базы данных одновременно.
Первая трудность, возникающая при сегментировании базы данных, заключается в том, что правильно реализовать архитектуру сегментирования базы данных довольно сложно. Если вы не сделаете это правильно, вы сильно рискуете, потому что в процессе шардинга базы данных может произойти потеря данных, повреждение таблицы данных и другие последствия. Даже в случае успеха операции сегментирования базы данных могут существенно повлиять на рабочий процесс команды. Вместо того, чтобы иметь единую точку для чтения и управления данными, люди будут управлять данными в нескольких сегментах базы данных, что может создать путаницу в некоторых командах.
Другая проблема заключается в том, что вы можете столкнуться с дисбалансом фрагментации после фрагментации базы данных. Например, предположим, что в вашей базе данных есть два отдельных сегмента: один для клиентов, имена которых начинаются с букв от A до M, а другой — для клиентов, имена которых начинаются с букв от N до Z. Однако в вашем приложении есть большое количество пользователей, имена которых начинаются с буквы G. В результате сегменты AM постепенно генерируют больше данных, чем сегменты N-Z, в результате чего приложение становится очень медленным и даже зависает для некоторых пользователей. Здесь перегородка А-М представляет собой так называемуюТочки доступа к базе данных. В этом примере все преимущества сегментирования базы данных бесполезны, так как приложение замедляется и падает. Следовательно, базу данных необходимо восстановить и повторно разбить на сегменты, чтобы добиться более разумного распределения данных.
Другим важным недостатком является то, что после сегментации базы данных трудно вернуться к предварительно сегментированной схеме. Любые резервные копии, сделанные до операции сегментирования, не содержат данных, записанных после разделения. Следовательно, чтобы перестроить исходную нераспределенную схему базы данных, необходимо объединить данные нового раздела со старыми данными резервной копии или импортировать базу данных каждого раздела в единую базу данных. Оба метода требуют много времени, трудоемки и дороги.
Последний недостаток, который следует учитывать, заключается в том, что не все механизмы баз данных изначально поддерживают сегментирование. Например, в PostgreSQL нет автоматического сегментирования, поэтому мы можем сегментировать базу данных PostgreSQL только вручную. Хотя существует множество разветвленных версий Postgres с автоматическим сегментированием, они обычно выпускаются позже, чем последняя версия PostgreSQL, и в них отсутствуют некоторые функции. Некоторые профессиональные технологии баз данных, такие как кластер MySQL или некоторые сервисные продукты баз данных (например, MongoDB Atlas), имеют функцию автоматического сегментирования, но общая версия реляционной системы баз данных не имеет такой функции. Из-за этого сегментирование базы данных часто выполняется самостоятельно, а это означает, что может быть сложно найти документацию или советы по устранению неполадок при сегментировании базы данных.
Конечно, это лишь некоторые из распространенных вопросов, которые следует учитывать перед операциями сегментирования базы данных. Столкнувшись с различными сценариями использования, операции сегментирования базы данных могут столкнуться с большим количеством проблем.
До сих пор мы обсуждали преимущества и недостатки некоторых сегментов баз данных, а затем мы представим несколько архитектурных методов сегментирования баз данных.
Архитектура разделения базы данных
Как только вы решите, что хотите сегментировать свою базу данных, вам нужно решить, как это реализовать. Выбор правильного раздела имеет решающее значение при запросе данных или сохранении данных в сегментированную базу данных или таблицу. В противном случае это приведет к потере данных или мучительно медленным запросам. В этом разделе мы рассмотрим некоторые распространенные архитектуры сегментирования базы данных, каждая из которых имеет несколько разные способы сохранения данных между сегментами.
Шардинг базы данных на основе ключей
шардинг на основе ключейТакже известен какШардинг на основе хэша, используя значения вновь записанных данных — таких как идентификатор клиента, IP-адрес клиента, почтовый индекс и т. д. — черезхэш-функцияРешите, где сохранить осколок. Хэш-функция преобразует входные данные (например, адрес электронной почты пользователя) в дискретные данные (также называемые хэш-значением) для вывода. При сегментировании базы данных хеш-значение используется в качестве идентификатора сегмента базы данных для сохранения данных в соответствующем сегменте. В целом весь процесс выглядит так:
Чтобы гарантировать, что все данные хранятся в правильном месте, а поведение при хранении является согласованным (то есть одни и те же данные каждый раз сохраняются в одном и том же месте, примечание переводчика), входное значение хеш-функции должно быть одинаковым. столбец данных. Этот столбец данных называетсяОсколочный ключ. Просто ключ раздела что-то вродепервичный ключ, оба используются для создания уникального идентификатора для каждого data/shard. Как правило, ключ сегмента должен быть статическим, что означает, что он не должен содержать изменяемые данные. В противном случае потребуется больше работы по обновлению данных, и производительность может ухудшиться.
Хотя сегментирование базы данных на основе ключей является очень распространенной архитектурой сегментирования базы данных, динамическое добавление или удаление серверов баз данных в этой архитектуре может быть затруднено. По мере добавления серверов хэш каждого сегмента базы данных необходимо корректировать, поэтому многие, если не все данные, необходимо переназначить на правильный хэш, а затем перенести на нужный сервер. При балансировке данных и старая, и новая хеш-функции перестанут работать. Поэтому во время переноса данных сервер баз данных не сможет записывать какие-либо данные, и приложение будет приостановлено.
Самое привлекательное в этой стратегии то, что она распределяет данные равномерно, тем самым избегая горячих точек данных. Кроме того, поскольку он использует алгоритм для распределения данных, нет необходимости поддерживать отношение сопоставления распределения данных, как в других стратегиях (стратегии сегментирования базы данных на основе диапазона или каталога).
Разделение базы данных на основе диапазона
Разделение базы данных на основе диапазонаРазбивает данные на основе заданного диапазона данных. Скажем так, если у вас есть база данных, содержащая информацию о продуктах для розничных магазинов, вы можете создать несколько сегментов базы данных и распределить данные о продуктах по разным сегментам в зависимости от ценовых диапазонов, например:
Самым большим преимуществом сегментирования базы данных на основе диапазонов является то, что его относительно просто реализовать. Каждый сегмент содержит разные наборы данных, но они имеют другую схему и, безусловно, отличаются от исходной базы данных. Коду приложения нужно только прочитать, в какой диапазон попадают данные, и записать их в соответствующий раздел.
С другой стороны, сегментирование базы данных на основе диапазонов не предотвращает неравномерное распределение данных и не предотвращает появление горячих точек базы данных, о которых говорилось ранее. Глядя на приведенную выше легенду, даже если объем данных, хранящихся в каждом сегменте, одинаков, некоторые продукты могут быть более популярными, чем другие, поэтому каждый сегмент будет иметь неравномерное распределение чтения данных.
Разделение базы данных на основе каталогов
ДостигатьРазделение базы данных на основе каталогов, вы должны создать и поддерживатьСправочная таблицаи используйте ключ сегмента базы данных, чтобы записать место сохранения данных в таблице. Короче говоря, таблица поиска — это таблица, содержащая статический набор данных о том, как найти данные. На следующем рисунке показан простой пример сегментирования базы данных на основе каталогов:
В этом примереDelivery ZoneСтолбец определяется как ключ сегмента, и значение ключа сегмента записывается в таблицу поиска вместе с разделом, в котором хранятся данные строки. Это похоже на сегментирование базы данных на основе диапазона, но вместо того, чтобы судить, в какой диапазон попадают данные, мы привязываем каждый фрагмент данных к его сегменту. По сравнению с сегментированием базы данных на основе диапазона, сегментирование базы данных на основе каталога является лучшим выбором.Если кардинальность ключей сегментирования мала, для сегментирования базы данных сохранение диапазона ключей становится бессмысленным. Конечно, сегментирование базы данных на основе каталогов также отличается от сегментирования базы данных на основе ключей тем, что оно не использует хеш-функцию для обработки ключа сегмента, а просто проверяет имя ключа в таблице поиска и находит, где данные должны быть. написано.
Наиболее привлекательным аспектом архитектуры сегментирования базы данных на основе каталогов является гибкость. Архитектура сегментирования базы данных на основе диапазона требует, чтобы вы указали диапазон значений, в то время как архитектура сегментирования базы данных на основе ключа требует использования фиксированной хеш-функции.Как упоминалось ранее, изменить эту функцию очень сложно. Архитектура сегментирования базы данных на основе каталогов позволяет использовать любую систему и любой алгоритм для указания местоположения сегмента, в котором хранятся данные, а добавление сегментов относительно просто.
Хотя архитектура сегментирования базы данных на основе каталогов является наиболее гибким методом сегментирования, обсуждавшимся до сих пор, необходимость запрашивать таблицу поиска перед каждым запросом и записью данных может повлиять на производительность приложения. Кроме того, таблицы поиска могут создать единую точку отказа: если таблица поиска повреждена или не работает по другим причинам, это повлияет на возможность записи новых данных или запроса существующих данных.
Должен ли я шардировать базу данных?
Вопрос о том, следует ли использовать сегментированную архитектуру базы данных, был спорным. Одни считают, что когда база данных достигает определенного уровня, переход на сегментированную архитектуру неизбежен; другие считают, что из-за сложности операции сегментированную архитектуру следует использовать только в крайнем случае.
Из-за своей сложности архитектуры сегментирования базы данных в основном используются для обработки очень больших объемов данных. Шардинг базы данных может быть очень полезен в следующих сценариях:
- Объем данных приложений продолжает увеличиваться за пределы емкости хранения единой базы данных.
- Чтение и запись базы данных превышают вычислительную мощность одноточечной базы данных или ведомой библиотеки, доступной только для чтения (в соответствии с архитектурой разделения чтения и записи, примечание переводчика), что приводит к медленному отклику или тайм-ауту.
- Пропускная способность сети, необходимая приложению, превышает доступную пропускную способность одноточечной базы данных или ведомой библиотеки только для чтения, что приводит к медленным ответам или тайм-аутам.
Перед шардингом базы данных лучше попробовать другие способы оптимизации базы данных. Например:
- Использовать удаленную базу данных. Если у вас большое приложение, все его компоненты зависят от одного и того же сервера базы данных, вы можете рассмотреть возможность переноса базы данных на одну машину, чтобы повысить их производительность. Это не так сложно, как фрагментация базы данных, потому что все таблицы базы данных остаются нетронутыми. Более того, этот подход также позволяет вам отложить в сторону другую инфраструктуру для масштабирования базы данных.
- использоватьтайник. Если приложение ограничено производительностью чтения данных, использование кеша является одним из способов повышения производительности. Кэши ускоряют последующий доступ к данным, временно удерживая запрошенные данные в памяти.
- Создайте несколько подчиненных библиотек только для чтения. Еще один способ повысить производительность чтения — преобразовать данные изосновная библиотекаскопировать в несколькоиз библиотекисередина. Таким образом, новые операции записи будут использовать основную библиотеку, которая затем копируется в подчиненную библиотеку, а операции чтения будут использовать подчиненную библиотеку. Такое разделение операций чтения и записи предотвращает перегрузку каждой машины и помогает предотвратить ее замедление или даже сбой. Стоит отметить, что создание ведомых устройств только для чтения требует больше вычислительных ресурсов, стоит больше денег, а в некоторых случаях это усложнит вам задачу.
- обновить сервер. В некоторых случаях обновление конфигурации сервера базы данных намного проще, чем сегментирование базы данных. Обновление конфигурации сервера может стоить больше, чем создание ведомого устройства только для чтения. Поэтому, если это действительно ваш лучший вариант, вам не следует масштабировать свою машину.
Имейте в виду, что сегментирование базы данных действительно лучший вариант, только когда ваше приложение или веб-сайт выходят за определенный уровень, когда ни один из вышеперечисленных методов не является достаточным для эффективного повышения его производительности.
Суммировать
Шардинг базы данных — отличный вариант для тех, кто пытается масштабировать базу данных. Однако это также усложняет модель и добавляет в приложение множество потенциальных точек отказа. Для некоторых сегментирование базы данных может быть очень необходимо, но для других время и ресурсы, затрачиваемые на создание и поддержку схемы сегментирования базы данных, перевешивают преимущества.
Прочитав эту концептуальную статью, вы должны получить более четкое представление о преимуществах и недостатках сегментирования базы данных. Позднее вы сможете использовать идеи из этой статьи, чтобы определить, действительно ли вашему приложению нужна архитектура сегментирования базы данных.
Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.
Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.