Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 вопросы насчет секционирования  [new]
vv40in
Member

Откуда:
Сообщений: 122
у нас создаются ежедневно(напр.) таблицы типа
CREATE TABLE [dbo].[T_XXX_{YYYY}_{MM}_{DD}_{HH}_{mm}_00](
	[Id] [int] IDENTITY(1,1) NOT NULL, -- кластерный, в файлгруппе data_filegroup
	[SysTime] [datetime], --индексируемое поле. Индекс в отдельной файлгруппе
	x1 [int] ,--индексируемое поле. Индекс в отдельной файлгруппе
	s1 [varchar](..) ,--индексируемое поле. Индекс в отдельной файлгруппе
	-- итд
) on data_filegroup
На одном из серверов(не буду говорить за другие) ней за день скапливается по ~40млн записей или 41Гб
И это не единственная таблица, записываемая на сервере в один день(скажем), ей соответствует еще 1 подобная-параллельная (в ней в неск.раз больше записей, но по объему <10Гб). Ну есть еще и другие... Тоже большие.
Создаются заново - это значит, что при создании новой таблицы начинают заново создаваться все индексы (ID тоже). Это то, что надо. А надо для того, чтобы индексы и соответствующие им данные(мне так думается) уместились в оп.памяти. Так быстрее работает. Проверяли.(нам главное-скорость записи)
Теперь мне поручено создавать ВСЕ файлгруппы по датам.
Здесь на форуме мне предложили использовать секционирование.
Я о нём почитал, но вот чего не понял:
ВОПРОСы: если я буду секционировать по дате (SysTime в моей таблице), то смогу ли я (и как это сделать) создавать индексы для остальных полей в том же стиле, что и ранее: т.е. чтобы новой секции дат соответствовала новая секция индексов (скажем по x1). А что делать с параллельной таблицей, которая ссылается на указанную ч-з её ID? За год это ~ 15*(10^9) - надо использовать bigint в обеих таблицах. (note:FK отсутствует. говорят, так быстрее для записи. главное-скорость записи!).
В общем - как проидексировать остальные полЯ (втч в параллельной таблице), чтоб индексы начинали строиться заново и оказавались в параллельных файлгруппах, чтоб их можно было бы также быстро и безболезненно удалить, как и группу с SysTime
23 сен 11, 17:23    [11328453]     Ответить | Цитировать Сообщить модератору
 Re: вопросы насчет секционирования  [new]
секционист
Guest
вы что-нибудь уже читали о секционировании?

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

про паралельно/перпендикулярные таблицы и автоматическое создание индексов не осилил, ни чё заказать не могу.
23 сен 11, 17:29    [11328508]     Ответить | Цитировать Сообщить модератору
 Re: вопросы насчет секционирования  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
vv40in, а у вас склад или вы всё таки делаете селекты их этих таблиц? А то нужно учесть переписывание запросов.

Если FK нет то чё вы паритесь?

Посмторите внимательно на команды CREATE TABLE и CREATE INDEX. Что в partition_scheme_name ( column_name ) вам непонятно?

Посмторите внимательно на команду ALTER PARTITION SCHEME? Что в NEXT USED вам непонятно?
23 сен 11, 17:49    [11328722]     Ответить | Цитировать Сообщить модератору
 Re: вопросы насчет секционирования  [new]
vv40in
Member

Откуда:
Сообщений: 122
Mnior,
а я могу использовать ту же схему для индексации int-поля (и других - varchar..) , что и date(который у меня systime)?
тогда при переходе systime в новый диапазон и , соответствнно, в новую файл-группу - остальные индексы также попадут в новые файл-группы?
23 сен 11, 18:49    [11329251]     Ответить | Цитировать Сообщить модератору
 Re: вопросы насчет секционирования  [new]
vv40in
Member

Откуда:
Сообщений: 122
Mnior
vv40in, а у вас склад или вы всё таки делаете селекты их этих таблиц?
у нас склад, из которого мы всё-таки делаем селекты :)
Mnior
А то нужно учесть переписывание запросов.
этого я не понимаю. объясните, пожалуйста.
Mnior
Если FK нет то чё вы паритесь?
тоже не понял.
Mnior
Посмторите внимательно на команды CREATE TABLE и CREATE INDEX. Что в partition_scheme_name ( column_name ) вам непонятно?
Посмторите внимательно на команду ALTER PARTITION SCHEME? Что в NEXT USED вам непонятно?
непонятно, что будет, если использовать ту же схему для индексов int-поля (и других - varchar..) , что и date (который у меня systime), для которого я и создам схему типа:
CREATE PARTITION FUNCTION SysTimeRangePS(datetime)
    AS RANGE LEFT FOR VALUES ('20110101 23:59:59.997', '20120101 23:59:59.997')
