ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Производительность сортировки.
57 сообщений из 57, показаны все 3 страниц
  все  
Производительность сортировки.
    #35733674
Hisbreht Victor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hisbreht Victor
Гость
Есть такая загвоздочка.
Есть некий класс, содержащий кучу полей и среди них поля Flag и Field.
На оба поля созданы Bitmap индексы.
Есть запрос вида
SELECT Id FROM Class WHERE Flag=2 OR Flag=3
Первая запись получается почти мгновенно.
Если же его задать с правилом ORDER BY Field, то при большом количестве записей этого класса с большим разнообразием значений поля Field время получения первой записи иногда больше на порядки.
SELECT Id FROM Class WHERE Flag=2 OR Flag=3 ORDER BY Field,

Как можно это дело ускорить?
Множить число индексов на всевозможные сочетания полей, участвующих в сортировке и фильтрации представляется нецелесообразным, поскольку это неизбежно ухудшит время вставки записи.
Или в данном случае тоже следует переходить на COS?
Для задач подсчета количества записей разного рода это уже позволило получить очень хороший выигрыш в производительности по сравнению с обычным SQL.
...
Рейтинг: 0 / 0
24.12.2008, 22:32
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35733872
logist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
logist
Участник
Тут конечно надо посмотреть планы запросов, однако почти наверняка окажется, что
в первом случае перебор идет по исходной глобали, а во втором случае - делается
временная глобаль с верхним индексом Field. Можно ли это оптимизировать как-то -
знают наверняка только разработчики SQL движка в Интерсистемсе. Попробуй сделать
по Field не-bitmap индекс. А вообще лучше это в WRC спрашивать.

На COS, наверное, можно написать более производительный алгоритм, побитово
складывающий два индекса по flag а потом последовательно перемножающий их со
всеми индексами field. Опять таки, я не уверен, что это уже не делается SQL
движком - надо смотреть план запроса.

=Сергей Шутов (logist)
ООО Димас, Хабаровск
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
25.12.2008, 04:36
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35733985
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
Hisbreht Victor
Есть запрос вида
Код: plaintext
SELECT Id FROM Class WHERE Flag= 2  OR Flag= 3


У меня "шкурный" интерес... А запрос

Код: plaintext
SELECT Id FROM Class WHERE Flag IN ( 2 ,  3 )

