Да.

Конечно же, при условии, что в where еще будут все колонки, которые перед isShow\isClick в ключе

Т.е. имеет смысл внести isShow в первичный ключ(у нас все сильно сложнее, чем я описал, и показы и так подзапросов вытаскиваются )?

Да, "при условии, что в where еще будут все колонки, которые перед isShow\isClick в ключе" и при условии, что эта фильтрация отфильтровывает достаточно большое количество строк.

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

Спасибо за ответ! Жаль, что нельзя массивы использовать для атрибутов словарей. Было бы удобно

Да, "при условии, что в where еще будут все колонки, которые перед isShow\isClick в ключе" и при условии, что эта фильтрация отфильтровывает достаточно большое количество строк.

Спасибо

Блин :) Опять с runningDifference влип )

Есть таблица, learnerId, video, action, position. action = play - запуск видео action = stop - остановка видео position - место в видео (конкретная секунда) Например данные. SELECT * FROM vid ┌─learnerId─┬─videoId─┬─action─┬─position─┬───────────eventTime─┬──eventDate─┐ │ 1 │ test │ play │ 0 │ 2017-01-01 00:00:00 │ 2017-01-01 │ │ 1 │ test │ stop │ 14 │ 2017-01-01 00:00:14 │ 2017-01-01 │ │ 1 │ test │ stop │ 55 │ 2017-01-01 00:01:05 │ 2017-01-01 │ │ 1 │ test │ play │ 55 │ 2017-01-01 00:01:25 │ 2017-01-01 │ │ 1 │ test │ play │ 20 │ 2017-01-01 00:00:33 │ 2017-01-01 │ │ 1 │ test │ stop │ 60 │ 2017-01-01 00:01:30 │ 2017-01-01 │ └───────────┴─────────┴────────┴──────────┴─────────────────────┴────────────┘ Тут получается, что в целом человек пропустил всего 5 секунд видео (с 15 по 20). Мне нужно в конечном счете получить кол-во уникальных человек просмотревших видео на каждой секунде... Решил сделать так... SELECT uniq(learnerId), range FROM ( SELECT learnerId, range FROM ( SELECT learnerId, action, runningDifference(position) AS diff, if(action = 'play', emptyArrayUInt32(), arrayFilter(x -> ((x >= (position - diff)) AND (x <= position)), range(toUInt32(position)))) AS range FROM ( SELECT * FROM vid ORDER BY eventTime ASC LIMIT 1 BY position ) ) ARRAY JOIN range ) GROUP BY range ORDER BY range ASC Получаю что нужно...но если добавляются данные по нескольким пользователям...ну, вы сами поняли что будет :)

А вот если бы была возможность runningDifference прикончить по определенному правилу, то проблем бы не было :)

Может есть вариант создать range без runningDifference? ) Что бы работало аналогично

Добавили changelog для недавнего и прошлого релиза https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md

Поклон ! ) Спасибо!!!

Добрый вечер! Есть сайт на django работает с подсгресом, хочется вместо него попробовать использовать clickhouse

Может кто то решал задачу с подключением django к clickhouse?

Добрый вечер! Есть сайт на django работает с подсгресом, хочется вместо него попробовать использовать clickhouse

А в чем причина появления желания смены СУБД?

Мы протестировали кликхаус и т.к он показал классную производительность, хотели использовать в проде )

я думал у веб-фрейморков нагрузка в основном oltp

скорее его дефолтные настройки быстрее постгреса в вашем конкретном случае. попробуйте лучше mysql :)

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

а у постгреса по дефолту лимит на память которую он может сожрать

'''Доступ к БД не связан с настройкой readonly. Невозможно дать полный доступ к одной БД и readonly к другой.''' Из документации. Есть ли изменения в сисетме прав доступа, или пока всё так же?

Может кто то решал задачу с подключением django к clickhouse?

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

'''Доступ к БД не связан с настройкой readonly. Невозможно дать полный доступ к одной БД и readonly к другой.''' Из документации. Есть ли изменения в сисетме прав доступа, или пока всё так же?

