не решает проблему по тому что эта техника не используется для процессинговый данных по тому что фиксирует случившиеся события. Ты, наверное, говоришь про CQRS, но и он тоже тут не решает проблему. При воспроизведении мы получим актуальные данные с большей долей вероятности, а не историю по тому что корзина по факту ничего не должна знать о продуктах кроме ссылок на них в идеальном сферическом проекте в вакууме
старые данные нужно хранить, чтобы их использовать в дальнейшем
надо понимать зачем мы это делаем. Для логов или аналитики - ладно, для версионирования и возможности отката для пользователя - ладно, а для всего остального не нужно)
Ну и не забываем - машину по вчерашней цене вам никто не продаст
dimonchik2013, а при чем тут сравнение маркетплейсов и гугла? принципы везде одни и те же. А для проектов ниже поисковых гигантов хватает эластика и алголии, где не надо даже близко понимать что такое Inverted Index
pandaa, про фразы я уже ответил. Можно принять реальность или думать что есть какая-то волшебная магия. Если нужны не фразы , а просто все слова в определенном порядке то там идет первичная выборка по индексу и далее уже расчет веса исходя из порядка слов в документе. Это достигается, как я уже говорил, связанными списками с последовательностью термов, связанных последовательно и расчётом расстояния между термами. Это дорого и долго и нужны серьезные вычислительные мощности
pandaa, термы состоят из слов, но для генерации термов необходимо подготовить документ специфическим образом и разделить его на наборы слов длиной от 1 и до необходимого значения. Подготовка в себя включает проведение
в нижний регистр
в один и тот же род и число
исправление опечаток
на один язык
замена синонимов
чистка от слов с избыточной частотностью (предлоги, междометия, местоимения, слова предметной области вроде "доктор" в документе про докторов)
есть еще разные преобразования и я не помню уже как они называются правильным образом
pandaa, поисковая фраза преобразовывается, бьется на все термы от максимального к минимальному, по им ищутся документы с соответствующими дермами и раздаются веса исходя из размера терма и частотности. Есть различные формулы для расчета от довольно старых до совсем новых и прогрессивных.
pandaa, посмотрите на ElastcSearch или Solr. Другие инструменты в этом мире сегодня не используются. Ну, за исключением таких проектов как Algolia. Я не в курсе что у них под капотом работает
pandaa, ну и в догонку - в тегах у вас указан MySQL, который в таких системах не используется по тому что он не нужен. Там используются key-value или nosql решения
pandaa, есть такой факт что задача поиска не выдавать всю информацию, а самую релевантную. С увеличением длины поисковой фразы число документов экспоненциально падает и после определенного значения практически не меняется. Самая большая длина полезной нагрузки фразы была что-то вроде 6 слов. Это предел. В мире поиска размер дискового пространства менее значим чем вычислительные ресурсы и время отклика. Term'ы создаются из документов, а не из запросов пользователей все-же. Не забываем что в мире search главную роль играет подготовка данных, которую проходят как документы так и поисковые запросы, где происходит вся магия и что является гарантией успеха
pandaa, антипаттерн это не плохо. Это то что работает. Я потратил время на то чтобы вытрясти из специалистов по search'у подобную информацию. Так это работает в реальной жизни. Все остальное не перформит никак и очень дорого по тому что идут вычисления. Если очень надо последовательность слов то можно извратиться и представлять документы в виде связанных списков, но это уже абсолютно другие решения и подходы, не имеющие ничего общего с данным вопросом.
Еще раз, для закрепления, антипаттерн это не плохо. Паттерны, имеющиеся сегодня это наследие IT из 90х и монолитных проектов. Сегодня многие из них уже устарели не применяются по тому что не подходят для быстро изменяющихся проектов. Антипаттерны появились как то что не эффективно решало проблемы ранее, но сегодня ветер дует в другую сторону
Алексей Потапенко, правда 100% гарантии не существует, поэтому если хочется такое то придется добавлять обработчик с аудитом, который будет ходить и смотреть за тем не превысил ли кто чего
не решает проблему по тому что эта техника не используется для процессинговый данных по тому что фиксирует случившиеся события. Ты, наверное, говоришь про CQRS, но и он тоже тут не решает проблему. При воспроизведении мы получим актуальные данные с большей долей вероятности, а не историю по тому что корзина по факту ничего не должна знать о продуктах кроме ссылок на них в идеальном сферическом проекте в вакууме
надо понимать зачем мы это делаем. Для логов или аналитики - ладно, для версионирования и возможности отката для пользователя - ладно, а для всего остального не нужно)
Ну и не забываем - машину по вчерашней цене вам никто не продаст