Комментарии 29
Интересная статья. Раньше писал на C#, и прошёл курс по SQL, так что в принципе все понятно. Жду продолжения
Очень хочется все денормализовать к такой-то бабушке. И каталог сделать атрибутом. Вот пятой точкой чувствую, что один и тот же продукт захочет быть в разных категориях рано или поздно. Типа как и "азиатки" и "худые" одновременно. Или это не про продукты? Энивей, когда найденное решение содержит жонглирование экспрешенами, очень хочется вернуться к архитектуре как таковой и что-нибудь с ней сделать, чтобы не трогать экспрешены.
А на том месте где выбираются категории и атрибуты для фильтров, сразу хочется найти альтернативы. Какой-нибудь материалайзед вью, или хотя-бы кэш результатов запроса. И если уж EF, то EF.CompileAsyncQuery в этом месте. И кэш. Иначе что там лоад тестировать, если при проектировании производительность даже вскользь не фигурировала.
А в целом упражнение хорошее. Но для реалистичности все же нужно еще какие-то нон-фанкшинал требования принять во внимание и уделить им немножко времени.
Готов к куче минусов. Мелкософт уходит от нас но появляется все больше статей как писать на .NET как пользовать их технологии. Не надоело!
Чисто формально - .НЕТ открытый проект, куда бы МС не ушёл, на возможность пользоваться .НЕТом это не повлияет.
Дальше, .НЕТ - от рантайма-джита, через базовую библиотеку и до дизайна языка и компилятора - громадный и интереснейший кусок знаний (и опыта), развивающийся у нас на глазах.
Так что хотя бы с этой точки зрения должно быть познавательно.
Ну и возвращаясь к уходу МС - было бы, конечно, здорово и интересно всё это импортозаместить - да хотя-бы даже реализовать рантайм-джит для Эльбруса или только MAUI для авроры (или как там её?), но я/ты/он/она такое организовать не потянем, а заинтересованности у тех, кто мог бы, к сожалению, не заметно.
А могло бы стать шагом к какой-нибудь православной хармони-ос.
Двадцать пять лет уже читаю, что Мелкософт уходит...
Сейчас довольно не плохой поиск по json полям идет. И если запихнуть туда поля может быть вполне не плохо. Но мне кажется для этого бд лучше взять Mongo.
Хм, а как в задаче поиска по множеству категорий поможет Mongo? Там для этого вообще нет никаких инструментов.
Можно идти или в сторону специализированных поисков или таки по таблице на категорию или играть с селективностью запросов и дальше уже отбирать на уровне приложения.
Впрочем, подход EAV (описанный в статье) вообще непригоден для подобных задач, он крайне неэффективен.
Так речь шла про свойства/параметры товара, а не категории.
Так свойство товара - это и есть категория.
И поиск по свойствам - это поиск по множеству категорий, к которым отнесен товар.
Это одно и то же.
С чего бы это. Свойства, это например, емкость жесткого диска или год выпуска. А категория - бытовая техника, компьютеры.
Хм, и емкость жесткого диска и год выпуска и тип товара и позиция в какой-то иерархии - это все категории товара (или свойства товара, это синонимы).
Категория товара - не то же, что и "товарная категория".
Просто поиск по множеству категорий - термин скорее из теории БД, а "товарная категория" - из товарного учета.
Выбранная структура данных идеально вписывается в semantic web.
Но оно не в тренде, к сожалению.
В эластик все запихать или кликхаус.
Это не статика, а постоянно изменяющая информация. Что-то нужно удалить, что-то добавить. Кликхаус и эластик не для этого.
Эластик отлично сюда ложится - построенный на Lucene прямо из коробки будет фасетный поиск. Кликхаус да, для другого.
С эластиком +/-. Вроде хорош, но мне кажется что не совсем тут идеально ложится.
Ну, оперативное изменение будет довольно дорогим и на большом объеме будет сильно тормозить или требовать очень много ресурсов. Но для небольших объемов решение на эластике или солре вполне допустимо.
CH, увы, потянет, но до 10-100rps, дальше уже будет невыгодно.
В общем, как всегда, нужно сначала смотреть на ФТ/НТФ, а потом уже решение выбирать.
1) Сорри, не понял графика - при скольки запросах в секунду началось замедление?
2) Про базу
2.1) Postgres намного популярнее и неспроста
2.2) хорошо бы проверить план исполнения запросов
На двух :) через 4 секунды график пошёл вверх. Шучу, на графике нет RPS.
JMetter работает так: у нас есть некое количество тредов, каждый из которых в цикле выполняет свой план. Если тред ждёт ответа 2 секунды, значит он будет давать нагрузку в пол запроса в секунду. Если сервер быстро отвечает, один тред и 100 запросов может сделать. Когда сервер не вывозит, запросы становятся в очередь, а линия начинает линейно расти от количества ожидающих.
Можно прикинуть, что на 1 запрос сервер тратит 85мс и вывозит где-то 12 запросов в секунду.
Да прибудет с Вами фасетный поиск
Expressions медленные как ни крути.Expression.Lambda - тяжёлая вещь. Попробуйте хотя бы начать замену с неё.
дел
Если посмотреть на Вашу схему, то это похоже на EAV модель.
Если цель эксперимента - реализация фасетного поиска, то это тупиковый путь, потому что там есть нюансики.
Лучше смотреть в сторону Эластика, Сфинкса и т.п.
Кроме этого, есть определенный алгоритм построения запроса. Как вариант, можно почитать здесь https://habr.com/ru/articles/517074/
Спасибо тебе добрый человек, никак не мог вспомнить и нагуглить EAV-модель.
Вот скажи мне, микросервис, в чем сила