Оптимизация sql

[ArtemPitov]

Доброго времени суток господа!

Вопрос довольно интересный (для меня так точно), речь пойдет об оптимизации SQL, а в частности подсчета строк для той же пагинации, 

для решения задачи есть 2а варианта SQL_CALC_FOUND_ROWS или count(*)

 

Какой оптимальнее использовать когда записывай за 10 000? 

 

Спасибо !

[chukcha]

Грубо..

Если нет условий - то count(*)

если есть условия, то  SQL_CALC_FOUND_ROWS

 

Не грубо

 

Если есть индекс, то count

если нет индекса

 

WHERE name LIKE '%patern%', то SQL_CALC_FOUND_ROWS

 

Ну и  ORDER BY и LIMIT - типа все равно все таблица перебирается.

Змінено 2 серпня 2016 користувачем chukcha

[markimax]

chukcha, Как везде пишут SQL_CALC_FOUND_ROWS "по любому" быстрее count, за счет внутренней оптимизации MySQL

Другое дело что не всегда можно использовать SQL_CALC_FOUND_ROWS, к примеру в подзапросах.

[ArtemPitov]

Ну и  ORDER BY и LIMIT - типа все равно все таблица перебирается.

Куда без них, я подбираю оптимальное решения для панагии

 

Тогда скорее будет работать вариант с count(*), если после выборки написать что то типа 

SELECT COUNT(id) FROM ` tab_name`

[ArtemPitov]

Как везде пишут SQL_CALC_FOUND_ROWS "по любому" быстрее count, за счет внутренней оптимизации MySQL

Другое дело что не всегда можно использовать SQL_CALC_FOUND_ROWS, к примеру в подзапросах. 

 

 

 

При использовании выборки по колонкам с индексам однозначно быстрее «классическая» схема. При использовании же колонок без индексов, а также смешанных запросов, быстрее становится функция FOUND_ROWS(), однако её выигрыш весьма незначителен.

https://habrahabr.ru/post/64655/

 

Стаття довольно старая, Вы случайно не тестили на сколько есть различия ? 

[snastik]

https://habrahabr.ru/post/64655/

 

Стаття довольно старая, Вы случайно не тестили на сколько есть различия ? 

 

Поставьте ocstore 1.5.5.1 (с модификациями уважаемого Toporchillo) и чистый OPencart 1.5.5.1 налейте тестовую базу в пару тыщ товаров в одну категорию и увидите результат...

Где то процентов 80 сокращения ttfb.

 

Хотя на 100 000 товаров в одной категории. Ни индексы. Ни FOUND_ROWS не помогут )

[ArtemPitov]

Поставьте ocstore 1.5.5.1 (с модификациями уважаемого Toporchillo) 

я как раз на 1.5.5.1 шяс пилю, правильно я понимаю ocstore 1.5.5.1 уже с коробки с модификациями от Toporchillo ? 

 

 

 

Хотя на 100 000 товаров в одной категории. Ни индексы. Ни FOUND_ROWS не помогут )

+ Кеш + CDN для картинок тоже сильно не спасут ? 

 

+ под это нужен нормальный VDS с ginx+php-fpm еще читал сюда апачь крутят (правда тут я совсем далек, пока не изучал данную тематику)

[snastik]

1.5.5.1 - да.

CDN для картинок  и php-fm  - это сектанты с fl.ru такие оптимизации предлагают.

Актуально только для 500к+ pageview, когда сервер не справляется с отдачей статичного контента (не забываем что до этого мы переводим практически все страницы в статичный html).

 

Т.е. нужн понимать, что apache 2, не сильно немощней nginx, и статики он может вылить в мир ровно столько, сколько может позволить это исходящий канал (берем в расчет, что сервер у нас не шаред )))).

 

А вот если говорить о 100к товаров.. на категорию - то тут есть несколько вариантов. Либо делать отельную count табилцу и обновлять ее при изменении товара. И пагинацию переводить на wildcard как в Гугле.

 

Либо использовать индексирующую прокладку в виде sphinx.

Да да его можно не только для поиска использовать!

[ArtemPitov]

(не забываем что до этого мы переводим практически все страницы в статичный html).

то есть при первом запросе пишем все модули в кеш и дергаем оттуда, правильно я понимаю  ? 

 

 

 

Либо делать отельную count табилцу и обновлять ее при изменении товара.

Какие основные данные будут сюда вноситься ? 

 

 

 

 И пагинацию переводить на wildcard как в Гугле.

