подключали

Несложно пример?

Как я делал с постгресным драйвером: sudo apt-get install -y unixodbc sudo apt-get install -y odbcinst sudo apt-get install -y odbc-postgresql В /etc/odbc.ini: [DEFAULT] Driver = myconnection [myconnection] Description = PostgreSQL connection to norma Driver = PostgreSQL Unicode Database = norma Servername = 10.... (твой хост) UserName = uname Password = pwd Port = 5432 Protocol = 9.3 ReadOnly = No RowVersioning = No ShowSystemTables = No ConnSettings = <dictionary> <name>table_name</name> <source> <odbc> <table>postgresql_table</table> <connection_string>DSN=myconnection</connection_string> <!— может потребоваться UID=norma;PWD=norma;, но по идее не должно —-> </odbc> </source> <lifetime> <min>300</min> <max>360</max> </lifetime> <layout> <flat/> </layout> <structure> <id> <name>id</name> </id> <attribute> <name>some_column</name> <type>Int32</type> <null_value>-1</null_value> </attribute> ... </structure> </dictionary>

в поиске по чату еще должно быть

Круто! Вот такую инфу в аддон хотя бы.

?

Любителям Freebdsm привет: https://www.freshports.org/databases/clickhouse/

Однако, с сарказмом)

с первого раза не сразу понял))

С разрешения отцов-основателей чата небольшое объявление. Я ищу одного-двух человек на позиции Database Performance Engineer и/или Database Solutions Architect, с основным фокусом на ClickHouse. Основные технические требования -- глубокое понимание архитектуры баз данных, опыт работы в этой области с более чем одной DBMS, не обязательно ClickHouse, но желательно аналитической, хороший Linux, желательно опыт деплоймента в облаках, умение программировать не только на SQL и скриптовых языках (приветствуется Java/Scala/C++). Основное нетехническое требование -- желание работать с ClickHouse, делать на нем эффективные решения и показывать своим примером, что ClickHouse это круто. Работа в иностранной компании, можно удаленно, возможен офис в некоторых городах России и не-России. Остальные вопросы в личный чат.

Всем привет! Скажите пожалуйста. Вы каким ETL пользуетесь, чтобы наполнять CH ? Можно ли в качестве ETL использовать внешние словари?

День добрый. Насколько я понял, нагуглив, сейчас нет возможности использовать в materialized views вложенных select-ов. Подскажите, пожалуйста, правильный кейс, если у меня есть большая таблица, куда порциями по паре миллионов вливаются данные с одинаковым значением одного из полей типа datetime и я хочу создать вьюху, где я сразу получал бы именно последнюю влитую в мастер-таблицу порцию плюс дополнительные фильтр по результатам из вьюхи. Или этот кейс заведомо невыигрышный?

привет всем! а что можете посоветовать для мониторинга CH с помощью графита?

привет всем! а что можете посоветовать для мониторинга CH с помощью графита?

Посмотри в сторону python-diamond

привет всем! а что можете посоветовать для мониторинга CH с помощью графита?

ClickHouse сам умеет отправлять разные метрики в графит. Или вам что-то дополнительно нужно?

да просто хотим видеть базовые характеристики - сколько было записей, сколько чтений, объёмы, рэйты и т.д.

вот здесь надо сконфигурировать: https://github.com/yandex/ClickHouse/blob/master/dbms/src/Server/config.xml#L110

о! спасибо!

> @milovidov_an Думаю, это плохая идея. Лучше используйте какой-нибудь хэш. Плохая, потому что при каждом мерже, rand() будет вычияться заново и давать новый результат... А если я сделаю поле для сэмплирования sample_id MATERIALIZED rand(), то какие будут минусы? Не совсем понимаю, чем rand() будет хуже, чем хэш от каких-то полей.

> @milovidov_an Думаю, это плохая идея. Лучше используйте какой-нибудь хэш. Плохая, потому что при каждом мерже, rand() будет вычияться заново и давать новый результат... А если я сделаю поле для сэмплирования sample_id MATERIALIZED rand(), то какие будут минусы? Не совсем понимаю, чем rand() будет хуже, чем хэш от каких-то полей.

Можно. Разница в том, что вы не сможете гарантировать, что строки с какими-то значениями полей (например, с одним идентификатором посетителя) всегда будут целиком попадать или целиком не попадать в сэмпл. Кстати, DEFAULT на практике более удобен чем MATERIALIZED.

Чем, если я никогда не заполняю поле руками?

