риск того, что ее кто-то забудет смонтировать

Всем привет! Есть какие-нибудь прогнозы по решению https://github.com/yandex/ClickHouse/issues/364 ?

риск того, что ее кто-то забудет смонтировать

Это и с обычным линуксом кстати та еще проблема: что-то ломается в монтируемом сторадже и сервер бд радостно пишет в каталог пару дней, потом получается недоступный неудаляемый кусок данных

^^ на windows такой проблемы нету! :)

Нет стораджа нет проблем

не, корень проблемы в БД

вот без БД - жезь совершенно прекрасна :)

Всем привет! Есть какие-нибудь прогнозы по решению https://github.com/yandex/ClickHouse/issues/364 ?

Это запланировано на ближайшую неделю.

Это запланировано на ближайшую неделю.

спасибо!

Это и с обычным линуксом кстати та еще проблема: что-то ломается в монтируемом сторадже и сервер бд радостно пишет в каталог пару дней, потом получается недоступный неудаляемый кусок данных

я это решаю так: монтирования все делаю в /mnt. Например /mnt/clickhouse там создаю папку ROOT и делаю символьную ссылку там где хочу этот диск использовать в ROOT например ln -s /mnt/clickhouse/ROOT /opt/clickhouse/storage тогда если монтирование по какой-то причине отвалилось ссылка окажется битой и база просто не заработает - это будет заметно быстро. Еще вариант просто на монтируемом томе создавать папку и писать в неё. Но тогда надо убедиться что база не сможет сама для себя создать недостающие уровни при старте.

ключевая проблема как раз в том, что бы база не создавала нужные директории. Это очень удобно для пользователей

слишком много телодвижений, почему просто не прописать /mnt/clickhouse/ в docker-compose volumes?

слишком много телодвижений, почему просто не прописать /mnt/clickhouse/ в docker-compose volumes?

вот да

слишком много телодвижений, почему просто не прописать /mnt/clickhouse/ в docker-compose volumes?

потому что если /mnt/clickhouse не смонтируется - будет работа с папкой /mnt/clickhouse а тут суть в том что внутри диска создается еще одна папка, которая будет отсутствовать, если диск не смонтировался.

т.е. можно например прописать /mnt/clickhouse/ROOT

если создать запрос вида select (select count() from log group by userid where eventdate=today()) + (select count() from log group by userid where eventdate=today()-1) + (select count() from log group by userid where eventdate=today()-2) + ... as cnt то подзапросы (select count() from log group by userid where eventdate=today()) будут исполняться последовательно или параллельно?

А чего ему не смонтироваться? Довод принял, но имхо это уже не проблема докера или кликхауса.

точнее подзапросы вида: select count() from (select userid group by userid having count() < 2)

А чего ему не смонтироваться? Довод принял, но имхо это уже не проблема докера или кликхауса.

согласен, не их проблема. Это защита от ошибок на другом уровне. Например если пользоваться LVM-thin, то сначала всё работает. А при росте количества томов начинаешь замечать что том активируется не моментально при старте системы, а через некоторое время. Это и другие проблемы могут быть неочевидны при настройке и вызывать задержки, в гонке с которыми докер например запустится раньше, чем будет готово хранилище для базы. Это конечно решаемо, но есть другие случаи, к которым можно быть неготовым и тогда лучше чтобы не работало - это чинить проще.

Здравствуйте. Пытаюсь запустить тестовую конфигурацию из 4-х шардов с одной репликой, делаю всё так, как описано в документе, однако при INSERT'e получаю: Code 170 (cluster not found)

помогите понять в чём проблема

версия - последняя, поставил сегодня из репозитория

Наверное, потому что имя кластера указано через минусики. Такое интерпретировалось в запросе как выражение с оператором минус. Попробуйте заменить минусы на _ в имени кластера.

может из-за этого?

нет в имени кластера минусиков... af_4_shards - название кластера

таблички: локальная и распределенные создались без проблем на всех нодах

Здравствуйте. Пытаюсь запустить тестовую конфигурацию из 4-х шардов с одной репликой, делаю всё так, как описано в документе, однако при INSERT'e получаю: Code 170 (cluster not found)

Здравствуйте. Возможно ли увидеть полный текст ошибки?

michael@clickhouse-20001-001-test:~$ cat input | ./fix.pl | clickhouse-client --query="INSERT INTO inapps_dist FORMAT TabSeparated" Received exception from server: Code: 170. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Requested cluster 'af_4_shards' not found.

michael@clickhouse-20001-001-test:~$ cat input | ./fix.pl | clickhouse-client --query="INSERT INTO inapps_dist FORMAT TabSeparated" Received exception from server: Code: 170. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Requested cluster 'af_4_shards' not found.

А что у вас выводит запрос "select * from system.clusters"?

ничего...

логи посмотрите, может там в конфиге где то беда? ;)

Попробуйте, тогда, ещё раз провеить конфиг. Там где-то ошибка. Если всё настроено правильно, то в таблице system.clusters должна быть соответствующая запись.

@spektom Если вы разместили описание кластера в отдельном файле, то попробуйте переместить его в основной config.xml

