ax2009, 2012. У кого есть опыт работы с paging в Query? Стоит ли этим заморачиваться?

[mazzy]

У кого есть опыт работы с paging в Query? Стоит ли этим заморачиваться?

методы пагинации
https://msdn.microsoft.com/en-us/lib...(v=ax.50).aspx
https://msdn.microsoft.com/en-us/lib...(v=ax.50).aspx
https://msdn.microsoft.com/en-us/lib...(v=ax.50).aspx

идея разбиения на страницы, например, здесь http://www.quizful.net/post/paging-in-sql

идея в том, чтобы сказать как то SQL'ю что не нужно делать выборку всех-всех-всех записей (а их там может быть сотни тысяч)
а достаточно выбрать первые 1000 или 100... но в случае необходимости, дозапросить еще.


в режиме paging SQL должен использовать существенно меньше памяти для хранения результатов выборки. а также готовить результат гораздо быстрее.

при этом совершенно не хочется делать "закат солнца вручную" и вручную разбивать на страницы и отслеживать уже просмотренные записи...

в общем, есть ли у кого-нибудь опыт работы с методам paging?
где подсмотреть документацию и примеры работы с этими методам?
(на аксфоруме только sumitax: Paging using QueryRun Class in AX )

[trud]

Какая интересно задача привела к такой проблеме? т.е. что мешает из квери просто выбрать 100 записей и остановиться или продолжить если нужно. и откуда уверенность что
"в режиме paging SQL должен использовать существенно меньше памяти для хранения результатов выборки. а также готовить результат гораздо быстрее."
как минимум если будет сортировка не по индексам это не так

[mazzy]

Цитата:

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

Какая интересно задача привела к такой проблеме?

закрытие склада, сопоставление. и подобные задачи.
там где ведется поиск первых подходящих записей...
а после того, как найдено, выполняется обработка, которая меняет входящий набор. в результате (языком аксапты) приходится делать queryrun.reset

Цитата:

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

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

никто не мешает.
правда SQL напрягается и готовит результаты для всей выборки, а не для 100 записей.
а в выборке может быть 100500+ записей

Цитата:

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

и откуда уверенность что
"в режиме paging SQL должен использовать существенно меньше памяти для хранения результатов выборки. а также готовить результат гораздо быстрее."

Ну, конечно же с Аксаптой у меня никакой уверенности нет )
Поэтому и спрашиваю.

А вообще говоря, весь интернет именно на этом и живет - без paiging ни один боль-мень серьезный форум, ни один фейсбук-вконтакт не выживет. я ж привел ссылку "идея разбиения на страницы, например, здесь http://www.quizful.net/post/paging-in-sql " можно еще поискать.

Цитата:

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

как минимум если будет сортировка не по индексам это не так

бггг. вообще говоря, выборка индексов и выборка данных по найденным индексам - на SQL - это разные вещи Думаю, что стоит почитать теорию.

Давайте вернемся к вопросу.
В Аксапте кто-нибудь этот paging использовал?

[AP-1055D]

Цитата:

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

А вообще говоря, весь интернет именно на этом и живет - без paiging ни один боль-мень серьезный форум, ни один фейсбук-вконтакт не выживет.

Я думаю, что вы немного неправильно употребляете термин пагинация (paging). Пагинация это механизм, с помощью которого можно "отдавать" данные определёнными порциями. В терминах MVC (Model-View-Controller) это C (Controller). По ссылке, которую вы привели, речь идёт как раз о том, как можно отдавать клиенту небольшое количество записей. Здесь ключевое слово "отдавать", а не получать. То есть чтобы по HTTP-запросу клиенту ушло не все 1000 записей, которые он должен будет потом как-то отображать, а только какую-то порцию, часть этих данных, например 20 записей. При этом, сам запрос не оптимизируется настолько сильно, что он будет обрабатывать меньшее количество записей. Конечно, для простых запросов оптимизатор СУБД сможет построить план с помощью которого будут выбраны те самые 20 записей или несколько больше. Но для более сложных запросов операции TOP или условие по ROW_NUMBER будут выполняться уже в качестве фильтра, то есть отсекать лишние записи. Именно поэтому вы видите большее количество по счётчикам в SQL Server: сервер выбирает множество записей, но клиенту возвращается только часть этих данных.

Facebook, VK и другие используют витрины данных, в которых находятся актуальные данные, например, за последнюю неделю или день. Также они использую горячий кэш и другое.

Кстати, витрины данных очень часто используются в DWH: когда в хранилище есть данные за 20 лет, а, фактически, для оперативного анализа нужны данные только за последнюю неделю. В качестве решения делают витрину данных, куда с помощью ETL/ELT собирают нужные актуальные часто используемые данные. Даже in-memory системы у которых время выполнения "запроса" на порядки меньше чем у ROLAP, также используют витрины. Иначе не хватит никакой памяти :-) Также можно подумать о партицировании таблицы: то есть физически разбивать таблицу на несколько более мелких таблиц. Этот метод очень активно используется в SSAS на более-менее крупных данных.