CREATE PARTITION SCHEME SysTimeRangePS AS PARTITION SysTimeRangePF TO( fg1, fg2, fg3 );
CREATE TABLE [dbo].[T_XXX](
	[Id] [int] IDENTITY(1,1) NOT NULL, -- кластерный индекс в SysTimeRangePS
	[SysTime] [datetime], --индексируемое поле. Индекс в отдельной файлгруппе
	x1 [int] ,--индексируемое поле. Индекс в отдельной файлгруппе
	s1 [varchar](..) ,--индексируемое поле. Индекс в отдельной файлгруппе
	-- итд
)ON SysTimeRangePS([SysTime])
ALTER TABLE [T_XXX] ADD  CONSTRAINT [PK_T_XXX] PRIMARY KEY CLUSTERED ([Id] ASC) ON SysTimeRangePS([SysTime])
CREATE NONCLUSTERED INDEX IX_T_XXX_x1 ON T_XXX (x1 ASC) ON SysTimeRangePS([SysTime])
-- итд
тогда при переходе systime в новый диапазон и, соответствнно, в новую файл-группу - остальные индексы (PK_T_XXX, X_T_XXX_x1) также попадут в новые файл-группы? НО (если это так) - это будут те же файлы, что и все остальные данные. Т.е. я не смогу изолировать каждый индекс в своей собственной файл-группе, параллельной текущей файл-группе SysTime (т.е. такой, которую я мог бы удалить одновременно с какой-н. файл-группой SysTime). Это - минус...
Но данные-то для индексов будут складываться в соответствии со схемой SysTimeRangePS.
И ещё одна основная идея в том, чтобы текущие индексы занимали минимум памяти. А если индексы нельзя поделить на независимые части параллельно systime - тогда что же это - будут использоваться полностью за весь период существования?!?!?!?
Ну, блин, это просто вредительство. Раньше за это расстреливали. Ну, если это так, конечно...
:)
В общем, похоже, что не подходит мне секционирование ...
23 сен 11, 20:18    [11329636]     Ответить | Цитировать Сообщить модератору
 Re: вопросы насчет секционирования  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31985
vv40in
Ну, блин, это просто вредительство. Раньше за это расстреливали.
Ага, без причины.
vv40in
А если индексы нельзя поделить на независимые части параллельно systime - тогда что же это - будут использоваться полностью за весь период существования?!?!?!?
Ну вы подумайте, как индексы могут разделяться по systime, если одно значение x1 относится (потенциально) ко всем systime???
vv40in
Т.е. я не смогу изолировать каждый индекс в своей собственной файл-группе, параллельной текущей файл-группе SysTime (т.е. такой, которую я мог бы удалить одновременно с какой-н. файл-группой SysTime).
Разумеется.
Если, конечно, вы не включите systime в индексы, при этом в запросе тоже должно быть, разумеется, включено поле systime
23 сен 11, 20:51    [11329740]     Ответить | Цитировать Сообщить модератору
 Re: вопросы насчет секционирования  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
vv40in
у нас склад, из которого мы всё-таки делаем селекты :)
Тогда подумайте, как тогда они должны работать, когда таблица стала одна. Как скуль определит в какой секции будут данные?! Правильно, в запросах должно явно присутствовать SysTime и не в виде какой-то переменной.
vv40in
если использовать ту же схему для индексов
при переходе в новый диапазон индексы также попадут в новые файл-группы, и это будут те же файлы, что и все остальные данные.
Т.е. я не смогу изолировать каждый индекс в своей собственной файл-группе, параллельной текущей файл-группе SysTime (т.е. такой, которую я мог бы удалить одновременно с какой-н. файл-группой SysTime).
Вы так это писали, словно старые диапазоны при этом в разной файловой группе.
А зачем вы вообще описали вариант который вам не нужен?
- Мне пжалуста горячий кофе и сливочное мороженное. И положите всё в этот термос.
- Эээ, зачем?
- Ну в термосе горячее же остаётся горячим, а холодное холодным.
Может использовать больше термосов?:
CREATE PARTITION SCHEME psSysTimeForData AS PARTITION SysTimeRangePF TO (fgData1, fgData2, fgData3);
CREATE PARTITION SCHEME psSysTimeForIdxA AS PARTITION SysTimeRangePF TO (fgIdxA1, fgIdxA2, fgIdxA3);
CREATE PARTITION SCHEME psSysTimeForIdxB AS PARTITION SysTimeRangePF TO (fgIdxB1, fgIdxB2, fgIdxB3);
Не путайте функцию секционирования, определяющую логику разделения данных, от схемы секционирования, определяющую место хранения.

