Английский давно принят в качестве международного языка. Его и следует использовать для коммуникаций в масштабе планеты. P.S.: Вряд ли лица, требующие повсеместно использовать только русский, опираются в своей позиции на патриотизм и т.п., скорее на незнание английского. ?

кем принят? В ООН международных языков побольше

кем принят? В ООН международных языков побольше

Людьми принят. Большое количество носителей в качестве как родного, так и второго языка в куче стран. Его активно преподают в школах в качестве второго. В том числе и в нашей с вами (сюрприз). Так же является официальным языком в международных корпоративных коммуникациях. Программный код пишется на (сюрприз) английском языке. Ну и т.п. Продолжать смысла не вижу.

я тоже хочу понегодовать. на моём родном белорусском доки нет! :)

Комплекс яндекса на тему "мы старше гугль на неделю" плюс "мы можем, а другие нет". Все ведут доку на двух и более языках и тут приходит Яндекс с докой, актуальной только на одном.

Комплекс яндекса на тему "мы старше гугль на неделю" плюс "мы можем, а другие нет". Все ведут доку на двух и более языках и тут приходит Яндекс с докой, актуальной только на одном.

а вот с этого момента поподробнее, пожалуйста. не укажете на расхождения в неактуальности какой-либо из документаций? )

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

нет нужды - нет проблемы. :)

нет нужды - нет проблемы. :)

с языка снял

у меня как-то был коллега-перлоед, воинственно не знающий английского на все ссылки на доки посылал к абаме и яростно плевался

как такие программистами становятся?..

*шутка про перл*

Элементарно становятся. Как все.

как такие программистами становятся?..

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

Я вот английский изучал по докам и фильмам. Мне его не преподавали. Читать и говорить могу. Но это мало что значит. Ибо напрягаться всё еще приходится.

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

Толик Лично мной ) если тебе так интересно хотя мне и не нравится. Просто мне нужно сегригировать тех кто знает русский и всех остальных ) а с остальными как то надо общаться and this stupid simpky barbarian language is ideal choice for conversation problem solving

Ребят, а кто активно юзает докер? сравнивали различия в производительности кликхауса в докере и без него ? Есть воообще какая-то разница ?

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