Пока всё так же.

Алексей, а нет никакой информации по исправлению ошибок в оптимизаторе? https://github.com/yandex/ClickHouse/issues/859

да, очень печальная ошибка, раз 10 в неделю на нее натыкаюсь

Добавили changelog для недавнего и прошлого релиза https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md

здорово что появился тип для UUID, еще бы для IP был и было бы здорово (пока мы на своей стороне всё в FixedString(16) складываем)

IP в FixedString? А почему не в uint32?

ipv6 в него не влезет, например

Так возьми тип куда влезет, а в4 конверть в в6 нотацию)

ipv6 в него не влезет, например

а в FixedString(16) влезет?)

а в FixedString(16) влезет?)

да, он (ipv6) как раз 16 байт

IP в FixedString? А почему не в uint32?

FixedString в ClickHouse это набор байт с фиксированой длиной, очень удобно для хранения кастомных типов которых нет в КХ, но иногда нужно и "глазами" посмотреть, пока небыло встроенного типа UUID это было неочень наглядно и местами просто ломало "консольку" если кто-то его решил через клиент поле выбрать )

Та же проблема была fixedString. Пока не было smi2 клиента приходилось очень осторожно выбирать колонки тк бинарные данные моментально ломают форматирование в консоли

А вот у такой ошибки какая причина может быть? 2017.08.20 08:23:11.342928 [ 6 ] executeQuery: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Assertion violation: !_path.empty() in file "/home/robot-metrika-test/jenkins/workspace/clickhouse-packages-build/sources/contrib/libpoco/Foundation/src/File_UNIX.cpp", line 370, e.what() = Assertion violation (from 10.*.*.*:60398) (in query: INSERT INTO table FORMAT CSV)

2017.08.20 08:23:11.369209 [ 6 ] ServerErrorHandler: Code: 99, e.displayText() = DB::Exception: Unknown packet from client, e.what() = DB::Exception, Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x2a890e6] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string, std::allocator > const&, int)+0x1f) [0x10dea3f] 2. clickhouse-server(DB::TCPHandler::receivePacket()+0x21f) [0x10eb2af] 3. clickhouse-server(DB::TCPHandler::runImpl()+0x55c) [0x10ec91c] 4. clickhouse-server(DB::TCPHandler::run()+0x2b) [0x10ed54b] 5. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x3416fff] 6. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x13b) [0x341d43b] 7. clickhouse-server(Poco::PooledThread::run()+0xb7) [0x3688287] 8. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0xa5) [0x36542c5] 9. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7fadc26b76ba] 10. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fadc1cd83dd] Code: 210. DB::NetException: Connection reset by peer while writing to socket (10.*.*.*:9000)

Всем привет. Поднял на сервере clickhouse-server в докере, порт прокинут наружу, если открыть через браузер, то отображается "Ок.", но при попытке законнектиться удаленно клиентом получаю ошибку "Code: 209. DB::NetException: Timeout exceeded while reading from socket" При этом если прямо на сервере рядом в докере поднять клиент, то оттуда корректно получается зацепиться. Подскажите, пожалуйста, с чем может быть связана эта ошибка? То есть он вроде цепляется к серверу, но висит долго, а потом отваливается по таймауту.

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

Пока всё так же.

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

Может кто то решал задачу с подключением django к clickhouse?

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

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

Нашел коннектор к алхимии + фласк

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

Как вариант - отдельный инстанс для аналитиков, на котором созданы Distributed таблицы, смотрящие на основной кластер.

Я тоже сначала так подумал, но тогда если делать join, то мы будем тянуть по сети оба селекта(и левый и правый) и только потом джойнить. Больше проблем чем профита

Нашел коннектор к алхимии + фласк

Тоже не взлетел) Вообщем сделаю напишу инструкцию )

Тоже не взлетел) Вообщем сделаю напишу инструкцию )

А что именно хотите сделать ?

Clickhouse не поддерживает update. Что значит "подключить к джанге"?

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

