Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Тяжелый запрос и выдача результата пользователю постранично / 15 сообщений из 15, страница 1 из 1
29.01.2017, 19:49
    #39394176
gandalf-the-grey
gandalf-the-grey
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
Коллеги, ещё один вопрос к коллективному разуму. По архитектуре, такскть.
Заранее благодарен за любые советы, кроме вредных.

Имеем веб-приложение + пул соединений --> каждый запрос с веба приходит в произвольную сессию из пула. Используем механизм прикладных псевдосессий для хранения окружения юзера.
Юзер что-то ищет, запросы могут быть от простых до очень тяжелых.
Результаты поиска юзеру на гуй надо отдавать постранично, а не всю портянку (которая может тупо в ОЗУ не влезть к нему, в худшем случае, до миллиона-двух записей, если юзер ленив и вообще параметры не задал, хочет хоть что-то увидеть, а такое допустимо).
Ах, да, ещё при этом гуй хочет знать сколько всего строк в результате.

Имеет смысл сохранять, например, в nologging-таблицу (не временную, ибо должна быть видима всем сессиям) по результатам поиска набор ROWID от ведущей таблицы, чтобы при перемещении юзера по страницам отдавать нужные порции, не выполняя основного тяжелого запроса;
Или это всё от лукавого и стоит переложить нагрузку на средний слой, обязав его доставать всю портянку и рулить постраничным разбиением самостоятельно?

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

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

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

Как сейчас принято такие задачи решать?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.01.2017, 20:47
    #39394196
gandalf-the-grey
gandalf-the-grey
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
Дополню:

Архитектуру придумали до нас и пока работаем с тем, что имеем. Есть кластер WebSphere, бэкенд на жаве, фронт на JS, и один единственный "мозг" на Oracle 11g.
БД получает данные из нескольких источников, агрегирует, преобразует. Это не OLTP, не DWH... Скорее что-то типа DSS. Но данные некоторые обновляются динамично, кэшировать не получится. Юзер хочет среди этих данных искать, цели и мотивы - разные. В общем случае он может ввести фильтры, по которым отберутся 99% записей. Надо обеспечить комфортную постраничную навигацию, учитывая вводные по архитектуре.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.01.2017, 21:58
    #39394235
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
gandalf-the-greyИли это всё от лукавого и стоит переложить нагрузку на средний слой, обязав его доставать
всю портянку и рулить постраничным разбиением самостоятельно?

Это будет оптимальнее. Особенно если этот средний слой будет портянку кэшировать и
отдавать по аналогичным запросам без повторного запроса с сервера.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.01.2017, 09:39
    #39394380
Alexls
Alexls
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
gandalf-the-grey,

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

Проблем тут минимум две
1. Серьезное увеличение времени первой выборки.
2. Если с таблицей можно работать из разных сессий то - время жизни данной таблицы.
Ведь если архитектура системы позволяет пользователю задавать параметры выборки с прогнозируемым result-set несколько миллионов, то кто ему помешает создать одну сессию, поработать с ней, пойти пообедать создать другую сессию, поработать с ней и т.д.

Так что пока - кэширование просмотренных страниц в пределах сессии работы с таблицей.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.01.2017, 13:07
    #39394563
Vint
Vint
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
Dimitry Sibiryakov,
[quot gandalf-the-grey]Но данные некоторые обновляются динамично, кэшировать не получится. /quot]

gandalf-the-grey,
oracle+pagination + result_cache информации в интернете валом. или вы думаете что вы такой первый?)
имхо средний слой вас не спасет. какой бы масштабируемый он не был.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.01.2017, 18:19
    #39394945
gandalf-the-grey
gandalf-the-grey
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
Vintgandalf-the-grey,
oracle+pagination + result_cache информации в интернете валом. или вы думаете что вы такой первый?)
имхо средний слой вас не спасет. какой бы масштабируемый он не был.

Да ладно, прям навалом? А вы смотрели сами результаты первого поиска??
Там ничего полезного, кроме баянного рецепта 20-летней давности от Тома
Код: plsql
1.
2.
3.
4.
5.
6.
select * 
  from 
