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

[n3bo]

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

@****** , гделай 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, ****** 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, ****** said:

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

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

 

Spoiler

 

[chukcha]

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

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

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

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

[100napb]

15 minutes ago, chukcha said:

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

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

похоже на то.

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

[******]

Циии

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

[******]

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 часа назад, ****** сказал:

Очень имеет!

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

 

[******]

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

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

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

 

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

 

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