Комментарии 6
Хорошая работа
ого, спасибо
Хорошая статья, спасибо.
Интересно почему потребление ресурсов (скорость и память) растет не линейно а чуть быстрее. И так же интересно такой огромный скачек по памяти на Го. Мне кажется с такими успехом можно было бы на С++ / Раст. А сравнивали разницу по времени/памяти с эластиком? Что будет если немного перестроить тип данных и всё таки хранить список продуктов и у каждого его список атрибутов и просто перебирать одним циклом, может jit поможет. Или ещё продублировать данные в разном формате чтобы можно было гораздо легче доставать нужные идентификаторы продуктов. Думаю будет интересно сначала продумать правильный алгоритм с подсчётом "О" и потом его реализовать с нужным типом данных и возможной дубликацией для быстрого доступа.
p.s. а если добавить ещё индекс по названиям с разбиением на слова (или другие токены) то можно и простенький TF-IDF алгоритм прикрутить, а это вам полноценный полнотекстовый поиск...
p.p.s. но честно говоря как по мне лучше всё таки эластик/сфинкс/солр, их будет гораздо проще масштабировать и поддерживать.
С эластиком сравнивал только финальное время получения агрегата (коннект по сети, выполнение запроса, получение результата), это было около 2ух лет назад данные не сохранились.
Если хранить список продуктов целиком «как есть», это потребует значительно больше оперативной памяти и сама структура будет менее эффективна для прохода. Простой пример: представим у нас есть миллион товаров, среди которых 2 красных телефона. Доступ к id этих двух товаров с условием «красный» будет стремится к константе
$list = $data['color']['red'];Было несколько подходов с разными вариантами хранения данных, в каждом были свои + и -, где-то больше памяти, где-то больше CPU. Скорее всего, есть какие-то более подходящее экзотические структуры, пока текущий вариант кажется наиболее сбалансированный с учетом особенностей PHP и задачи подсчета агрегатов.
Конечно можно написать на C++ :-)
Контекст задачи был иной — использовать PHP, индекс в runtime с возможностью доступа из кода, исключить хождения по сети, упростить API. Если бы был выбор писать на C++ или использовать готовое решение, эта статья бы никогда не появилась.
Естественно Elastic/Sphinx лучше как решения, в нашем случае удалось от них временно отказаться и сэкономить на инфраструктуре и интеграции. Возможно возникнут потребности, которые потребуют перехода на другое решение и это нормально. Два года эта штука крутилась и не доставляла боли, сервис начал генерировать прибыль это уже победа.
История разработки фасетного поиска средствами PHP