( select rownum rnum, a.*
    from (your_query) a
   where rownum <= :M )
where rnum >= :N;

НЕТ
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.01.2017, 18:30
    #39394954
Vint
Vint
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
gandalf-the-grey,
я то смотрел, а ты? когда мне действильено была интересна тема пейджинга я докопался до этого . в твоих постах желания копать нет. есть желание нахаляву получить готовое решение. готов платить?)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.01.2017, 19:03
    #39394973
gandalf-the-grey
gandalf-the-grey
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
Vint,

Спасибо за последнюю ссылку. Желание копать есть, времени не хватает, очень много задач. Неспроста обе мои темы заведены в воскресенье...
Однако, FIRST_ROWS(N) пользуем. Другой вопрос, что выхлопа не замечаем.
И другой вопрос, что у нас пока есть обязательное требование отображать общее количество строк, удовлетворяющих условиям.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.01.2017, 22:23
    #39395027
SY
SY
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
gandalf-the-grey
И другой вопрос, что у нас пока есть обязательное требование отображать общее количество строк, удовлетворяющих условиям.

А зачем? Достаточно взять какое-либо разумное ограничение, например 50000 и "Ваш поиск возвращает слишком много строк(бoльше 50000). Пожалуйста уточните критерии поиска".

SY.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.01.2017, 11:23
    #39395251
Vint
Vint
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
gandalf-the-grey,
всех денег не заработаешь.))
"Другой вопрос, что выхлопа не замечаем." - план смотрели? или с секундомером сидели? статей по педжингу море. и подсчет общего количества строк в общем и целом не проблема) там куча подводных камней потом всплывает) например переход на последнюю страницу которая перестает существовать в момент перехода) кстати с 12 версии пейджинг по другому делается). и кстати советую почитать как педжинг делается в компаниях типа яндекса и гугля.

SY,
под всеми темами есть такая надпись "Страницы: 1 2 3 4 5 6 7 8 9 10 .. 2154" вот и они хотят)) чтобы все страницы было видно))
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.01.2017, 12:14
    #39395327
gandalf-the-grey
gandalf-the-grey
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
Vint,
Да, статей много, но реально полезных среди сотни пока только 2 прочитал, считая ваш pdf.
Подсчёт кол-ва строк пока для меня проблема - дважды приходится выполнять запрос на каждое обращение гуя.
А запросы тяжёлые, с множеством параметров.
С подводными камнями сталкивались, в частности, проблему отсутствия последней страницы уже решили.
Идея перейти на прикладное кэширование (хранить в результаты) возникла тоже неспроста.

Если вы уже прошли через это и можете посоветовать, куда копать, что почитать: буду благодарен.
Есть предположение (может и ошибочное), что совать всё в Result Cache не особо поможет для тяжелых многопараметрических запросов от пары тысяч юзеров.
Vintкак педжинг делается в компаниях типа яндекса и гугляИскал в первую очередь, в самом начале. Не нашёл. Может, хреново искал. Но есть правило: гуглю, если 15 мин результата нет - прекращаю. Время ценно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.01.2017, 13:01
    #39395393
Vint
Vint
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
"Подсчёт кол-ва строк пока для меня проблема - дважды приходится выполнять запрос на каждое обращение гуя." - count() over (). это последний совет)) остальное за деньги. вы не просто в начале пути? вы даже первый шаг в пейджинге не сделали))
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.01.2017, 17:17
    #39395707
SY
SY
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
Vintпод всеми темами есть такая надпись "Страницы: 1 2 3 4 5 6 7 8 9 10 .. 2154" вот и они хотят)) чтобы все страницы было видно))

Мало чeго они желают. Они будут читать вce 2154 cтраницы? Конечно-же нет. Так чем отличается "Страницы: 1 2 3 4 5 6 7 8 9 10 .. 2154" от, например, "Страницы: 1 2 3 4 5 6 7 8 9 10 .. 100"?

SY.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.01.2017, 17:38
    #39395732
