Ага..

Коллеги, подскажите, а где можно взять скомпилированный jdbc драйвер со всеми зависимостями?

<dependency> <groupId>ru.yandex.clickhouse</groupId> <artifactId>clickhouse-jdbc</artifactId> <version>0.1.26</version> </dependency>

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

@vladimirmyuge , или нужен просто jar?

<dependency> <groupId>ru.yandex.clickhouse</groupId> <artifactId>clickhouse-jdbc</artifactId> <version>0.1.26</version> </dependency>

Мне джарник нужен

А multiregion cluster при таких вводных адекватно собирается ?

Мне джарник нужен

https://github.com/yandex/clickhouse-jdbc/releases

Нужно ha, мультирегиональность и возможность оперативно докидывать ноды когда кончается место

https://github.com/yandex/clickhouse-jdbc/releases

обманул, там исходники :(

https://github.com/yandex/clickhouse-jdbc/releases

Спасибо, но, на сколько я понимаю, там исходники, а мне бы скомпленный

обманул, там исходники :(

ага

Я просто не умею компилировать (

Нужно ha, мультирегиональность и возможность оперативно докидывать ноды когда кончается место

Если сеть тянет, то проблем с гео нет, если самостоятельно организуете запись в нужные шарды (или chproxy это умеет Aliaksandr ?) то проблем особых нет

Ну это облака, там проблем нет. Ну, пока не сломалось - нет :(

А ch умеет чинить один регион данными из второго ?

На случай если данные побились

И умеет ли он affin'ить шарды по каким либо условиям ?

КХ всё равно на регионы, это вы все сами настраиваете, он просто видит сервера в кластере и шарды, если на сервере чего-то не хватает он пытается вытащить куски данных с других (это если совсем на пальцах).

https://clickhouse.yandex/docs/en/single/#distributed

Оке, спасибо большое, пойду пробовать

хмм. вот у меня получилось клиентом подключиться и он даже исполняет SELECT-ы тестовые, но когда пробую все-таки закачать данные, через пару секунд размышления дает такое Code: 210. DB::NetException: Connection reset by peer while writing to socket (172.17.0.2:9000) это уже не преодолеть? )

Если сеть тянет, то проблем с гео нет, если самостоятельно организуете запись в нужные шарды (или chproxy это умеет Aliaksandr ?) то проблем особых нет

chproxy умеет только равномерно раскидывать запросы (пофиг какие - селекты или инсерты) по репликам и шардам. Сначала выбирается наименее нагруженная реплика, а потом в ней - наименее нагруженный шард. Нагрузка определяется по количеству исполняемых в данный момент запросов на реплике/шарде

Понятно

А количество свободного места она не учитывает ?

нет

Как тогда быть при добавлении новой ноды?

хотя если на шарде закончится свободное место, то она начнет возвращать ошибки при попытке записать туда данные. chproxy в таком случае снизит нагрузку на эту шарду, перекинув запросы на рабочие шарды :)

Проксей можно ставить несколько ? Они не поссорятся друг с другом?

Как тогда быть при добавлении новой ноды?

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

Проксей можно ставить несколько ? Они не поссорятся друг с другом?

можно ставить несколько. Они про друг друга ничего не знают

О, а на каких машинах вы там все это гоняете ?

на 16-ядерных с 104гб озу

Thx )

Диски ssd же?

нет, hdd )

они дешевле

Ээ..

И медленнее

приходится чем-то жертвовать

Давайте я к вам со своей балалайкой зайду - у нас прирост от SSD менее 12% тоже на hdd сидим

Давайте я к вам со своей балалайкой зайду - у нас прирост от SSD менее 12% тоже на hdd сидим

Опа.. Гугл? Какой паттерн использования ? Какие размеры дисков ?

при использовании hdd в гугл клауде пока столкнулись с одной проблемой - ограниченная скорость записи/чтения на один комп - 120/180 мб/с соответственно. Без разницы, сколько туда замаунтить hdd - все равно будет такое ограничение. Мы его обходим добавлением дополнительных шард )

Опа.. Гугл? Какой паттерн использования ? Какие размеры дисков ?

Нет, не Гугл, selfhosted, аналитика, риалтайм графики, диски по 6 TB

в сентябре они обещали поднять это ограничение до 400мб/с, но пока еще не подняли

Всем привет! Хотим провернуть такую операцию. Есть шардированная таблица. Хотим сделать из неё обычную. Т.е. хотим сделать DETACH на всех серверах. Перенести все файлы со всех серверов на один сервер. Сделать ATTACH. Получить на тех же данных нешардированную таблицу. Так получится? Спасибо.

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

Добрый день! На недавнем митапе обещали, что в первом квартале 18го года появятся update/delete. Можете подсказать примерную дату релиза?

/stat@combot

combot.org/chat/-1001080295593

короче, 30Мб льются нормально в КХ на докере, через клиента в докере, а когда пихаю 400Мб - выпадает с ошибкой Code: 210. DB::NetException: Connection reset by peer while writing to socket (172.17.0.2:9000) это может быть докера проблема, моей сети, КХ или всего вместе? :)

короче, 30Мб льются нормально в КХ на докере, через клиента в докере, а когда пихаю 400Мб - выпадает с ошибкой Code: 210. DB::NetException: Connection reset by peer while writing to socket (172.17.0.2:9000) это может быть докера проблема, моей сети, КХ или всего вместе? :)

ещё ulimit может быть с ограничениями)

щас попробую ) спс

щас попробую ) спс

а в логе что?

а как глянуть?

а как глянуть?

по умолчанию в /var/log/clickhouse-server/

а там вообще пусто

чудеса, ничего не менял, но закачалось в конце концов. самые пугающие ошибки вот такие – фантомные.

