Взялся за разбиение индексов по разделам, и возникло несколько вопросов как всё это в итоге будет работать:
1) Если разбить индекс (например по дате, входящей в ключ), может ли план запроса измениться настолько, что индекс перестанет использоваться либо станет неэффективным с т.з. БД?
2) Понятно, что разбивка наиболее эффективна, когда происходит по первому полю ключа индекса. Если это поле не первое, либо вообще не включено в индекс, то будут просматриваться индексы всех разделов. Влияет ли на производительность количество разделов, если они находятся на одном хранилище (в одной или нескольких файловых группах)? Имеет ли смысл уменьшать количество разделов, т.е. будет ли это влияние сколь-нибудь значимым (сервер на 4-х Ксеонах, памяти >0.5ТБ) или им можно пренебречь?
3) Цель разбивки — вывести архивные данные в отдельные файлы и сжать их, уменьшив объём файла содержащего оперативные данные.
4) С точки зрения архитектуры всего этого: имеет ли смысл делать отдельные схемы разбиения (partition scheme и/или partition function) для разных индексов, даже если они будут разбиваться одинаковым способом?
Ну и на закуску:
Есть 2 таблицы: документ и его строки, дата указана в документе, строки ссылаются на id документа. Есть ли возможность разделить обе таблицы по дате документа и стоит ли вообще смотреть в эту сторону (с учётом того что запрос строк происходит по id документа)? Есть ли смысл разбивать таблицы по каким-либо другим критериям (запись по итогу будет идти во все разделы)?
Здравствуйте, Somescout, Вы писали:
S>Взялся за разбиение индексов по разделам, и возникло несколько вопросов как всё это в итоге будет работать:
Собрался тебе отвечать, написал простынку и понял, что единственный верный ответ — это любимый ответ DBA.
It depends...
В общем, не зная твоей БД и тому, каким нагрузкам она подвергается сказать что-то точно нельзя.
На каждый ответ — может повлиять, а может и не повлиять или влияния ты даже не заметишь.
Единственное — я бы всё-таки на каждую таблицу завел свою функцию и схему. Разделяемых таблиц не должно быть
много, поэтому это не очень сильно усложнит администрирование, а по опыту могу сказать, что то, что предполагается
изначально универсальным/одинаковым очень быстро приобретает индивидуальность.
S>Есть 2 таблицы: документ и его строки, дата указана в документе, строки ссылаются на id документа. Есть ли возможность разделить обе таблицы по дате документа и стоит ли вообще смотреть в эту сторону (с учётом того что запрос строк происходит по id документа)?
Только если ввести дату еще и в строки.
А насчет того, имеет ли смысл смотреть в эту сторону... Ну ты ответ уже знаешь, да?
S>Есть ли смысл разбивать таблицы по каким-либо другим критериям (запись по итогу будет идти во все разделы)?
Очевидно, что заявленная цель (уменьшить стоимость хранения именно архивных данных) достигнута не будет.
Хотя не так уж мало случаев, когда сжатие данных улучшало производительность системы.
А с какой целью ты хочешь уменьшить объем файла с оперативными данными?
S>1) Если разбить индекс (например по дате, входящей в ключ), может ли план запроса измениться настолько, что индекс перестанет использоваться либо станет неэффективным с т.з. БД?
Может
S>2) Понятно, что разбивка наиболее эффективна, когда происходит по первому полю ключа индекса.
Если это поле не первое, либо вообще не включено в индекс, то будут просматриваться индексы всех разделов.
Нет, могут быть просмотрены только нужные разделы. Например, если в запросе фильтр по диапазону дней (3 дня скажем), то можно
просмотреть только 3 партиции.
S>Влияет ли на производительность количество разделов, если они находятся на одном хранилище (в одной или нескольких файловых группах)? Имеет ли смысл уменьшать количество разделов, т.е. будет ли это влияние сколь-нибудь значимым (сервер на 4-х Ксеонах, памяти >0.5ТБ) или им можно пренебречь?
Количество разделов следует увеличивать, чем их больше, тем более выгодно их иметь.
S>3) Цель разбивки — вывести архивные данные в отдельные файлы и сжать разделы, уменьшив объём файла содержащего оперативные данные.
Сомнительная цель. То же можно сделать индексами.
S>4) С точки зрения архитектуры всего этого: имеет ли смысл делать отдельные схемы разбиения (partition scheme и/или partition function) для разных индексов, даже если они будут разбиваться одинаковым способом?
Здравствуйте, MasterZiv, Вы писали:
S>>3) Цель разбивки — вывести архивные данные в отдельные файлы и сжать разделы, уменьшив объём файла содержащего оперативные данные. MZ>Сомнительная цель. То же можно сделать индексами.
Может я что-то не так понял. Что именно ты имеешь в виду?
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, MasterZiv, Вы писали:
S>>>3) Цель разбивки — вывести архивные данные в отдельные файлы и сжать разделы, уменьшив объём файла содержащего оперативные данные. MZ>>Сомнительная цель. То же можно сделать индексами. _AB>Может я что-то не так понял. Что именно ты имеешь в виду?
Полагаю имеются в виду фильтрованные индексы. К сожалению sql server не умеет их склеивать (т.е. использовать два смежных индекса (x<a) и (x>=a)).
Здравствуйте, _ABC_, Вы писали:
_AB>It depends...
_AB>В общем, не зная твоей БД и тому, каким нагрузкам она подвергается сказать что-то точно нельзя. _AB>На каждый ответ — может повлиять, а может и не повлиять или влияния ты даже не заметишь.
Конкретно эта — 3ТБ 1С база со склонностью к росту. Т.е. много таблиц со схожей структурой.
_AB>Единственное — я бы всё-таки на каждую таблицу завел свою функцию и схему. Разделяемых таблиц не должно быть _AB>много, поэтому это не очень сильно усложнит администрирование, а по опыту могу сказать, что то, что предполагается _AB>изначально универсальным/одинаковым очень быстро приобретает индивидуальность.
Ну вообще-то их прилично (хотя опять-же, смотря что считать "много") и разбиты они будут по одной схеме (речь о логической схеме, а не объекте базы) на активные данные (за последние 2-3 месяца), которые читаются и пишутся, и архив за предыдущие года (только чтение). Архив будет сжат. С моей точки зрения это должно упростить и ускорить обслуживание базы (дефрагментацию индексов, бэкап и т.д.), и возможно позволит хранилке лучше разместить горячие данные на ssd-кэше.
S>>Есть 2 таблицы: документ и его строки, дата указана в документе, строки ссылаются на id документа. Есть ли возможность разделить обе таблицы по дате документа и стоит ли вообще смотреть в эту сторону (с учётом того что запрос строк происходит по id документа)? _AB>Только если ввести дату еще и в строки. _AB>А насчет того, имеет ли смысл смотреть в эту сторону... Ну ты ответ уже знаешь, да?
Ну, да... в принципе... идеально было бы ремап ключей сделать, заменив псевдослучайный guid на year-month-guid... мечты, мечты...
S>>Есть ли смысл разбивать таблицы по каким-либо другим критериям (запись по итогу будет идти во все разделы)? _AB>Очевидно, что заявленная цель (уменьшить стоимость хранения именно архивных данных) достигнута не будет. _AB>Хотя не так уж мало случаев, когда сжатие данных улучшало производительность системы.
А вот тут я в раздумьях — может ли повыситься скорость работы с таблицей, при уменьшении размера её индекса? т.е. если, к примеру, поделить таблицу по GUID PK на 256 частей, и, соответственно, уменьшить индексы в ~256 раз, ускорит ли это обновление индексов (а возможно и поиск по ним — первое поле ключа индекса — PK)?
_AB>А с какой целью ты хочешь уменьшить объем файла с оперативными данными?
Выше ответил.
Здравствуйте, MasterZiv, Вы писали:
MZ>Может
Надо будет потестить.
S>>2) Понятно, что разбивка наиболее эффективна, когда происходит по первому полю ключа индекса. S>>Если это поле не первое, либо вообще не включено в индекс, то будут просматриваться индексы всех разделов. MZ>Нет, могут быть просмотрены только нужные разделы. Например, если в запросе фильтр по диапазону дней (3 дня скажем), то можно MZ>просмотреть только 3 партиции.
Не совсем понял. Допустим индекс создан по (guid), я разбиваю его по (date) и она неявно добавляется в ключ (date, guid). Чисто технически искомый guid может оказаться в любом разделе, если дата поиска не указана явно.
S>>Влияет ли на производительность количество разделов, если они находятся на одном хранилище (в одной или нескольких файловых группах)? Имеет ли смысл уменьшать количество разделов, т.е. будет ли это влияние сколь-нибудь значимым (сервер на 4-х Ксеонах, памяти >0.5ТБ) или им можно пренебречь? MZ>Количество разделов следует увеличивать, чем их больше, тем более выгодно их иметь.
Можешь пояснить?
S>>3) Цель разбивки — вывести архивные данные в отдельные файлы и сжать разделы, уменьшив объём файла содержащего оперативные данные. MZ>Сомнительная цель. То же можно сделать индексами.
Можешь пояснить?
S>>4) С точки зрения архитектуры всего этого: имеет ли смысл делать отдельные схемы разбиения (partition scheme и/или partition function) для разных индексов, даже если они будут разбиваться одинаковым способом? MZ>не понял.
т.е. стоит ли для каждой таблицы создавать свою partition function/scheme или использовать общую? (таблицы 1С и достаточно однотипны).
Здравствуйте, Somescout, Вы писали:
S> Конкретно эта — 3ТБ 1С база со склонностью к росту. Т.е. много таблиц со схожей структурой.
С базами 1С нужно быть особенно осторожным, поскольку они не под твоим прямым контролем. Если стоит задача повышения производительности, то прибегать к таким средствам, как секционирование, стоит только после того, как средства, предоставляемые 1С, уже опробованы и исчерпаны.
Я бы посоветовал начать с профилирования нагрузки и выявления проблемных мест, то есть конкретных запросов. Или это уже сделано?
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Somescout, Вы писали:
S>> Конкретно эта — 3ТБ 1С база со склонностью к росту. Т.е. много таблиц со схожей структурой.
W>С базами 1С нужно быть особенно осторожным, поскольку они не под твоим прямым контролем. Если стоит задача повышения производительности, то прибегать к таким средствам, как секционирование, стоит только после того, как средства, предоставляемые 1С, уже опробованы и исчерпаны.
Средства, предоставляемые 1С это что? Переписывание запросов в принципе возможно (а может быть и необходимо, потому что очень часто используется repeatable read и serialized режимы изоляции), но это дело весьма неближнего будущего (их отдел и так загружен).
W>Я бы посоветовал начать с профилирования нагрузки и выявления проблемных мест, то есть конкретных запросов. Или это уже сделано?
В процессе. Проблемные запросы есть, но они достаточно редки. В большинстве случаев проблемы либо с IO, либо с блокировками. Секционирование рассматривается как возможность, поэтому я и пытаюсь выявить возможные проблемы.
В чём могут быть проблемы с секционированием таблиц 1С, кроме того что их могут неожиданно перестроить?
BTW. Database Tuning Advisor к сожалению стабильно падает на анализе логов, независимо от версии и окружения, может посоветуете альтернативу?
Здравствуйте, Somescout, Вы писали:
S> Средства, предоставляемые 1С это что? Переписывание запросов в принципе возможно (а может быть и необходимо, потому что очень часто используется repeatable read и serialized режимы изоляции), но это дело весьма неближнего будущего (их отдел и так загружен).
Не только. Оптимизация структуры метаданных, индексирование, управляемые блокировки, агрегаты для регистров и другие. Общий смысл моего совета в том, что методы, учитывающие специфику приложения, скорее всего дадут больший эффект, и создадут меньше проблем в процессе, чем слепой тюнинг самой базы.
А вот что обойдется дешевле (с учетом поддержки) — уже другой вопрос. Может оказаться, что дешевле всего проапгрейдить железо.
S> W>Я бы посоветовал начать с профилирования нагрузки и выявления проблемных мест, то есть конкретных запросов. Или это уже сделано?
S> В процессе. Проблемные запросы есть, но они достаточно редки. В большинстве случаев проблемы либо с IO, либо с блокировками. Секционирование рассматривается как возможность, поэтому я и пытаюсь выявить возможные проблемы.
Странно, а IO создается чем, не запросами? Проблемы с блокировками в 90% случаев решаются на прикладном уровне.
S> В чём могут быть проблемы с секционированием таблиц 1С, кроме того что их могут неожиданно перестроить?
Это основная проблема. А индексы, кстати, перестраиваются гораздо чаше, чем таблицы.
Еще может быть, что 1С раз в год захочет выполнить что-нибудь заковыристое, что не поддерживается для секционированных таблиц.
Какая у вас версия платформы и SQL сервера? Ну и конфигурация до кучи.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, _ABC_, Вы писали:
_AB>>It depends...
_AB>>В общем, не зная твоей БД и тому, каким нагрузкам она подвергается сказать что-то точно нельзя. _AB>>На каждый ответ — может повлиять, а может и не повлиять или влияния ты даже не заметишь. S>Конкретно эта — 3ТБ 1С база со склонностью к росту. Т.е. много таблиц со схожей структурой.
Во что упирается производительность? В диски? Тогда покупайте SSD. По цене выйдет примерно столько же, сколько игрища с базой, а эффект даст многократный.
Здравствуйте, Somescout, Вы писали:
S>Средства, предоставляемые 1С это что? Переписывание запросов в принципе возможно (а может быть и необходимо, потому что очень часто используется repeatable read и serialized режимы изоляции), но это дело весьма неближнего будущего (их отдел и так загружен).
Наймите подрядчика, серьезно. Скорее всего тормозит пара-тройка очень долгих запросов, их можно будет поправить и все.
Здравствуйте, wildwind, Вы писали:
W>Не только. Оптимизация структуры метаданных, индексирование, управляемые блокировки, агрегаты для регистров и другие. Общий смысл моего совета в том, что методы, учитывающие специфику приложения, скорее всего дадут больший эффект, и создадут меньше проблем в процессе, чем слепой тюнинг самой базы.
Не согласен. Если структура хранения данных неоптимальна, то хоть заоптимизируйся на уровне приложения — значимого эффекта не будет. Вопрос был, впрочем, вполне конкретный.
S>> В процессе. Проблемные запросы есть, но они достаточно редки. В большинстве случаев проблемы либо с IO, либо с блокировками. Секционирование рассматривается как возможность, поэтому я и пытаюсь выявить возможные проблемы. W>Странно, а IO создается чем, не запросами? Проблемы с блокировками в 90% случаев решаются на прикладном уровне.
"Проблемные запросы" достаточно редки, а вот обычных запросов много: эта база агрегирует данные из ~100 баз.
W>Это основная проблема. А индексы, кстати, перестраиваются гораздо чаше, чем таблицы.
Как перестроятся, так и пересоздадутся job'ом. Но кстати, да, можно вынести все таблицы в отдельную файловую группу, чтобы в PRIMARY появлялись только новые индексы.
W>Еще может быть, что 1С раз в год захочет выполнить что-нибудь заковыристое, что не поддерживается для секционированных таблиц.
Например?
W>Какая у вас версия платформы и SQL сервера?
2008R2, 8.2.19.
Здравствуйте, Somescout, Вы писали:
S> "Проблемные запросы" достаточно редки, а вот обычных запросов много: эта база агрегирует данные из ~100 баз.
О, это уже серьезно. Типовая Консолидация или самописная? Впрочем, в любом случае "лечить по фотографии" не стану. Посоветую прислушаться к gandjustas и пригласить специалиста.
S> W>Еще может быть, что 1С раз в год захочет выполнить что-нибудь заковыристое, что не поддерживается для секционированных таблиц. S> Например?
Не знаю. Я не сталкивался, но теоретически возможно.
S> W>Какая у вас версия платформы и SQL сервера? S> 2008R2, 8.2.19.
Будь у вас OLTP нагрузка, можно было бы попробовать уменьшить блокировки, включив SNAPSHOT ISOLATION, но в консолидационной базе смысла нет.