как будет выполняться? Быстрее или медленнее? Что будет с оценкой запроса?
...
Рейтинг: 0 / 0
25.12.2008, 09:02
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35734065
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
servit
Участник
Caché 2008.2.526
Сгенерировал 1000000 записей со случайными значениями Flag и Field.
Код: plaintext
1.
2.
Index iFlag On Flag [ Type = bitmap ];
Index iField On Field;
Сделал тюнинг таблицы.
Запросы вида
Код: plaintext
1.
2.
select ID from Class where Flag in ( 2 , 3 ) order by Field
select ID from Class where Flag= 2  or Flag= 3  order by Field
дали одинаковый план и соответственно стоимость.
На моих данных:
Код: plaintext
Относительная стоимость = 1857.9 Количество строк: 27    Быстродействие: 0.002 Секунд  292 глобальных ссылок
...
Рейтинг: 0 / 0
25.12.2008, 09:37
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35734429
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
servitдали одинаковый план и соответственно стоимость.
Вот и верь после этого в оптимизацию запросов!
...
Рейтинг: 0 / 0
25.12.2008, 11:44
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35734759
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Чем же тут не угодил оптимизатор? Условия в запросах и вправду эквивалентны: IN по определению - лишь краткая форма OR, не более.
...
Рейтинг: 0 / 0
25.12.2008, 13:32
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35734806
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
Alexey MaslovIN по определению - лишь краткая форма OR, не более.
Как раз всегда утверждалось другое. Типа более оптимален и все такое...
...
Рейтинг: 0 / 0
25.12.2008, 13:48
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35734888
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Кем утверждалось и что именно? IN, как известно, может выступать как предикат в условиях равенства (equality comparisons) и в подзапросах (subquery comparisons). Наш случай - первый. По определению:Док-яThe IN predicate can serve as shorthand for the use of multiple equality comparisons linked together with the OR operator.Т.е. имеем
Код: plaintext
x IN ( 2 , 3 ) <=> x= 2  OR x= 3
IN в данном случае - лишь краткая форма OR (shorthand). Что здесь можно соптимизировать? в COS, кроме ! и ||, других операторов для OR в общем случае нет.
Более сложный случай - второй (Subquery Comparison), и насколько помню, как раз с этим были проблемы в Cache 5.0 и произошли серьезные подвижки в последних версиях.
...
Рейтинг: 0 / 0
25.12.2008, 14:07
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35734925
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
Alexey MaslovКем утверждалось и что именно?
Кем-то из ИС... Цитат и ФИО привести уже не могу...
Alexey MaslovЧто здесь можно соптимизировать?
Панятия не имею... Вот и прошу время от времени потестиль тех, у кого большое количество даных, индексов и т.п...
Пока разницы не наблюдалось.
...
Рейтинг: 0 / 0
25.12.2008, 14:15
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35735134
ceshka-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ceshka-
Участник
krvsa
Вот и прошу время от времени потестиль тех, у кого большое количество даных, индексов и т.п...
Пока разницы не наблюдалось.
так было выведено, что $O(,-1) рабоатет медленне, чем просто $O() ?
...
Рейтинг: 0 / 0
25.12.2008, 15:09
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35735157
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
Про разницу с ордером я не знал...
----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT
...
Рейтинг: 0 / 0
25.12.2008, 15:16
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35735409
ceshka-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ceshka-
Участник
krvsaПро разницу с ордером я не знал...
----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT
я джо некоторого времени тоже))))
...
Рейтинг: 0 / 0
25.12.2008, 16:18
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35736349
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
ceshka-krvsa
Вот и прошу время от времени потестиль тех, у кого большое количество даных, индексов и т.п...
Пока разницы не наблюдалось.
так было выведено, что $O(,-1) рабоатет медленне, чем просто $O() ?
А что, появилась левосторонняя ссылка в блоках? Вроде не замечал еще.
...
Рейтинг: 0 / 0
26.12.2008, 08:26
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35736929
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Сергей, не удивляйтесь: для некоторых форумчан Cache - черный ящик, им возможно и не интересно знать "что под капотом" (но надеюсь, что таких меньшинство, иначе здесь станет совсем грустно :). Отчасти в этом виновата и ИнтерСистемз: интерес к "внутренностям" не приветствуется, даже по каналам WRC нелегко что-то разузнать. Последнее описание формата БД, которым я располагаю, 10 летней давности, и, конечно, это 2К-формат БД. Некое понимание устройства 8К-БД приходит после ремонта оных с помощью ^RECOVER, но не все опции этой утилиты понятны. ИМХО, не хватает книги "Inside Cache" или "Cache Internals".
...
Рейтинг: 0 / 0
26.12.2008, 12:52
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35736982
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Имел в виду, конечно, ^REPAIR :)
...
Рейтинг: 0 / 0
26.12.2008, 13:14
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35736989
Ahil79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ahil79
Гость
Во истину чтото скрытое но ценное. Вот толи MSM была
...
Рейтинг: 0 / 0
26.12.2008, 13:15
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35737048
ceshka-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ceshka-
Участник
Sergei Obrastsov
А что, появилась левосторонняя ссылка в блоках? Вроде не замечал еще.
тут имеется в виду, что идти вперёд естественно, и структура блока заточена только под это?
...
Рейтинг: 0 / 0
26.12.2008, 13:39
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35737269
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Если в двух словах, то да.
1) В блоках используется сжатие ключей, т.е. хранится изменение полной индексной ссылки по отношению к предыдущему узлу.
2) Хранится Right Link - ссылка на следующий блок на том же уровне.
...
Рейтинг: 0 / 0
26.12.2008, 15:01
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35737373
ceshka-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ceshka-
Участник
Alexey MaslovЕсли в двух словах, то да.
1) В блоках используется сжатие ключей, т.е. хранится изменение полной индексной ссылки по отношению к предыдущему узлу.
2) Хранится Right Link - ссылка на следующий блок на том же уровне.
это многое объясняет)))
а откуда информация? мне вот давно интересно как и что происходит на системном уровне, например механизм транзакций, механизм создания журнала, что происходит при появлении новой записи между двумя соседними...
или это всё закрытая информация?
...
Рейтинг: 0 / 0
26.12.2008, 15:40
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35737442
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Информация почерпнута из очень старой док-ии (10 лет назад она была еще бумажной :) и еще из столь же старого учебного пособия ИнтерСистемз, в переводе которого я участвовал. Если ISC не возражает, я могу вырезать главу про структуру БД (2К-блоки!) и выложить сюда. Но это, наверное, уже после праздников.
Кроме того, некоторое знакомство с алгоритмами работы B-дерева помогает найти ответы на многие вопросы :) Здесь источников - море.
...
Рейтинг: 0 / 0
26.12.2008, 16:03
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35737482
ceshka-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ceshka-
Участник
Alexey MaslovИнформация почерпнута из очень старой док-ии (10 лет назад она была еще бумажной :) и еще из столь же старого учебного пособия ИнтерСистемз, в переводе которого я участвовал. Если ISC не возражает, я могу вырезать главу про структуру БД (2К-блоки!) и выложить сюда. Но это, наверное, уже после праздников.
Кроме того, некоторое знакомство с алгоритмами работы B-дерева помогает найти ответы на многие вопросы :) Здесь источников - море.
да, конечно, лишним не будет, выкладывайте, с радостью почитаю
ничо, если я еще спрошу?
в оракле принцип работы с В-деревьями такой же, как в М-системах?
...
Рейтинг: 0 / 0
26.12.2008, 16:16
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35739016
=Dimon=
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
=Dimon=
Участник
Alexey MaslovИнформация почерпнута из очень старой док-ии (10 лет назад она была еще бумажной :) и еще из столь же старого учебного пособия ИнтерСистемз, в переводе которого я участвовал. Если ISC не возражает, я могу вырезать главу про структуру БД (2К-блоки!) и выложить сюда. Но это, наверное, уже после праздников.
Кроме того, некоторое знакомство с алгоритмами работы B-дерева помогает найти ответы на многие вопросы :) Здесь источников - море.
Алексей, может выложите на writeimagejournal, там и База Знаний имеется.
...
Рейтинг: 0 / 0
29.12.2008, 03:45
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35739462
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
cheshkaв оракле принцип работы с В-деревьями такой же, как в М-системах?Не знаток Оракла, но подозреваю, что нет. В традиционных РСУБД В-деревьями могут быть индексы, а данные хранятся в таблицах. Cache (и М-системы), напротив, хранят данные на нижнем уровне B-дерева. Чтобы подчернуть этот факт, его обычно называют "B*-дерево". Это по классике :) я многого не знаю про Оракл, и он, возможно, тоже умеет нечто подобное.
...
Рейтинг: 0 / 0
29.12.2008, 12:19
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35739519
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Dimonможет выложите на writeimagejournalУвы, Copyright мне этого не позволяет :( Выходные данные документа такие:
INTERSYSTEMS' EDUCATIONAL SERVICES. Руководство для студентов по системному и сетевому администрированию Caché. InterSystems Corporation Copyright, 1998, C52898
Глава, которую имел в виду, называется "Module 5. Основные понятия".
Может быть, я что-то свое про это напишу, когда будет время (в Новом году :).
...
Рейтинг: 0 / 0
29.12.2008, 12:36
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35739553
ceshka-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ceshka-
Участник
Alexey Maslovcheshkaв оракле принцип работы с В-деревьями такой же, как в М-системах?Не знаток Оракла, но подозреваю, что нет. В традиционных РСУБД В-деревьями могут быть индексы, а данные хранятся в таблицах. Cache (и М-системы), напротив, хранят данные на нижнем уровне B-дерева. Чтобы подчернуть этот факт, его обычно называют "B*-дерево". Это по классике :) я многого не знаю про Оракл, и он, возможно, тоже умеет нечто подобное.
спасибо
...
Рейтинг: 0 / 0
29.12.2008, 12:51
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35739604
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
Производительность обхода одного уровня индекса зависит от структуры данных. Если индекс с ключами фиксированной длины и с фиксированным значением (что часто используется в sql-based субд, там значение - это номер записи в массиве записей), то можно вычислить положение любой внутренней ссылки в блоке и использовать например поиск методом половинного деления. Если ключи переменной длины, то это уже невозможно, приходится проходить по блоку сначала в том же направлении сортировки, в котором он был построен (неважно, по возрастанию или убыванию). Будет там компрессия или нет - это уже не важно. Если применяется компрессия для составных ключей каждый фрагмент которого пусть даже фиксирован, проходить придется также в направлении сортировки при построении. Если в индексе ключи фиксированной длины, а значения переменной, то проходить также придется в направлении сортировки. Если требуется перечисление в обратном порядке, то придется пройти вперед, проскочить нужный, выяснить что проскочили и вернуться обратно. То же самое относится к операции $query. Но $order намного усложняется если ключи еще и с компрессией, потому что искомое значение может оказаться как в пройденном предыдущем, так и в дописанном хвосте. Те, кто особенно внимательно изучали mssql, могли заметить в документации оговорку, что выборка по индексу производится быстрее если desc или asc в операции order by совпадает с desc или asc используемом при построении индекса. Что касается right link и left link в блоках cache и msm - то это для переливов при балансировке. Переливы конечно упрощаются, но поддержание согласованных уровней имеет и отрицательную сторону - простенькая операция изменения базы (неважно, вставка, перезапись или удаление) может привести к перестроению совершенно невиновных блоков и к отметке об их модифицированности, что снижает ценность кеша. Впрочем, нам это только одно теоретизирование, повлиять на структуру базы каше мы вряд ли сможем. Хотя в стандарте не оговаривается в каком именно порядке должны храниться ключи, обычно все М системы хранят все глобалы в одной сортировке. В sql системах в зависимости от реализации можно повлиять на сортировку в структуре индекса. Можно даже попробовать побарствовать и иметь два индекса отличающиеся направлением сортировки.
...
Рейтинг: 0 / 0
29.12.2008, 13:07
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35739642
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
Некоторые материалы можно найти тут
http://drus.boom.ru/Science.htm
...
Рейтинг: 0 / 0
29.12.2008, 13:18
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35739860
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
ну яЧто касается right link и left link в блоках cache и msm - то это для переливов при балансировке.Left link нет ни в Cache, ни в MSM. Right link есть, но они, ИМХО, используется в 2 случаях:
- для доступа к блокам длинных данных
- для обеспечения возможности контроля целостности БД.
Если бы не было блоков длинных данных, в правых связях не было бы необходимости. При расщеплении блоков можно "плясать" как (1) от блоков указателей, так и (2) от правых связей в блоках данных. Но в последнем случае блоки указателей все равно пришлось бы корректировать для поддержания целостности, и неизвестно еще, какой подход быстрее. Есть подозрение, что Cache использует второй подход.
Пример М-системы без правых связей: GT.M. В нем, конечно же, и блоков длинных данных нет :)
...
Рейтинг: 0 / 0
29.12.2008, 14:29
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35792462
Hisbreht Victor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hisbreht Victor
Гость
И все-таки возвращаясь к проблеме времени получения ответа на запрос с сортировкой.
Индексы какого типа лучше использовать для сортировки?
Почему сортировка настолько увеличивает время получения первой записи? Особенно странно это выглядит, когда из массива записей различными условиями выбирается достаточно небольшое количество. Запрос с сортировкой дает первую запись за время на порядки большее, чем без сортировки при тех же условиях. Ведь сортировка вроде бы выполняется в последнюю очередь.
Может быть дело в каких нибудь системных настройках самой СУБД?