видимо

задачка интересная, но отсутствие апдейта делает ее какой-то одноногой )

Да, в этом и дело

Если хочется иметь django-подобный orm то могу посоветовать infi.clickhouse_orm опять же. Надо понимать что вы без проблем можете сделать API на джанге к данным которые хранятся в кликхаусе. Но не подключить clickhouse в качестве бэкенда для django.db.models

Привет, max_threads влияет на вставку в таблицу типа insert into ... format TSV при вставке через cat test.tsv | clickhouse-client?

Всем привет. К вопросу о ключе семлирования. Мы хотим использовать ключем семплирования id пользователя. ID пользователя у нас это - UUID4. Вопрос, нужно ли этот ID оборачивать в хеш функцию по типу cityHash64? или в исходном виде пойдет? А хеш актуален только для значений которые что-то значат?

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

Привет, max_threads влияет на вставку в таблицу типа insert into ... format TSV при вставке через cat test.tsv | clickhouse-client?

Нет, вставка происходит в один поток (точнее в два - клиент парсит TSV и формирует блоки формате Native, сервер сортирует и записывает результат).

Привет. А есть ли какая-нибудь возможность заставить кх выполнять запрос, вида Select FROM Select полностью на шардах?

Можете пример запроса привести? Distributed запрос и так выполняется по возможности на локальных машинах, но сервер-инициатор всё-таки должен принять и смержить результаты.

Пример запроса: SELECT hash1, hash2, month, p, p - pos_diff AS prev_p, p_diff FROM ( SELECT hash1, hash2, month, p, runningDifference(hash1) AS p, runningDifference(hash2) AS u, runningDifference(p) AS p_diff FROM ( SELECT hash1, hash2, month, p FROM distributed_table WHERE (d = 'value') AND (month IN ('2017-05-15', '2017-06-15')) AND (hash1 = cityHash64('value2')) ORDER BY hash1 ASC, hash2 ASC, month ASC, p ASC LIMIT 1 BY hash1, hash2, month ) ) WHERE (p = 0) AND (u = 0) ORDER BY p_diff DESC LIMIT 10 Сейчас он идет в каждый шард, выполняя запрос SELECT hash1, hash2, month, p FROM distributed_table WHERE (d = 'value') AND (month IN ('2017-05-15', '2017-06-15')) AND (hash1 = cityHash64('value2')) ORDER BY hash1 ASC, hash2 ASC, month ASC, p ASC LIMIT 1 BY hash1, hash2, month Дальше смерживает данные на сервере-инициаторе и продолжает выполнение запроса. Можно ли как-нибудь сделать так, чтобы он все выполнил на шардах, результат смержил на сервере-инициаторе, выполнил там же сортировку и limit?

в конец каждого подзапроса который надо мержить локально надо добавлять "settings distributed_group_by_no_merge = 1" если я правильно понял что нужно

но это не работало для ридонли юзеров, вроде

Подскажите пожалуйста, есть ли способ при помощи стандартных движков решить следующию задачу: Есть уникальный ключ (назовем его session_id) с этим ключем могут появлять события (request_id) c определенным набором полей, но хотелось бы чтобы в итоге все поля получалсь в виде одной записи (сессия и все поля, относящиеся к этой сессии) Можно ли, какой-то движек использовать, чтобы в рамках session_id в зависимости от request_id подставлялось нужное значение. Можно было бы писать несколько записей , а потом GROUB BY session_id и anyIf(value1, request_id = 1), anyIf(value_2, request_id = 2) но возможно можно как-то сократить обьем и ускорить выборки

Всем привет! до этого не сталкивался c clickhouse, вроде интересно в некоторых моих 'use cases'. Но мучает один вопрос. Допустим изза нештатной траблы, появится необходимость поменять какието данные за определенный период времени... с этим вообще все плохо?

а... увидел в Roadmap план "Начальная поддержка UPDATE и DELETE"