зависит от того, какой хост если линукс, то у контейнеров очень маленький оверхед, насколько я знаю если винда-макось, то там один хрен все в виртуалке крутится (а в случае с новым докером и макосью с hxyve производительность, емнип, даже хуже, чем в virtualbox'е)

зависит от того, какой хост если линукс, то у контейнеров очень маленький оверхед, насколько я знаю если винда-макось, то там один хрен все в виртуалке крутится (а в случае с новым докером и макосью с hxyve производительность, емнип, даже хуже, чем в virtualbox'е)

Понял, спасибо :)

В линуксе это такие же процессы, как и любые другие, просто закрытые от внешнего мира в своих неймспейсах +- capabilities. Я не уверен, что там вообще можно говорить об оверхеде, а если и есть, то по сравнению с приложением весьма незаметный. Там совсем другие штуки вылезают, engineering.linkedin, например, недавно рассказывал, как системные треды сборщика мусора jvm (в кликхаусе конкретно такой пример должен быть неприменим, насколько понимаю) выжирали отведенную процессорную квоту и оставляли само приложение ни с чем.

а правильно я понимаю что в этом выражении я должен явно перечислять столбцы из правой таблицы, чтобы отобразить их во внешнем select? по-умолчанию они не будут доступны

SELECT <right-table-columns>, * FROM ( SELECT * FROM table1 WHERE $mainCond ) ALL LEFT JOIN ( SELECT <some-columns> FROM table2 WHERE $mainCond ) USING (pk_id)

да (

это жопа, конечно

хотя если есть способ - я тоже буду рад услышать

ну как сказать, я пока писал запросы максимум с 3 таблицами в join, с 4ым придется еще немного поднапрячься

у меня как-то было три уровня вложенности с 5 таблицами (привет UNION ALL еще)

как я дьявола не вызвал - не знаю

but i'm not sure what clickhouse applies first with a join will it first filter left table and then filter right table and then join?

Performs joins with data from the subquery. At the beginning of query execution, the subquery specified after JOIN is run, and its result is saved in memory. Then it is read from the "left" table specified in the FROM clause, and while it is being read, for each of the read rows from the "left" table, rows are selected from the subquery results table (the "right" table) that meet the condition for matching the values of the columns specified in USING.

оно?

В линуксе это такие же процессы, как и любые другие, просто закрытые от внешнего мира в своих неймспейсах +- capabilities. Я не уверен, что там вообще можно говорить об оверхеде, а если и есть, то по сравнению с приложением весьма незаметный. Там совсем другие штуки вылезают, engineering.linkedin, например, недавно рассказывал, как системные треды сборщика мусора jvm (в кликхаусе конкретно такой пример должен быть неприменим, насколько понимаю) выжирали отведенную процессорную квоту и оставляли само приложение ни с чем.

Нет ничего бесплатного. Цгруппы и неймспейсы имеют оверхед в пару процентов обычно

там же все и так выполняется в корневом нейспейсе

там же все и так выполняется в корневом нейспейсе

Я к тому что докер имеет оверхед

Виртуальная сеть тоже

Бридж имеет оверхед

Нат

Неймспейсы, цгруппы. Все его имеет

Performs joins with data from the subquery. At the beginning of query execution, the subquery specified after JOIN is run, and its result is saved in memory. Then it is read from the "left" table specified in the FROM clause, and while it is being read, for each of the read rows from the "left" table, rows are selected from the subquery results table (the "right" table) that meet the condition for matching the values of the columns specified in USING.

ага, спасибо

Я не спец по cgroups, но, насколько понимаю, они либо работают, либо нет для всей машины разом. Поэтому сетевые расходы, конечно, будут, но - если я правильно понимаю - остальное не влияет вообще никак, потому что процесс #1 запускается ровно в тех же условиях, что и внутриконтейнерные

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

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

ага, у меня тоже 3 таблицы для джойнов - вчера пришлось извратиться + юнион олы )

ну и групп эррей в некоторых задачах выручал, а так без multiple join жить тяжко :)

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

ReplacingMergeTree?

он недокументирован, правда

окей, возможно, а можно где-нибудь про это почитать, кроме исходников?)

ща поищу

все, сам нашел: https://github.com/yandex/ClickHouse/blob/master/dbms/tests/queries/0_stateless/00325_replacing_merge_tree.sql надо optimize table делать руками видимо, что грустно, но хоть что-то :) спасибо за наводку!

сорри, отвлекли :(

optimize table вроде необязательно руками, если терпит он сам периодически делается

ещё вопрос: "Для реплицируемых таблиц запрос OPTIMIZE применяется только к нереплицируемым данным (эти данные присутствуют только после преобразования нереплицируемой таблицы в реплицируемую). Если такие отсутствуют, то запрос ничего не делает." - то есть если я сделаю репликацию таблицы с ReplacingMergeTree, то optimize будет бесполезен и строки не будут схлопываться?

ещё вопрос: "Для реплицируемых таблиц запрос OPTIMIZE применяется только к нереплицируемым данным (эти данные присутствуют только после преобразования нереплицируемой таблицы в реплицируемую). Если такие отсутствуют, то запрос ничего не делает." - то есть если я сделаю репликацию таблицы с ReplacingMergeTree, то optimize будет бесполезен и строки не будут схлопываться?

Это уже изменено. Сейчас OPTIMIZE применяется к реплицированным данным тоже.

спасибо большое!

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

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

Давай. Вообще снести.

спасибо!

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

Будет работать.

Плагин для Grafana для работы с КХ как источником https://github.com/Vertamedia/clickhouse-grafana (увидел ссылку в сообщении google groups) #grafana

Спасибо, очень интересно! Даже использует функцию runningDifference :) Надо будет у себя попробовать...

