вброшу голос за организацию документации на основе jekyll

там же сразу и github pages, а с основного сайта можно просто проксировать запросы или установить cname

мы свою публичную базу знаний так и ведем

сильно приходится в руби врубаться при использовании его ?

нет, вообще не приходится

там просто пишешь --- title: мой тайтл страницы --- и дальше содержимое

Написано что он платный и не поддерживает БД,

pelican тоже нетребовательный, это просто консольные утилитки для генерации статик сайтов

пока приходилось только по мелочи css править и с relative url немного бодаться, но если все будет только на gh, особых проблем быть не должно

Написано что он платный и не поддерживает БД,

а зачем там БД и про платность бред https://github.com/jekyll/jekyll

Написано что он платный и не поддерживает БД,

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

Имхо - лучше пулл реквесы прямо в доку CH

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

Мне кажется мешать документацию и faq не самая хорошая идея

Фак можно и отдельной страницей сделать

На официальном сайте

А обновлять как?

Рулон ну вот ты начал фак. хорошее дело. просто не надо укоза и вот этого вот всего. лучше gh просто readme.md и все

А мой форк надо комитить в мастер?

> @milovidov_an это не инкременты ооо, надо запомнить. Возможно тогда такой как есть, вариант отображения метрик и не плох - да можно улучшить, но тогда потребуется хардкодинг или просить тебя что то придумать внутри CH - отдавать тип/формат, мне помог такой вариант отрисовки когда я исследовал проблемные запросы и разбирался что "лагает". Когда графики сильно просаживаются - повод задуматься. Конечно у нас не такие нагрузки и под всех не подстроить. Я думаю это повод обсудить на "Мск meetup-e" в живую как и что отрисовывать, очень хотел отрисовать граф кластера ... но явно не хватает данных для этого, хотел повторить datastax Cassandra мanadrer http://www.datastax.com/wp-content/uploads/2012/03/preview-1024x652.png но понял что будет не информативно данные с одной ноды ))

Да, с удовольствием обсудим.

Я начал создавать Faq ) Надеюсь взлетит ) http://clickhouse.my1.ru/

Хорошо! Это уже лучше, чем ничего. Переконвертировать в другой формат, если что, всегда успеем.

вброшу голос за организацию документации на основе jekyll

Мы сейчас выбираем платформу для документации - обсуждаем с коллегами, которые занимаются переводами; ещё один человек писал в личку. Есть вариант - readthedocs.

http://clickhouse-docs.readthedocs.io/ru/latest/ Пока перенёс не все. Процентов 45%. Формат RST, при желании конвертируется во что угодно.

По-моему очень удобно

А там поддержка нескольких языков возможна? Чтобы для одного и того же раздела документации можно было бы язык переключать?

Да

Снизу слева, там где latest, можно будет сделать выбор языка.

Снизу слева, там где latest, можно будет сделать выбор языка.

Ооо. Там же можно будет и между документацией для различных версий переключаться? если это вдруг понадобится

Да

Ребята, ну ок. А там где секция EXAMPLES с FAQ? Просто у вас много FAQ в тех же гугл-доках. Да и сообщество экзамплов насыпет. Например отсутствует секция про визуализацию метрик.

Как вариант пушить в текущую доку. Либо подождать до понедельника, я думаю успею отправить PR доков в формате rst. Тогда можно будет уже в универсальном формате делать в центральной репе.

А в остальном секцию FAQ или "готовые решения" поддерживаю руками и ногами.

вот про это хотелось бы отдельно сказать/спросить - например хотелось бы как то примерно увидеть потребление ресурсов на примере. Например - есть такая то таблица, вот ее структура, вот такой запрос. При одновременном коннекте 1, 10 и т.д пользователей съедается столько то памяти... Просто я понимаю что все зависит от реализации и аппаратной и софтовой и от каждого конкретного случая, но все таки на данном примере(ах) можно оценить требования.

может это глупо звучит, но...

