Если вы разрабатываете свой API с помощью rails/ruby, вы можете посмотреть searchkick, который в значительной степени выполняет эту работу, делая решение для поиска более разумным каждый день с большим использованием.
Теперь, если вы не находитесь на рельсах или хотите разработать собственную внутреннюю реализацию, вот несколько советов по архитектуре с моей стороны.
Позволяет сначала начать с базового обзора, ключевых модулей, недостатков и адаптировать архитектуру для этих недостатков в решении.
вам потребуется
1) алгоритм скоринга, где вы можете определить уравнение для формулы, которая будет генерировать счет для каждого документа. позволяет рассмотреть приведенные вами параметры.
a) Количество раз, когда каждый документ был показан b) Не было нажато ни одного документа. c) запрос поиска документа.
сейчас, как вы уже не упомянули, как a) и b) подходит в текущем контексте. Я бы предположил более простой, но если вы хотите создать действительно передовое интеллектуальное решение, я бы также совпадал: a) b) с c). Например, сколько раз документ появился для данного ключевого слова. Как и я, поиск «снежных сапог» должен учитывать это (количество появления/отсутствия щелчка) только тогда, когда запрос был более или менее похож на «снежные ботинки» не для всех случаев. где «снежные сапоги» могут быть разбиты на ключевые слова с помощью следующей мета с близорукостью по расписанию.
{
"keyword": "snow",
"document_ids": [3, 5, 6, 8],
"document_ids_views": [{
"doc_id": 3,
"views ": 110,
"clicks": 560
}, {
"doc_id": 5,
"views": 100,
"clicks": 78
}, {
"doc_id": 6,
"views": 100,
"clicks": 120
}, {
"doc_id": 3,
"views": 100,
"clicks": 465
}]
}
{
"keyword": "boots",
"document_ids": [3, 5, 6, 8],
"document_ids_views": [{
"doc_id": 3,
"views ": 100,
"clicks": 56
}, {
"doc_id": 5,
"views": 100,
"clicks": 78
}, {
"doc_id": 6,
"views": 100,
"clicks": 120
}, {
"doc_id": 3,
"views": 100,
"clicks": 465
}]
}
Выше представлены агрегированные данные, хранящиеся в отдельной базе данных для каждого ключевого слова.
Нравится программа? Поделись с друзьями! Если у меня уже есть «снег» в моей мета и новые запросы появляются с этим ключевым словом, я бы обновил один и тот же мета-документ.
Теперь я хочу обсудить недостатки и почему я решил сохранить их в отдельной базе данных, вместо этого добавляя их в документ elasticsearch.
Я не хочу забивать кластер elasticsearch каждый раз, когда вы запрашиваете новый запрос, чтобы обновить количество щелчков и количество просмотров в эластичных документах, так как я знаю, что обновление очень обширно в/в с инвертированным слиянием индексирования.
Теперь, чтобы исправить этот недостаток, у меня было бы ежедневное или двухдневное пакетное задание для переноса этой метаинформации на каждый документ в эластичном состоянии. Я бы перестроил весь кластер с помощью этой новой метаинформации и переместил псевдоним от старого индекса к новому индексу без какого-либо простоя.
Теперь, чтобы связать или добавить эту информацию в эластичный документ, я бы использовал parent-child documents relationship, чтобы нанести на карту упругий документ с ключевыми словами, связанными с этим.
Так что мой основной родительский документ и ребенок документ может выглядеть
родительского документа
PUT /index/type/3
{
"name": "Reebok shoes",
"category": "snow boots",
"price": 120
}
ребенка документ
PUT /index/type_meta/1?parent=3
{
"keyword": "boots",
"document_id": 3,
"doc_id": 3,
"views ": 100,
"clicks": 56
}
PUT /index/type_meta/1?parent=3
{
"keyword": "snow",
"document_id": 3,
"doc_id": 3,
"views ": 110,
"clicks": 560
}
Вышеприведенная родитель-потомок документа в значительной степени объяснить, как я строю мета для статистики поиска для каждого документа.
До сих пор мы создали действительно умное решение для сбора данных о событиях для статистики поиска и успешного их сопоставления с каждым документом в эластичном состоянии.
Позволяет начать смотреть на скоринговой запрос здесь -
Я не буду углубляться в проектировании оценка Algo здесь, но я пойду больше к реализации запроса, который может забить документы, основанные на представлениях, щелкните связанный с ключевым словом, а также для соответствия ключевым словам.
Function score query
Script score
Теперь я могу выбрать, чтобы дать больше weightage на матчи в наименовании, чем в категории. Это все из вашей точки зрения, и я не буду углубляться в разработку формулы счета для вас.
{
"query": {
"function_score": {
"query": {
"match_all": {}
},
"boost": "5",
"functions": [{
"filter": {
"match": {
"name": "snow"
}
},
"random_score": {},
"weight": 200
}, {
"filter": {
"match": {
"name": "boots"
}
},
"weight": 200
}, {
"filter": {
"match": {
"category": "snow"
}
},
"random_score": {},
"weight": 100
}, {
"filter": {
"match": {
"category": "boots"
}
},
"weight": 100
}, {
"filter": {
"query": {
"has_parent": {
"type": "type_meta",
"query": {
"match": {
"keyword": "snow"
}
}
}
}
},
"script_score": {
"script": {
"lang": "painless",
"inline": "_score + 20*doc['clicks'].value + 40 * doc['views].value"
}
}
}, {
"filter": {
"query": {
"has_parent": {
"type": "type_meta",
"query": {
"match": {
"keyword": "boots"
}
}
}
}
},
"script_score": {
"script": {
"lang": "painless",
"inline": "_score + 20*doc['clicks'].value + 40 * doc['views].value"
}
}
}],
"score_mode": "max",
"boost_mode": "multiply"
}
}
}
Таким образом, вы можете использовать запрос вроде предложения этого типа выше, я только выбрал очень простую формулу с демо-наддув Params для каждого пункта и этот запрос может быть переработан Furthur по реализации предварительного подсчета очков алгоритма.
Функция оценки сценариев важна здесь, так как я сначала фильтрую дочерние документы на основе ключевых слов для поиска для одного родительского документа, а затем используя оценку скрипта для использования щелчка и подсчета просмотров, чтобы повлиять на мою общую оценку документа.
Теперь это было своего рода решение, которое я хотел реализовать в своем проекте, и я открыт для предложений и улучшений в моем решении.
Пожалуйста, поделитесь своими предложениями и улучшениями.
Надеется, что это помогает Спасибо
как вы хотите ES знать о кликах? невозможно, это то, что вам нужно реализовать в вашей системе, которое позже представит некоторые данные щелчка в ES в качестве значений boost/bury. – Mysterion
Я знаю, что моя система должна отправлять данные кликов в elasticsearch. мой вопрос в том, как я могу сделать elasticsearch рассматривать данные журнала как часть формулы подсчета, которая содержит запросы и результаты. это не так просто, как усиление документа. –
Да, это не просто, но что-то легкое ad hoc может быть реализовано, например, при увеличении времени запроса на основе некоторой формулы let say score = initial_score + clicksw * показывает или что-то – Mysterion