Помогите ускорить магазин и MegaFilter Pro

[n3bo]

18 часов назад, SooR сказал:

@Yoda , делай crc32, как самый быстрый способ проверить.

 

 

Не

 

product_id	filter_id	filter_value_id
1	1	1
1	1	2
1	2	3
1	2	4
1	3	5

 

а

 

product_id	filter_id_1	filter_id_2	filter_id_3
1	[1,2]	[3,4]	[5]

 

условно.

 

Если нет мультиатрибутов, то еще быстрее без json

 

 

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

 

А если у одних товаров одни атрибуты, а у других другие? избыточность? 

Змінено 29 грудня 2018 користувачем n3bo

[Soong]

20 часов назад, zlob сказал:

отключить подсчет товаров в категории 

 

Дельный совет ) Прям читая такие сложные слова в теме , увидев знакомые буковки, настроение поднялось)

[100napb]

On 12/28/2018 at 9:25 PM, Yoda said:

можно ведь подсчет значений атрибутов делать не по текстовому полю, а по crc32 хешу

 

Старый, но теряющий актуальности пост. Может быть полезным. Например вот тут, где человек делится опытом о том, что, например, могут встречаться коллизии на больших объемах данных с использованием crc32 - повторяются результаты.
 

Spoiler

 

Да, иногда это удобно, особенно вместо того чтобы создавать составной индекс по нескольким полям (который будет достаточно большой), можно создать по одному полю, например используя ф-ию MD5 (128 бит, запись состоит из 32 символов) или если мы хотим подстраховаться больше то лучше использовать Sha1 (160 бит, 40 символов) нежели CRC32 (32 бита, беззнаковое число)
И соответственно запросы примут вид

SELECT * FROM

   tbl_name
WHERE
  hash_col=MD5(CONCAT(col1, col2))
  AND col1='constant'
  AND col2='constant';

так просто большая вероятность того, что значения CRC32 совпадут, особенно если в таблице много записей.
Ну и соответственно индекс поставить не на все поле, а на какую-то его часть.

 

 

On 12/28/2018 at 11:16 PM, Yoda said:

3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega.

Банально, но может быть профилирование запросов окажется полезным. Есть возможность показать план выполнения тяжелого селекта + статистику изменения статусных переменных, что бы понять, какие именно операции СУБД являются бутылочным горлышком. Вот, например:

 

Spoiler

 

[chukcha]

Не имеет значения, какой хеш будет использоваться, это может быть и md5

1 час назад, 100napb сказал:

, но может быть профилирование запросов окажется полезным.

Вы не поняли саму суть решения..
Это смена системы хранения и обработки

[100napb]

15 minutes ago, chukcha said:

Не имеет значения, какой хеш будет использоваться, это может быть и md5

Вы не поняли саму суть решения..
Это смена системы хранения и обработки

похоже на то.

*ушел читать за сфинкс*

[Yoda]

Цитата

Старый, но теряющий актуальности пост. Может быть полезным. Например вот тут, где человек делится опытом о том, что, например, могут встречаться коллизии на больших объемах данных с использованием crc32 - повторяются результаты.

Какие коллизии? На  наборе уникальных значений атрибутов в 300 штук, Вы ща серьезно?

 

Цитата

Банально, но может быть профилирование запросов окажется полезным. Есть возможность показать план выполнения тяжелого селекта + статистику изменения статусных переменных, что бы понять, какие именно операции СУБД являются бутылочным горлышком. 

Опять какой то текст, я не совсем понял к чему. Но уточню суть проблемы. В структуре базы Opencart, самое узкое место - это таблица с атрибутами и поле типа text на значениях. Так как mysql плохо приспособлен для поиска-обработки-группировки по текстовым данным, и это все-таки реляционная база, которая по своей природе предполагает первичную типизацию, реализовать в лоб, какой либо вменяемый механизм невозможно. Есть несколько вариантов решения, но они все требуют денормализации таблиц и влекут за собой проблемы с совместимостью остального функционала. И в любом случае это будет костыль. Даже если использовать выборки match against и full-text индексы, мы все равно упремся  в ограничении длины минимального слова в четыре символа, а все остальное заигнорится.

Самый трезвый способ использовать для обработки больших текстовых массивов инструменты для этого предназначенные Solr, Elastic, Manticore либо Сфинкс. Так как изначально эти платформы разрабатывались для обработки больших текстовых массивов. Эластик и Солр - мне не нравятся, в силу тех или иных причин - это тема для отдельного поста, мантикора - это сфинкс 2.6 от тех кто убежал от Аксенова. А Sphinx 3.1 показывает прирост по скорости по сравнению с 2.6 и даже 3.0.3 процентов на 30.

 

14 часов назад, chukcha сказал:

Не имеет значения, какой хеш будет использоваться, это может быть и md5

Очень имеет!

MD5-хеш содержит 128 бит, а crc 32  - в четыре раза меньше. Для большого набора, который надо отсортировать в нашем случае, те самые 10M решает.
 

[Yoda]

1 час назад, nikifalex сказал:

можно еще в этом направлении смотреть

https://habr.com/post/261137/

Это плохое решение для нашей ситуации.

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

Во вторых - самое главное, то, что  у меня целиком и полностью весь каталог крутится в индексе сфинкса. Цены, порядок сортировки, бренды, категории, абсолютно вся выборка на страницы каталога идет из того же самого индекса, в котором хранятся и атрибуты. Кроме этого, не нужно мудрить велосипед, и писать сложную логику для преобразования-извлечения данных. Все на sql, единственное стоит сервер 8 версии, там очень пригодилась поддержка JSON. Опять же не нужно было делать какие то прокладки, я прямо из базы новыми операторами mysql забираю готовую json-коллекцию. 

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

 

Пока что после всех консультаций, если говорить о программных способах дать пинка этому монстру, я вижу два метода. Это хеширование значений атрибутов и отказ от json-коллекций в пользу mva-аттрибутов. Это потребует формированя дополнительных справочников, но сократит размер обрабатываемых данных раз в 50.

[chukcha]

19 часов назад, 100napb сказал:

Старый, но теряющий актуальности пост. Может быть полезным.

Полезность поста, условно - никакая

количество хешей 2^32
Вероятность совпадений 1/(2^32)
Даже если в условиях  фильтрации вы получите неверные данные, то цена ошибки что в результат  попадет неверная инфа очень мала, Это ведь realtime, для которых  вероятность коллизии  также имеет ограничение.

 

2 часа назад, Yoda сказал:

Очень имеет!

Не имеет.. md5 ,был приведен как пример, очень хотите, скажу crc64 что-то изменит?

 

[Yoda]

16 часов назад, chukcha сказал:

Полезность поста, условно - никакая

количество хешей 2^32
Вероятность совпадений 1/(2^32)
Даже если в условиях  фильтрации вы получите неверные данные, то цена ошибки что в результат  попадет неверная инфа очень мала, Это ведь realtime, для которых  вероятность коллизии  также имеет ограничение.

 

Не имеет.. md5 ,был приведен как пример, очень хотите, скажу crc64 что-то изменит?

 

Я сделаю тесты. Покажу. Как раз есть набор данных подходящий.