Хоть и далеко до объективности такому тесту, но думаю да, что-то похожее можно сделать.

Т.к. Clickhouse True многопоточный, он будет брать все доступное. Т.е. загрузка при 1 запросе может быть 100%, и при 10 таких же запросах 100%, просто медленнее )) это я так, сильно сильно утрировал

Тут нельзя забывать ещё и про настройки. В особенности внешние group by/сортировки и тп. Они могут сильно поменять профиль нагрузки.

А мб уже true пример данных для КХ? Чтобы за несколько простых действий можно было поднять адекватного размера базу, чтобы на ней поучиться? На ней можно было бы проверять эффективность различных запросов, делясь с community результатами — за счет того, что тестовый набор данных был бы у всех одинаковый, это упростило бы обсуждение различных кейсов.

Речь о чем-то подобном https://docs.oracle.com/database/121/COMSC/toc.htm

Так есть же тестовый набор данных

Чёт там с самолётами связанный.

В туториале

Так есть же тестовый набор данных

Сорри, пропустил

Кстати интересная идея. В туториале на сколько помню только одна таблица. А вот общую схему придумать было бы интереснее. Ну чтоб с джоинами, словарями и прочими радостями жизни.

да это все ясно. Есть тестовый набор. и прочее прочее. ВОт! ия про это же.

Андрей, вы правы!

Кстати интересная идея. В туториале на сколько помню только одна таблица. А вот общую схему придумать было бы интереснее. Ну чтоб с джоинами, словарями и прочими радостями жизни.

У меня основное желание про "поднять в несколько кликов". Прямо сразу делать универсальную базу для всего не обязательно. Для начала можно что-то простое, но чтоб не сложнее чем yum install clickhouse-samples ставилось. Для чайников для иллюстрации чайниковских запросов.

Ну я отталкиваюсь от того что сам по себе туториал сейчас не сильно сложный(вроде)

Если делать несколько таблиц, то разница будет только в количестве заливаемых файлов

Не возражаю :)

о, новая сборка появилась 1.1.54181

Коллеги, подскажите, какая то странная вещь. Начали биться данные. Debain, CH 1.1.54164. Заметили что побился файл column.mrk. Ругался: DB::Exception: bad size of marks file …./20141201_20141231_3580_9020_7/total.mrk':146912, must be: 146944. пробовал делать optimize table * partition * final, не помогает. То же сообщение. Обновил версию до 1.1.54180. После optimize изменился размер mrk файла, но целевого так и не достиг) DB::Exception: bad size of marks file …/20141201_20141231_3580_9020_8/total.mrk':146896, must be: 146944. Можно как то обойти эту проблему? И как правильно лечить.

Сервер ребутали неожиданными для него способами?

Нет, кроме обновлений ничего не было.

А с диском у сервера все ок?

Да, схд hi-end класса.

из нового select * from system.columns limit 4; SELECT * FROM system.columns LIMIT 4 ┌─database─┬─table─────────┬─name─────────┬─type───┬─default_type─┬─default_expression─┬─data_compressed_bytes─┬─data_uncompressed_bytes─┬─marks_bytes─┐ появились data_compressed_bytes, data_uncompressed_bytes, поэтому теперь можно прикинуть коэффициент сжатия для таблиц

извините за лень, а где запись 3го митапа?

https://www.youtube.com/watch?v=CVrwp4Zoex4&feature=em-lss

сам спросил - сам ответил

+ за расширение метрик

добавил еще инфы http://clickhouse.my1.ru/

с Маши письменную версию про 10 вещей про КХ

=) дак там же вроде слайды есть? рядом с видео?

ссылка?

https://events.yandex.ru/events/meetings/28-february-2017/

а блин там без слайдов

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

+ за 9. argMin, argMax

mrk

ошибся. Сори

