[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Пагинация
Страницы: 1, 2
sergeiss
Цитата (Игорь_Vasinsky @ 9.01.2015 - 03:43)
при сегментировании данные выбираются из нужной секции, которая отвечает условию. не больше - не меньше. и если условие затрагивает несколько секций - то и несколько секций участвует в опросе - но не как не все.

Вот именно - условие (WHERE). Но не LIMIT!!! Лимит к условиям никаким боком не относится.

Прочитай таки тему с самого начала... Ты стал упорно говорить про партицирование, хотя я многократно пытался обратить твое внимание на то, что у Павла проблема такая, которой партицирование практически не поможет. А ты продолжаешь с упорством, достойным лучшего применения, говорить про партицирование. Павел спросил - и правильно поставил вопрос - об АЛГОРИТМЕ, улучшающем работу.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
Игорь_Vasinsky
Цитата
Прочитай таки тему с самого начала

biggrin.gif biggrin.gif biggrin.gif

ну ты петросян.

я ему не предлагал решение с лимитом - я ему предлагал решение для пагинации больших объёмов данных.

Цитата
и правильно поставил вопрос - об АЛГОРИТМЕ


1. спроектировать и задать схему сегментирования
2. разбить таблицы на сегменты
3. переписать запрос под сегментированные таблицы

чем тебе не алгоритм?

путаешь понятия - алгоритм и логика.

Цитата
что у Павла проблема такая, которой партицирование практически не поможет


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



_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
paul85
sergeiss, ну с юзабилити более или менее разобрались. Хотя мне бы конечно хотелось отображать цифры (номера) страниц, как в гугле или яндексе. Но там, очевидно, в силу формирования индексов "без дыр" расчет идет арифметическим способом. Чего в моем случае добиться не представляется возможным.

Очень важный момент для поисковых машин. Хочется показать всё что есть под индексацию. Но если резать количество отображаемых страниц, или кнопку "еще", которая будет на JS, то ни один робот не увидит всех товаров.

Игорь, а с партициями я все-равно не понял. Там кажется есть огромный гемор с заведением, скажем, 11-й партиции? То есть этот момент нужно тоже прорабатывать. Поскольку данные могут единовременно прибавиться в БД в количестве 20-30к и более. Насколько я понял, партиционирование очень плохо дружит с масштабируемостью.

Опять же, что делать с "дырами"? То есть нужно как-то хэндлить "остаток" строк в каждой партиции и при добавлении распихивать сначала туда... Что взять индексом партиции? Короче мне вообще не понятно. Если объяснишь подробно (ну как будто бы мне 3 года) - низкий поклон тебе.

Цитата (Игорь_Vasinsky @ 9.01.2015 - 03:13)
а вообще - нужно было предвидеть такой объём на этапе проектирования и исходя из этого подбирать железо.

Это был магазин одного бренда. Я посидел-подумал и решил, что больше 10к товаров там ну никак не будет. А клиент возьми и залуди туда еще пару брендов. В итоге общее количество товаров возросло до 80+к. Естественно относительно скромная VDS-ка стала чуточку подтормаживать на последних страничках. Там у меня получилось чего-то 8000+ страниц. Время обработки запроса приблизилось к нескольким десятым секунды, кажется около 0,4-0,6. А я глубоко убежден, что ни один запрос не должен отрабатываться дольше 5 сотых. Ну максимум 1 десятую... Только когда уже все методы оптимизации использованы, тогда уже решать вопрос железом. ИМХО такое, может быть чуточку странное...

Свернутый текст
*На правах хвастовства. Там же я переделывал структуру хранения каталогов под произвольную вложенность. Сделал, конечно, классно! Применил Closure Table + Adjacency List. С хлебными крохами, с тасканием и копированием субдеревьев, короче вообще классно, реально. Бывает так, что сделаешь и сам протащишься. Вот как раз мой случай. =))


Игорь_Vasinsky
paul85
портации будут автоматом создаваться в зависимости от схемы, которую ты задал.

Цитата
партиционирование очень плохо дружит с масштабируемостью.


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

Цитата
Что взять индексом партиции?

