Типы и производительность индексирования ElasticSearch

Question

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

Если ответ на вышеизложенное отсутствует и что типы эффективно объединены вместе, тогда я выложу остальную часть того, что я делаю, чтобы попытаться получить более подробный ввод.

В этом примере используется твиты для пользователей Twitter (для ясности назовите его владельцем). У меня многопользовательская среда с одним индексом на одного владельца твиттера. Тем не менее, сосредоточив внимание на одном владельце:

• Я захватить твиты от каждой шкале (упоминает, прямые сообщения, мои твиты и полный «домашний» график) в единый индекс, с каждым типом график, имеющий другое сопоставление в ElasticSearch
• Каждый твит относится к родительскому типу, пользователю, который создал твит (который может быть или не быть владельцем), с родительским сопоставлением. Существует только один тип пользователя для всех типов временной шкалы
• Я ищу и фасет только на одного владельца в одном запросе, поэтому мне не нужно заниматься поиском по нескольким индексам
• Домашняя хронология может захватывать миллионы твитов, где собственные твиты владельца могут приводить к сотням или тысячам.
• Документы пользователя регулярно обновляются с информацией за пределами временных графиков Twitter, поэтому я хотел бы избежать (если возможно) ситуации, когда я должен хранить несколько копий одного и того же объекта пользователя в синхронизации по нескольким индексам

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

Есть ли способ, который я могу понять, если проблема связана с общим количеством документов в определенном индексе, что-то связано с работой фильтрованных запросов has_child, другой плохой дизайн запросов или граней или что-то еще еще?

Любой вход будет оценен.

EDIT

Для уточнения о том, что твиты хранятся на временной шкале. Это означает, что существует тип ElasticSearch, определенный для home_timeline, my_tweets_timeline, mentions_timeline, direct_messages_timeline и т. Д., Которые соответствуют тому, что вы видите в стандартном пользовательском интерфейсе twitter.com. Таким образом, существует естественное разделение между наборами твитов, хотя и с некоторым перекрытием.

Я вернулся, чтобы проверить запросы has_child, и это определенная красно-селедка на данный момент. Основные запросы по более крупным индексам намного медленнее, даже если вы запрашиваете тип с несколькими тысячами строк (my_tweets_timeline).

Answer 1

Могу ли я предположить, что типы индексируются отдельно вдоль линий реляционной базы данных, где каждая таблица фактически разделена?

Нет, все типы объединены в один индекс, как вы уже догадались.

Есть ли способ, я могу понять, если вопрос с общим количеством документов в определенном индексе, что-то делать с операцией «has_child» отфильтрованных запросов, некоторые другие плохой дизайн запросов или граней, или что-то другое?

Общее количество документов в индексе, очевидно, является фактором. Вопрос о том, является ли вопрос has_child медленным, - это еще один вопрос - попробуйте сравнить производительность has_child запросов с тривиальными запросами term. has_child documentation предлагает один ключ под «соображений памяти»:

С текущей реализации, все _id значения загружаются в память (кучи) для того, чтобы поддерживать быстрый поиск, поэтому убедитесь, что имеется достаточно памяти для него.

Это означало бы, что требуется большой объем памяти для любого запроса has_child, где есть миллионы потенциальных детей. Убедитесь, что для таких операций достаточно памяти, или рассмотрите редизайн, который устраняет необходимость в has_child.