Коллеги, подскажите, какая то странная вещь. Начали биться данные. Debain, CH 1.1.54164. Заметили что побился файл column.mrk. Ругался: DB::Exception: bad size of marks file …./20141201_20141231_3580_9020_7/total.mrk':146912, must be: 146944. пробовал делать optimize table * partition * final, не помогает. То же сообщение. Обновил версию до 1.1.54180. После optimize изменился размер mrk файла, но целевого так и не достиг) DB::Exception: bad size of marks file …/20141201_20141231_3580_9020_8/total.mrk':146896, must be: 146944. Можно как то обойти эту проблему? И как правильно лечить.

Мы не сталкивались с такой проблемой. У вас просто MergeTree или ReplicatedMergeTree? Если Replicated, то сервер при старте восстановит part с реплики. В любом случае посмотрите в логе всё что связано с именем этого куска 20141201_20141231_3580_9020_7. Также посмотрите на всякий случай на все времена запуска и остановки сервера и на времена модификации файлов внутри куска. Осуществлялись ли ALTER-ы в это время? Есть ли ещё что-то необычное. Если сервер корректно говорит о том, что .mrk файл неправильный, и неправильный только он, то данные в порядке, и конкретный случай проблемы можно полностью исправить.

Мы не сталкивались с такой проблемой. У вас просто MergeTree или ReplicatedMergeTree? Если Replicated, то сервер при старте восстановит part с реплики. В любом случае посмотрите в логе всё что связано с именем этого куска 20141201_20141231_3580_9020_7. Также посмотрите на всякий случай на все времена запуска и остановки сервера и на времена модификации файлов внутри куска. Осуществлялись ли ALTER-ы в это время? Есть ли ещё что-то необычное. Если сервер корректно говорит о том, что .mrk файл неправильный, и неправильный только он, то данные в порядке, и конкретный случай проблемы можно полностью исправить.

Таблицы MergeTree, без реплик. Данные вставлялись через distributed таблицу( у нас два сервера). На одном сервере побились месяца 2014-10, 2014-11, 2014-12 а на другом эти же + 2017-02. Везде ругается на mrk файлы. Если выбирать колонки из pk - запрос проходит нормально. Два раза расширялся(добавление новых элементов в конец) enum8 для вложенной таблицы alter table * MODIFY COLUMN Payments.pay_system Array(Enum8('' = 0, 'Visa' = 1, 'VISA electron' = 2, 'MIR Credit' = 3, 'MIR Debit' = 4, 'EuroCard' = 5, 'Maestro' = 6, 'Jcb' = 7, 'AmericanExpress' = 8))

Таблицы MergeTree, без реплик. Данные вставлялись через distributed таблицу( у нас два сервера). На одном сервере побились месяца 2014-10, 2014-11, 2014-12 а на другом эти же + 2017-02. Везде ругается на mrk файлы. Если выбирать колонки из pk - запрос проходит нормально. Два раза расширялся(добавление новых элементов в конец) enum8 для вложенной таблицы alter table * MODIFY COLUMN Payments.pay_system Array(Enum8('' = 0, 'Visa' = 1, 'VISA electron' = 2, 'MIR Credit' = 3, 'MIR Debit' = 4, 'EuroCard' = 5, 'Maestro' = 6, 'Jcb' = 7, 'AmericanExpress' = 8))

