Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Сегментированные представления
|
|||
|---|---|---|---|
|
#18+
Отзовитесь, кто работал с такими представлениями Есть пара вопросов по поводу принципов реализации в БД С уважением, Александр Soshnikov.A@jr.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2002, 13:36 |
|
||
|
Сегментированные представления
|
|||
|---|---|---|---|
|
#18+
Слушаем вопросы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2002, 15:38 |
|
||
|
Сегментированные представления
|
|||
|---|---|---|---|
|
#18+
Glory, спасибо, что отозвался Имеется стандартная система по учету товара и платежей: таблицы-документы, таблицы-регистры (собирают информацию о движении товара, задолженностях, оплатах, резервах и т.д.). Так вот эти самые таблицы-регистры растут достаточно быстро, операции за год раздувают их до вушительных размеров, что сокращает время проведения этих самых операций. Давно обсуждается идея разбиения этих таблиц на сегменты по временному признаку, тогда для возможности доступа к регистру в целом понадобится представление, которое при определенных условиях позволит оптимизировать доступ к отдельным сегментам. Тогда возникает вопрос с отчетами, большая часть которых реализована при помощи хранимых процедур. Если в этих хранимых процедурах для доступа к регистрам использовать представление, из которого отбирать записи, соответствующие значениям параметров, переданных в процедуру, тогда все преимущества этой технологии будут потеряны из-за того, что план выполнения уже будет помещен в кэш. Как может быть решена эта проблема? И вообще хотелось бы услышать мнение насчет эффективности этой технологии, в каких случаях следует применить, в каких нет? Александр ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2002, 13:08 |
|
||
|
Сегментированные представления
|
|||
|---|---|---|---|
|
#18+
Со следующими статьями знакомы ? http://www.osp.ru/win2000/sql/2001/01/525.htm http://www.osp.ru/win2000/sql/2001/02/630.htm http://www.iso.ru/cgi-bin/main/journal.cgi?do_what=details&id=91 Если в этих хранимых процедурах для доступа к регистрам использовать представление, из которого отбирать записи, соответствующие значениям параметров, переданных в процедуру, тогда все преимущества этой технологии будут потеряны из-за того, что план выполнения уже будет помещен в кэш Что-то я не понял вашего утверждения. Использование сегментированных представлений и подразумевает то, что сервер на основе условий в конкретном запросе должен фактически осуществить чтение только тех таблиц, которые непосредственно содержат необходимые для обработки записи, т.е. составить план выполнения. Причем здесь план предыдущего выполнения с другими параметрами ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2002, 15:07 |
|
||
|
Сегментированные представления
|
|||
|---|---|---|---|
|
#18+
IMHO, не там Вы, Alexander, увидели проблему. Обычно когда приводят примеры использования сегментированных представлений, используют учетные задачи с выборкой данных из множества учетных периодов. Однако, учетные периоды на месте-то не стоят. Возникают новые сегменты информации, и необходим механизм их автоматического добавления во все сегментированные представления. Такой механизм отсутствует. Вот в этом и есть главная проблема. Для того, чтобы решить сию проблему, нужно накропать самому некий динамический периодически выполняемый скрипт (например, с помощью JOB), который будет выдавать Alter View (или DROP VIEW / CREATE VIEW), к примеру, ежемесячно. А эта задача не является тривиальной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2002, 17:59 |
|
||
|
Сегментированные представления
|
|||
|---|---|---|---|
|
#18+
> Однако, учетные периоды на месте-то не стоят. Возникают новые сегменты информации, и > необходим механизм их автоматического добавления во все сегментированные представления. > Такой механизм отсутствует. Вот в этом и есть главная проблема. > Для того, чтобы решить сию проблему, нужно накропать самому некий динамический > периодически выполняемый скрипт (например, с помощью JOB), который будет выдавать Alter > View (или DROP VIEW / CREATE VIEW), к примеру, ежемесячно. А эта задача не является > тривиальной. Не совсем понял проблему. Если Вы позаботились о том, чтобы разбить таблицу на n-ое количество сегментов, то скорее всего и представление объединит все эти n сегментов. Тут, конечно, речь не идет о динамическом добавлении сегментов. Проблема несколько в другом. Есть некоторое количество сегментов: segment1, ... segmentN (используется временной критерий разбиения, допутим, месяц), есть также представление, объединяющее все эти сегменты. План выполнения запроса SELECT * FROM view WHERE month = 1 содержит сканирование одной таблицы segment1 declare @month int set @month = 1 SELECT * FROM view WHERE month = @month в этом случае план включает обращение ко всем N таблицам ... а именно так устроено все хранимые процедуры для отчетов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2002, 06:38 |
|
||
|
Сегментированные представления
|
|||
|---|---|---|---|
|
#18+
в этом случае план включает обращение ко всем N таблицам Пожалуйста поконкретнее, что за "обращение" ? У меня, например, сегмент вообще состоит из связки двух таблиц и представление имеет вид SELECT * FROM Mytable11 INNER JOIN Mytable21 ... UNION ALL SELECT * FROM Mytable12 INNER JOIN Mytable22 ... ... при этом информация о периоде находится во второй таблице Так вот в плане выполнения запроса к такому представлению действительно присутсвуют все таблицы, но для каждой пары имеется Hash match/Inner Join с заданным в WHERE условием фильтрации. В результате при жестко заданном периоде(я использую BETWEEN @period_begin AND @period_end) отбирается только заданные периоды. Если в фильтре имеются еще дополнительные условия, то в Hash match/Inner Join используются и они. Это конечно не сканирование только одной таблицы, но в итоге запрос для периода в 1 месяц к представлению из 3-х периодов(35 000 000 записей) и из 24-х периодов(240 000 000 записей) отличался в пределах 30-40%(25 мин против 35 мин), что на таких объемах IMHO довольно неплохо(2xPIII-800, RAM 2Gb, данные на RAID-5 UWSCSI, tempdb на RAID-1 UWSCSI). А вот запросы без фильтра были просто убийственны, т.к. происходило построение общей промежуточной таблицы Проанализируйте внимательно ваш план выполнения и то, в каких именно операциях участвует каждый сегмент и сколько записей выдает каждает операция на своем выходе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2002, 07:44 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=32022588&tid=1823930]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
25ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 219ms |
| total: | 323ms |
| 0 / 0 |