Vint
Vint
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
SY,
я когда то тоже задавал схожий вопрос. ответ оказался прост. если надо посмотреть самую первую тему с которой начался этот форум. как это сделать в рамках текущей функциональности данного форума?)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.02.2017, 18:51
    #39396665
gandalf-the-grey
gandalf-the-grey
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тяжелый запрос и выдача результата пользователю постранично
Vint"Подсчёт кол-ва строк пока для меня проблема - дважды приходится выполнять запрос на каждое обращение гуя." - count() over (). это последний совет)) остальное за деньги. вы не просто в начале пути? вы даже первый шаг в пейджинге не сделали))

Простите, но Вы слишком самоуверенны.

без count() over()
 
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
SQL_ID  7zzkhu59wf6sv, child number 0
-------------------------------------
select --+ gather_plan_statistics tst31
         rownum rn, t.*
from ( 
select u.rowid 
from cmon_uploads u,
       cmon_serials s
where s.upload_id = u.upload_id
order by u.upload_id) t
where rownum <= 100

Plan hash value: 2396673459

------------------------------------------------------------------------------------------------------
| Id  | Operation            | Name                | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |                     |      1 |        |    100 |00:00:00.01 |       6 |
|*  1 |  COUNT STOPKEY       |                     |      1 |        |    100 |00:00:00.01 |       6 |
|   2 |   VIEW               |                     |      1 |    101 |    100 |00:00:00.01 |       6 |
|   3 |    NESTED LOOPS      |                     |      1 |    101 |    100 |00:00:00.01 |       6 |
|*  4 |     INDEX FULL SCAN  | CMON_SERIALS_UPLOAD |      1 |    801 |    100 |00:00:00.01 |       2 |
|*  5 |     INDEX UNIQUE SCAN| CMON_UPLOADS_PK     |    100 |      1 |    100 |00:00:00.01 |       4 |
------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(ROWNUM<=100)
   4 - filter("S"."UPLOAD_ID" IS NOT NULL)
   5 - access("S"."UPLOAD_ID"="U"."UPLOAD_ID")


c count() over()
 
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
SQL_ID  cwcxmkb725svu, child number 0
-------------------------------------
select --+ gather_plan_statistics tst32
         rownum rn, t.*
from ( 
select u.rowid, count(*) over () cnt
from cmon_uploads u,
       cmon_serials s
where s.upload_id = u.upload_id 
order by u.upload_id) t
where rownum <= 100

Plan hash value: 827397964

-------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                | Name                | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
-------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT         |                     |      1 |        |    100 |00:00:00.01 |      11 |       |       |          |
|*  1 |  COUNT STOPKEY           |                     |      1 |        |    100 |00:00:00.01 |      11 |       |       |          |
|   2 |   VIEW                   |                     |      1 |    778 |    100 |00:00:00.01 |      11 |       |       |          |
|   3 |    WINDOW SORT           |                     |      1 |    778 |    100 |00:00:00.01 |      11 | 46080 | 46080 |40960  (0)|
|   4 |     NESTED LOOPS         |                     |      1 |    778 |    801 |00:00:00.01 |      11 |       |       |          |
|*  5 |      INDEX FAST FULL SCAN| CMON_SERIALS_UPLOAD |      1 |    102 |    801 |00:00:00.01 |       7 |       |       |          |
|*  6 |      INDEX UNIQUE SCAN   | CMON_UPLOADS_PK     |    801 |      8 |    801 |00:00:00.01 |       4 |       |       |          |
-------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(ROWNUM<=100)
   5 - filter("S"."UPLOAD_ID" IS NOT NULL)
   6 - access("S"."UPLOAD_ID"="U"."UPLOAD_ID")

...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Тяжелый запрос и выдача результата пользователю постранично / 15 сообщений из 15, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 534ms
Закрыть
start [/forum/topic.php?fid=52&mobile=1&tid=1886525]:
 0ms
get settings:
 10ms
get forum list:
 24ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 201ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 39ms
get tp. blocked users:
 1ms
others: 238ms
total:  534ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]