Разделение базы данных против разбиения


166

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

Могут ли эксперты в stackoverflow помочь мне понять основы правильно?

  • В чем разница между шардингом и разбиением ?
  • Правда ли, что «все сегментированные базы данных по существу разделены (по разным узлам), но все разделенные базы данных не обязательно сегментированы» ?

digitalocean.com/community/tutorials/… это может помочь.
mchawre

Ответы:


130

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

Здесь вы реплицируете схему между (как правило) несколькими экземплярами или серверами, используя какую-то логику или идентификатор, чтобы узнать, какой экземпляр или сервер ищет данные. Идентификатор такого рода часто называют «ключом осколка».

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

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

Хорошо известный пример, который вы можете изучить, это то, как Instagram решал их разделение в первые дни (см. Ссылку ниже). Сначала они были разбиты на несколько серверов, используя Postgres для разделения данных с самого начала. Я полагаю, что на этих нескольких физических осколках было несколько тысяч логических осколков. Прочитайте их потрясающую рецензию 2012 года здесь: Instagram Engineering - Sharding & IDs

Смотрите также здесь: http://www.quora.com/Whats-the-difference-between-sharding-and-partition


16
Осколок - это тип HP . Это не HP.
NoChance

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

48

Похоже, это отвечает на оба ваших вопроса:

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

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

Источник: Wiki-Shard .

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

Источник: MongoDB .


41

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

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

https://en.wikipedia.org/wiki/Partition_(database)

Sharding - это тип разделения, например, горизонтальное разделение (HP)

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

https://en.wikipedia.org/wiki/Shard_(database_architecture)

Мне очень нравится ответ Тони Бако о Quora, где он заставляет вас думать с точки зрения схемы (а не столбцов и строк). Он утверждает, что ...

« Горизонтальное разделение », или сегментирование, - это копирование [копирование] схемы, а затем разделение данных на основе ключа сегмента.

« Вертикальное разделение » включает в себя разделение схемы (и данные идут вместе для поездки).

https://www.quora.com/Whats-the-difference-between-sharding-DB-tables-and-partitioning-them

В Oracle Partitioning Guide есть несколько хороших цифр. Я скопировал несколько выдержек из статьи.

https://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm

Когда разделить таблицу

Вот несколько советов о том, когда разбивать таблицу:

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

Обрезка перегородок

Сокращение разделов является самым простым, а также наиболее существенным средством повышения производительности с помощью разделения. Сокращение разделов часто может повысить производительность запросов на несколько порядков. Например, предположим, что приложение содержит таблицу «Заказы», ​​содержащую историю заказов, и что эта таблица была разбита по неделям. Запрос, запрашивающий заказы на одну неделю, будет обращаться только к одному разделу таблицы «Заказы». Если бы в таблице «Заказы» имелись данные за 2 года, то этот запрос получал бы доступ к одному разделу вместо 104. Этот запрос может потенциально выполняться в 100 раз быстрее просто из-за сокращения раздела.

Стратегии разделения

  • Ассортимент
  • гашиш
  • Список

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

И наконец, важно понимать, что базы данных чрезвычайно ресурсоемки:

  • ЦПУ
  • диск
  • I / O
  • объем памяти

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

В то время как другие стратегии будут использовать архитектуру «без разделения ресурсов», где сегменты будут размещаться в отдельных и отдельных вычислительных блоках (узлах), имеющих 100% ЦП, диска, ввода-вывода и памяти. Предоставление собственного набора преимуществ и сложностей.

https://en.wikipedia.org/wiki/Shared_nothing_architecture


«« Горизонтальное разделение »или сегментирование - это копирование [копирование] схемы, а затем разделение данных на основе ключа сегмента». - это тавтологическое.
8bitjunkie

Так что есть зеркало, и оно фрагментировано, отсюда и этимология.
Маккензм

5

Рассмотрим таблицу в базе данных с 1 миллионом строк и 100 столбцами. В разделе «Разделение» вы можете разделить таблицу на 2 или более таблиц, имеющих такие свойства, как:

  1. 0,4 миллиона строк (таблица1), 0,6 миллиона строк (таблица2)

  2. 1 миллион строк и 60 столбцов (таблица1) и 1 миллион строк и 40 столбцов (таблица2)

    Там может быть несколько таких случаев

Это общее разбиение

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


1

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


1

Говоря о разделении, не используйте термин «репликация» или «репликация». Репликация является другой концепцией и выходит за рамки этой страницы. Когда мы говорим о разделении, тогда лучшее слово - это разделение, а когда мы говорим о разделении, то лучшее слово - это распространение. В секциях (обычно и в общем понимании не всегда) строки таблицы большого набора данных делятся на две или более непересекающихся (не разделяющих ни одной строки) группы. Вы можете назвать каждую группу разделом. Эти группы или все разделы остаются под контролем одного экземпляра RDMB, и это все логично. Основой каждой группы может быть хеш или диапазон и т. Д. Если у вас есть данные за десять лет в таблице, вы можете хранить все данные за год в отдельном разделе, и это может быть достигнуто путем установки границ раздела на основе ненулевой столбец CREATE_DATE. После того, как вы запросите базу данных, затем, если вы укажете дату создания между 01-01-1999 и 31-12-2000, тогда будут затронуты только два раздела, и это будет последовательным. Я сделал подобное на БД для миллиарда + записей и sql время дошло до 50 миллисекунд с 30 секунд с использованием индексов и т. Д. Все. Sharding - это то, что вы размещаете каждый раздел на другом узле / машине. Теперь поиск внутри разделов / осколков может происходить параллельно.


0

Горизонтальный раздел при перемещении в другой экземпляр базы данных * становится осколком базы данных .

Экземпляр базы данных может находиться на той же машине или на другой машине.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.