какие задачи ты ставишь перед еластиком?

если тебе нужна масштабируемость/неубиваемость курить в сторону кубернетиса

но опять же, нахер он в простом магазине не нужен

эм, поиск, да можно херачить по старинке (ничуть не считаю что это плохо)

используй еластик, если захлебнётся база

а сейчас сову на глобус натягивать так себе решение)

ну вот мне нужна была конкретика

я даже в принципе редко тот же редис присобачиваю

ну, смотря какой поиск. в эластике есть ранжирование документов, что очень важно для релевантной выдачи. одно дело найти слова, другое дело - что это те самые документы, которые ты искал

если оно работает  работает — хорошо, совать всё не надо) проще работает — проще отлаживать

а я скажу зачем. несколько лет назад, году в 2016 я работал вот над этим магазином. https://www.netpris.dk/
у них была проблема, что поиск по 50к записей шел 20 секунд. там использовалась eav архитектура бд. Так вот самый безболезненный вариант, это альтернативное представление данных, без рефакторинга бд. Ты получаешь профит в производительности не теряя при этом жесткую структуру реляционки. Носкюль версус реляционки это всегда компромисс, тут по сути ты испольщуешь 2 бд, одна их них наполовину бд.

а что вместо это берешь? (кэш, очереди)

так у него простой магазин)

ясно, что можно и амазон пилить)

на кэше редис, просто не везде его впендюриваю

а очереди на раббите

не для всех данных имеется ввиду, могу сделать обычный джоин — сделаю джоин

ES это больше не про производительность. в реляционных БД уже давно завезли полнотекстовый поиск, который работает очень быстро

нет если ты редис редко берешь, но иногда стоит что-то в кэш запихивать, то что делаешь?

это он сейчас простой, а через год там может быть куча клиентов. Разумеется что он решил заранее подумать(что может и сомнительно если это знаимает много времени) но в плане обучения, чеб нет