Просто полнотекстового поиска недостаточно. Нужен полнотекстовый префиксный поиск с учётом морфологии.
Так же требуется агрегировать данные для отчётов (например, нам интересно знать динамику размещения и выполнения заказов по рубрикам и регионам)
Всё это можно сделать на PostgreSQL. Первое решение как раз было реализовано на PostgreSQL, но работало достаточно медленно и серьёзно нагружало CPU. Можно основательно разобраться в документации, правильно настроить индексы и написать оптимальные запросы. Но сколько это займёт времени и будет ли результат — мне сложно сказать.
С другой стороны — в ElasticSearch достаточно просто выгрузить данные и тут же получить результат. Что и было сделано.
На проекте настроено обновление с нулевым простоем серверов. Детально расписывать — получится отдельная статья. Если кратко:
Пока перезапускается процесс uwsgi — запросы ждут в очереди, либо уходят на другой сервер
Версия кода на сервере строго связана с версией скриптов и стилей (чтобы не получилась новая разметка со старыми стилями)
Так как миграция схемы БД выполняется до перезапуска сервера, то старый код должен уметь работать с новой версией схемы БД.
Не все изменения можно выложить на проект при таком подходе. В таких случаях — обновление производится по ночам или субботам с остановкой работы проекта.
Спасибо. Я полностью с Вами согласен. Рано или поздно это будет реализовано.
Но тут важно понимать как мы расставляем приоритеты задач: мы задаём вопрос «Как это влияет на основные показатели?»
В итоге в первую очередь реализуем то, что требуется для роста проекта и его монетизации. Lean startup в чистом виде.
В стандартной поставке celery уже хорош. Я доволен и не ищу «легковесных» альтернатив.
Обязательно нужен веб-мониторинг celery flower. Когда какая-нибудь задача сходит с ума и забивает все рабочие процессы — только так можно быстро всё наладить.
Приоритетов задач в celery нет, но они нужны. Помогает запуск нескольких сервисов celery с различными очередями. Приоритетные и важные задачи отправляются в одну очередь, медленные и неприоритетные — в другую. В результате задачи не блокируют друг друга.
В качестве очереди задач в теории можно использовать Redis, но стабильно у меня работает только RabbitMQ.
Согласен. Но отмечу: что бы вы зашли на юлмарт — юлмарту потребовалось потратить десяток миллионов рублей на маркетинг. Что бы вы про них вспомнили, когда потребуются наушники.
Где вы будете покупать книги? Скорее всего зайдёте на Озон и через его поиск найдёте то что требуется.
А если нужно купить подвесное кресло-гамак? Гугл/Яндекс приведут вас сразу на карточку товара noname-магазина, про который вы никогда не слышали.
Это всё безусловно имеет смысл, если клиент использует витрину для подбора товаров.
Но как правило основной канал привлечения: контекстная реклами/сео/агрегаторы. В этом случае пользователь сразу заходит на нужную карточку товара минуя каталог/поиск.
Цель оправдывает средства :/
А пользователи как считают?
Так же требуется агрегировать данные для отчётов (например, нам интересно знать динамику размещения и выполнения заказов по рубрикам и регионам)
Всё это можно сделать на PostgreSQL. Первое решение как раз было реализовано на PostgreSQL, но работало достаточно медленно и серьёзно нагружало CPU. Можно основательно разобраться в документации, правильно настроить индексы и написать оптимальные запросы. Но сколько это займёт времени и будет ли результат — мне сложно сказать.
С другой стороны — в ElasticSearch достаточно просто выгрузить данные и тут же получить результат. Что и было сделано.
Выбор делал достаточно давно — с тех пор что-то могло поменяться.
Если возникают проблемы с выполнением фоновых задач, то они в самих задачах, а не в транспорте нескольких сообщений между серверами.
Не все изменения можно выложить на проект при таком подходе. В таких случаях — обновление производится по ночам или субботам с остановкой работы проекта.
Но тут важно понимать как мы расставляем приоритеты задач: мы задаём вопрос «Как это влияет на основные показатели?»
В итоге в первую очередь реализуем то, что требуется для роста проекта и его монетизации. Lean startup в чистом виде.
www.youtube.com/watch?v=ktqe9ZoDl7E
А с точки зрения маркетолога вы — брендовый траффик :) Ещё есть траффик с СЕО/Контекста/Агрегаторов/Партнёрок…
Где вы будете покупать книги? Скорее всего зайдёте на Озон и через его поиск найдёте то что требуется.
А если нужно купить подвесное кресло-гамак? Гугл/Яндекс приведут вас сразу на карточку товара noname-магазина, про который вы никогда не слышали.
Но как правило основной канал привлечения: контекстная реклами/сео/агрегаторы. В этом случае пользователь сразу заходит на нужную карточку товара минуя каталог/поиск.