самое популярное, как я и писал - дата чего либо. но в твоём случае, либо ID либо псевдо ID

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
sergeiss
paul85, я понял, что Игорю бесполезно объяснять smile.gif Но ты мне поверь: в твоем случае партиции не помогут для решения основной задачи. Да, они могут ускорить выборку в ряде случаев (при правильном использовании), но если у тебя будет тот самый "LIMIT 50000, 100" или что-то подобное, то партиции будут бессильны.

Кстати говоря, я тоже сторонник партиций wink.gif Но только хорошо надо понимать, где и как они могут помочь.


Цитата (paul85 @ 9.01.2015 - 03:57)
Очень важный момент для поисковых машин. Хочется показать всё что есть под индексацию. Но если резать количество отображаемых страниц, или кнопку "еще", которая будет на JS, то ни один робот не увидит всех товаров.

Для роботов можно что-то другое сделать. Например, указать ссылки на страницы со всеми товарами в sitemap.xml.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
Игорь_Vasinsky
sergeiss
сигналы сотовых сетей на тебя плохо влияют.

https://ru.wikipedia.org/wiki/MySQL

Цитата
Сегментирование — возможность разбить одну большую таблицу на несколько частей, размещенных в разных файловых системах, основываясь на определенной пользователем функции. При определенных условиях это может дать серьёзное увеличение производительности и, кроме того, облегчает масштабирование таблиц.


увеличение производительности

а у Павла 1й строкой

Цитата
Каким образом можно реализовать пагинацию больших таблиц (свыше 100к записей) без потери производительности?


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

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
sergeiss
Игорь, я тебе еще раз повторю (уже сбился со счета, сколько раз это сказал в этой теме, причем одному-единственному форумчанину): у Павла основной вопрос был про АЛГОРИТМЫ работы. Понимаешь, АЛГОРИТМЫ!!! Каким образом будет лучше реализовать работу с пагинацией. Он там даже разные варианты привел, как можно пагинацию реализовать.
Ты же упёрся в партицирование как в панацею "на все случаи жизни". Да, еще раз повторю, в определенных случаях она может помочь, но это не панацея!

Как ты правильно заметил "иди проспись" smile.gif Только примени это к себе.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
Игорь_Vasinsky
Цитата
но это не панацея!


Свернутый текст
user posted image


_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
Michael
а вот сразу из нагугленного попробуй.

_____________
There never was a struggle in the soul of a good man that was not hard
T1grOK
Цитата (Michael @ 9.01.2015 - 06:32)
а вот сразу из нагугленного попробуй.

Такая штука подойдет все таки в простых ситуациях, без множества параметризаций(для которых все таки Sphinx незаменимая вещь).
И к слову, дело не в JOIN даже(c тем же успехом можно было бы использовать IN), а в том, что мы узнаем конкретные id в пределах индекса и потом, опять же по индексу сразу берем конкретные записи.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
inpost
paul85
У меня на 40 млн. не тормозит стандартная пагинация. Один из лучших способов - не давать возможность открыть ПОСЛЕДНЮЮ страницу, а лишь первые 5-10. Где-то читал, что при стандартной пагинации без такой возможности максимум люди доходят до 5-10 странице и всё.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
T1grOK
Цитата (inpost @ 9.01.2015 - 12:15)
Где-то читал, что при стандартной пагинации без такой возможности максимум люди доходят до 5-10 странице и всё.

Я такой дотошный пройду по всем страницам) или начну с конца)
Личный рекорд: в гугле дошел до 17-ой страницы)

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
inpost
T1grOK
Парочку тяжелых запросов вряд ли нанесут вред сайту. У меня вот боты-парсеры всё ходят по всей пагинации и ничего, опасности пока не вижу.
Как говорят в highload, что решать проблему производительности надо с определения проблемных мест системы. Пока что в этой части проблем не было. Хотя через поиск-фильтров там не более 100 страниц.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
paul85
Цитата (sergeiss @ 9.01.2015 - 04:15)
Для роботов можно что-то другое сделать. Например, указать ссылки на страницы со всеми товарами в sitemap.xml.

Да, я тоже примерно так и подумал. А разве это хорошо, когда на страницу нет ссылок, кроме из sitemap.xml? Часть товаров заведена в каталог... Но больше половины товаров ищется напрямую - полнотекстовым поиском.

