Какая быстрая база данных для интернет-магазина с более чем 50 тысячами товаров и поиском?

Question

[Андрей]

День добрый!

Пишу проект на Django, интернет-магазин с большим каталогом, товаров от 50 тысяч. Поиск будет осуществляться по множеству параметров.

Сейчас используется структура для поиска в виде массива в postgres, с поиском по нему. Сам поиск, в принципе, осуществляется быстро, но вот вывод доступных вариантов для поиска собирается очень долго.

Пример - яндекс-маркет. Ткнул на телефоны – он их вывел, а справа все доступные варианты параметров.
Использую redis для кеширования, но как смешно не звучало – от этого только хуже, редис не предназначен для кеширования больших объектов.

Есть идеи?

У меня не используется EAV. Я выбираю товары по типу tags @> ['param1', 'param2', 'param3']
Параметры дополнительные для уточнения поиска выбираются
SELECT unnest(tags) FROM items WHERE tags @> ['param1', 'param2', 'param3'] GROUP BY 1

Оперативной памяти 24 гб. Параметров поиска от 1 до 6 сразу. Чем больше параметров сразу указывает юзер, тем быстрее все ищется. ManyToMany плохо потому что у параметра "диаметр", к примеру, может быть сразу 10-15 значений. Если я хочу найти товар, у которого есть диаметр 10, 11, 12 – это делает join на каждый из диаметров, что очень тормозит систему.

Всему виной был redis и список в более чем миллион элементов в нем. Недоглядел, но положительные плоды есть – товары без всяких кешей отгружаются за 350-400 мс вместе с доступными фильтрами и 200-250 без фильтров, только товары.

Есть перспективы ускорения еще больше?)
Всем страждущим – solr + facets и будет вам счастье, поиск неимоверно быстрый.

Comments

[sim3x]

а сколько на редис памяти выделили, кстати?

[Андрей]

хм, даже не помню, но, по-моему, достаточно много. Да и большие слишком данные я там не собирался хранить.

Answer 1

[Dimitriy]

Сделайте вложенный запрос перед использованием unnest,

Вложенный запрос

explain (analyze) select unnest(tags) from (SELECT tags FROM t5 WHERE tags @> array['param-1'] group by 1) as t group by 1;
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=14655.30..14660.38 rows=1000 width=84) (actual time=490.721..490.722 rows=10 loops=1)
   ->  Subquery Scan on t  (cost=14647.62..14652.80 rows=1000 width=84) (actual time=490.690..490.706 rows=55 loops=1)
         ->  HashAggregate  (cost=14647.62..14647.73 rows=10 width=84) (actual time=490.676..490.676 rows=10 loops=1)
               ->  Seq Scan on t5  (cost=0.00..13459.00 rows=475450 width=84) (actual time=0.033..181.649 rows=475324 loops=1)
                     Filter: (tags @> '{param-1}'::text[])
                     Rows Removed by Filter: 24676
 Total runtime: 490.843 ms
(7 rows)

Исходный

explain (analyze) SELECT unnest(tags) FROM t5 WHERE tags @> array['param-1'] group by 1;
                                                      QUERY PLAN                                                       
-----------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=368857.88..368862.95 rows=1000 width=84) (actual time=1196.758..1196.759 rows=10 loops=1)
   ->  Seq Scan on t5  (cost=0.00..249995.38 rows=47545000 width=84) (actual time=0.020..680.547 rows=2501231 loops=1)
         Filter: (tags @> '{param-1}'::text[])
         Rows Removed by Filter: 24676
 Total runtime: 1196.790 ms
(5 rows)

Вложенный с seqscan off

с set enable_seqscan to off;

explain (analyze) select unnest(tags) from (SELECT tags FROM t5 WHERE tags @> array['param-1'] group by 1) as t group by 1;
                                                                      QUERY PLAN                                                                      
------------------------------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=19433.16..19438.24 rows=1000 width=84) (actual time=411.248..411.249 rows=10 loops=1)
   ->  Subquery Scan on t  (cost=19425.49..19430.66 rows=1000 width=84) (actual time=411.220..411.233 rows=55 loops=1)
         ->  HashAggregate  (cost=19425.49..19425.59 rows=10 width=84) (actual time=411.205..411.206 rows=10 loops=1)
               ->  Bitmap Heap Scan on t5  (cost=5084.74..18236.86 rows=475450 width=84) (actual time=74.696..126.809 rows=475324 loops=1)
                     Recheck Cond: (tags @> '{param-1}'::text[])
                     ->  Bitmap Index Scan on t5_tagx_gist  (cost=0.00..4965.87 rows=475450 width=0) (actual time=73.514..73.514 rows=475324 loops=1)
                           Index Cond: (tags @> '{param-1}'::text[])
 Total runtime: 411.337 ms
(8 rows)

исходные данные:

create table t5 as (select i id, rand_array() tags from generate_series(1,500000) as i);
create index t5_tagx_gin on t5 using gin (tags);

create or replace function rand_array() returns text[][] as $$
begin
 return (select array_agg(t1.col1) from (select format('param-%s', i) col1 from generate_series(1,rand(10)) as i) as t1);
end;
$$ language 'plpgsql' strict;

ЗЫ, i5 2410M 8gb, PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu

Comments

[sim3x]

