Независимые индексы в упругом поиске

Question

ОБНОВЛЕНИЕ: Переопределено то, что я пытаюсь сделать.

У меня есть модель контакта, этот контакт относится к учетной записи, как и любая другая модель моей учетной записи. Мне нужны все поисковые запросы, являются ли они глобальными или специфичными для модели, чтобы запрашивать только содержащую учетную запись. Мне сказали, что я могу сделать это с помощью пользовательских имен индексов. Я хотел бы, чтобы имя индекса было «index - # {account-id}». Как я могу добиться этого в своих активных моделях?

class Contact < ActiveRecord::Base 
    include Tire::Model::Search 
    include Tire::Model::Callbacks 

    belongs_to :account 

    mapping do 
    indexes :first_name 
    indexed :last_name 
    end  

end 

class Account < ActiveRecord::Base 
    has_many :contacts 
end 

Answer 1

Вы ссылаетесь на то, что каждая учетная запись (пользователь?) Физически разделяется в каждом своем собственном индексе? Это, как правило, называют «мульти-арендатора» http://en.wikipedia.org/wiki/Multitenancy

Предполагая, что это действительно то, что вы намеревались сделать:

Многое было сказано в прошлом о «необходимости» (я предполагаю, что вы хотите это для по соображениям безопасности, я не знаком с другими причинами, по которым вы хотели бы этого, хотя я не являюсь экспертом в приложениях с несколькими приложениями) для разделения данных на одного пользователя/пользователя, поскольку он имеет только поле, скажем, поле accountid для Contact и убедитесь, что все ваши запросы фильтруют, по крайней мере, на accountid. IMO, тщательно спроектированный компонент запроса, где, скажем, каждый запрос, используемый в системе, наследуется от «супер-запроса», который требуется для установки accountid, будет достаточным во многих случаях.

Даже если вы не знаете заранее, какие приложения в будущем захотят запросить эти индексы, вы все равно можете обеспечить соблюдение вышеуказанного, например, имея тонкую службу REST вокруг ES и требующую, чтобы все программы взаимодействовали с ES через эта услуга. Затем вы можете использовать эту службу для защиты этого типа, применяя accountid или, возможно, лучше, вызывая accountid текущим зарегистрированным пользователем, выполняющим запрос.

Если вы все еще хотите преуспеть в многоквартирном деле, посмотрите: http://elasticsearch-users.115913.n3.nabble.com/Multi-tenacy-td471400.html (быстро найти это, возможно, есть что-то лучше). «Кимчи» (создатель ES) также комментирует эту тему.

Независимо от того, лучший способ в ES иметь многопользовательский договор, вероятно, иметь 1 индекс для учетной записи/пользователя. В этом случае вы можете иметь несколько «типов» (конструкцию ES), где Contact может быть таким типом.

http://www.elasticsearch.org/guide/reference/mapping/ http://www.elasticsearch.org/guide/reference/api/search/indices-types.html

Обеспечение этого в моделях, как вы предлагаете, это, вероятно, не правильный путь ИМО. Как правило, вы должны держать свои модели домена в чистоте от любых знаний на бэкэнде хранилища (включая индекс, в котором хранятся данные)

Для меня лучшим решением было бы, как было предложено ранее, компонент, в котором будет содержаться логика выбора правильного индекса на основе учетной записи/пользователя. Исходя из вышеприведенного подхода к сервису rest-service, динамическое имя индекса, как вы сказали, может быть получено от пользователя, выполнившего запрос.

Я понимаю, что это, вероятно, не был прямым ответом на ваш вопрос, но я надеюсь, что это было полезно, тем не менее.

Answer 2

Возможно, вы захотите проверить это comment at Tire's issues, в котором в основном просматриваются некоторые возможные сценарии, называемые индексом «арендатор» с тире. Я верю, что это то, что тебе нужно.

В самом elasticsearch вы можете иметь отдельный индекс для каждой учетной записи, отфильтрованный псевдоним псевдонимов & для каждой учетной записи, шаблоны индексов и т. Д. И т. Д., Поэтому набор инструментов в этой области обширен.