Можно ли разделить более одного пути одновременно в SQL Server?

Question

Я рассматриваю различные способы разделения моих данных в SQL Server. Один из подходов, который я рассматриваю, состоит в том, чтобы разбить определенную огромную таблицу на 8 разделов, а затем в каждом из этих разделов разделить на другой столбец раздела. Возможно ли это даже в SQL Server, или я ограничен определением одного столбца разделов + функция + схема для таблицы?

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

Answer 1

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

ALTER TABLE MYTABLE ADD PartitionID AS ISNULL(Column1 * Column2,0) persisted

Я делаю это все время, очень просто.

Answer 2

DPV в наборе секционированных таблиц - это ваш единственный чистый способ для достижения этой цели, что-то вроде DPV для tblSales2007, tblSales2008, tblSales2009, и затем каждая из соответствующих таблиц продаж снова разделяется, но затем может другой ключ. В этом есть некоторые очень хорошие преимущества с точки зрения эксплуатационной устойчивости (одна многораздельная таблица, выходящая в автономный режим, не сбивает DPV - она ​​все еще может удовлетворить запросы для других временных шкал)

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

Вы должны думать о конкретных проблемах управления / DR для объемов данных, хотя, если объемы данных очень велики, и вы обращаетесь к ним с помощью механизма первичного чтения, вам следует изучить SQL 'Madison', который будет масштабироваться очень сильно. как в количестве строк, так и в общем размере данных. Но он действительно подходит только для хранилища данных с типом чтения 99,9% и не подходит для OLTP.

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

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