XML - результаты поиска/Поиск туров/Буфер поиска — различия между версиями
Jeka (обсуждение | вклад) (Новая страница: «Буфер поиска - искусственное ограничение на возможное количество найденных туров в резу…») |
м (Artemandreev переименовал страницу XML экспорт/Поиск туров/Буфер поиска в XML - результаты поиска/Поиск туров/Буфер поиска) |
||
| (не показаны 13 промежуточные версии 1 участника) | |||
| Строка 4: | Строка 4: | ||
| − | + | Если вам кажется это странным, посмотрите на Яндекс и Google, если пролистать их результаты будет видно что они позволяют находить не более 1000 сайтов. | |
| + | === Автоматическая корректировка размера буфера === | ||
| + | Для поиска туров наиболее критично время ответа с данными запрошенными пользователем, которое значительно увеличилось с введением технологии онлайн-поиска. Поэтому поиск даже 2500 записей может отнять время и создать дополнительные накладные расходы. При том что на практике редко кто из пользователей вообще будет пролистывать дальше первых 3-х страниц. | ||
| − | |||
| + | Для оптимизации этого процесса в нашей системе используется '''автоматическая корректировка размера буфера'''. | ||
| + | Это означает что размер буфера выбирается на основе запрошенной страницы данных и ее размера. | ||
| + | |||
| + | * Минимальный размер буфера - 500 записей. | ||
| + | * Максимальный размер буфера - 2500 записей. | ||
| + | |||
| + | Именно это количество будет возвращено сервисом как количество найденных туров, в случае если в системе их больше. Это не означает что это все туры которые есть в системе по данному запросу, это означает что найдено туров больше чем размер буфера. | ||
| + | |||
| + | Буфер выбирается таким образом чтобы в него попало данных чуть больше чем необходимо для запрошенной страницы. | ||
| + | |||
| + | |||
| + | ''Например:'' | ||
| + | |||
| + | Если вы запросили 5-ю страницу размером 50 записей, будет выбран буфер 500 записей. Если же теперь запросить 10-ю страницу размером 50 записей, будет выбран буфер в 1000 записей. | ||
| − | |||
| + | '''Обратите внимание:''' при изменении размера буфера инициируется новый поиск (т.е. закешированный результат использоваться уже не будет и поиск начнется заново). | ||
| − | === | + | === Организация постраничной навигации на сайте === |
| − | + | Не смотря на всю сложность в получении результата и выбора размера буфера в нашей системе, организация постраничной навигации в этом случае для клиента предельно проста. Вы в каждый момент поиска просто рассчитываете количество страниц исходя из количества найденных туров, которые вернул сервис (это количество будет меняться по мере нахождения новых данных). | |
| − | + | ||
| − | + | Единственное на что стоит обращать внимание это поле '''exactCount''' объекта '''Статус поиска'''. В случае если оно true, это означает что найдено ровно такое количество туров. В случае если оно false это означает что количество туров ограничено буфером поиска. В этом случае необходимо это обозначить для пользователя (например - "найдено более 500 туров", ">500", "500+"), и дать возможность ему кликнуть на несколько страниц вперед. В случае если он это сделает, поисковый запрос к этой странице инициирует новый поиск с увеличенным буфером, и пользователь получит данные. | |
Текущая версия на 15:40, 22 декабря 2014
Буфер поиска - искусственное ограничение на возможное количество найденных туров в результатах поиска.
Необходимость введения буфера продиктована большими объемами данных которые потенциально могут быть выбраны в результате поискового запроса. Простыми словами архитектура поиска не позволяет выбирать более N туров, где N размер буфера.
Если вам кажется это странным, посмотрите на Яндекс и Google, если пролистать их результаты будет видно что они позволяют находить не более 1000 сайтов.
Автоматическая корректировка размера буфера
Для поиска туров наиболее критично время ответа с данными запрошенными пользователем, которое значительно увеличилось с введением технологии онлайн-поиска. Поэтому поиск даже 2500 записей может отнять время и создать дополнительные накладные расходы. При том что на практике редко кто из пользователей вообще будет пролистывать дальше первых 3-х страниц.
Для оптимизации этого процесса в нашей системе используется автоматическая корректировка размера буфера.
Это означает что размер буфера выбирается на основе запрошенной страницы данных и ее размера.
- Минимальный размер буфера - 500 записей.
- Максимальный размер буфера - 2500 записей.
Именно это количество будет возвращено сервисом как количество найденных туров, в случае если в системе их больше. Это не означает что это все туры которые есть в системе по данному запросу, это означает что найдено туров больше чем размер буфера.
Буфер выбирается таким образом чтобы в него попало данных чуть больше чем необходимо для запрошенной страницы.
Например:
Если вы запросили 5-ю страницу размером 50 записей, будет выбран буфер 500 записей. Если же теперь запросить 10-ю страницу размером 50 записей, будет выбран буфер в 1000 записей.
Обратите внимание: при изменении размера буфера инициируется новый поиск (т.е. закешированный результат использоваться уже не будет и поиск начнется заново).
Организация постраничной навигации на сайте
Не смотря на всю сложность в получении результата и выбора размера буфера в нашей системе, организация постраничной навигации в этом случае для клиента предельно проста. Вы в каждый момент поиска просто рассчитываете количество страниц исходя из количества найденных туров, которые вернул сервис (это количество будет меняться по мере нахождения новых данных).
Единственное на что стоит обращать внимание это поле exactCount объекта Статус поиска. В случае если оно true, это означает что найдено ровно такое количество туров. В случае если оно false это означает что количество туров ограничено буфером поиска. В этом случае необходимо это обозначить для пользователя (например - "найдено более 500 туров", ">500", "500+"), и дать возможность ему кликнуть на несколько страниц вперед. В случае если он это сделает, поисковый запрос к этой странице инициирует новый поиск с увеличенным буфером, и пользователь получит данные.