Виктор
...
Рейтинг: 0 / 0
02.02.2009, 20:33
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35792834
MaWr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MaWr
Гость
Hisbreht Victor...Запрос с сортировкой дает первую запись за время на порядки большее, чем без сортировки при тех же условиях. Ведь сортировка вроде бы выполняется в последнюю очередь.

Сортировка выполняется во время выборки путем записи в промежуточную глобаль (индексы - Ваш порядок сортировки) или путем пробежки по индексу, удовлетворяющему порядку сортировки. Поэтому, если нет индекса перед выдачей даже одного значения необходимо выполнить полную выборку (по всем данным).
...
Рейтинг: 0 / 0
03.02.2009, 08:19
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35792849
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
MaWrперед выдачей даже одного значения необходимо выполнить полную выборку (по всем данным).
Эт того-то и задержка.
Даже если сортирока по возрастанию и имеет надежду ускорения с "подключением" некоего индекса... То сортировка по убыванию теряет всякую надежду на ускорение.

Как вариант ускоряться в другом направлении. Вплоть до прямого доступа...
...
Рейтинг: 0 / 0
03.02.2009, 08:34
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35792894
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Смотрите планы запросов с сортировкой и без, че-то тут нечисто.
...
Рейтинг: 0 / 0
03.02.2009, 09:04
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35794864
Hisbreht Victor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hisbreht Victor
Гость
А как насчет видов индексов? bitmap индексы, похоже, в этом случае совсем не помощники?
...
Рейтинг: 0 / 0
03.02.2009, 19:01
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35795366
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
Есть мнение что они просто супер в запросах "типа count"...
----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT
...
Рейтинг: 0 / 0
04.02.2009, 08:34
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35797710
Hisbreht Victor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hisbreht Victor
Гость
krvsaЕсть мнение что они просто супер в запросах "типа count"...Это да, но только если эти "запросы" реализовывать на COS, ручками проводя операции над разными bitmap индексами. Как показала личная практика, если использовать обычный SQL, ничего они не дают.
...
Рейтинг: 0 / 0
04.02.2009, 20:16
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35798128
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
Hisbreht VictorКак показала личная практика, если использовать обычный SQL, ничего они не дают.
А как же все анонсы от ИС? Получается что все библия нафик? "Хорошенькое" дело...
...
Рейтинг: 0 / 0
05.02.2009, 08:41
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35802774
Hisbreht Victor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hisbreht Victor
Гость
krvsaHisbreht VictorКак показала личная практика, если использовать обычный SQL, ничего они не дают.
А как же все анонсы от ИС? Получается что все библия нафик? "Хорошенькое" дело...Когда запрос простенький, то все оно работает, но если навернуть что-нибудь посерьезнее, с большим количеством условий, связанных разными отношениями, из нескольких взаимосвязанных классов-таблиц, то оптимизатор начинает использовать только один из индексов, вместо того, чтобы начать их подвергать операциям "и" и "или". По крайней мере это показывает план доступа. Или я что-то не понимаю?
...
Рейтинг: 0 / 0
06.02.2009, 19:26
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35802898
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
servit
Участник
Hisbreht VictorКогда запрос простенький, то все оно работает, но если навернуть что-нибудь посерьезнее, с большим количеством условий, связанных разными отношениями, из нескольких взаимосвязанных классов-таблиц, то оптимизатор начинает использовать только один из индексов, вместо того, чтобы начать их подвергать операциям "и" и "или". По крайней мере это показывает план доступа. Или я что-то не понимаю?
Все зависит от запроса, наличия или отсутствия индекса, их типов, подсказок оптимизатору, настроек таблиц и т.д. Иногда оптимизатор не использует индекс, когда это выгодно.

