Добрый день, уважаемые форумчане!
Прошу проконсультировать меня в следующем вопросе.
Есть поиск по БД. Поиск занимает значительное время (гео-координаты) и выдает довольно внушительный результат поиска.
Для вывод результата используется листинг.
Подскажите, пожалуйста, как грамотно организовать листинг (каждый раз запрашивать базу при переходе на новую страницу результатов поиска - это дополнительное время). Единственное, что мне пока пришло на ум - это записывать результаты поиска в переменную сессии и листать уже от туда, но меня смущает то что при росте посетителе переменные сессий будут сильно кушать ресурсы сервера!
Заранее благодарен за помощь !
Полная Версия: Долгий поиск и большой результат
Добрый день, frundik!
| Цитата (frundik @ 15.05.2013 - 21:06) |
| сильно кушать ресурсы сервера |
Тут уж тебе придется выбирать, быстрота для пользователя, или экономия на сервере. Если результат выборки реально большой, то можно сохранять список первичных ключей (в memcached, к примеру), и потом выбирать записи из БД по ним - будет намного быстрее.
P.S: А если выборка просто огромна, тогда стоит подумать над тем, чтобы хранить часть таблиц БД in memory.
| Цитата (Rand @ 15.05.2013 - 15:53) | ||
Добрый день, frundik!
Тут уж тебе придется выбирать, быстрота для пользователя, или экономия на сервере. Если результат выборки реально большой, то можно сохранять список первичных ключей (в memcached, к примеру), и потом выбирать записи из БД по ним - будет намного быстрее. P.S: А если выборка просто огромна, тогда стоит подумать над тем, чтобы хранить таблицы БД in memory. |
какой смысл, если "выборка огромна" (а значит и таблица)?
| Цитата (frundik @ 15.05.2013 - 15:06) |
| Добрый день, уважаемые форумчане! Прошу проконсультировать меня в следующем вопросе. Есть поиск по БД. Поиск занимает значительное время (гео-координаты) и выдает довольно внушительный результат поиска. Для вывод результата используется листинг. Подскажите, пожалуйста, как грамотно организовать листинг (каждый раз запрашивать базу при переходе на новую страницу результатов поиска - это дополнительное время). Единственное, что мне пока пришло на ум - это записывать результаты поиска в переменную сессии и листать уже от туда, но меня смущает то что при росте посетителе переменные сессий будут сильно кушать ресурсы сервера! Заранее благодарен за помощь ! |
Могу предположить, что организовали бд и обращения к ней вы весьма неудачно. Опишите алгоритм и релевантную структуру бд полностью, а там уж посмотрим, что стоит, а что не стоит делать
| Цитата (glock18 @ 15.05.2013 - 16:19) |
| Опишите алгоритм и релевантную структуру бд полностью, а там уж посмотрим, что стоит, а что не стоит делать |
Запись в базе содержит геоокординаты, которые представлены в виде полилайна. Поиск: принадлежность любой точки полилайна полигону-круг (в поиске задается точка, по радиусу строится этот самый круг полигон).
Суть: полилайн - это маршрут, полигон-круг (точка заданная на карте и определенный радиус), вот и надо определить принадлежность к маршруту !
| Цитата (glock18 @ 15.05.2013 - 22:16) |
| какой смысл, если "выборка огромна" (а значит и таблица)? |
Я не призываю хранить абсолютно всё в RAM, я лишь предположил, что какую-то часть наверняка можно перенести в память.
frundik, задача понятна. Непонятно что за СУБД, структура таблиц и текст запроса на выборку.
| Цитата |
| полигон-круг (точка заданная на карте и определенный радиус) |
намного лучше использовать квадрат. Выборка проще, результат, примерно тот же.
Я использую именно так. И более того, гугл так же возвращает координаты. Квадратом, 2 крайние точки, верхнюю левую и нижнюю правую(4мя координатами)
_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
Я использую именно так. И более того, гугл так же возвращает координаты. Квадратом, 2 крайние точки, верхнюю левую и нижнюю правую(4мя координатами)
_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
| Цитата (DedMorozzz @ 15.05.2013 - 16:59) |
| намного лучше использовать квадрат. Выборка проще, результат, примерно тот же. Я использую именно так. И более того, гугл так же возвращает координаты. Квадратом, 2 крайние точки, верхнюю левую и нижнюю правую(4мя координатами) |
Спасибо за совет. Я обязательно попробую ваш метод.
А с поиском, я так понимаю, что единственный выход всё таки записывать индексы в переменную сессии и уже непосредсвенно при листинге делать выборку из базы по индексам!?
| Цитата (frundik @ 15.05.2013 - 19:06) |
| Есть поиск по БД. Поиск занимает значительное время (гео-координаты) и выдает довольно внушительный результат поиска. |
В ответ на этот вопрос был задан встречный ответ
| Цитата (glock18 @ 15.05.2013 - 20:19) |
| Опишите алгоритм и релевантную структуру бд полностью, а там уж посмотрим, что стоит, а что не стоит делать |
Но автор темы не понятно, заметил ли это. Не то, что не прочитал... Но - не понял, судя по тому, что он ответил.
А начинать нужно именно с оптимизации структуры БД (структура таблиц и их связей, индексы, партиции и т.д.) и правильно организовывать запросы. Если выборка действительно большая, то, может быть, имеет смысл разбивать ее на части (страницы)?
И еще - всё перечисленное имеет специфику для каждого вида БД. Это только элементарные запросы одинаковые везде.
Какие там ты собрался "записывать индексы в переменную сессии" я так и не понял, если честно говорить
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Здесь расположена полная версия этой страницы.