А если мне не надо гарантировать, что строки одного пользователя попадают в один сэмпл (я этого и не могу, т.к. у меня в хэше несколько независимых идентификаторов пользователя), то rand() наверное будет быстрее работать при вставке, чем подсчет хэша.

Но есть проблема: я добавил еще один идентификатор, и хочу добавить его как еще одно поле в свой cityHash64, однако получаю ошибку: DB::Exception: trying to ALTER key column sample_id.

А если мне не надо гарантировать, что строки одного пользователя попадают в один сэмпл (я этого и не могу, т.к. у меня в хэше несколько независимых идентификаторов пользователя), то rand() наверное будет быстрее работать при вставке, чем подсчет хэша.

Одинаково, так как время при вставке тратится сильно больше на работу по вставке чем на вычисления этих функций.

Чем, если я никогда не заполняю поле руками?

Неудобства при вставке в Distributed таблицы.

Но есть проблема: я добавил еще один идентификатор, и хочу добавить его как еще одно поле в свой cityHash64, однако получаю ошибку: DB::Exception: trying to ALTER key column sample_id.

Да, значит лучше rand.

Поздно )

Данные налиты... Разве что все переливать.

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

Ребята, а как часто выкладываются сборки для Ubuntu 14.04 (Trusty)?

Обычно раз в 1-2 недели (для trusty, precise и xenial синхронно)

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

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

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

Понятно. Тогда для качественного сэмплирования, придётся переливать данные.

Добрый вечер. Подскажите пожалуйста, важно ли, в каком порядке колонки перечислены в primary key merge tree таблицы с точки зрения производительности фильтрации по этим колонкам?

И есть ли какое-нибудь описание того, как устроен primary key индекс на merge tree?

И есть ли какое-нибудь описание того, как устроен primary key индекс на merge tree?

https://groups.google.com/forum/#!topic/clickhouse/eUrsP30VtSU

https://groups.google.com/d/msg/clickhouse/eUrsP30VtSU/p4-pxgdXAgAJ https://medium.com/@f1yegor/clickhouse-primary-keys-2cf2a45d7324#.qldcr8fkg

@f1yegor а чё, в медиуме нельзя тройные backtick'и использовать для code block'ов? это бы сильно спасло внешний вид визуального представления там ) и поправь пожалуйста asci-art на ASCII art

@milovidov_an Спасибо

Товарищи,игрался с КХ в докере и удачно его роняю) в конце он пишет только что clickhouse | 2017.03.02 20:44:47.449889 [ 7 ] <Debug> MemoryTracker: Peak memory usage (for query): 4.80 GiB. clickhouse | 2017.03.02 20:44:47.450032 [ 7 ] <Debug> MemoryTracker: Peak memory usage (for user): 4.80 GiB. clickhouse | 2017.03.02 20:44:47.450055 [ 7 ] <Debug> MemoryTracker: Peak memory usage (total): 4.80 GiB. clickhouse | 2017.03.02 20:44:47.465186 [ 7 ] <Information> HTTPHandler: Done processing query clickhouse | 2017.03.02 20:44:48.137024 [ 8 ] <Trace> HTTPHandler-factory: HTTP Request for HTTPHandler-factory. Method: POST, Address: [::ffff:172.18.0.1]:50476, User-Agent: none clickhouse | 2017.03.02 20:44:48.137118 [ 8 ] <Trace> HTTPHandler: Request URI: /? clickhouse | 2017.03.02 20:44:48.287400 [ 8 ] <Debug> executeQuery: (from [::ffff:172.18.0.1]:50476) INSERT INTO dbtest.test FORMAT CSV clickhouse exited with code 137запускал это все дело в докере под виндой на ноуте с Celeron и 8гб оперативки) возможно ему ресурсов не хватило,но хотя бы сказал бы для приличия..или может еще что-то происходит? Как бы это отдебажить попроще?

вставляются туда правда адовые таблицы с 1000+ колонками,но оно же вставляет до какой-то поры..

Похоже на out of memory + sigkill

попробую свои тесты на "взрослом" железе)

Почитал я документацию, что в https://github.com/yandex/ClickHouse/tree/master/doc/developers (Про внутреннее устройство по совету Алексея.) Одного не понял — почему движки называются MergeTree? То есть, откуда Merge объяснено, но где там деревья?

https://en.wikipedia.org/wiki/Log-structured_merge-tree может, поэтому

Всем привет. А перешардирование сейчас работает?

а то помнится был момент когда сломано было