Choosing Index Type

Optimizing Performance
...
Рейтинг: 0 / 0
06.02.2009, 20:57
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35804780
=Dimon=
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
=Dimon=
Участник
Hisbreht Victor,
Может у вас сервер слабый? Или скажем медленные диски?
И сколько у вас время получения первой записи и количество строк в таблице?
...
Рейтинг: 0 / 0
09.02.2009, 03:39
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35804797
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Hisbreht Victor то оптимизатор начинает использовать только один из индексов, вместо того, чтобы начать их подвергать операциям "и" и "или". По крайней мере это показывает план доступа. Или я что-то не понимаю?

Ну операции "или" в индексах есть точно - выбирается только один индекс.

А что вы подразумете под "и"? Какая операция на глобалах должна проводиться?
Вообще я видел план запроса с INTERSECT индексов, но это специфичная ситуация (и кстати я специально менял селективности чтобы уйти от этого)
...
Рейтинг: 0 / 0
09.02.2009, 06:07
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35865992
Hisbreht Victor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hisbreht Victor
Гость
Вопрос, с которого началась данная ветка, все более становится ребром.
COS - это, конечно, очень хорошо, но некоторые вещи проще и удобнее делать через SQL, тем более, что сил и времени на переделку просто не остается.
И тут как раз именно такая ситуация.
Есть таблица на 2 миллиона записей.
Таблица содержит около десятка полей, на каждое из которых создан bitmap индекс.
Запрос простой. Как правило имеет вид, указанный в начале обсуждения. Может быть только с дополнительным условием на одно из полей.
Типа
SELECT Id FROM Class WHERE Flag IN(2,3) AND Param1=10 ORDER BY Field
или
SELECT Id FROM Class WHERE Flag IN(2,3) AND Param2->param2data=1 ORDER BY Field
Запрос может выполняться больше минуты.
Машина - зверь.
Два Core2 Quad, Памяти 16 Г, дисковая подсистема - чередующийся RAID из 8 дисков.
Но при работе Cache создается ощущение, что дисковая система не перегружена (индикаторы доступа мигают не особо активно) Процессоры заняты от силы на 10 процентов.
Может быть, что-то надо подкрутить в параметрах СУБД и операционной системы (2003 Server R2 32 бит)?

