Comments 14
а количество RAM под Java Heap наоборот уменьшили до 30 ГБ
А вас при таком хипе GC-паузы не мучают?
+1
Несколько вопросов:
1. Что у вас используется для мониторинга и управления кластером?
2. Сколько суммарно используется оперативки на мастер-нодах без учёта реплик?
3. Какая у вас ширина индекса?
4. Как долго вставляется документ?
Спасибо за ответы!
1. Что у вас используется для мониторинга и управления кластером?
2. Сколько суммарно используется оперативки на мастер-нодах без учёта реплик?
3. Какая у вас ширина индекса?
4. Как долго вставляется документ?
Спасибо за ответы!
0
1. www.elasticsearch.org/overview/marvel/
2. Всего 18 мастер нод, на каждой ~ 100 гб RAM. 30% -> Java Heap (для всяких кешей фильтров, сортировок и тп), 70% -> OS, RAM забивается под 90%, из-за того что при использовании mmapfs данные с диска кешируются именно туда, за счет этого сильно растет производительность
3. уточните вопрос
4. 10к документов балком ~ 90 мс. Но это все равно что пальцем в небо — все зависит от размера документа, анализаторов и тп вещей.
2. Всего 18 мастер нод, на каждой ~ 100 гб RAM. 30% -> Java Heap (для всяких кешей фильтров, сортировок и тп), 70% -> OS, RAM забивается под 90%, из-за того что при использовании mmapfs данные с диска кешируются именно туда, за счет этого сильно растет производительность
3. уточните вопрос
4. 10к документов балком ~ 90 мс. Но это все равно что пальцем в небо — все зависит от размера документа, анализаторов и тп вещей.
0
3. Помимо индексирования текста документа используются дополнительные индексированные атрибуты: дата создания, категория, код, владелец/автор, etc?
4. Да, согласен про палец :) Задал вопрос, смотря на тему со своей колокольни. Среднюю температуру по больнице понял, спасибо!
4. Да, согласен про палец :) Задал вопрос, смотря на тему со своей колокольни. Среднюю температуру по больнице понял, спасибо!
0
в эластике есть такая штука как роутинг, думаю, его стоит посмотреть.
blog.qbox.io/launching-and-scaling-elasticsearch
blog.qbox.io/launching-and-scaling-elasticsearch
0
Роутинг — отличная вещь, когда есть хотя бы 1 признак, по которому можно из-вне создать уникальный ключ для группы документов. К примеру у вас есть база пользователей и логично что все, что относится к этому пользователю должно быть на 1 шарде — производительность растет экспоненциально, ведь мы не опрашиваем 400 шардов как в нашем случае, а всего 1.
При всех плюсах рутинга в нашем случае очень сложно выделить какой-то один признак (много емейлов, много телефонов, много социальных сеток — а профиль 1)
При всех плюсах рутинга в нашем случае очень сложно выделить какой-то один признак (много емейлов, много телефонов, много социальных сеток — а профиль 1)
+1
а что представляют из себя ваши документы? если исходить из «поисковый движок по социальной информации», то это например профиль в твиттере, отдельный твит или всё вместе?
0
Честно говоря, я никогда не работал с ElasticSearch, поэтому не знаю насколько мои вопросы корректны, но всё же есть пару вопросов:
1) у вас шарды дифференцированы по типу индекса? Например: эти 20 шардов для FB, это 30 для Twitter и т.д.? Мне кажется, что если их так разделить, то можно настроить роутинг внутри группы шардов.
2) может вообще стоить разделить индексацию из разных типов источников данных по разным кластерам ElasticSearch, тогда вы во-первых сможете делать параллельные запросы по одному и тому же юзеру, но по разным источникам данных, а во вторых роутинг внутри каждого кластера сократит время запроса. Тогда получится, что суммарное время выполнения запроса будет не больше, чем самый долгий запрос по одному источнику (но и он будет не такой уж и долгий за счет того, что путь к шарде будет известен заранее)
1) у вас шарды дифференцированы по типу индекса? Например: эти 20 шардов для FB, это 30 для Twitter и т.д.? Мне кажется, что если их так разделить, то можно настроить роутинг внутри группы шардов.
2) может вообще стоить разделить индексацию из разных типов источников данных по разным кластерам ElasticSearch, тогда вы во-первых сможете делать параллельные запросы по одному и тому же юзеру, но по разным источникам данных, а во вторых роутинг внутри каждого кластера сократит время запроса. Тогда получится, что суммарное время выполнения запроса будет не больше, чем самый долгий запрос по одному источнику (но и он будет не такой уж и долгий за счет того, что путь к шарде будет известен заранее)
0
1. В эластике схема несколько другая. Есть индекс -> фиксированное количество шардов -> далее либо автоматом распределяется эластиком, либо опять же «автоматом», но с использованием routing key. У нас проблема в том, что нет 10 профилей для каждой соц сети, а есть 1 большой профиль со всеми сетями. Все «условно-уникальные» идентификаторы — это массивы таких идентификаторов. Поэтому для рутинга так ничего и не было придумано. Зато можно кешировать выборки по данным соц сетям внутри nested документов, что в свою очередь тоже повышает скорость индексирования
2. Много разных кластеров или 1 — это не принципиально. По сути в эластике индекс, шард, сегмент и так далее — это самостоятельные Lucene индексы.
2. Много разных кластеров или 1 — это не принципиально. По сути в эластике индекс, шард, сегмент и так далее — это самостоятельные Lucene индексы.
0
Sign up to leave a comment.
Масштабируем Elasticsearch на примере кластера с индексами в несколько терабайт