Нашёл проблему: пришлось закоментировать строчку <remote_servers incl="clickhouse_remote_servers" />

спасибо

Если я делаю запрос ... from table FINAL для SummingMergeTree - я могу рассчитывать на то что строки будут идти в порядке как в ключе указано? Например чтобы через runningDifference значения из предыдущей строки анализировать?

если критично - могу дома найти свои мучения с монгой :)

привет. напоминаю :)

собственно делалось так

ставилась чистая монга

после этого ДО создания юзеров откатывалась схема

var schema = db.system.version.findOne({"_id" : "authSchema"}) schema.currentVersion = 3 db.system.version.save(schema)

после этого создавался юзер

ага. спасибо я попробую

а вот тикет на базе которого я сформулировал эти команды - https://jira.mongodb.org/browse/SERVER-17459

Всем привет! Правильно я понимаю что если таблица Distributed смотрит на таблицы CollapsingMergeTree (или ReplicatedCollapsingMergeTree ) то ключ шардирования должен задаваться с учетом попадания различных данных по одному первичному ключу на один и тот же шард? Т.е. вообще правильно в этом случае шардировать по первичному ключу, получается?

а вот тикет на базе которого я сформулировал эти команды - https://jira.mongodb.org/browse/SERVER-17459

подумал над этим вариантом. думаю тупиковый путь. видимо лучший вариант сменить сорс словаря на url

наверное, да

Всем привет. Вернулся к задаче по сборке кликхаусе на маке. Все собралось. Но в системе clickhouse-server не появился(папки /etc/clickhouse-server тоже). make install .. - падает(в доке его нет, не уверен что он вообще нужен) .... Install the project... -- Install configuration: "RELWITHDEBINFO" CMake Error at /Users/user/Downloads/ClickHouse/build/contrib/libpoco/cmake_install.cmake:31 (file): file cannot create directory: /usr/lib/cmake/Poco. Maybe need administrative privileges. Call Stack (most recent call first): /Users/user/Downloads/ClickHouse/build/contrib/cmake_install.cmake:33 (include) cmake_install.cmake:32 (include) sh-3.2# whoami root sh-3.2# ls -altr /usr/lib/cmake/Poco ls: /usr/lib/cmake/Poco: No such file or directory sh-3.2# mkdir /usr/lib/cmake/Poco mkdir: /usr/lib/cmake: No such file or directory sh-3.2# mkdir /usr/lib/cmake mkdir: /usr/lib/cmake: Operation not permitted

make install - вредная идея, поставит ненужное

/etc/clickhouse-server создается при установке пакета в дебиане например, для мака всё немного по-другому и созданием правильного макового пакета еще не занимались.

т.е. руками все создать?

можно скопировать конфиг dbms/src/Server/config.xml и бинарник из build/dbms/src/Server/clickhouse а можно сразу запустить build/dbms/src/Server/clickhouse --server --config-file=dbms/src/Server/config.xml

а зачем в систему ставить? если нужен автозапуск - еще и правильные старт-стоп скрипты для этой ОС писать надо

/etc/clickhouse-server создается при установке пакета в дебиане например, для мака всё немного по-другому и созданием правильного макового пакета еще не занимались.

у меня более-менее рабочий (~неделю назад, по крайней мере, был рабочий) https://github.com/hatarist/homebrew-clickhouse/

в идеале службу еще написать к launchd для удобного запуска/остановки, но у меня времени нет пока (

Я думал, что автозапуск сам по себе появится, когда установлю в систему)

Ладно, пока запускаю руками, спасибо!

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

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

и зависит оно во многом от объемов данных, от патерна доступа и т.д.

или это вопрос минимального запуска на поиграться с 10 строками?

тогда причем тут железо...

вот рекомендации по типам CPU (какие там фичи используют и как проветь их наличие) было бы полезно (если этого реально нет)

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

одной машины должно хватить.

20 80 событий в секунду выдержит любая СУБД на 2 гигах оперативки и чата винтах

Можно просто в файлик писать)

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

по одной строке только не вставляйте по возможности.

файлик то можно ) а тогда CH зачем? ) дело в том, что при "записи по одной строке" как раз я на ноутбуке хватал странную ошибку когда сервер clickhouse переставал отвечать с ошибкой Code: 210. DB::NetException: Connection refused: (localhost:9000, 127.0.0.1)

это было в виртуалке на 1гиге

Если вы не понимаете зачем вам кликхаус значит он Вам не нужен

записывать по одной строке - плохая идея :)

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

как раз понимаю зачем, но в данный момент нахожусь в стадии изучения

дизайн CH хорошо работает, когда вставки идут крупными батчами

при записи по одной строке у вас будет перестроение таблиц на каждую вставку, это будет медленно

НО он падать и выдавать ошибку как у вас - явно не должен, просто должен работать относительно медленно (относительно, опять же, кейса, когда он используется "правильно")

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

возможно

вот тут обсуждалось, такая проблема не только у меня встречалась https://groups.google.com/forum/#!searchin/clickhouse/evgeni$20makarov%7Csort:relevance/clickhouse/OYfKtSYKVzQ/HOQF8upDDQAJ