Виктор
...
Рейтинг: 0 / 0
12.03.2009, 21:44
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35866269
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Зачем вам индексы по всем полям, тем более битмап. Это действительно нужно?

Попробуйте удалить индекс по полю Field, в некоторых версих каше оптимизатор запросов творит фигню, если индексировано поле, по которому идет сортировка.

Покажите план запроса.
...
Рейтинг: 0 / 0
13.03.2009, 06:05
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35866286
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Да, попробуйте $system.SQL.TuneTable("Tablename",1,1)

(Чукча не читатель, чукча писатель, мож кто уже говорил - не знаю)
...
Рейтинг: 0 / 0
13.03.2009, 06:47
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35866449
Hisbreht Victor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hisbreht Victor
Гость
Блок А.Н.,

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

Проблема кстати, гораздо серьезнее, чем казалась раньше. Теперь и без сортировки запрос выполняется неоправданно медленно.

SELECT ID FROM BAG.Params WHERE Flags IN (2,3) AND Param1->Value=10
План запроса выглядит так
====================
Read master map BAG.Params1.IDKEY, using the given idkey value.

Read bitmap index BAG.Params.Param1IDX, using the given Param1, and looping on ID.

For each row:

Read master map BAG.Params.IDKEY, using the given idkey value.
Output the row.
=====================
Выполняется больше минуты.
...
Рейтинг: 0 / 0
13.03.2009, 09:26
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35866537
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Какой реальный объем глобалов, в которых хранятся данные (можно посмотреть с помощью ^%GSIZE)