В AX хорошим примеров витрины данных является InventSum.

[mazzy]

Цитата:

Сообщение от Maxim Gorbunov

Посмотри методы в классе SysEPDeployment deployCompanyImages() -> loopOverImagesInPartition() -> getImagesFromPartition() (это в AX 2012).

ага. спасибо. посмотрю.

Цитата:

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

Сначала определись, это "заморачивание ради заморачивания" или есть конкретная проблема которую надо решить. В моем случае...

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

Цитата:

Сообщение от AP-1055D

Я думаю, что вы немного неправильно употребляете термин пагинация (paging). Пагинация это механизм, с помощью которого можно "отдавать" данные определёнными порциями. В терминах MVC (Model-View-Controller) это C (Controller). По ссылке, которую вы привели, речь идёт как раз о том, как можно отдавать клиенту небольшое количество записей.
...
В AX хорошим примеров витрины данных является InventSum.

Возможно и неправильно.
Да, клиент запрашивает порцию, а SQL отдает и готовит только порцию, а не всю выборку. Да, у SQL возникают дополнительные накладные расходы когда запрашивается порция, близкая к концу выборки.

но я не зря начал говорить про операции типа "сопоставление" )))
см. начало ветки.

да, про витрины данных понял.

==========================
мне коллеги подсказали доку. оказывается есть описалово.
оказывается по-русски это называется "подкачка данных". кто бы мог подумать!

дока в книге "Справочник профессионала. Microsoft Dynamics AX 2009".
Авторы Ларс Олсен и прочие.
вышло в 2009 году под патронажем АНД Проджект
Скриншоты:
https://yadi.sk/i/mSWTMBbKjNH8H
https://yadi.sk/i/9xTQDYjAjNHAs
https://yadi.sk/i/buBvwyYCjNHCw
https://yadi.sk/i/yfToQi9sjNHEB

Да, как я и ожидал, используется ROW_NUMBER со всеми его ограничениями, достоинствами и недостатками.
https://msdn.microsoft.com/ru-ru/lib...=sql.110).aspx
https://support.microsoft.com/ru-ru/kb/186133

Спасибо!

[AP-1055D]

Цитата:

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

Да, клиент запрашивает порцию, а SQL отдает и готовит только порцию, а не всю выборку.

Не совсем так. SQL Server будет обрабатывать все 1000 записей или более, потом наложит на них ограничение в виде TOP или ROW_NUMBER и выдаст как раз те самые 10 записей. Для простых запрос, возможно, получиться сократить объём обрабатываемых данных до 900 записей, а может и не получится.

[AndyD]

Цитата:

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

идея в том, чтобы сказать как то SQL'ю что не нужно делать выборку всех-всех-всех записей (а их там может быть сотни тысяч)
а достаточно выбрать первые 1000 или 100... но в случае необходимости, дозапросить еще.

Так Аксапта именно так и делает, что в Query, что в select'е - смотри серверные курсоры

Только, количеством записей, возвращаемых с сервера за раз мы не управляем

И, как правильно выше заметили - это не значит, что SQL не будет напрягаться и хранить результат, если запрос связан с сортировками/группировками/объединениями

[mazzy]

Цитата:

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

Так Аксапта именно так и делает, что в Query, что в select'е - смотри серверные курсоры

да, я в курсе, что так должно быть.
но судя по логам и счетчикам на SQL - это не совсем так. по крайней мере для 2009.

Цитата:

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

Только, количеством записей, возвращаемых с сервера за раз мы не управляем

угу.
я также в курсе про параметр "размер буфера", который был в конфигурационной утилите прошлых версий.

хорошо, переформулирую вопрос.

в Аксапте 2009 в QueryRun появились методы, которые, судя по названию, позволяют каким-то образом управлять paging. в частности, включать(!!) paging. Ссылки на msdn с примерами я привел в самом начале.

Вопрос: У кого есть опыт работы с paging-методами в Query? Стоит ли этим заморачиваться?

[Vadik]

Цитата:

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

Вопрос: У кого есть опыт работы с paging-методами в Query?

Я использовал (опосредованно) с AIF и его change tracking

Цитата:

Стоит ли этим заморачиваться?

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

Цитата:

Сообщение от Maxim Gorbunov

Если верить вот этому - https://technet.microsoft.com/en-us/.../gg840967.aspx - paging автоматически включается для всех запросов через Query Service

Скорее, paging "поддерживается" - параметры для него опциональные и по умолчанию используется одна "безразмерная" страница - т.е. поведение ровно то же что и без него

Цитата:

If you pass a NULL paging object to the query service, it will not use any paging and will return all records for the specified query up to the maximum record limit