А, нет там же, в architecture MergeTree is not an LSM tree because it doesn't contain "memtable" and "log": inserted data is written directly to the filesystem. This makes it suitable only to INSERT data in batches, not by individual row and not very frequently – about once per second is ok, but a thousand times a second is not. We did it this way for simplicity's sake, and because we are already inserting data in batches in our applications.

@ztlpn а если надо указать в конфиге 2 графита - надо делать 2 секции <graphite> ? или он поддерживает передачу метрик только в один графит?

я просто уже попробовал - и во второй ничего не передалось :(

Всем привет. А перешардирование сейчас работает?

ответ по решардингу https://youtu.be/CVrwp4Zoex4?t=2h36m50s

@ztlpn а если надо указать в конфиге 2 графита - надо делать 2 секции <graphite> ? или он поддерживает передачу метрик только в один графит?

Только в один

А, нет там же, в architecture MergeTree is not an LSM tree because it doesn't contain "memtable" and "log": inserted data is written directly to the filesystem. This makes it suitable only to INSERT data in batches, not by individual row and not very frequently – about once per second is ok, but a thousand times a second is not. We did it this way for simplicity's sake, and because we are already inserting data in batches in our applications.

Вот именно, тогда бы оно называлось MergeNotATree :) В документации не сказано, в каком порядке и вообще когда объединяются чанки. Если (не лезть в код и) предполагать, как бы я это сделал, то получилось бы что-то аналогичное то ли биномиальной куче, то ли дереву Хаффмана. Логичное же предположение: если хочется объединять, то объединять самые мелкие, это быстрее и почти даёт логарифм на суммарную длину объединений. И тут возникают какие-то структуры, похожие на деревья, пусть и неявно. Но это как-то… За уши притянуто.

Ещё, и это уже более обидно, в документации на github'е ни слова про то, как работают MATERIALIZED VIEW. Это же самое интересное (по крайней мере, после того, как я прочитал остальное).

А, нет там же, в architecture MergeTree is not an LSM tree because it doesn't contain "memtable" and "log": inserted data is written directly to the filesystem. This makes it suitable only to INSERT data in batches, not by individual row and not very frequently – about once per second is ok, but a thousand times a second is not. We did it this way for simplicity's sake, and because we are already inserting data in batches in our applications.

MergeTree это недо-LSM-Tree, именно потому в MergeTree нет memtable, а вставленные данные сразу превращаются в кусок. В остальном принцип тот же.

Только в один

спасибо

Чем-то напоминает дерево Фенвика, которое дерево только в том смысле, что если нарисовать зоны ответственности элементов, будет похоже на ёлку. Ну да ладно. Почему бы и не Tree, я же не против.

ответ по решардингу https://youtu.be/CVrwp4Zoex4?t=2h36m50s

спасибо )

Хм.. а как в КХ быть с шардами которые под завязочку забиты? Добавили новые шарды, пишем на новые, а старые только в выборках?

один из вариантов установить вес шарда.

как заполненность выровняется то вес шардов уровнять

Привет всем. А кто может подсказать текущий статус с ODBC драйвером для CH? Нам нужна интеграция с Tableau и это, похоже, единственный нормальный вариант интеграции.

(ответил в английском чате)

а дайте ссылку на него?

@clickhouse_en

благодарю

Спасибо!

Добрый день. А есть какие-нибудь рекомендации по ускорению запросов с сэмплированием? Исходя из структуры индекса по MergeTree я предполагал, что ключ сэплирования даст наибольший прирост, если он будет идти первым выражением в primary key, но что-то я не замечаю вообще прироста от сэмплирования. Ожидал, что sample 0.1 в разы ускорит запрос, а он выполняется столько же, сколько и без сэмплирования.

Добрый день. А какой у вас create table, и какой запрос?