Какой объем кеша глобалов?
...
Рейтинг: 0 / 0
13.03.2009, 10:04
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35866729
CJIECAPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CJIECAPb
Гость
Hisbreht VictorБлок А.Н.,

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

Проблема кстати, гораздо серьезнее, чем казалась раньше. Теперь и без сортировки запрос выполняется неоправданно медленно.

SELECT ID FROM BAG.Params WHERE Flags IN (2,3) AND Param1->Value=10
План запроса выглядит так
====================
Read master map BAG.Params1.IDKEY, using the given idkey value.

Read bitmap index BAG.Params.Param1IDX, using the given Param1, and looping on ID.

For each row:

Read master map BAG.Params.IDKEY, using the given idkey value.
Output the row.
=====================
Выполняется больше минуты.
А на поле Flags индекс висит? По вашему плану запроса, каше использует только индекс по Param1.
И ещё вопрос: сколько (примерно) различных Param1 с Value=10 ? (Т.е. если почти всем Param1 в таблице BAG.Params соответствует Value=10, то индекс по этому полю вообще лучше не использовать)
...
Рейтинг: 0 / 0
13.03.2009, 10:52
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35866981
Hisbreht Victor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hisbreht Victor
Гость
Блок А.Н.Какой реальный объем глобалов, в которых хранятся данные (можно посмотреть с помощью ^%GSIZE)
BAG.ParamsD 81337 552,500,652 83 % 78
BAG.ParamsI 6751 41,843,281 76 % 0

