Я хочу обработать большой набор данных (> 1 млрд. Строк) в SQL Server 2008 R2. Я слышал, что если вы устанавливаете «сегментирование» или «горизонтальное разбиение», это позволяет быстрее обрабатывать большие наборы данных, так как таблицы разбиваются на несколько файлов.
Вы использовали шард или горизонтальное разбиение раньше? Если да, не могли бы вы предложить какие-либо модели, которые, по вашему опыту, достигают лучших результатов по сравнению с одной массивной таблицей?
Ответы:
Во-первых, обратите внимание, что 1 млрд. Строк можно эффективно обрабатывать с помощью многораздельной архитектуры на обычном аппаратном сервере. Архитектура с экзотическим общим доступом не понадобится для этого объема данных, однако вы, вероятно, получите значительные преимущества от разбиения таблиц.
Sharding - это что-то отличное от горизонтального разбиения, и подразумевает архитектуру «Ничего общего», которая не поддерживается большинством версий SQL Server 1
SQL Server может поддерживать горизонтальное разбиение, а архитектура общего диска будет достаточна для ~ 1 биллона строк.
В SQL Server вы создаете функцию разделения, которая выбирает раздел на основе значений или диапазонов значений в столбце таблицы, например
create partition function F_AccPrdPart (int)
as range left for values (
180001 -- Dummy value
,199012 ,199112 ,199212 ,199312, 199412 ,199512
,199612 ,199712 ,199812 ,199912 ,200012 ,200112
,200212 ,200312 ,200412 ,200512 ,200612 ,200712
,200812
,200901, 200902, 200903, 200904, 200905, 200906
,200907, 200908, 200909, 200910, 200911, 200912
,201001, 201002, 201003, 201004, 201005, 201006
,201007, 201008, 201009, 201010, 201011, 201012
,201101, 201102, 201103, 201104, 201105, 201106
,201107, 201108, 201109, 201110, 201111, 201112
,202012
,939999 -- Dummy value
)
goЗатем создайте одну или несколько файловых групп для выделения разделов. Для большого набора данных эти группы файлов могут быть настроены на разных физических томах. Обратите внимание, что хранилище с прямым подключением будет намного быстрее, чем SAN, почти во всех случаях. В приведенном ниже примере мы создали бы 6 файловых групп с именем PartVol1-PartVol6.
Одна или несколько схем секционирования могут быть созданы для выделения секций таблицы для файловых групп на основе значения функции секционирования, например
create partition S_AccPrdPart as partition F_AccPrdPart
TO ([PRIMARY]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2]
,[PRIMARY]
,[PRIMARY])
goЭта схема предназначена для разделения на отчетный период. Для этого также часто используются даты, хотя можно использовать любой ключ.
Вы можете создать таблицу на схеме разбиения, как если бы она была файловой группой, например
Create table FooTrans (
FooTransID int identity (1,1) not null
,AccPeriod int not null
,[...]
) on S_AccPrdPart (AccPeriod)
goОбратите внимание, что таблица создается на схеме секционирования вместо указанной группы файлов, и в этом разделе указывается столбец, который будет использоваться в качестве ключа секционирования. На основе ключа раздела строки в таблице будут выделены одной из файловых групп в схеме разделения.
Примечание. Практическое правило для разработки схемы разделения состоит в том, что для каждого раздела должно быть число строк в младших десятках миллионов, например, от 10 до 50 миллионов, в зависимости от ширины строк. Том диска, на котором расположен раздел, должен быть достаточно быстрым, чтобы выполнить сканирование хотя бы одного раздела за несколько секунд.
Системы разбиения, разбиения и совместного использования ничего
Здесь, кажется, немного терминологии для того, чтобы устранить неоднозначность в обсуждении этой темы.
Система «Ничего общего» - это параллельная система, в которой узлы не имеют общего хранилища SAN, но используют хранилище локально для узла. Классическим примером этого типа архитектуры является Teradata. Системы без разделения ресурсов хорошо масштабируются до очень больших наборов данных, поскольку у них нет узких мест центрального ввода-вывода. Пропускная способность ввода / вывода зависит от количества узлов в системе.
Система с общим диском - это система, в которой один или несколько серверов баз данных совместно используют одну подсистему хранения на диске. База данных может быть отдельным сервером с локальным хранилищем или подключенным к SAN, или кластером серверов, подключенным к общей SAN. Системы этого типа ограничены пропускной способностью, доступной из подсистемы хранения.
«Sharding» - это термин, используемый для описания разделения базы данных между несколькими физическими серверами в архитектуре без общего доступа. Различные платформы будут иметь большую или меньшую поддержку для закрытых баз данных. В кругах Teradata этот термин не используется, потому что Teradata представляет клиентам прозрачное единое системное изображение, даже если физическая архитектура не имеет общего типа.
Более старые версии SQL Server имеют ограниченную поддержку для разделения через распределенные многораздельные представления. Теперь Microsoft делает версию SQL Server 2008 R2, которая поддерживает архитектуру без общего доступа с одним образом системы, но эта версия доступна только OEM-производителям и может быть приобретена только в комплекте оборудования.
На 1 миллиард строк
Для 1 миллиарда строк (если только отдельные строки не очень широки) архитектура с общим доступом или с разделенными областями комфортно находится в сфере избыточного убийства. Этот тип тома может обрабатываться на одном сервере разумной спецификации, если у него достаточно быстрая дисковая подсистема.
Локальный диск прямого подключения на сегодняшний день является наиболее экономически эффективным с точки зрения цены за производительность. Один контроллер SAS RAID может занимать несколько массивов, и на сервере может быть установлено несколько контроллеров. В зависимости от конфигурации, современный массив SAS с 24-25 слотами может пропускать тысячи операций ввода-вывода в секунду или 1 ГБ + / с в потоковом режиме; сервер с несколькими шинами PCI-e и несколькими контроллерами теоретически может обрабатывать больше.
Тип производительности, необходимый для работы с базой данных на 1 миллиард строк, может быть достигнут довольно легко и дешево с помощью аппаратного серверного оборудования и хранилища с прямым подключением этого типа. Можно также использовать SAN, но вам может потребоваться несколько контроллеров SAN для получения эквивалентной производительности, и аппаратное обеспечение, вероятно, будет на порядок дороже.
В качестве общей рекомендации используйте хранилище с прямым подключением для приложений с высокими требованиями к вводу / выводу, если только вам не требуется действительно хорошее время безотказной работы. Ошибки управления конфигурацией и изменениями являются гораздо большим источником незапланированных простоев, чем отказ оборудования в современных операциях центра обработки данных.
Сети SAN могут предоставить вам более управляемую платформу хранения, если у вас большой портфель приложений, поскольку они предоставляют вам ряд средств централизованного управления хранением. Однако это дорого обходится, а получить высокую производительность инфраструктуры на основе SAN сложно и дорого.
1 Microsoft делает параллельную версию SQL Server, но она доступна только через OEM-каналы в комплекте с оборудованием. Версии, доступные с полки, не поддерживают эту возможность.