Как стать автором
Обновить

Комментарии 14

а количество RAM под Java Heap наоборот уменьшили до 30 ГБ

А вас при таком хипе GC-паузы не мучают?
Где-то видел график (от разработчиков Кассандры, кажется) — после 8ГБ задержки растут экспоненциально, в связи с этим общая производительность падает.


Примерно так это все выглядит в разрезе ноды, так что нет — не мучает
Несколько вопросов:
1. Что у вас используется для мониторинга и управления кластером?
2. Сколько суммарно используется оперативки на мастер-нодах без учёта реплик?
3. Какая у вас ширина индекса?
4. Как долго вставляется документ?
Спасибо за ответы!
Для 1, мне нравятся плагины ES Head и Paramedic.
1. www.elasticsearch.org/overview/marvel/
2. Всего 18 мастер нод, на каждой ~ 100 гб RAM. 30% -> Java Heap (для всяких кешей фильтров, сортировок и тп), 70% -> OS, RAM забивается под 90%, из-за того что при использовании mmapfs данные с диска кешируются именно туда, за счет этого сильно растет производительность
3. уточните вопрос
4. 10к документов балком ~ 90 мс. Но это все равно что пальцем в небо — все зависит от размера документа, анализаторов и тп вещей.
3. Помимо индексирования текста документа используются дополнительные индексированные атрибуты: дата создания, категория, код, владелец/автор, etc?
4. Да, согласен про палец :) Задал вопрос, смотря на тему со своей колокольни. Среднюю температуру по больнице понял, спасибо!
3. Маппинг, который мы используем занимает порядка 300 строчек, типы разнятся, и включают в себя nested объекты, в них есть просто термины, даты, комбинации всего перечисленного.
Роутинг — отличная вещь, когда есть хотя бы 1 признак, по которому можно из-вне создать уникальный ключ для группы документов. К примеру у вас есть база пользователей и логично что все, что относится к этому пользователю должно быть на 1 шарде — производительность растет экспоненциально, ведь мы не опрашиваем 400 шардов как в нашем случае, а всего 1.

При всех плюсах рутинга в нашем случае очень сложно выделить какой-то один признак (много емейлов, много телефонов, много социальных сеток — а профиль 1)
а что представляют из себя ваши документы? если исходить из «поисковый движок по социальной информации», то это например профиль в твиттере, отдельный твит или всё вместе?
Сейчас мы обрабатываем ~ 50 соц сетей. Профиль — это агрегированные данные по конкретному человеку исходя из наших алгоритмов.
Честно говоря, я никогда не работал с ElasticSearch, поэтому не знаю насколько мои вопросы корректны, но всё же есть пару вопросов:
1) у вас шарды дифференцированы по типу индекса? Например: эти 20 шардов для FB, это 30 для Twitter и т.д.? Мне кажется, что если их так разделить, то можно настроить роутинг внутри группы шардов.
2) может вообще стоить разделить индексацию из разных типов источников данных по разным кластерам ElasticSearch, тогда вы во-первых сможете делать параллельные запросы по одному и тому же юзеру, но по разным источникам данных, а во вторых роутинг внутри каждого кластера сократит время запроса. Тогда получится, что суммарное время выполнения запроса будет не больше, чем самый долгий запрос по одному источнику (но и он будет не такой уж и долгий за счет того, что путь к шарде будет известен заранее)
1. В эластике схема несколько другая. Есть индекс -> фиксированное количество шардов -> далее либо автоматом распределяется эластиком, либо опять же «автоматом», но с использованием routing key. У нас проблема в том, что нет 10 профилей для каждой соц сети, а есть 1 большой профиль со всеми сетями. Все «условно-уникальные» идентификаторы — это массивы таких идентификаторов. Поэтому для рутинга так ничего и не было придумано. Зато можно кешировать выборки по данным соц сетям внутри nested документов, что в свою очередь тоже повышает скорость индексирования

2. Много разных кластеров или 1 — это не принципиально. По сути в эластике индекс, шард, сегмент и так далее — это самостоятельные Lucene индексы.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории