|
![]() |
#1 |
Moderator
|
Очень странно, что перенос склада в inventTrans дал такой прирост производительности. Могу поверить в типичный показатель накладных расходов на джойн двух таблиц в 40-50%. Могу поверить на нетипичные случаи с 200% накладных расходов. Не могу поверить в накладные расходы в 900%
Мне кажется, у вас там просто какая-то беда с планом запроса в стандартной оборотке. Может статистика кривая, может сам сиквел глючит почему-то, может индексы не перестраивались несколько лет. В общем - попробуйте план запроса выщемить и выложить. |
|
|
За это сообщение автора поблагодарили: Logger (3). |
![]() |
#2 |
Участник
|
![]()
От объема памяти зависит много, но в данном случае по сути не зависит ни чего!
А верить не надо - возьми например, тот же x++ (хотя лучше c++) и напиши на нем выборку без использования оператора select со связкой двух таблиц с использованием индекса. (Если кто не знает, то индекс - это тоже такая таблица только сортированная). И все недоумение сразу пропадет... |
|
|
За это сообщение автора поблагодарили: fed (-3). |
![]() |
#3 |
Участник
|
|
|
![]() |
#4 |
Moderator
|
Цитата:
Последний раз редактировалось fed; 25.12.2011 в 18:06. |
|
![]() |
#5 |
Участник
|
Цитата:
Сообщение от fed
![]() А это такое проявление "научного подхода" к внедрениям. Автор считает что индекс, это не B-дерево, а таблица отсортированная. Также автор считает что джойн на SQL Server (все равно какой - sort/merge, hash join, nested loop join) легко может быть смоделирован с помощью вложенного селекта на клиентской стороне. Причем - и в этом, вероятно, суть "научного подхода", писать джойн надо не не ламерском X++, а на
Хотите - можно написать на Х++, вместо таблиц здесь можно использовать контейнер без операции поиска, только с запоминанием индекса элемента. Суть задачи сводится к выборке по двум таблицам и четырем индексам: фильруем по полю 1 в первой таблице, связываем по полю 2 таблицы, фильтруем по полю 3 вторую таблицу. В первой таблице есть 2 индекса по полю 1 и полю 2 соответственно, аналогично во второй есть индексы по полям 2 и 3. А ваше предположение что авторы которые пишут SQL сервер обладают тайным знанием - в корне неверно, скорее те кто использую SQL по большей части бездари и по этому разница бросается в глаза... Но вы fed уж не обижайтесь - я не про Вас, ваши обиды мне дорого обходятся... ![]() |
|
|
За это сообщение автора поблагодарили: Vadik (-6). |
![]() |
#6 |
Moderator
|
Цитата:
Сообщение от Мартынов Дмитрий
![]() Интересно, что когда я не вдаюсь в технические детали - то меня начинаю обвинять в невежестве... Разница между B-деревом и сортированной таблицей с точки зрения нашей задачи небольшая. Более того если мы создаем правильные структуры данных и делаем правильные запросы, то разница между ними вообще не в пользу B-дерева.
Цитата:
Сообщение от Мартынов Дмитрий
![]() Хотите - можно написать на Х++, вместо таблиц здесь можно использовать контейнер без операции поиска, только с запоминанием индекса элемента. Суть задачи сводится к выборке по двум таблицам и четырем индексам: фильруем по полю 1 в первой таблице, связываем по полю 2 таблицы, фильтруем по полю 3 вторую таблицу. В первой таблице есть 2 индекса по полю 1 и полю 2 соответственно, аналогично во второй есть индексы по полям 2 и 3.
Цитата:
Сообщение от Мартынов Дмитрий
![]() А ваше предположение что авторы которые пишут SQL сервер обладают тайным знанием - в корне неверно, скорее те кто использую SQL по большей части бездари и по этому разница бросается в глаза... Но вы fed уж не обижайтесь - я не про Вас, ваши обиды мне дорого обходятся...
![]() |
|
![]() |
#7 |
Участник
|
Цитата:
Цитата:
Сообщение от fed
![]() Не хочешь чтобы над тобою стебались, почитай для начала Вирта "Алгоритмы и структуры данных (про B-Деревья и Хэш-таблицы) и почитай в BOL про виды джойнов в SQL Server. Еще можно почитать блог Craig Freeman Так что знания не тайные, просто, вероятно, твой ''научный подход" - это такое политически корректный термин для "невежество".
|
|
![]() |
#8 |
Участник
|
Цитата:
А ключевая проблема в том что выборка по двум таблицам принципиально плохооптимизируемая операция. Например некорректное решение структуры данных при объемах данных порядка биллиона операций хоронит проект... Но чаще всего мы работаем с маленькими таблицами. При этом мы работаем кое как - и все работает быстро. И тогда лагание на десятках миллионов записей всех ставит в тупик... Последний раз редактировалось Мартынов Дмитрий; 25.12.2011 в 18:51. Причина: про кое как забыл написать |
|
![]() |
#9 |
Участник
|
Цитата:
Интересно было бы увидеть более развернутый ответ. А то вы вроде начали, а по существу ничего не написали. Отделались общими словами. По поводу памяти - поясняю. На нашем проекте база крутится с 2005-го года. Стартовали на 3-ке. в 2006 году заметили явные подтормаживания на запросах когда был джоин по InventSum и InventDim с фильтром по складу и номенклатуре (ItemId like 'XXX%' . (Нам важно было достичь быстрого времени отклика - порядка доли секунды). Проблему решили денормализацией InventSum. Добавили туда поле склад, проиндексировали, а InventDim из джоина выкинули. Система словно задышала. Все сразу стало быстрее. Админ был очень доволен - сказал что память используется намного меньше. Но когда я сейчас попробовал построить пример и замерять время, то с удивлением обнаружил что разницы практически нет. Результат поразительный. Пока вижу причину в том что в 2006 году был другой сервер БД, в котором стояло совсем немного памяти. А сейчас памяти навалом. Но чтобы точно можно было сказать - придется провести дополнительные тесты. |
|
![]() |
#10 |
Участник
|
Цитата:
Сообщение от Logger
![]() По поводу памяти - поясняю. На нашем проекте база крутится с 2005-го года. Стартовали на 3-ке. в 2006 году заметили явные подтормаживания на запросах когда был джоин по InventSum и InventDim с фильтром по складу и номенклатуре (ItemId like 'XXX%' . (Нам важно было достичь быстрого времени отклика - порядка доли секунды). Проблему решили денормализацией InventSum. Добавили туда поле склад, проиндексировали, а InventDim из джоина выкинули. Система словно задышала. Все сразу стало быстрее. Админ был очень доволен - сказал что память используется намного меньше.
|
|
![]() |
#11 |
Участник
|
Цитата:
Сообщение от fed
![]() Очень странно, что перенос склада в inventTrans дал такой прирост производительности. Могу поверить в типичный показатель накладных расходов на джойн двух таблиц в 40-50%. Могу поверить на нетипичные случаи с 200% накладных расходов. Не могу поверить в накладные расходы в 900%
Мне кажется, у вас там просто какая-то беда с планом запроса в стандартной оборотке. Может статистика кривая, может сам сиквел глючит почему-то, может индексы не перестраивались несколько лет. В общем - попробуйте план запроса выщемить и выложить. Вот пример из реальной базы inventTrans - 22 млн записей inventDim - 4 млн записей Включены аналитики - склад (~ 10 складов, по каждому из складов примерно пропорциональной движение товара по количеству операций) - партия - ячейка запрос, код которого ниже (вызывается одним из наших отчетов Аксапта) X++: Use Axapta; SELECT SUM(A.QTY), SUM(A.COSTAMOUNTPOSTED), SUM(A.COSTAMOUNTADJUSTMENT), A.ITEMID, A.DIRECTION FROM INVENTTRANS A WHERE A.DATAAREAID=N'cmp' AND A.DATEFINANCIAL>={ts '2010-12-01 00:00:00.000'} AND A.DATEFINANCIAL<={ts '2010-12-31 00:00:00.000'} AND EXISTS (SELECT 'x' FROM INVENTDIM B WHERE ((B.DATAAREAID=N'cmp') AND ((B.INVENTLOCATIONID=N'Магазин3') AND (A.INVENTDIMID=B.INVENTDIMID)))) GROUP BY A.ITEMID,A.DIRECTION ORDER BY A.ITEMID,A.DIRECTION Вряд ли добавление поля "код склада" в InventTrans как то повлияет на производительность... Интересно а как с этим у других ? |
|
![]() |
#12 |
Участник
|
Цитата:
inventDim - 11 млн записей (склад,размер,партия) 170 складов, 40 тыс. номенклатур (это к тому, что у вас же там группировка и сортировка по ItemId). Возвращает результат (10 тыс строк) за 5 мин 22 сек - очень даже есть что оптимизировать. |
|
|
За это сообщение автора поблагодарили: someOne (3). |
![]() |
#13 |
Участник
|
|
|