#mysql #ruby-on-rails #elasticsearch #full-text-search #elasticsearch-indices
#mysql — сервер #ruby-на-рельсах #эластичный поиск #полнотекстовый поиск #elasticsearch-индексы #mysql #ruby-on-rails #elasticsearch
Вопрос:
Я создал аукционную систему, которая использует ElasticSearch. В нем есть 3 модели, пользователи, аукционы и ставки. Пользователь может опубликовать аукцион, а также может делать ставки на других аукционах.
Один из моих первых вариантов использования для поиска — это поиск заявок. Помимо поиска по идентификатору, user_id, цене и т.д., я столкнулся с интересным вариантом использования. Я хочу иметь возможность искать имя пользователя, и оно должно возвращать все мои ставки со всех аукционов, размещенных этим пользователем.
например, когда я ищу «John», он получит все ставки, которые я отправил на все аукционы, опубликованные пользователем «John».
Вот как выглядит индекс:
Bids
- id (not analyzed)
- user_id (not analyzed)
- price (not analyzed)
- auction_user_name (uses ngrams)
У меня есть пара проблем с этим индексом:
-
В Bids много строк (10M ), а наличие n-граммов
auction_user_name
занимает много места. Я думаю, действительно ли эти данные должны быть ненормализованы в одном индексе с одним типом, или если есть какие-либо альтернативы, которые более подходят (родительско-дочерние типы)? -
Некоторые пользователи очень активны и могут делать тысячи ставок. Если один из них изменит свое имя, это приведет к тысячам обновлений индекса ставок. Это не идеально, и из-за дубликатов это может привести к индексу с большим объемом записи, который может быть уязвим для отказа в обслуживании.
Существуют ли известные решения этих двух проблем? Я уверен, что есть какой-то компромисс, на который я могу пойти, чтобы решить эту проблему.
Я видел несколько предложений по:https://www.elastic.co/guide/en/elasticsearch/guide/current/relations.html
Методы не так элегантны, как я себе представлял, поэтому мне интересно, есть ли еще способы решения этой проблемы.
Комментарии:
1. Для # 2. Идентификатор выполняет поиск имени пользователя в таблице пользователя, а затем возвращает соответствующие ставки для найденной «записи» (не результат) вместо добавления имени пользователя в виде столбца в таблицу ставок, поскольку у вас уже есть связь между ними по идентификатору пользователя.
2. @bkunzi01 Да, я также думал о том, чтобы сначала получить идентификаторы пользователей из индекса пользователей, а затем снова выполнить поиск по индексу eoi. Но проблема в том, что разбивка на страницы может быть сложной при объединении результатов индекса на уровне приложения. Как вы думаете, это может привести к принудительному использованию реляционного решения в хранилище, отличном от sql?