В логах ничего не нашл. Сервер 1. 20141201_20141231_3580_9020_8/ mtime для всех колонок - 3 марта, для контрольных сумм - 8 марта ls -ltr … -rw-rw-rw- 1 clickhouse clickhouse 136000 Mar 3 11:37 date_t.mrk -rw-rw-rw- 1 clickhouse clickhouse 622721 Mar 3 11:37 date_t.bin -rw-rw-rw- 1 clickhouse clickhouse 1274 Mar 8 01:40 columns.txt -rw-rw-rw- 1 clickhouse clickhouse 2842 Mar 8 01:40 checksums.txt Сервер 2, после optimize table * partition 201412 final: -rw-rw-rw- 1 clickhouse clickhouse 146944 Mar 11 12:28 date_t.mrk -rw-rw-rw- 1 clickhouse clickhouse 672812 Mar 11 12:28 date_t.bin -rw-rw-rw- 1 clickhouse clickhouse 1274 Mar 11 12:28 columns.txt -rw-rw-rw- 1 clickhouse clickhouse 2789 Mar 11 12:28 checksums.txt ``` В обоих случаях ругается на несовпадение размера mrk файлов.

В логах вот так: 2017.03.02 16:34:10.746123 [ 442 ] <Debug> ххх.ххх (Data): Removing part 20141201_20141231_6090_6752_4 2017.03.03 11:43:32.087476 [ 5 ] <Debug> executeQuery: (from [::1]:52908) optimize table ххх.ххх partition 201412 final 2017.03.03 11:43:32.087648 [ 5 ] <Debug> checks.ch2016 (Merger): Selected 1 parts from 20141201_20141231_3580_9020_5 to 20141201_20141231_3580_9020_5 2017.03.03 11:43:32.087680 [ 5 ] <Debug> checks.ch2016 (Merger): Merging 1 parts: from 20141201_20141231_3580_9020_5 to 20141201_20141231_3580_9020_5 into 20141201_20141231_3580_9020_6 2017.03.03 11:43:32.093235 [ 5 ] <Trace> MergeTreeBlockInputStream: Reading 1 ranges from part 20141201_20141231_3580_9020_5, approx. 75235328 rows starting from 0 2017.03.03 11:46:04.485705 [ 5 ] <Trace> ххх.ххх (Data): Renaming tmp_20141201_20141231_3580_9020_6. 2017.03.03 11:46:04.485889 [ 5 ] <Trace> ххх.ххх (Merger): Merged 1 parts: from 20141201_20141231_3580_9020_5 to 20141201_20141231_3580_9020_5 2017.03.03 11:54:07.818596 [ 356 ] <Debug> ххх.ххх (Data): Removing part 20141201_20141231_3580_9020_5 2017.03.11 11:59:20.382123 [ 4 ] <Error> executeQuery: Code: 246, e.displayText() = DB::Exception: bad size of marks file…

Есть гипотезы, почему изменение "для контрольных сумм - 8 марта"?

Был alter 2017.03.08 01:41:01.116035 [ 436 ] <Debug> executeQuery: (from [::1]:59540) alter table хххх MODIFY COLUMN Payments.pay_system Array(Enum8('' = 0, 'Visa' = 1, 'VISA electron' = 2, 'MIR Credit' = 3, 'MIR Debit' = 4, 'EuroCard' = 5, 'Maestro' = 6, 'Jcb' = 7, 'AmericanExpress' = 8))

Спасибо. Это похоже на одну из проблем, которую мы исправляли давно - там тоже было расширение Enum внутри Nested. Попробую исследовать и дам способ устранить последствия.

Спасибо! Буду ждать. Из особенностей, в партициях 2014 года в колонках Payments.pay_system совсем не было данных. Ну и не все партиции пострадали.

кто-нибудь компилировал КХ под fedora?

да (кто-то в issues в комментах писал), а в чем проблема?

Добрый день!

Согласен, добрый.

Наверняка этот вопрос уже поднимался, но в гугле и в этом чате не нашёл ответа на свой вопрос. Как связать Kafka+ClickHouse?

У меня в беклоге стоит этот вопрос, тоже интересует на будущее. Но если честно, не совсем понимаю чего вы ожидаете? Чего то вроде внутреннего механизма для выгребания данных из Kafka?

Оч разный формат

Обертка на кафку пишется оч быстро.

Мы рассматриваем отказ от Vertica в пользу Clickhouse

>Обертка на кафку пишется оч быстро. например)

Ну забрать батч с кафки и уложить в кликхаус

Я на С++ такое написал за два дня

Как формат представления в кафке юзал capnp

Буфер таблица тоже решение, если событий не сильно много

То есть вы написали демон (службу) которая постоянно читает события из кафки и направляет их в ClickHouse?

Да;)