ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Производительность SQL на разросшейся иерархии классов
9 сообщений из 9, страница 1 из 1
Производительность SQL на разросшейся иерархии классов
    #36692857
cache hit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cache hit
Гость
Привет

У меня возникла проблема с производительностью SQL на разросшейся иерархии классов, ситуация такая:

От одного persistent класса (назовем его A) создана куча классов наследников (назовем их B,C,D) и соответственно на каждый класс есть своя таблица. В базе все это хранится, как я вижу, в одном единственном глобале. Приложение выполняет запросы по таблицам наследников класса A.
Все устраивало до недавних пор пока количество объектов не стало возрастать и я понял что SQL при запросе к таблицам B,C,D перебирает все объекты класса A вместо некоего небольшого их подмножества, относящегося к конкретному классу наследнику.

Вопрос - как увеличить быстродействие? Если индекс, то как его создать? Я попробовал построить индекс типа Extent для класса A, но это не повлияло на производительность никак.
...
Рейтинг: 0 / 0
17.06.2010, 16:23
| Ответить | Цитировать | Написать  
Производительность SQL на разросшейся иерархии классов
    #36693036
Фотография kolesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kolesov
Участник
cache hit,
Перебор идет по индексам, а не по данным...
Видимо, что-то не так делаете. Подробнее можно?
...
Рейтинг: 0 / 0
17.06.2010, 17:05
| Ответить | Цитировать | Написать  
Производительность SQL на разросшейся иерархии классов
    #36693572
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
cache_hit
дело в том, что что субд должна выбирать только те данные, которые нужно, либо по крайней мере минимумальный выделяемый кусок. И это не зависит от числа классов, и это не только в каше.
(Хотя при сложной иерархии классов ошибиться с индексами легче)

Индексирование полей нужно делать исходя из того, какими запросами вы пользуетесь.
Ну и там хитрости есть в этом деле. В любом случае вам должен помочь план запроса, смотрите его, если что-то не так с быстродействием.
...
Рейтинг: 0 / 0
17.06.2010, 21:01
| Ответить | Цитировать | Написать  
Производительность SQL на разросшейся иерархии классов
    #36693968
cache hit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cache hit
Гость
Код: plaintext
1.
2.
3.
4.
class A extends %Persistent [abstract]
class B extends A
class C extends A
class D extends A

Выполняю запрос select * from D, всего объектов классов B,C,D - 150000, объект класса D - единственный. В плане запроса показано что идет перебор по IDKEY класса D. Запрос работает более 40 секунд, из чего я делаю вывод что перебор идет по всем объектам

С другой стороны запрос select count(*) from D отрабатывает за 1-2 секунды, мистика
...
Рейтинг: 0 / 0
18.06.2010, 05:03
| Ответить | Цитировать | Написать  
Производительность SQL на разросшейся иерархии классов
    #36693969
=Dimon=
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
=Dimon=
Участник
cache hit
Код: plaintext
1.
2.
3.
4.
class A extends %Persistent [abstract]
class B extends A
class C extends A
class D extends A

Выполняю запрос select * from D, всего объектов классов B,C,D - 150000, объект класса D - единственный. В плане запроса показано что идет перебор по IDKEY класса D. Запрос работает более 40 секунд, из чего я делаю вывод что перебор идет по всем объектам

С другой стороны запрос select count(*) from D отрабатывает за 1-2 секунды, мистика

Как вариант можете в class A добавить поле class это будет имя класса, которое сохраняется в БД (
Property class As %String(MAXLEN = 2000) [ Final, InitialExpression = {$S($G(%this):$zobjclass(%this),$$$TRUE:$$$NULL)}, ReadOnly ];
).
И добавить bitmap-индекс по этому полю
...
Рейтинг: 0 / 0
18.06.2010, 05:15
| Ответить | Цитировать | Написать  
Производительность SQL на разросшейся иерархии классов
    #36693974
cache hit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cache hit
Гость
=Dimon=,

насколько я понимаю, мне в каждом запросе нужно будет указать where class='D'?
...
Рейтинг: 0 / 0
18.06.2010, 05:36
| Ответить | Цитировать | Написать  
Производительность SQL на разросшейся иерархии классов
    #36693977
=Dimon=
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
=Dimon=
Участник
cache hit=Dimon=,

насколько я понимаю, мне в каждом запросе нужно будет указать where class='D'?
Да
...
Рейтинг: 0 / 0
18.06.2010, 06:21
| Ответить | Цитировать | Написать  
Производительность SQL на разросшейся иерархии классов
    #36693978
=Dimon=
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
=Dimon=
Участник
Можно конечно попробовать сделать свой обход глобалов, при выполнении запросов.
...
Рейтинг: 0 / 0
18.06.2010, 06:23
| Ответить | Цитировать | Написать  
Производительность SQL на разросшейся иерархии классов
    #36693993
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
select * from D

Такой запрос в принципе идет по master map.
Но если там будут условия с использованием индексов, то должно работать лучше.
(2-3 секунды тоже очень долго.)
...
Рейтинг: 0 / 0
18.06.2010, 08:26
| Ответить | Цитировать | Написать  
9 сообщений из 9, страница 1 из 1
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Производительность SQL на разросшейся иерархии классов
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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