на 64гб памяти можно три ноды запустить по 7гб хипа каждая

Если один шард сделать на одной ноде, то будет green :)

да

двух же достаточно, зачем три

ну да, на одной тачке сплит брейна не будет

тоже верно

так-то и одной хватит на 64гб.

рекомендуется запускать несколько нод на машинах там с 64гб+ памяти, например, 128 - две ноды по 31гб хипа

просто надо перенастроить под кластер без реплик, заодно и шардов больше влезет, кстати

вот не хочется об этом думать ) на таких копеечных объемах данных придумывать там что-то с шардами, нодами и т.п.

абсолютно согласен

короче эластик классный поиск, но как база он ужасающ. ок, попробуем кликхаус тогда

причем elastic у нас на селектах нормально себя показывает, в этом смысле претензий к нему не очень много просто неудобный в использовании и обслуживании

как будете переливать из мускуля в кликхаус?

хранить там вечно? или подчищать перенесенные данные клх?

а кликхаус же хорош для хранения?

мы с этим переездом в мускуль писать перестаем первичные данные в виде файлов собираем, их в clickhouse, а потом в s3

а как кхе-кхе ETL из кликхауса в s3?

есть че-то готовое или тулзу писать?

у эластика круто сделаны снапшоты, кстати. вот этого не хватает в старых базах

кнопку нажал, индексы улетели на s3

не не, не из clickhouse в s3. просто - логи в виде файлов и забекапить так чтобы если что поднять их можно было оттуда

запрос написал, из s3 индекс вернул

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

Добрый вечер, мы подготовили вторую статью про ClickHouse для публикации на Хабре, мы еще прогоним статью через наших “орфограторов и пунктуаторов”, и попросим нашего филолога поправить русский язык, но техническую часть оформили: https://github.com/smi2/phpClickHouse/blob/master/doc/02_article_cluster.md Будем рады предварительной критике )

блин, в кликхаусе зукипер, вот это подстава

%)))

блин, в кликхаусе зукипер, вот это подстава

?

блин, в кликхаусе зукипер, вот это подстава

А вам непременно кластер нужен?

не, думаю, одной машины хватит

Тогда зукипер нинужын

если честно, хотелось бы альтернатив в виде consul и etcd

если уж припрет кластер делать

zk изящен, как седло на корове

^

вот-вот, мы для сервисов консул собираемся

у кого чего есть

просто если есть консул впихивать еще zk как-то лишне

ну понятно почему зк, я так понял, внутри яндекса везде zk

так что это если только мы с вами запилим альтернативы

если надо хадуп кому-то, всё равно зукипер ставить, например.

но мы ведь ставим кликхаус чтобы не надо было

Для твоей одиночной машины оно и не надо

а как мониторить кликхаус? есть для prometheus чо?

о, неплохо

А в качестве хранения clickhouse - вполне себе ок. Я пробовал заливать суточный срез netflow - результаты более чем устроили.

ну если кому-то нужен zk, то можно zk

а если zk нет, то нафиг он

?

поидее без zk не будет работать дедупликация вставляемых данных. когда послал пачку данных, упал в процессе, послал снова

что CH делает с ZK?

key-value или что-то сложнее?

Вообще, в Яндексе не только zk. Есть и решения по-лучше но они не в оупесорсе пока. А для своих целей zk в кликхаусе вполне норм. У вас с ним какие-то проблемы?

так какие цели у zk?

так какие цели у zk?

консенсус в кластере же.

какие ещё могут быть

Вообще, в Яндексе не только zk. Есть и решения по-лучше но они не в оупесорсе пока. А для своих целей zk в кликхаусе вполне норм. У вас с ним какие-то проблемы?

решения получше в смысле распределенные менеджеры конфигураций?