а как такое вообще "по-человечески" делается?

[Андрей]

@Vakiliy странное поведение, откуда такое узнали?

[Андрей]

Да, похоже пошустрее.) Еще выяснил, что плохо хранить в redis список из 1003877 элементов(

[Dimitriy]

@sim3x т.е "по человечески"?
@xmdy даже уже и не помню как такое вылыло :)
да в вашем случае наверно правильней использовать поле tags как нормализованную таблицу для M2M, т.е только tag_id.
По поводу кеширования, не совсем понял что вы кешируете в redis`е.
Заносите в редисе запрос и его конечный результат, т.е если вы ищете товары с param-1 то это tag_ids и будет ваши результатом, следующий раз вам не придется делать выборку по все базе. Глубже наверно нет делать смыла, тк как это будет пересечение двух множеств param1[tag_ids] x param2[tag_ids].

[Андрей]

очень не очевидное поведение. как показывает опыт – хранить в редис сложные объекты не стоит. Большие – тоже. Поэтому скоро переработаю на хранение там только небольших списков и словарей.
@Vakiliy м2м нельзя, т.к. структура у базы такая, что хранятся теги из разных мест. Ну, в общем, это все хрень, пережитки прошлого, проект переделывать придется)

[Dimitriy]

@xmdy даже если и не будете использовать нормализацию, в любом случае запрос и агрегированые теги сохраните в кеш, след раз просто возмете эти данные их кеша :)

[Андрей]

@Vakiliy ну я так и делаю, но, объективно и через профайлер - запросить из базы быстрее, чем получить из кеша объекты. Пока не переделал на словари, может тогда будет побыстрее.

[Dimitriy]

@xmdy вот тебе и кеш :) вобще странно конешна, сколько раз делал нечно подобное query:md5(query) [...] обычно быстрее, чем дернуть базу

[Андрей]

@Vakiliy к сожалению вы на хабре в read-only, а тут не напишешь персонально. Можно с вами как-то еще связаться?)

[sim3x]

@Vakiliy
интересно, как еще такое можно реализовать и главное как это реализуют на рабочих проектах?

[Андрей]

я в джанге просто делаю кастомным запросом в базу)

Answer 2

[Пума Тайланд]

поиск перенести на выбор в сфинкс, эластик серч, солр
и будет больше счаться

Comments

[Андрей]

А как из них выбирать подсказки для поиска?

[Igor German]

@xmdy в elasticsearch www.elasticsearch.org/guide/en/elasticsearch/refer...

Answer 3

[FacedSID]

Не знаю чем вам EAV не угодила. У меня база значений по каждому полю лежит в разных таблицах. Когда происходит выборка по одному параметру, то подключается именно та таблица, которая отвечает за конкретный параметр. Получается, что при поиске по трем параметрам подключается например три таблицы суммарный объем которых составляет 3000 записей, а не одна таблица в которой около 200 000 записей (причем по несколько раз на каждый параметр) и это вполне приемлимо + кеширование SQL запросов и самих объектов в apc.

Comments

[Андрей]

Спасибо за ответ. А можно уточнить, как вы соединяете параметры в eav с объектами?
А apc работает с erlang?

[FacedSID]

@xmdy Есть типы данных, которые хранят в себе список всех возможных атрибутов объекта. У каждого объекта соответственно есть свой тип данных. Таблица objects содержит в себе всего три поля: id, name, type_id. В таблице со значениями каждого объекта есть поля: id, object_id, field_id, string, text, int, float, object. Соответственно, что бы получить все атрибуты объекта можно просто выбрать SELECT * FROM objects_attributes WHERE object_id = 1 и т.д. Т.е. я не получаю сначала возможные атрибуты объекта через тип данных, а сразу получаю все атрибуты, которые есть у объекта. Каждый возможный атрибут так же хранится в бд. В конфигурационном файле хранится список таблиц в которых хранятся значения определенных атрибутов.

В моем случае я не использую динамический набор атрибутов, т.к. в этом нету особой необходимости, но можно реализовать и эту возможность без ущерба производительности.

APC предназначен только для PHP и клиентов для других языков я честно не встречал. С версии PHP 5.5 если я не ошибаюсь он является встроенным opcache движком (APCu).

Вообще вроде как Erlang с Memcached работает без проблем. Соответственно и PHP тоже. Написать интерфейс для взаимодействия с memcached на PHP не сложно, у меня интерфейс составляет всего 92 строки кода.
Для erlang клиент можно найти тут https://code.google.com/p/memcached/wiki/Clients

Надеюсь ответил на вопрос :)

[FacedSID]

@xmdy Для поиска объектов по бд использую внутринний конструктор запросов в стиле fluent. Он сам формирует необходимый запрос, подключает нужные таблицы, прописывает условия, выполняет запрос и возвращает данные в указанном виде.

В вашем случае можно прикрутить Apache Solr (очень мощная штука, если ее правильно приготовить :))

[Андрей]

Спасибо, про эрланг я так, к слову. у меня django и рекомендовать apc не стоит. )
Буду смотреть solr, хорошо.

[FacedSID]

@xmdy Сори ) Я простужен и не сплю уже вторые сутки ) Плавит ( Не заметил, что у вас Python ))

[Андрей]

Спать надо, спать хорошо)