Тут, кстати, раз уж речь о сфинксе зашла... Скажите, получается нет разницы в производительности между INNER JOIN и WHERE IN?

Цитата (Michael @ 9.01.2015 - 10:32)
а вот сразу из нагугленного попробуй.

Так и сделано. Да, с помощью данного варианта удалось несколько сократить время. Примерно в 2 раза засчет того, что внутренний запрос работает с ограниченным объемом данных. Но все-равно не панацея, потому, что товаров завтра может стать не 80к а 160к, причем запросто. И снова здравствуй проблема.

Вот он, кстати, запрос, если что. На отображение всего, что есть:
Свернутый текст
<pre class="sh_sourceCode" rel="sql"><span class="sh_keyword">SELECT</span>
t<span class="sh_symbol">.</span>product_id<span class="sh_symbol">,</span>
t<span class="sh_symbol">.</span>product_partnumber<span class="sh_symbol">,</span>
t<span class="sh_symbol">.</span>product_description<span class="sh_symbol">,</span>
q<span class="sh_symbol">.</span>product_price<span class="sh_symbol">,</span>
p<span class="sh_symbol">.</span>photo_id
<span class="sh_keyword">FROM</span><span class="sh_symbol">(</span>
<span class="sh_keyword">SELECT</span>
temp1<span class="sh_symbol">.</span>product_id<span class="sh_symbol">,</span>
CEIL<span class="sh_symbol">(</span>temp1<span class="sh_symbol">.</span>product_price<span class="sh_symbol">*</span>temp2<span class="sh_symbol">.</span>currency_value <span class="sh_symbol">- (</span>temp1<span class="sh_symbol">.</span>product_price<span class="sh_symbol">*</span>temp2<span class="sh_symbol">.</span>currency_value<span class="sh_symbol">/</span><span class="sh_number">100</span><span class="sh_symbol">*</span><span class="sh_number">0</span><span class="sh_symbol">))</span> <span class="sh_keyword">AS</span> product_price
<span class="sh_keyword">FROM</span>
product <span class="sh_keyword">AS</span> temp1
<span class="sh_keyword">INNER JOIN</span>
currency <span class="sh_keyword">as</span> temp2
<span class="sh_keyword">ON</span>
temp1<span class="sh_symbol">.</span>currency_numcode<span class="sh_symbol">=</span>temp2<span class="sh_symbol">.</span>currency_numcode
<span class="sh_keyword">LIMIT</span> <span class="sh_number">0</span><span class="sh_symbol">,</span> <span class="sh_number">10</span><span class="sh_symbol">)</span> <span class="sh_keyword">AS</span> q
<span class="sh_keyword">INNER JOIN</span>
product <span class="sh_keyword">AS</span> t
<span class="sh_keyword">ON</span>
q<span class="sh_symbol">.</span>product_id <span class="sh_symbol">=</span> t<span class="sh_symbol">.</span>product_id
<span class="sh_keyword">LEFT JOIN</span>
photo <span class="sh_keyword">AS</span> p
<span class="sh_keyword">ON</span>
q<span class="sh_symbol">.</span>product_id<span class="sh_symbol">=</span>p<span class="sh_symbol">.</span>product_id</pre>


Цитата (inpost @ 9.01.2015 - 16:15)
У меня на 40 млн. не тормозит стандартная пагинация.

inpost, а что за проект, если не секрет? Где на него можно взглянуть?

Цитата (T1grOK @ 9.01.2015 - 17:10)
Личный рекорд: в гугле дошел до 17-ой страницы)

Ну можно сделать отображение первых 50-ти страниц. Ничего страшного. =) Кстати, по-моему в гугле около 40-ка страниц отображается.

Цитата (inpost @ 9.01.2015 - 17:25)
У меня вот боты-парсеры всё ходят по всей пагинации и ничего, опасности пока не вижу.

А как они там оказываются, если количество страниц в выдаче искусственно зарезано? Или это решено через анализ клиента? То есть пришел робот - ему показывать всё. А клиентам только первые N?

И вообще, вот робот увидел на странице 2434 какой-то товар. В поиске (яндекс) выдал ссылку на эту страницу. Пользователь туда по этой ссылке пошел. И что увидел? =)) В каком виде у него отобразился pagebar?
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.