Блок А.Н.Какой объем кеша глобалов?
Стоит автоматическое распределение памяти, оно выделяет на кэш глобалов 255 МБ
...
Рейтинг: 0 / 0
13.03.2009, 11:42
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35866996
Hisbreht Victor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hisbreht Victor
Гость
CJIECAPbА на поле Flags индекс висит? По вашему плану запроса, каше использует только индекс по Param1.
И ещё вопрос: сколько (примерно) различных Param1 с Value=10 ? (Т.е. если почти всем Param1 в таблице BAG.Params соответствует Value=10, то индекс по этому полю вообще лучше не использовать)
На поле Flags тоже есть bitmap индекс
Param1 с Value=10 в таблице чуть больше 3 тысяч из 2 миллионов
...
Рейтинг: 0 / 0
13.03.2009, 11:47
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35867021
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Hisbreht VictorСтоит автоматическое распределение памяти, оно выделяет на кэш глобалов 255 МБИмеет смысл отдать под кэш всю свободную физическую память (но обычно не более 1600Мб на 32-битной системе). Можно сразу, можно постепенно, наблюдая за эффектом (512 - 1024 - 1536).
...
Рейтинг: 0 / 0
13.03.2009, 11:57
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35867025
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Около 600мб реальных данных, расположенных непоследовательно фрагментированных, практически без кэша (255мб для таких данных все-таки мало, думаю нужно столько, сколько максимум получится выделить)
Чтение вероятно будет многопроходное, причем будут подтягиваться данные из других таблиц.

Средняя скорость чтения в таких условиях
600Мб/1мин=10 Мб/сек, что в общем неплохо, если не используется индекс. А он не используется, я сразу и не заметил.

авторSELECT ID FROM BAG.Params WHERE Flags IN (2,3) AND Param1->Value=10
План запроса выглядит так
====================
Read master map BAG.Params1.IDKEY, using the given idkey value.

Read bitmap index BAG.Params.Param1IDX, using the given Param1, and looping on ID.

For each row:

Read master map BAG.Params.IDKEY, using the given idkey value.
Output the row.

Куда ведет Param1->Value и ндексировано ли Value?
...
Рейтинг: 0 / 0
13.03.2009, 11:57
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35867030
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Торможу, Param1->Value
ведет в таблицу BAG.Params1, но все-таки индекс по Value не используется. Или его там нет, или с ним что-то не так.
...
Рейтинг: 0 / 0
13.03.2009, 11:59
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35867283
Hisbreht Victor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hisbreht Victor
Гость
Блок А.Н.Торможу, Param1->Value
ведет в таблицу BAG.Params1, но все-таки индекс по Value не используется. Или его там нет, или с ним что-то не так.Я, конечно, могу заблуждаться, но, как мне кажется, это не должно иметь особого значения в данном случае, поскольку выборка данного значения осуществляется из небольшого справочника в самом начале, и, согласно плану, на дальнейшем исполнении запроса никак не сказывается
...
Рейтинг: 0 / 0
13.03.2009, 13:06
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35870476
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Ну мне же неизвестно было, какой размер у таблицы BAG.Params1

А сколько строк в результате выборки должно появиться?
...
Рейтинг: 0 / 0
16.03.2009, 08:35
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35871764
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
servit
Участник
Hisbreht Victor,

Caché 2009.1.FT1

На моей машине (Intel Core2 Duo, 2Гб) выборка с отображением ID всех 2000000 записей на C# занимает 28 секунд:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
  var t1 = DateTime.Now.Ticks;
  using (var cn = new CacheConnection("server=localhost;port=1972;namespace=TEST;uid=_system;pwd=SYS"))
  {
      using (var cmd = cn.CreateCommand())
      {
          cmd.CommandText = "select id from Class";
          var adapter = new CacheDataAdapter { SelectCommand = cmd };
          adapter.Fill(ds);
          dataGrid1.DataSource = ds;
          dataGrid1.DataMember = "Table";
      }
  }
  Text = new TimeSpan(DateTime.Now.Ticks - t1).Seconds + " s.";