[mazzy]

Цитата:

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

И, как правильно выше заметили - это не значит, что SQL не будет напрягаться и хранить результат, если запрос связан с сортировками/группировками/объединениями

Похоже таки надо сказать несколько слов по поводу сортировок и "напрягаться".
определения:

1. MS SQL хранит данные экстентами, которые состоят из 8Кб-страниц. MS SQL отравляет на диск команду чтения/записи для всего экстента. меньшими порциями MS SQL дисковые операции не делает.
2. данные (record) хранятся в страницах. в каждой 8кб странице умещается несколько строк (record). В частности это означает, что максимальный объем хранения в одной записи в MS SQL - 8Кб
3. индекс - это маленкая запись ))) Да с натяжкой, но в данном случае отличия не важны. Важно, что индексы также хранятся в страницах. столько индексов, сколько уместится на страницу.
4. индексы как правило (Бггг!) отсортированы, и с огромной вероятностью нужные для выборки строки индекса хранятся рядом на одном экстенте.
5. для сортировки MS SQL все равно прочтет с диска экстенты с индексами. Прочтет в любом случае (почти в любом - есть кластерные индексы, есть покрывающие индексы)
6. важно! размер индекса как правило существенно меньше размера записи. обычно индексы содержат поля, сумма которых 60-200 байт. А размер записи с данными легко может составлять 1000-3000 байт. см. vendTrans, см. InventTrans, inventSellement.

собственно проблема:

1. после сортировки, после того, как SQL определил какие записи нужно вернуть, для выдачи результатов в Аксапту MS SQL будет читать экстенты с записями (record). МНОГО. поскольку сами записи больше и раскиданы по разным экстентам, операций чтения данных будет много.
2. поскольку прочитанные данные (record) достаточно объемные, СКЛю нужно очень много "временной" памяти, чтобы хранить полученные результаты и выдать их в Аксапту при следующем QueryRun.next
3. да, вроде должен использоваться курсор... но... есть счетчики и мониторинг в СКЛ, который позволяет увидеть, что большую часть времени для алгоритмов типа "сопоставление" SQL читает экстенты с данными впустую. По крайней мере, у меня сложилось стойкое впечатление, что это так.

еще раз:

• экстенты с индексами все равно будут прочитаны )))) даже не беспокойтесь об этом
• число читаемых с диска экстентов в индексами в разы, на порядки меньше числа экстентов с данными (это сделано специально, в этом и суть индексов )
• беспокоит число операций чтения самих данных, которые SQL готовит для отдачи Аксапте.
• суть paging в том, что SQL хранит у себя ссылки на данные (небольшой объем памяти), а сами данные читает по мере запроса страниц. Причем программист может управлять размером порции, которая готовится SQL'ем и отдается в ответ на запрос.

В операциях, которые делают выборку, по каким-то бизнес-условиям забирают несколько записей из выборки и изменяют выборку (операции типа сопоставление)...
в таких операциях хотелось бы использовать управляемый paging.

собственно отсюда и вопрос - У кого есть опыт работы с paging-методами в Query? Стоит ли этим заморачиваться?
в частности, даст ли гемор с pagin'ом лучший результат, чем автоматическая работа с однонаправленным серверным курсором?

[Maxim Gorbunov]

Если верить вот этому - https://technet.microsoft.com/en-us/.../gg840967.aspx - paging автоматически включается для всех запросов через Query Service. Могу ошибаться, но, как мне кажется, этим сервисом пользуется, например, Enterprise Portal, чтобы вытаскивать данные из Аксапты, и поэтому у GridView в web-контролах есть свойство AllowPaging.

Примеров использования в X++ не много, и они, в основном, связаны с реализацией сервисов. Если я правильно тебя понял, то ближе всего к тому, что ты ищешь, чтение из базы картинок перед их деплойментом на портал. Посмотри методы в классе SysEPDeployment deployCompanyImages() -> loopOverImagesInPartition() -> getImagesFromPartition() (это в AX 2012).

Только я не очень понимаю, как это тебе поможет оптимизировать закрытие или сопоставление. Исходя из чего ты собираешься ограничивать размер страницы? Кроме того, как уже было замечено, paging накладывает некоторые ограничения на сортировку/группировку (ну или наоборот, сортировка/группировка ограничивает paging).

[AP-1055D]

Наверное, в данном случае, это я неправильно понял вас. Если говорить о конечном результате, то, да, всё верно. А вот под капотом SQL Server все немного иначею

[AP-1055D]

Начиная с SQL Server 2012, для пагинации можно использовать OFFSET и FETCH:

SELECT DepartmentID, Name, GroupName
FROM HumanResources.Department
ORDER BY DepartmentID
OFFSET 10 ROWS
FETCH NEXT 10 ROWS ONLY;