InventLocationId в InventTrans

[Мартынов Дмитрий]

Цитата:

Сообщение от Logger

А почему в данном случае не зависит ? Чем он отличается от общего случая ? Как-то вы загадками говорите.

Зависит конечно, но по сути не зависит. Ведь проблему быстродействия можно решать увеличением мощности сервера и это тоже решение. Вопрос памяти является важным, но в данном случае он не ключевой.

А ключевая проблема в том что выборка по двум таблицам принципиально плохооптимизируемая операция. Например некорректное решение структуры данных при объемах данных порядка биллиона операций хоронит проект...
Но чаще всего мы работаем с маленькими таблицами. При этом мы работаем кое как - и все работает быстро. И тогда лагание на десятках миллионов записей всех ставит в тупик...

[Logger]

Цитата:

Сообщение от Мартынов Дмитрий

Зависит конечно, но по сути не зависит. Ведь проблему быстродействия можно решать увеличением мощности сервера и это тоже решение. Вопрос памяти является важным, но в данном случае он не ключевой.

Ну в данном случае речь идет не об увеличении мощности сервера, а как повлияет на производительность переход на 1 денормализованную табличку. На том же самом сервере.
Интересно было бы увидеть более развернутый ответ. А то вы вроде начали, а по существу ничего не написали. Отделались общими словами.

По поводу памяти - поясняю. На нашем проекте база крутится с 2005-го года. Стартовали на 3-ке. в 2006 году заметили явные подтормаживания на запросах когда был джоин по InventSum и InventDim с фильтром по складу и номенклатуре (ItemId like 'XXX%' . (Нам важно было достичь быстрого времени отклика - порядка доли секунды). Проблему решили денормализацией InventSum. Добавили туда поле склад, проиндексировали, а InventDim из джоина выкинули. Система словно задышала. Все сразу стало быстрее. Админ был очень доволен - сказал что память используется намного меньше.

Но когда я сейчас попробовал построить пример и замерять время, то с удивлением обнаружил что разницы практически нет. Результат поразительный.

Пока вижу причину в том что в 2006 году был другой сервер БД, в котором стояло совсем немного памяти. А сейчас памяти навалом.

Но чтобы точно можно было сказать - придется провести дополнительные тесты.

[Мартынов Дмитрий]

Цитата:

Сообщение от Logger

По поводу памяти - поясняю. На нашем проекте база крутится с 2005-го года. Стартовали на 3-ке. в 2006 году заметили явные подтормаживания на запросах когда был джоин по InventSum и InventDim с фильтром по складу и номенклатуре (ItemId like 'XXX%' . (Нам важно было достичь быстрого времени отклика - порядка доли секунды). Проблему решили денормализацией InventSum. Добавили туда поле склад, проиндексировали, а InventDim из джоина выкинули. Система словно задышала. Все сразу стало быстрее. Админ был очень доволен - сказал что память используется намного меньше.

Вы правы, память - это важно и в этой статье (я ссылку давал выше) я тоже об этом писал. Но в обсуждаемой здесь проблеме ключ в другом. Дело в том, что даже если мы все засунем в оперативку (а это бывает сложно сделать, т.к. есть ограничения системы и железа, например, на ее количество) на биллионах записей система подавится при неправильной структуре данных.