И планы запросов на моих данных не такие как у Вас.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
План запроса:
SELECT %ID FROM Class WHERE Flag IN( 2 , 3 ) AND Param1= 10  ORDER BY Field


Относительная стоимость =  13366  
Call module B, which populates temp-file A.

Read temp-file A, looping on Field and a counter.

For each row:

 Output the row. 
 
module B 
Read bitmap index SQLUser.Class.iFlag, looping on Flag (with a given set of values) and ID.

For each row:

 Read master map SQLUser.Class.IDKEY, using the given idkey value. 
 Add a row to temp-file A, subscripted by Field and a counter, with node data of ID.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
План запроса:
SELECT %ID FROM Class WHERE Flag IN ( 2 , 3 ) AND Param1->Value= 10 


Относительная стоимость =  13878  
Read bitmap index SQLUser.Class.iFlag, looping on Flag (with a given set of values) and ID.

For each row:

 Read master map SQLUser.Class.IDKEY, using the given idkey value. 
 Read bitmap index SQLUser.Param1.iValue, using the given Value and ID. 
 For each row: 
 Output the row.
...
Рейтинг: 0 / 0
16.03.2009, 15:13
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35871920
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
servit
Участник
krvsaMaWrперед выдачей даже одного значения необходимо выполнить полную выборку (по всем данным).
Эт того-то и задержка.
Даже если сортирока по возрастанию и имеет надежду ускорения с "подключением" некоего индекса... То сортировка по убыванию теряет всякую надежду на ускорение.

Как вариант ускоряться в другом направлении. Вплоть до прямого доступа...
Наличие индексов на полях, участвующих в сортировке, приводит к ускорению запроса в независимости от направления сортировки.
Планы запросов приведены для версии 5.0.21:
Код: plaintext
1.
2.
3.
4.
select Field from Class order by Field asc

Read index map SQLUser.Class.iField, looping on Field and ID.
For each row:
 Output the row.
Код: plaintext
1.
2.
3.
4.
select Field from Class order by Field desc

Read index map SQLUser.Class.iField, looping on Field and ID.
For each row:
 Output the row.
...
Рейтинг: 0 / 0
16.03.2009, 15:57
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35872978
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
>Наличие индексов на полях, участвующих в сортировке, приводит к ускорению запроса
Мой опыт говорит об обратном. По крайней мере в каше 5.2 в запрос
select * from table where field1=value1 order by field2
выполняется намного дольше при наличии индекса по field2, потому что независимо от селективности почему-то используется индекс по field2

При том, что select * from table where field1=value1 выдается быстро и количество записей небольшое.
...
Рейтинг: 0 / 0
17.03.2009, 05:28
| Ответить | Цитировать | Написать  
Производительность сортировки.
    #35873094
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
servit
Участник
Блок А.Н.,

В версии 5.2 - вполне возможно. Это кандидат на запрос о проблеме в WRC.

В версиях 2008.2.1.902, 2009.1.FT1 планы запросов следующие:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
select * from Class where Param1= 10 

Относительная стоимость =  902840  
Read index map SQLUser.Class.iParam1, using the given Param1, and looping on ID.

For each row:

 Read master map SQLUser.Class.IDKEY, using the given idkey value. 
 Output the row.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
select * from Class where Param1= 10  order by Field desc

Относительная стоимость =  1153070 
Call module B, which populates temp-file A.

Read temp-file A, looping on Field and ID.

For each row:

 Output the row. 
 
module B 
Read index map SQLUser.Class.iParam1, using the given Param1, and looping on ID.

For each row:

 Read master map SQLUser.Class.IDKEY, using the given idkey value. 
 Add a row to temp-file A, subscripted by Field and ID, 
 with node data of Flag and Param1.
Количество возвращаемых записей на моих данных - 4313, время выполнения с отображением в Портале ~0.5 (c.), вне зависимости от наличия сортировки и ее направления.
...
Рейтинг: 0 / 0
17.03.2009, 09:13
| Ответить | Цитировать | Написать  
57 сообщений из 57, показаны все 3 страниц
  все  
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Производительность сортировки.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]