CREATE TABLE lbc_an_1shards_4replicas_sample.fact_local ( ts DateTime, campaignId Int32, insertionOrderId Int32, insertionOrderGroupId Int32, advertiserId Int32, osId Int8, browserId Int8, domain String, alpha2 String, stateCode String, cityId Int32, sellerId Int32, placementId Int32, publisherId Int32, year UInt16 DEFAULT toYear(ts), month UInt8 DEFAULT toMonth(ts), week UInt8 DEFAULT CAST(((toRelativeWeekNum(ts) - toRelativeWeekNum(toStartOfYear(ts))) + 1) AS UInt8), day UInt8 DEFAULT toDayOfMonth(ts), weekDay UInt8 DEFAULT toDayOfWeek(ts), hour UInt8 DEFAULT toHour(ts), sampleKey UInt16 DEFAULT CAST(((toMinute(ts) * 60) + toSecond(ts)) AS UInt16), creativeFreq Int32, advertiserFreq Int32, creativeRec Int32, advertiserRec Int32, impressions UInt8, clicks UInt8, measurableImpressions UInt8, viewableImpressions UInt8, actionsPC UInt8, actionsPV UInt8, revenue Float64, revenueAdvCurr Float64, cost Float64, date Date DEFAULT toDate(ts)) ENGINE = ReplicatedMergeTree(\'/clickhouse/tables/lbc_an_1shards_4replicas_sample/0/fact_local\', \'3\', date, sampleKey, (sampleKey, date, advertiserId, insertionOrderGroupId, insertionOrderId, campaignId, ts, osId, browserId, domain, alpha2, stateCode, cityId, sellerId, placementId, publisherId, year, month, week, day, weekDay, hour, creativeFreq, advertiserFreq, creativeRec, advertiserRec), 8192) CREATE TABLE lbc_an_1shards_4replicas_sample.fact ( ts DateTime, campaignId Int32, insertionOrderId Int32, insertionOrderGroupId Int32, advertiserId Int32, osId Int8, browserId Int8, domain String, alpha2 String, stateCode String, cityId Int32, sellerId Int32, placementId Int32, publisherId Int32, year UInt16, month UInt8, week UInt8, day UInt8, weekDay UInt8, hour UInt8, sampleKey UInt16, creativeFreq Int32, advertiserFreq Int32, creativeRec Int32, advertiserRec Int32, impressions UInt8, clicks UInt8, measurableImpressions UInt8, viewableImpressions UInt8, actionsPC UInt8, actionsPV UInt8, revenue Float64, revenueAdvCurr Float64, cost Float64, date Date) ENGINE = Distributed(perftest_1shards_4replicas, \'lbc_an_1shards_4replicas_sample\', \'fact_local\', rand()) SELECT advertiserId, stateCode, sum(impressions) AS impressions FROM fact SAMPLE 0.1 GROUP BY advertiserId, stateCode

Судя по тому, что времена выполнения без sample и с sample 0.1 не отличаются, я явно что-то делаю не так, но не могу понять, что именно

@orantius есть какие-нибудь идеи по моему вопросу?

Коллеги, когда говорят что кликхаус это не для финансов - подразумевается только отсутствие транзакций или что-то еще? Потому что если вести биллинг двойной записью (одна большая таблица где все фин проводки имеют два счета дебет и кредит) - то sql транзакции не нужны

@orantius есть какие-нибудь идеи по моему вопросу?

а impressions в ответе в ~10 раз отличаются?

а, у вас sampleKey это вообще функция времени.

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

для этого в sampleKey обычно пишут какой-то хеш от некоторых колонок, по которым желательно иметь все строки в одном семпле. если бы у вас была не колонка clicks а данные по всем кликам, я бы сказал что в качестве такой колонки подошел бы идентификатор кликнувшего человека. или clickId если вам не нужны несмещенные данные по отдельному человеку.

и я бы в ключе оставил только (advertiserId, date, sampleKey) , если вам нужна статистика только по advertiserID или глобальная,то сортировать по всем полям смысла нет.

Коллеги, когда говорят что кликхаус это не для финансов - подразумевается только отсутствие транзакций или что-то еще? Потому что если вести биллинг двойной записью (одна большая таблица где все фин проводки имеют два счета дебет и кредит) - то sql транзакции не нужны

Трудно обеспечить exactly once семантику - записи по одной вставлять не получится, значит придётся их где-то накапливать. А значит, есть риск потерять или наоборот два раза записать (защита от дублированной записи есть, но она работает только для последних 100 блоков). Нет констрейнтов (в том числе UNIQUE, первичный ключ уникальности не обеспечивает). Может, что-то ещё забыл :)

Вот ещё - репликация асинхронная мульти-мастер, то есть на реплике может не быть свежих данных.

>защита от дублированной записи есть, но она работает только для последних 100 блоков то есть если вставлять батчами по 99 записей - то дублей не будет? или я неверно понимаю механику?

я это понял как, если вставлять дубли с интервалом больше чем 100 запросов друг от друга, то они не дедуплицируются.

А то что regexp lookahead не работает, это бага или фича? select extract('123a456b', '([\\d]+)(?!a)'); cannot compile re2: ([\d]+)(?!a), error: invalid perl operator: (?!.

100 запросов, но не 100 строк в общем?

а impressions в ответе в ~10 раз отличаются?

Да, похоже ключ неравномерный.