у нас еластик, щас правда еще разработка, но с имитацией реальной нагрузки. база с кликами, каждый клик - какие-то распарсенные данные + неиндексируемые хедеры, в сумме примерно 1 клик = 1кб, судя по объемам на винте. щас база весит 2 тб, реальная нагрузка будет 50-100\с, но для тестов делали и 2к рпс. 3 сервака под это дело, с репликацией и шардингом, пока никакой боли не видно особой

мне бы тоже хотелось узнать про боль до выхода в прод)

у нас дефолт. но там хип по-моему больше, в районе 40-50, не помню точно

за 32 гб JVM начинает декомпрессить указатели, если вы этим специально не занимались, то это может наоборот ухудшить вам производительность. Точных данных, конечно, ни у кого нет, но rule of thumb за 32 не выходить

вы маппинги индексам делаете?

за 32 гб JVM начинает декомпрессить указатели, если вы этим специально не занимались, то это может наоборот ухудшить вам производительность. Точных данных, конечно, ни у кого нет, но rule of thumb за 32 не выходить

я там спутал(сейчас проверил). 57гб - это сколько сейчас elastic жрет памяти cat /proc/11211/status | grep VmSize VmSize: 56113512 kB хип там другой: -Xmx12Gb я повторюсь - скорее всего мы его плохо готовим. на селектах он проблем не вызывает, проблемы иногда возникают в обслуживании (бывало такое что он не поднимался после рестарта, или поднимался минут 20). я уверен что подкрутив параметры или как-то разнеся на ноды это может решиться. просто по впечатлениям которые получили - работать с ним сложно

маппинги используем

короче пора elasticsearch_ru заводить

ну и основное что напрягает - инструменты не очень удобные (когда в коде - еще ничего, но в отладке - мучаемся). запрос писать в json - то еще развлечение

единственно что могу пока конкретное сказать про обслуживание - переезд 1тб базы с 2.4 до 5.1 проходил около 12 часов (желтый статус)

короче пора elasticsearch_ru заводить

давай

Если вам просто собирать логи - попробуйте graylog, это обертка над elastic, которая сделает бОльшую часть за вас и позволит тупо скидывать логи в AMQP, особо не беспокоясь за время доставки. Я могу какие-то еще советы дать в личной беседе позже, но я на самом деле только теоретический сварщик; т.к. тут еще пара человек отписалась, возможно, имеет смысл действительно создать конфу.

я там спутал(сейчас проверил). 57гб - это сколько сейчас elastic жрет памяти cat /proc/11211/status | grep VmSize VmSize: 56113512 kB хип там другой: -Xmx12Gb я повторюсь - скорее всего мы его плохо готовим. на селектах он проблем не вызывает, проблемы иногда возникают в обслуживании (бывало такое что он не поднимался после рестарта, или поднимался минут 20). я уверен что подкрутив параметры или как-то разнеся на ноды это может решиться. просто по впечатлениям которые получили - работать с ним сложно

https://blog.frankdejonge.nl/how-a-20mb-data-set-brought-down-a-14gb-elasticsearch-cluster/

@elasticsearch_ru переезжаем

Никто с таким не сталкивался?

График Cpu utilization

http://i.imgur.com/g4edUBN.png

В CLH 6 таблиц

в две из них идет запись примерно 1600 запросов/сек (пиковые значения)

все таблицы - движок MergeTree

где непонятно? поясню

в две из них идет запись примерно 1600 запросов/сек (пиковые значения)

ваще вроде бы рекомендовали поменьше запросов в секунду

просто бóльшими пачками

> Производительность при вставке данных. > Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду.

может, поэтому так

попробуем, спасибо!

кстати нет, походу, это тот же чел из cloudflare

https://github.com/vavrusa

вон драйвер для ORM питоньей делает

кто знает я еще успею поговорить ?

записей немного, 300-400 документов в секунду

на таких объемах явно делаете что-то не так. сколько всего документов в индексе и размер базы?

у нас очень много индексов по некоторым причинам

возможно, проблема в этом

"active_primary_shards" : 6051, "active_shards" : 12042,

заставили?

Пока добровольно.