InventLocationId в InventTrans

[Владимир Максимов]

Цитата:

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

Так в чем причина такого поведения ?
Ограниченность X++ на котором не выразишь все идеи, которые можно сделать одним запросом на SQL ? Или накладные расходы внутри аоса при разборе полученной выборки и передаче её в X++ ?

Одно следствие другого. Факт ограниченности X++ в данном вопросе приводит к катастрофическому росту накладных расходов. X++ просто физически не может решить задачу по другому.

Если смотреть "шире", то приложение, "заточенное" на оптимизацию процедур модификации данных не может с равным успехом (в смысле оптимизации скорости выполнения) использоваться для формирования отчетности. Либо оптимизируем одно, либо оптимизируем другое. Одновременно - не получается.

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

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

Цитата:

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

Прошу прощения, а что имеет в виду под "Отсортированной таблицей"?
И как в этой таблице искать?

Цитата:

Сообщение от S.Kuskov

Уточню вопрос. Чем поиск по отсортированной таблице отличается от поиска по неотсортированной?

Судя по вопросу, вы не очень поняли смысл написания на Х++ процедуры выборки по двум таблицам.

Для начала отвечу на ваш вопрос: в отсортированной таблице можно использовать метод поиска делением пополам. НО с точки зрения нашей задачи это не важно.

Я не уточнял вопрос по задаче, в надежде, что вы догадаетесь. Уточняю задачу: требуется написать алгоритм для того чтобы определить какие индексы вы сможете использовать не перестраивая их в процессе выборки.
Инструменты: вместо таблиц я предложил использовать контейнеры, и не использовать conFind(). Для простоты будем считать что по контейнеру в котором у нас храниться индекс conFind() можно использовать. Ответ на задачу пока не даю - попробуйте решить самостоятельно.

[AndyD]

А можно я о своем, о мелком?

Поиск делением пополам на биллионах записей - это вы предлагаете, как альтернатива B-Tree?

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

Цитата:

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

А можно я о своем, о мелком?
Поиск делением пополам на биллионах записей - это вы предлагаете, как альтернатива B-Tree?

Ну раз вы знаете, что такое B-Tree, то вам будет несложно посчитать количество элементарный операций для поиска делением пополам и для поиска в B-Tree. Сделайте пожалуйста такую табличку, где видно максимальное количество элементарный операций для двух методов B-Tree и для поиска делением пополам для разного количества записей в таблице: для 1e+1, для 1e+2 записей, для 1е+3 записей..... и так до гугла (1е+100) можно с шагом 3 (т.е. тысяча, миллион, биллион.....). Надо сказать, что эта таблица с достаточной точностью считается в уме (без калькулятора), для тех кто помнит, что два в десятой это приблизительно 10 в третьей.

Чтобы не мучиться скажу вам сразу - разницы почти не будет..., точнее она будет не в ползу B-Tree. Это по тому, что мы смотрим на максимум элементарных операций, а B-Tree подразумевает большую рыхлость данных. Эта рыхлость эффективна при апдейтах а вот при поиске она дает лишние циклы...

[S.Kuskov]

Цитата:

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

Чтобы не мучиться скажу вам сразу - разницы почти не будет..., точнее она будет не в ползу B-Tree. Это по тому, что мы смотрим на максимум элементарных операций, а B-Tree подразумевает большую рыхлость данных. Эта рыхлость эффективна при апдейтах а вот при поиске она дает лишние циклы...

А вы учитываете, что дерево балансируется относительно значений хранящихся в таблице, а ваш "класический индекс" относительно их размера/местоположения? Т.е. вы допускаете, что величины в вашем биллионе записей могут быть распределены неравномерно?

[AndyD]

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

[Zabr]

Процитирую сам себя (это про выполнение запроса SomeOne):

Цитата:

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

Возвращает результат (10 тыс строк) за 5 мин 22 сек - очень даже есть что оптимизировать.

Мда. Тот же запрос на Х++ в Аксапте выполняется за 30 секунд.

[Vadik]

Цитата:

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

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

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

[Pustik]