alexeyvg
Если, конечно, вы не включите systime в индексы
Просто уточню:
BOL: http://msdn.microsoft.com/ru-ru/library/ms188783.aspx
Аргумент column_name может указывать на столбцы, не входящие в определение индекса.
Но естественно он там будет, явно или нет.

Конечно же, если для индексов будет использоваться другая функция секционирования (т.е. индексы не выровнены) то очевидно, что критерии отбора данных должны учитывать их все, чтоб не бегать по всем секциям. И возможность мгновенно откусывать/прикреплять данные вы естественно потеряете.

Да, создать уникальный ключ, не базирующийся на столбце секционирования нельзя. Иначе для проверки уникальности нужно просмотреть все секции, что чревато большими затратами. Вы же не можете гарантировать, что ID уникален во всех ваших таблицах вместе взятых.
vv40in
И ещё одна основная идея в том, чтобы текущие индексы занимали минимум памяти.
Чтобы поддерживать SWITH данных с не секционированными таблицами и т.к. секции это диапазоны (а не единицы), то ключ содержит и секционированный столбец. Саму секцию рассматривайте как CHECK ограничение.

Если занимаемое место является основным критерием, то вы можете остаться на логическом (классическом) секционировании.
Только не забывайте вешать на каждую таблицу CHECK CONSTRAINT типа ({From} <= [SysTime] AND [SysTime] < {To}). Ах, да точно, при этом SysTime опять таки должен явно присутствовать в запросах.
25 сен 11, 00:54    [11332620]     Ответить | Цитировать Сообщить модератору
 Re: вопросы насчет секционирования  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
vv40in
А что делать с параллельной таблицей, которая ссылается на указанную ч-з её ID? За год это ~ 15*(10^9) - надо использовать bigint в обеих таблицах?
Естественно нет, они то связываются по двум столбцам (ID, SysTime).
Но вы это сами поймёте когда напишите хотя бы один запрос по всем текущим таблам.

Может стоит уже задуматься что делать с этим "добром". Или просто хотите выстроить дом из BluRay болванок?!
Если запросы одноразовые или не за все периоды, то зачем все индексы вообще хранить, постоянно?
Да и сиквел иногда сам создаёт нехватающий временный индекс при запросах
Как бы вам так объяснить, цель определяет всё. Хранить - это не цель, ибо смысл, если потом нереально ничего достать.
Максимальная до крови скорость записи это тоже не цель. Эффективнее уж в /dev/null направить генератор бесполезных данных.
Некоторые вообще хранят данные не в СУБД.

vv40in
занимали минимум памяти
У вас уже не занимают. Имя/диапазон таблицы коррелирует с SysTime (DateTime). Сэкономить на спичках можно урезов до Time, или даже до SmallInt (мили-секунды).
25 сен 11, 01:45    [11332674]     Ответить | Цитировать Сообщить модератору
 Re: вопросы насчет секционирования  [new]
vv40in
Member

Откуда:
Сообщений: 122
Mnior, спасибо. Пока так: 1) Слишком много переделок. 2) Результат сомнителен. Тем более что sql-щиков у нас нет и не предвидится.
И: прежде чем ехидничать, надо внимательнее читать. Можно раза 2-3.
26 сен 11, 11:27    [11335233]     Ответить | Цитировать Сообщить модератору
 Re: вопросы насчет секционирования  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31985
vv40in
Тем более что sql-щиков у нас нет и не предвидится.
Вообще если у вас большие объёмы, большая нагрузка, то sql-щик нужен...
26 сен 11, 11:45    [11335422]     Ответить | Цитировать Сообщить модератору
 Re: вопросы насчет секционирования  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
vv40in
И: прежде чем ехидничать, надо внимательнее читать. Можно раза 2-3.
Одно дело внимательно, другое дело если написано криво.
И судя что вам кроме эмоций оветить нечем - значит правда. И это абсолютно нормально. Зачем приукрашивать реальность, без этого то лучше.
alexeyvg правильно говорит - специалист нужен.
vv40in
И: прежде чем ехидничать, надо внимательнее читать. Можно раза 2-3.
И: прежде чем обижаться, надо стоит прочитьтать раза 2-3 и выбрать из всех вариантов/предположений - нужный, а остальные проигнорировать.
26 сен 11, 15:49    [11336609]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить