Надо сделать 103тыс запросов к базе

postavkin, скорей всего вы что-то не то делаете...

Вы, похоже, хотите закешировать все возможные комбинации параметров (фильтра товаров). Но зачем??? Что вам мешает сразу делать выборки товаров по комбинации параметров? Выборка медленная и вы хотите все возможные выборки заранее своеобразным образом закешировать? Лучше настроить правильно структуру данных, проиндексировать поля и тогда при правильном подходе у вас изначально будут выборки быстрыми и их не потребуется кешировать.

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

Ребят, спасибо. Ну что тут сказать - самоучка.

Буду развиваться и изучать, то что вы написали.

Обычно это делается так: при посещении страницы с подбором - он кэшируется. А перебирать все варианты - смысла нет.

Так - тоже не делается, кроме отдельных race conditions. Это знает любой профессиональный DBA

postavkin, реально надо

- не кэшировать результаты

- иметь составные индексы на все сочетания (от вырожденнного "1 поле" до "все" ) полей, используемых в WHERE, чтобы запрос в реальном времени был незаметен на фоне других задержек

- заиметь (хотя бы контрактно) правильного профессионального DBA, который пп 1-2 знает как азбуку профы и не парит мОзги себе и другим

Ребятки, ну какой elasticsearch под 2 тысячи товаров, вы в своем уме? Давайте ещё кластер кассандры поднимем.

Что-то вы ляпнули, сами не зная что. При чем тут race conditions? О чем вообще вы говорите?

При правильном дизайне, составные индексы не нужны. Они даже на FLAT таблицах уже не нужны, не говоря о 5/6NF.

А за базар ответить?! Ну типа показать "правильно задизайненную базу" со всеми делами без составных индексов и предъявить запрос и результаты (время) исполнения? Возьмем как у ТС - объект и 6 свойств в произвольном сочетании и комбинации. Тем более что я вижу

Вы это всерьез ?

Скорее всего и вовсе без индексов всё будет работать с базой на 2000 строк...

ЗЫ. Менял, кстати, в одном из дебилошопов типа престашопа, некоторые части так, чтобы вместо выборки из базы автогенерировался php-файл с функцией с одним switch (для вариантов в 10-100 строк). И учитывая сколько раз эти части вызывались даже был ощутимый профит. Да, можно и кешировать, но не всегда это удобнее и быстрее, а если есть некая функция импорта, то она легко может прям php-код "готовить".

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

И да, количество строк для SELECT на скорость не так сильно роляет, как вся фуфень из WHERE (если делать качественную оценку потерь времени, а не количественную)

Всего артикулов в базе: 3204349

Выборка товаров по критериям:

Бренд: Xiaomi, Samsung, LG, Huawei

CPU: 2,

RAM: 2048, 4096

Выполнение: 6-10 мс.

QUERY PLAN                                                                                                   

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 Limit  (cost=2.57..547.25 rows=30 width=45) (actual time=0.238..6.094 rows=30 loops=1)

   ->  Nested Loop  (cost=2.57..2420214.72 rows=133303 width=45) (actual time=0.237..6.084 rows=30 loops=1)

         ->  Nested Loop Semi Join  (cost=2.15..2360638.33 rows=133303 width=38) (actual time=0.228..5.927 rows=30 loops=1)

               ->  Nested Loop  (cost=1.72..2148113.35 rows=462054 width=86) (actual time=0.101..5.401 rows=121 loops=1)

                     ->  Nested Loop  (cost=1.29..1934033.44 rows=462055 width=54) (actual time=0.092..4.839 rows=121 loops=1)

                           ->  Nested Loop  (cost=0.86..1558868.91 rows=806425 width=38) (actual time=0.082..3.734 rows=207 loops=1)

                                 ->  Index Scan using shop_product_sku_offer_price_idx on shop_product_sku_offer spso  (cost=0.43..94254.38 rows=3204341 width=22) (actual time=0.026..0.704 rows=780 loops=1)

                                 ->  Index Only Scan using shop_feature_cores_sku_pkey on shop_feature_cores_sku sfcs  (cost=0.43..0.46 rows=1 width=16) (actual time=0.004..0.004 rows=0 loops=780)

                                       Index Cond: ((sku_id = spso.sku_id) AND (feature_value_code = 2))

                                       Heap Fetches: 0

                           ->  Index Scan using shop_feature_brand_sku_pkey on shop_feature_brand_sku sfbs  (cost=0.43..0.47 rows=1 width=16) (actual time=0.005..0.005 rows=1 loops=207)

                                 Index Cond: (sku_id = spso.sku_id)

                                 Filter: (feature_value_code = ANY ('{xiaomi,samsung,lg,huawei}'::text[]))

                                 Rows Removed by Filter: 0

                     ->  Index Scan using shop_product_sku_pkey on shop_product_sku sps  (cost=0.43..0.46 rows=1 width=32) (actual time=0.004..0.004 rows=1 loops=121)

                           Index Cond: (id = spso.sku_id)

                           Filter: is_available

               ->  Index Only Scan using shop_feature_ram_sku_pkey on shop_feature_ram_sku sfrs  (cost=0.43..0.46 rows=1 width=16) (actual time=0.004..0.004 rows=0 loops=121)

                     Index Cond: (sku_id = spso.sku_id)

                     Filter: (feature_value_code = ANY ('{2048,4096}'::integer[]))

                     Rows Removed by Filter: 1

                     Heap Fetches: 0

         ->  Index Scan using shop_product_pkey on shop_product sp  (cost=0.42..0.45 rows=1 width=39) (actual time=0.005..0.005 rows=1 loops=30)

               Index Cond: (id = sps.product_id)

 Planning time: 12.581 ms

 Execution time: 6.204 ms

SELECT COUNT(*) FROM shop_product_sku;

  count  

---------

 3204349

Составные индексы есть, но они в этом запросе не участвуют, и созданы они не для запросов, а для констрейнтов.

danforth, ну это ж не ответ, проше пана. Где, миль пардон, структура таблицы? А то ведь SELECT COUNT(*) это немного чуть более, чем полностью, не о "Выборка товаров по критериям: Бренд: Xiaomi, Samsung, LG, Huawei"