InventLocationId в InventTrans

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

Цитата:

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

Мне кажется, результат еще сильно должен зависеть от объема памяти...

От объема памяти зависит много, но в данном случае по сути не зависит ни чего!

Цитата:

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

Не могу поверить в накладные расходы в 900%
Мне кажется, у вас там просто какая-то беда с планом запроса в стандартной оборотке.

А верить не надо - возьми например, тот же x++ (хотя лучше c++) и напиши на нем выборку без использования оператора select со связкой двух таблиц с использованием индекса. (Если кто не знает, то индекс - это тоже такая таблица только сортированная). И все недоумение сразу пропадет...

[Logger]

Цитата:

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

От объема памяти зависит много, но в данном случае по сути не зависит ни чего!

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

[fed]

Цитата:

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

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

А это такое проявление "научного подхода" к внедрениям. Автор считает что индекс, это не B-дерево, а таблица отсортированная. Также автор считает что джойн на SQL Server (все равно какой - sort/merge, hash join, nested loop join) легко может быть смоделирован с помощью вложенного селекта на клиентской стороне. Причем - и в этом, вероятно, суть "научного подхода", писать джойн надо не не ламерском X++, а на пацанском научном C++, потому что все нормальные пацаны ученые пишут только на C++, который компилируется не в ламерский байткод, а в настоящие процессорные команды. Что, конечно же, очень увеличивает степень подобия такого теста исполнению join внутри SQL Server...

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

Цитата:

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

А это такое проявление "научного подхода" к внедрениям. Автор считает что индекс, это не B-дерево, а таблица отсортированная. Также автор считает что джойн на SQL Server (все равно какой - sort/merge, hash join, nested loop join) легко может быть смоделирован с помощью вложенного селекта на клиентской стороне. Причем - и в этом, вероятно, суть "научного подхода", писать джойн надо не не ламерском X++, а на пацанском научном C++, потому что все нормальные пацаны ученые пишут только на C++, который компилируется не в ламерский байткод, а в настоящие процессорные команды. Что, конечно же, очень увеличивает степень подобия такого теста исполнению join внутри SQL Server...

Интересно, что когда я не вдаюсь в технические детали - то меня начинаю обвинять в невежестве... Разница между B-деревом и сортированной таблицей с точки зрения нашей задачи небольшая. Более того если мы создаем правильные структуры данных и делаем правильные запросы, то разница между ними вообще не в пользу B-дерева.

Хотите - можно написать на Х++, вместо таблиц здесь можно использовать контейнер без операции поиска, только с запоминанием индекса элемента. Суть задачи сводится к выборке по двум таблицам и четырем индексам: фильруем по полю 1 в первой таблице, связываем по полю 2 таблицы, фильтруем по полю 3 вторую таблицу. В первой таблице есть 2 индекса по полю 1 и полю 2 соответственно, аналогично во второй есть индексы по полям 2 и 3.

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

[fed]

Цитата:

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

Интересно, что когда я не вдаюсь в технические детали - то меня начинаю обвинять в невежестве... Разница между B-деревом и сортированной таблицей с точки зрения нашей задачи небольшая. Более того если мы создаем правильные структуры данных и делаем правильные запросы, то разница между ними вообще не в пользу B-дерева.

No comments. Если делаем правильные структуры, можно жить на голых таблицах - без B-Tree. Вероятно будет пересортировывать после каждой вставки и обновления. Очевидно это тот самый "научный подход" в действии.

Цитата:

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

Хотите - можно написать на Х++, вместо таблиц здесь можно использовать контейнер без операции поиска, только с запоминанием индекса элемента. Суть задачи сводится к выборке по двум таблицам и четырем индексам: фильруем по полю 1 в первой таблице, связываем по полю 2 таблицы, фильтруем по полю 3 вторую таблицу. В первой таблице есть 2 индекса по полю 1 и полю 2 соответственно, аналогично во второй есть индексы по полям 2 и 3.

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

Цитата:

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

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

Не хочешь чтобы над тобою стебались, почитай для начала Вирта "Алгоритмы и структуры данных (про B-Деревья и Хэш-таблицы) и почитай в BOL про виды джойнов в SQL Server. Еще можно почитать блог Craig Freeman Так что знания не тайные, просто, вероятно, твой ''научный подход" - это такое политически корректный термин для "невежество".

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

Цитата:

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

No comments. Если делаем правильные структуры, можно жить на голых таблицах - без B-Tree. Вероятно будет пересортировывать после каждой вставки и обновления. Очевидно это тот самый "научный подход" в действии.

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

Цитата:

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

Не хочешь чтобы над тобою стебались, почитай для начала Вирта "Алгоритмы и структуры данных (про B-Деревья и Хэш-таблицы) и почитай в BOL про виды джойнов в SQL Server. Еще можно почитать блог Craig Freeman Так что знания не тайные, просто, вероятно, твой ''научный подход" - это такое политически корректный термин для "невежество".

За Вирта спасибо, вообщето начать надо с Тьюринга и Черча... сижу изучаю....Дейкстру почитываю... Кстати, из наших рекомендую прежде всего Ершова.

[S.Kuskov]

Цитата:

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

Если мы не имеем аппаратных средств копирования блоков памяти, то при качественном проектировании БД В-дерево проиграет классическому индексу.

Что вы называете "классическим индексом"?

[Vadik]

Цитата:

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

Если мы не имеем аппаратных средств копирования блоков памяти, то при качественном проектировании БД В-дерево проиграет классическому индексу. Кстати и в обратную сторону - если у нас есть аппаратные средства сортировки то опять же сортировка выиграет
..
Зависит конечно, но по сути не зависит

Дмитрий, есть предложение вернуться к решению задачи поставленной в начале ветки (напомню - ускорение оборотки по складу за счет добавления InventLocationId в InventTrans) на основе коммерчески доступных в данное время в данной галактике технологий (AX, X++, SQL Server \ Oracle). Если по существу добавить нечего - пожалуйста, воздержитесь от увода ветки в оффтопик

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

Цитата:

Сообщение от 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 из джоина выкинули. Система словно задышала. Все сразу стало быстрее. Админ был очень доволен - сказал что память используется намного меньше.

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