Повторю вопрос, вдруг тот, кто знает вчера пропустил. 1) хотелось бы понять насколько оптимальна запись в AggregatingMergeTree, если хочется собирать данные по часам - везде в примерах по датам 2) И насколько там адекватно использовать GROUP BY во вложенных запросах и в целом вложенные запросы, Например: таблицы примерно так соотносятся: на каждую запись в Init в районе 10-15 записей в Event и 10-15 записей в Flow c одним sessionId metricN - uint8/16, ufa - фиксированная стринга CREATE MATERIALIZED VIEW default.AggregatedEvent ENGINE = AggregatingMergeTree(date, (hour, eventId, suid, date), 8192) AS SELECT toStartOfHour( toDateTime( time ) ) hour eventId, suid, any(date) date, countState() count, uniqState(ufa) AS unique, avgState(metric1) AS metric1, avgState(metric2) AS metric2, avgState(metric3) AS metric3 FROM ( SELECT sessionId, time, eventId, date, metric1, metric2, metric3 FROM ( SELECT sessionId, time, eventId, date FROM Event ) ANY LEFT JOIN ( SELECT sessionId, avg(metric1) metric1, avg(metric2) metric2, avg(metric3) metric3 FROM Flow GROUP BY sessionId ) USING sessionId ) ANY LEFT JOIN ( SELECT id sessionId, suid, ufa FROM Init ) USING sessionId GROUP BY hour, eventId, suid;

привет. ведь приконектиться к серверу с кликхаусом дефолтная авторизация: ?username=default&password= так?

стучусь на tcp://server:8123/?username=default&password=

на 9000 по tcp стучитесь

может http а не tcp ? ;)

на 9000 по tcp стучитесь

привет. ведь приконектиться к серверу с кликхаусом дефолтная авторизация: ?username=default&password= так?

Ни через HTTP, ни через консольный клиент, ни через jdbc эти дефолтные параметры указывать не нужно

на машине с кликхаусом сделайте netstat -anp|grep click

поменяйте в конфиге адрес на 0.0.0.0

Метаданные. Информация о том, что появился кусок данных - с каким-то названием, чексуммой и т. п.

Глупый вопрос к разработчикам: а что мешает делать апдейты для типов данных фиксированной длины, типа U/IntXY или FixedString? Можно же, в теории, прямо в файлике, в одном и ровно одном месте поменять и евент в реплики отправить. Медленно? Да вроде бы быстро, опять же в теории, особенно если редко использовать.

Новые возможности: * Распределённые DDL (например, CREATE TABLE ON CLUSTER) * Реплицируемый запрос ALTER TABLE CLEAR COLUMN IN PARTITION * Движок таблиц Dictionary (доступ к данным словаря в виде таблицы) * Движок баз данных Dictionary (в такой базе автоматически доступны Dictionary-таблицы для всех подключённых внешних словарей) * Возможность проверки необходимости обновления словаря путём отправки запроса в источник * Qualified имена столбцов * Квотирование идентификаторов двойными кавычками * Сессии в HTTP интерфейсе * Запрос OPTIMIZE Replicated таблицы теперь можно выполнять не только на лидере Обратно несовместимые изменения: * Убрана команда SET GLOBAL Мелочи: * Теперь после получения сигнала в лог печатается полный стектрейс * Ослаблена проверка на количество повреждённых/лишних кусков при старте (было слишком много ложных срабатываний) Исправления: * Исправлено залипание плохого соединения при вставке в Distributed таблицу * GLOBAL IN теперь работает при запросе из таблицы Merge, смотрящей в Distributed * Теперь правильно определяется количество ядер на виртуалках Google Compute Engine * Исправления в работе executable источника кэшируемых внешних словарей * Исправлены сравнения строк, содержащих нулевые символы * Исправлено сравнение полей первичного ключа типа Float32 с константами * Раньше неправильная оценка размера поля могла приводить к слишком большим аллокациям * Исправлено падение при запросе Nullable столбца, добавленного в таблицу ALTER-ом * Исправлено падение при сортировке по Nullable столбцу, если количество строк меньше LIMIT * Исправлен ORDER BY подзапроса, состоящего только из константных значений * Раньше Replicated таблица могла остаться в невалидном состоянии после неудавшегося DROP TABLE * Алиасы для скалярных подзапросов с пустым результатом теперь не теряются * Теперь запрос, в котором использовалась компиляция, не завершается ошибкой, если .so файл повреждается

Релиз "почти" выложен. Пакеты для версии 1.1.54244 опубликованы, но в testing ветке репозитория. Чтобы их установить, надо эту ветку добавить. Делается командами (пример для ubuntu trusty) sudo apt-add-repository "deb http://repo.yandex.ru/clickhouse/trusty testing main" sudo apt-get update

недавно поставили актуальную версию из grafana.net и почему-то не могу никак сменить "Table transformation: Time series to rows" на "Table".

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

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

А зачем? Первичный ключ может быть составным. Например может содержать дату и id-записи