ну и 1 гб в 21м веке... не надо так! :)

для экспериментов с записью с такой маленькой скоростью не ожидал подвоха )

честно говоря, Poco штука странная, я пытался использовать ее в своем проекте.... впечатления мягко говоря не особо

вот рекомендации по типам CPU (какие там фичи используют и как проветь их наличие) было бы полезно (если этого реально нет)

Там есть упоминание про sse4.2

Это минус эконом дедики на хетцзнере и минус виртуалбоксы ?

мне кажется хецнер уже такое не продает кроме как на маркете )

ну и всегда есть ребята класса online.net :)

это уже опционально. вполне собирается и работает на arm64 без вcяких sse

где за те же денбги можно взять топовый E5 v4:)

это уже опционально. вполне собирается и работает на arm64 без вcяких sse

Да? Давно убрали? Надо будет в виртуалке побаловаться

https://github.com/yandex/ClickHouse/commit/8b4b1534e3339847f3688a5853af0006011b8509

А никто не сталкивался с такой ошибкой? workers-MBP:test user$ cat test.csv| clickhouse-client --query="INSERT INTO test FORMAT CSV"; clickhouse-client(1086,0x70000a3b5000) malloc: *** error for object 0x10f1f6000: pointer being realloc'd was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap: 6

в логе 2017.02.07 02:48:37.760464 [ 7 ] <Error> ServerErrorHandler: Code: 210, e.displayText() = DB::NetException: Connection reset by peer: while reading from socket ([::1]:49583), e.what() = DB::NetException, Stack trace: 0. 0 clickhouse 0x000000010f971716 _ZN10StackTraceC1Ev + 22 1. 1 clickhouse 0x000000010fbba066 _ZN2DB9ExceptionC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_i + 38 2. 2 clickhouse 0x000000010f99214a _ZN2DB24ReadBufferFromPocoSocket8nextImplEv + 874 3. 3 clickhouse 0x000000010e05b632 _ZN2DB10TCPHandler7runImplEv + 2434 4. 4 clickhouse 0x000000010e05bf6c _ZN2DB10TCPHandler3runEv + 28 5. 5 clickhouse 0x000000011022667f _ZN4Poco3Net19TCPServerConnection5startEv + 15 6. 6 clickhouse 0x0000000110227e9f _ZN4Poco3Net19TCPServerDispatcher3runEv + 319 7. 7 clickhouse 0x00000001102e1627 _ZN4Poco12PooledThread3runEv + 167 8. 8 clickhouse 0x00000001102dac30 _ZN4Poco10ThreadImpl13runnableEntryEPv + 96 9. 9 libsystem_pthread.dylib 0x00007fff912bbaab _pthread_body + 180 10. 10 libsystem_pthread.dylib 0x00007fff912bb9f7 _pthread_body + 0 11. 11 libsystem_pthread.dylib 0x00007fff912bb1fd thread_start + 13

версия 1.1.54140

Если шлю через curl curl -X POST 'http://localhost:8123/?query=INSERT%20INTO%20test%20FORMAT%20CSV' --data-binary @test.csv тогда валится clickhouse-server целиком: 2017.02.07 03:04:01.267801 [ 6 ] <Debug> executeQuery: (from [::1]:49943) INSERT INTO test) FORMAT CSV clickhouse(2106,0x70000faa4000) malloc: *** error for object 0x1197f3000: pointer being realloc'd was not allocated *** set a breakpoint in malloc_error_break to debug 2017.02.07 03:04:02.637927 [ 7 ] <Error> BaseDaemon: ######################################## 2017.02.07 03:04:02.637955 [ 7 ] <Error> BaseDaemon: (from thread 6) Received signal Abort trap: 6 (6). 2017.02.07 03:04:02.642849 [ 7 ] <Error> BaseDaemon: 1. 1 libsystem_kernel.dylib 0x00007fff911d2dd6 __pthread_kill + 10 2017.02.07 03:04:02.642876 [ 7 ] <Error> BaseDaemon: 2. 2 clickhouse 0x000000010b466c30 _ZN4Poco10ThreadImpl13runnableEntryEPv + 96 2017.02.07 03:04:02.642881 [ 7 ] <Error> BaseDaemon: 3. 3 libsystem_pthread.dylib 0x00007fff912bbaab _pthread_body + 180 2017.02.07 03:04:02.642886 [ 7 ] <Error> BaseDaemon: 4. 4 libsystem_pthread.dylib 0x00007fff912bb9f7 _pthread_body + 0 2017.02.07 03:04:02.642891 [ 7 ] <Error> BaseDaemon: 5. 5 libsystem_pthread.dylib 0x00007fff912bb1fd thread_start + 13 2017.02.07 03:04:05.265694 [ 5 ] <Trace> SystemLog (system.query_log): Flushing query log 2017.02.07 03:04:05.278460 [ 5 ] <Trace> system.query_log (Data): Renaming tmp_20170207_20170207_73_73_0. Abort trap: 6

маленькие файлики жрет(до 100мб)