Всем привет! до этого не сталкивался c clickhouse, вроде интересно в некоторых моих 'use cases'. Но мучает один вопрос. Допустим изза нештатной траблы, появится необходимость поменять какието данные за определенный период времени... с этим вообще все плохо?

Выбрать движок ReplacingMergeTree

ммм, да удобно. спс, но наверно может создать лишний оверхед, если эта необходимость возникает крайне редко (вроде 2 раза за последние 1-2 года)

и еще В приницпи сейчас у нас и так есть сервера, собирающие реалтайм стату, и раз в какойто период времени скидывающие данные в 'общую' базу (пачками) но есть сервисы где вся стата сразу отправляется в единую базу (по мере поступления/реалтайм) вопрос наверно так: на сколько важно даные скидывать пачками - очень важно? желательно?

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

а... увидел в Roadmap план "Начальная поддержка UPDATE и DELETE"

Сейчас штатный способ поправить данные плохие - заменить партицию с плохими данными с помощью ALTER ... DETACH PARTITION / ATTACH PARTITION. ReplacingMergeTree для этого использовать нежелательно, т.к. действительно будет постоянный оверхед на столбец с версией, чтобы уникально идентифицировать записи, возможно придётся добавлять лишние столбцы в первичный ключ, ну и чтобы заменить данные, всё равно вручную придётся вызывать OPTIMIZE.

и еще В приницпи сейчас у нас и так есть сервера, собирающие реалтайм стату, и раз в какойто период времени скидывающие данные в 'общую' базу (пачками) но есть сервисы где вся стата сразу отправляется в единую базу (по мере поступления/реалтайм) вопрос наверно так: на сколько важно даные скидывать пачками - очень важно? желательно?

у меня на тестах получалось 800к вставок в секунду батчами. и 35к вставок если данные приходят как попало. когда по одной строке когда по 5000. cpu 100% в обоиз случаях. но при 800к вставок еще и было типа 120 iops а при как попало под 700 iops. так что критически важны.

Да, на каждую вставку происходит O(количества столбцов) disk seek-ов, а если таблица Replicated, то и где-то десяток транзакций в ZooKeeper.

Ну и константный оверхед на создание всяких временных std::string, shared_ptr и т.п., который для маленьких вставок становится заметен.

> с помощью ALTER ... DETACH PARTITION / ATTACH PARTITION ну для нештатной ситуации выглядит терпимо. спс. значит жить можно :) > ... так что критически важны. спасибо :)

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

а столбец с датой в таблице есть?

господа а http://repo.red-soft.biz/ фсё ?

а столбец с датой в таблице есть?

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

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

тогда SELECT date, count() from table GROUP BY date вроде бы то, что нужно

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

ну то есть это будет постоянно растущая кривая

господа а http://repo.red-soft.biz/ фсё ?

Для redhat-подобных дистрибутивов есть репозиторий altinity: https://packagecloud.io/altinity/clickhouse

ну то есть это будет постоянно растущая кривая

А, понял. То есть нужна кумулятивная сумма

хм. другие репы я слышал имеются да. но ту можно убирать из плейбука ?

А, понял. То есть нужна кумулятивная сумма

да

@ztlpn судя по сайту altinity это вы, да ?

Нет, не мы (Яндекс) ? От altinity в чате есть @alexanderzaitsev

ой. я при быстром прочтении ника вас с ним спутал :)

извните :)

ничего страшного ?

да

Есть способ с помощью недокументированной функции runningAccumulate(). Сейчас постараюсь изобразить...

SELECT date, runningAccumulate(countState()) FROM (SELECT date FROM Table WHERE date > '2017-08-10' ORDER BY date) GROUP BY date как-то так?) по идее даже подзапрос и ORDER не нужен. Не знаю, бывают ли ситуации, когда данные не отсортированы по date?

Почти верно. Единственное, для производительности лучше сначала GROUP BY, а потом ORDER BY, а у вас наоборот. ORDER BY всё-таки нужен, иначе блоки данных могут придти в произвольном порядке, и запрос отработает, но выдаст не совсем то, что нужно.

а, ну логично, конечно )