Привет. Пробую пользоваться кликхаус - пробую перенести туда анализ логов вместо анализа файлов. Как первую итерацию хочу просто вынуть все строки за интервал дат и скормить их существующему алгоритму анализа. Из https://clickhouse.yandex/reference_ru.html#SELECT понял что запросы вида select * from log where EventDate=today()-1 должны выполняться потоково, не занимая оперативки. Тем не менее после выкачивания 90 (девяносто) МБ логов я получаю в очередной строке ошибку: Code: 241, e.displayText() = DB::Exception: Memory limit (for query) exceeded: would use 962.54 MiB (attempt to allocate chunk of 16777216 bytes), maximum: 960.00 MiB: (while reading column UserAgent): (while reading from part /opt/clickhouse//data/prod/traffic/20170105_20170106_381032_393636_8/ from mark 1125 to 1133), e.what() = DB::Exception Запрос делаю по http, через GET-запрос. Что я делаю не так?

Запрос выполняется потоково, с использованием O(1) оперативки. Но это количество оперативки может быть достаточно большим - оно зависит от размера одного блока - единицы обработки данных, и от количества потоков. По-умолчанию, этот размер достаточно большой - 65536 строк. Это рассчитано на ситуацию, когда все значения мелкие. Но в вашем случае, строчки лога могут быть крупными, и тогда блоки обработки данных будут слишком большими. Размер блока можно изменить настройкой max_block_size. Пример (в интерактивном режиме): SET max_block_size = 8192. Или можно указать это в параметре URL. max_block_size не может быть меньше, чем index_granularity, заданная в таблице. Также можно уменьшить количество потоков: max_threads.

да, через go-клиента я получал как раз 65536 строк. Потом уже попробовал простой запрос. Сейчас попробую поменять размеры блока. Что интересно - если поменять EventDate=today()-1 на where EventDate=toDate('2017-01-05'), то проблема не возникает - Сейчас выкачал уже 390 МБ логов и продолжает качать.

> EventDate=today()-1 на where EventDate=toDate('2017-01-05') Разница с этим не связана, такие выражения идентичны.

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

пошел смотреть доки проблоки и потоки

Нам надо будет сделать размер блока адаптивным, чтобы пользователь об этом не беспокоился.

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

Значит надо поменять для профиля пользователя - см. users.xml.

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

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

Сейчас счетчики рассчитаны на получение строк в хронологическом порядке, т.е. мне надо что-то вроде ORDER BY Timestamp или на худой конец EventDate (это обязательное поле с датой. Как я понял по этому полю происходит разделение на кусочки), а в пределах суток я уже попробую отсортировать на стороне клиента.

а EventDate индексом считается?

ограничений нету - нужно все строки анализировать.

Желательно указать условие условие на ключ в WHERE. Иначе независимо от сортировки, будет прочитано больше строк, чем нужно... EventDate - это "недоиндекс" - он позволяет выбирать только нужные куски, но не более того. Куски крупные и их немного.

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

Можно - написать SHOW CREATE TABLE t.

Там будет в конце ENGINE. А у этого ENGINE, один из аргументов (как правило, кортеж) - первичный ключ.

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

пишу еще, случайно отправилось

предыдущая строка - да, runningDifference вроде

Я делаю select userid,max(timestamp) from traffic groupby userid. И мне нужно выбрать еще одно поле - по смыслу что-то вроде max-1 timestamp

или только изначально отсортировать надо как-то в подзапросе

Я делаю select userid,max(timestamp) from traffic groupby userid. И мне нужно выбрать еще одно поле - по смыслу что-то вроде max-1 timestamp

Как удобно это сделать - не знаю. Функции - достать второе после максимума нет. Можно неудобным способом: SELECT userid, max(timestamp), maxIf(timestamp, (userid, timestamp) NOT IN (SELECT userid, max(timestamp) FROM traffic GROUP BY userid)) FROM traffic GROUP BY userid

про NOT IN - тоже про такой способ думал. А внутри оно как работать будет - для каждого пользователя снова всю таблицу сканировать или это за один проход всё сделается?

Будет два раза сканировать. Также, если timestamp-ов мало, можно воспользоваться агрегатной функцией groupArray и функцией arraySort или arrayReverseSort от её результата; а потом взять первые два элемента.

ой, кстати, а сложно сделать функцию, возвращающую только уникальные значения массива?

Такая уже есть - arrayUniq.

хм, неужто проглядел :О

спасибо!

Она тоже не документирована... Впрочем, в этой функции ничего сложного нет - она работает.

да, ща исправим