а вы не гуглили ошибку? https://github.com/yandex/ClickHouse/issues/434

там у чувака памяти не хватало

еррор_лог настройте, без него никуда

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

ну вы же в докере запускаете?

да

лимит по памяти задаете может быть?

нет, вроде бы, я их рекомендуемыми параметрами пользуюсь https://hub.docker.com/r/yandex/clickhouse-server/

хотя там у самого докера есть настройки по памяти, попробую их тоже подергать, спасибо

короче, 30Мб льются нормально в КХ на докере, через клиента в докере, а когда пихаю 400Мб - выпадает с ошибкой Code: 210. DB::NetException: Connection reset by peer while writing to socket (172.17.0.2:9000) это может быть докера проблема, моей сети, КХ или всего вместе? :)

похоже на какой-то таймаут на стороне кликхауса. Засеките, через сколько времени после начала инсерта возникает эта ошибка.

потом гляньте в select * from system.settings where name like '%timeout%' и попытайтесь найти похожее значение )

если ошибка возникает через 10 секунд, то может быть виноват keep_alive_timeout - он по умолчанию 10 секунд

https://github.com/yandex/ClickHouse/releases/v1.1.54327-stable was tagged

Докер образы когда будут выкладваться?

Это патч релиз к версии 1.1.54318. Никаких новых фич нет. Исправлена проблема с возможным race condition при репликации, которая может приводить к потере данных. Проблеме подвержены версии 1.1.54310 и 1.1.54318. Если вы их используете и у вас есть Replicated таблицы, то обновление обязательно. Понять, что эта проблема существует, можно по сообщениям в логе Warning вида "Part ... from own log doesn't exist." Даже если таких сообщений нет, проблема всё-равно актуальна.

Докер образы когда будут выкладваться?

Сейчас автоматическая выкладка Docker образов не работает, выложим позже.

Отлично что до рождественских каникул патч пришел )

Отлично что до рождественских каникул патч пришел )

Да, специально решили сначала патч. А потом может быть будет ещё полноценный релиз для энтузиастов.

Докер образы когда будут выкладваться?

Docker посмотрели, вроде сейчас собрался.

Спасибо, какие же вы все таки молодцы

сейчас попробую zetcd на последнем релизе собрать

кстати оно поднимается и даже данные вставляются но если повторно вставить одни и теже данные то почему то падает clickhouse в кишках zookeper клиента =(

Да, специально решили сначала патч. А потом может быть будет ещё полноценный релиз для энтузиастов.

Спасибо.

кстати оно поднимается и даже данные вставляются но если повторно вставить одни и теже данные то почему то падает clickhouse в кишках zookeper клиента =(

Оно, скорее всего, так и будет падать пока кого-то конкретно не припрет перейти на zetcd с zookeper'a и этот кто-то не поправит zetcd )

Подскажите, как вы реализуете алгоритм по складыванию пачками? Какие приемы используете? Я пишу на php. Хотел бы услышать совета комъюнити. Выдержка из документации: "Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду."

Подскажите, как вы реализуете алгоритм по складыванию пачками? Какие приемы используете? Я пишу на php. Хотел бы услышать совета комъюнити. Выдержка из документации: "Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду."

a) пишите в очередь (kafka, rabbit, redis etc), раз в N секунд вытаскиеваете данные и пишите б) дописываете в файлик csv/tsv и раз в N секунд через клиент/curl его заливаете, после чего очищаете файлик

если пишете в кафку, то, возможно, вам подойдет https://clickhouse.yandex/docs/en/table_engines/kafka.html

кстати, а нет, случайно, готовых скриптов, который для ваших конкретных КХ, сети и природы данных определяют идеальный предел для вставки / чтения ?

a) пишите в очередь (kafka, rabbit, redis etc), раз в N секунд вытаскиеваете данные и пишите б) дописываете в файлик csv/tsv и раз в N секунд через клиент/curl его заливаете, после чего очищаете файлик

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

только в этом у меня сейчас проблема. Подскажите демона (или алгоритм), чтобы дописывал статистику раз в 2-3 секунды

Подскажите, как вы реализуете алгоритм по складыванию пачками? Какие приемы используете? Я пишу на php. Хотел бы услышать совета комъюнити. Выдержка из документации: "Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду."

есть еще вариант покурить buffer таблицы

мы пишем в локальный fluentd, который уже дальше накопленный буфер скидывает в КХ с нужным интервалом

может поможет

есть еще вариант покурить buffer таблицы

читал, но там написано "Заметим, что даже для таблиц типа Buffer не имеет смысла вставлять данные по одной строке, так как таким образом будет достигнута скорость всего лишь в несколько тысяч строк в секунду, тогда как при вставке более крупными блоками, достижимо более миллиона строк в секунду (смотрите раздел «Производительность»)." то есть смысла использовать buffer нет, если я не буду вставлять пачками

читал, но там написано "Заметим, что даже для таблиц типа Buffer не имеет смысла вставлять данные по одной строке, так как таким образом будет достигнута скорость всего лишь в несколько тысяч строк в секунду, тогда как при вставке более крупными блоками, достижимо более миллиона строк в секунду (смотрите раздел «Производительность»)." то есть смысла использовать buffer нет, если я не буду вставлять пачками

от вашей нагрузки зависит

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

Сам не проверял, но мне кажется что курлом можно пользоваться чаще чем раз в минуту. Если у вас данные в памяти, то и скидывайте их в КХ раз в секунду-две

Еще вот такая штука есть https://github.com/nikepan/clickhouse-bulk

Сам не проверял, но мне кажется что курлом можно пользоваться чаще чем раз в минуту. Если у вас данные в памяти, то и скидывайте их в КХ раз в секунду-две

нельзя, только костылями, и я пробовал использовать костыли и задедосил сам свой сервер, неприятная штука была