Коллеги, добрый вечер.
Был занят, поэтому не мог принимать участие в дискуссии..Многие моменты, о чем здесь говорилось, заинтересовали.
Началось все с того, что на протяжении многих лет, оборотка(и другие отчеты, написанные в 2003-4 году) стали немного напрягать по времени выполнения. Да они выполняются 3-6 минут, но это все равно как-то долговато. Особенно, если тебе звонит бухгалтер и говорит, что у него не идет что-то с обороткой ( ждать немного раздражает ). Сразу скажу, что у нас построение оборотки основаано на inventSum. Естественно, все оборотки чаще всего смотрятся в разрезе склада.
Тест происходил следующим образом : Запустил оборотку c InventDim, замерил время выполнения всех запросов в алгоритме (время вывода на экран не в счет) - 3 мин. Далее перенес склад в InventTrans, как указал выше. Единственное, что забыл сказать - я проиндексировал склад. Запустил. Время выполнения 20 сек.На этом мое тестирование закончилось. Я вынес предввыводы для себя и захотел услышать мнение других людей.
После того, как я полностью прочитал ветку, засомневался, и сегодня протестировал это более тщательно.А именно, после запуска оборотки, которая использует inventLocationid в inventtrans, я снова запустил оборотку старого образца. Увидел, что она стала выполняться за 32 секунды. Т.е. первый раз за 3 мин. - второй(с перенесенным складом) за 20 секунд - и третий раз(снова по первому варианту) за 32 секунды. Тут у меня возник интерес к фразе fed-а об оптимизации запросов. Честно признаюсь, что я представляю, что такое оптимизация и статистика запросов, но лично с этим не дружил .
Сравнивать с рабочей базой думаю смысла нет. Там совершенно другие параметры SQL и AOS-а.Переносить склад в inventTrans пока не планируем (боимся)
Да, добавлю, что для тестирования использовал не очень "частый" склад.

[gl00mie]

Цитата:

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

я снова запустил оборотку старого образца. Увидел, что она стала выполняться за 32 секунды. Т.е. первый раз за 3 мин. - второй(с перенесенным складом) за 20 секунд - и третий раз(снова по первому варианту) за 32 секунды.

Это еще отчасти может об'ясняться тем, что после первого прогона оборотки СУБД закэшировала все необходимые данные и перестала начитывать их с диска.

[Alexius]

Для решения подобных задач в свое время использовал индексированные вьюхи. Способ несколько "варварский", зато не предполагает уродования штатного функционала, пусть и далеко не идеального

[fed]

К предположению gl00mie могу только добавить совет перед каждым прогоном теста, сбрасывать дисковый кэш сиквела с помощью комманды DBCC DROPCLEANBUFFERS
Кроме того, если считать что тесты 2 и 3 из сообщения участника pustik выполнялись в равноправных условиях (в смысле все данные уже были закэшированы), то разница в полотора раза - это нормально. Нет смысла копаться в планах запросов, скорее всего все и так хорошо...

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

Цитата:

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

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

В соответствии с п.3.12 вынужден подчиниться......

Цитата:

Сообщение от S.Kuskov

А вы учитываете, что дерево балансируется относительно значений хранящихся в таблице, а ваш "класический индекс" относительно их размера/местоположения? Т.е. вы допускаете, что величины в вашем биллионе записей могут быть распределены неравномерно?

Вынужден оставить без ответа... Не вижу здесь офтопика (даже берусь доказать обратное) но не смею спорить с модератором...

[AndyD]

Как говорит mazzy - открывайте отдельную тему, там и расскажите

[kashperuk]

Не думаю, что у Майкрософт в планах делать такого рода денормализацию.
Было бы, наоборот, логичнее работать над более универсальным механизмом, который бы позволял с легкостью добавлять новые аналитики в зависимости от специфики учета в компании.

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

[Pustik]

Цитата:

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

Было бы, наоборот, логичнее работать над более универсальным механизмом, который бы позволял с легкостью добавлять новые аналитики в зависимости от специфики учета в компании.

Мне это очень нравиться. Как раз была необходимость в складской аналитике.
Как Вы считаете, это сильно трудоемко?

[kashperuk]

Цитата:

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

Мне это очень нравиться. Как раз была необходимость в складской аналитике.
Как Вы считаете, это сильно трудоемко?

Если вопрос ко мне, и о Майкрософт, то да, это было бы довольно трудоемко.
Но, для этого мы и существуем, чтобы делать трудоемкие задачи.
Вопрос только - в какой версии это будет сделано.

[Pustik]

Цитата:

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

Если вопрос ко мне, и о Майкрософт, то да, это было бы довольно трудоемко.
Но, для этого мы и существуем, чтобы делать трудоемкие задачи.
Вопрос только - в какой версии это будет сделано.

пожалуй создам новую ветку

[Vadik]

Цитата:

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

Дело в том что в отчете может так выглядит

Собеседники чуть выше поступили очень мудро, создав отдельные ветки
Пожалуйста, создавайте отдельные ветки для обсуждения отдельных тем

[sukhanchik]

Обсуждение с запросом к InventSum выделено в отдельную ветку Запрос к InventSum с InventLocationId