Бросьте что то почитать по этому поводу, не нагуглил =(

 

 

 

Либо использовать индексирующую прокладку в виде sphinx.

Да да его можно не только для поиска использовать!

Интересно, нужно будет поковыряться посмотреть что можно придумать, спасибо 

[snastik]

то есть при первом запросе пишем все модули в кеш и дергаем оттуда, правильно я понимаю  ? 

 

Какие основные данные будут сюда вноситься ? 

 

Бросьте что то почитать по этому поводу, не нагуглил =(

 

Интересно, нужно будет поковыряться посмотреть что можно придумать, спасибо 

1. Запускаем паука, который планомерно укладывает в кеш страницы категорий/товаров, сохраняя их как plain/html (скорость отдачи таких страниц даж не 200мс, а десятитысячные доли секунды)

2. Вам же необходимо было посчитать тотал в категориях - вот берем и считаем. Или по крону. Или при первом обращении к странице с укладкой потом значения в таблицу и дальнейших манипуляций с этой таблицей, когда добавляете-удаляете-переносите товар.

3. https://habrahabr.ru/post/44608/

4. http://www.opencart.com/index.php?route=extension/extension/info&extension_id=18266

[ArtemPitov]

1. Запускаем паука, который планомерно укладывает в кеш страницы категорий/товаров, сохраняя их как plain/html (скорость отдачи таких страниц даж не 200мс, а десятитысячные доли секунды)

2. Вам же необходимо было посчитать тотал в категориях - вот берем и считаем. Или по крону. Или при первом обращении к странице с укладкой потом значения в таблицу и дальнейших манипуляций с этой таблицей, когда добавляете-удаляете-переносите товар.

3. https://habrahabr.ru/post/44608/

4. http://www.opencart.com/index.php?route=extension/extension/info&extension_id=18266

Спасибо !

[snastik]

Но на самом деле у всех этих методов - есть большая обратная сторона.

Называется - денормализация.

 

Автоматически все фильтры, поиск и любой постраничный вывод товаров. Который может быть необходим, нужно дорабатывать.

При чем дорабатывать крепко.

Часть фукнционала - без вопросов. Часть закодировано.

А так как сервер который может держать 50 000-100 000 уников в день на магазине в 20-30к товаров стоит на сегодня всего $60  в месяц. Экономическая целесообразность танцев с бубном, нивелируется низкой стоимостью вычислительных ресурсов.

 

Возможно через год-два. И будет какая то эконономия. Но все таки чем меньше критичных изменений в дефолтном коде - тем проще всем жить.

[ArtemPitov]

Но на самом деле у всех этих методов - есть большая обратная сторона.

Называется - денормализация.

Злая это штука, и здорово может запутать, а также половину моделей нужно выкинуть тогда 

 

Ну и еще минус (цитата с Хабра)

 

 

В денормализованной базе данных повышается избыточность данных, что может повысить производительность, но потребует больше усилий для контроля за связанными данными. Усложнится процесс создания приложений, поскольку данные будут повторяться и их труднее будет отслеживать. Кроме того, осуществление ссылочной целостности оказывается не простым делом — связанные данные оказываются разделенными по разным таблицам.

 

Если сайт пишется с нудя и под себя - обратная совместимость не стоит так категорично,

Но если делать конкурента розетки или что то в этом роде, нужно смотреть в сторону YII 2, Symfony 2 и потратить много часов работы 

Кстати розетка на YII 2  :-) 

[snastik]

Злая это штука, и здорово может запутать, а также половину моделей нужно выкинуть тогда 

 

Ну и еще минус (цитата с Хабра)

 

Если сайт пишется с нудя и под себя - обратная совместимость не стоит так категорично,

Но если делать конкурента розетки или что то в этом роде, нужно смотреть в сторону YII 2, Symfony 2 и потратить много часов работы 

Кстати розетка на YII 2  :-) 

 

Не важно Y|| или Opencart.

 

Все  равно привет flat-таблицы hash-индексами.

Привет шардинг.

Ну и если есть безграничный бюджет-то еще можно кластер slave-mysql серверов поставить с 512 гб памяти, и перенести всю обработку-хранение данных в память.

 

Т.е. надо понимать, что производительность розетки обеспечивается не системой, на которой она развернута. А архитектурой комплекса.

А в каких типах хранилищ крутить данные. И как их обрабатывать - это уже технические детали. Но это в случае разработки с 0.

Если же допустим станет задача доводить Opencart до каких то диких показателей pageview. То тут очень долго можно обходится горизонтальным масштабированием. Самое главное укротить процессы регулярного обновления таблиц товаров.

Если интересно, кстати могу в личку показать 500 000, или уже наверное 700к товаров, с временем ответа практически любой страницы до 300мс. Сразу говорю, что и как сделано - тайна за семью печатями.

[ArtemPitov]

Если интересно, кстати могу в личку показать 500 000, или уже наверное 700к товаров, с временем ответа практически любой страницы до 300мс. Сразу говорю, что и как сделано - тайна за семью печатями.

Даже очень интересно, покажите