Обновляться ASAP только если вы наблюдаете большой рост размера снапшота в ZooKeeper.

По большей части нет. Сегодня вечером выложили на один кластер. На остальные кластеры только завтра. Фактически у нас ноды растут с такой скоростью, что есть запас по крайней мере в несколько дней/неделю.

Вместо агрегационной таблицы, вы просто делайте запрос, которым все посчитаете

Нужно считать все покупки до момента текущей покупки

Так текущая покупка -- она же последняя

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

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

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

Вполне себе нормальный кейс

Как в итоге решили?

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

Я кажется понял. Андрей хочет кумулятивный счетчик (хотя в таком виде он мне и не понятен, интереснее суммы накапливать). В лоб это не делается, нужно развернуть данные в "косынку" (то есть к каждому ордеру цеплять отдельным запросом всю историю)

Да )

Нужно строить график за 10 лет. Т.е. нужно перебрать все покупки и для каждой покупки сделать count только до момента текущей покупки. "До текущего момента времени" - не знаю как сделать в СН

Можно попробовать джоин с фильтром по дате и группировкой по заказу и джоинить это добро к основному запросу

select order_id, count(*), sum(prev_amount) from orders all inner join (select order_id, order_time prev_time, order_amount prev_amount from orders) using (order_id) where prev_time < order_time group by order_id;

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

ReplicatedMergeTree?

Мы поменяли на одном из кластеров. Работает, сжимает...

Добрый день! подскажите пожалуйста, есть ли php коннектор с поддержкой сессий

Много узлов в log накапливается, если одна из реплик долго находится в неактивном состоянии. Эти ноды сохраняются для того, чтобы эта реплика могла подняться и синхронизироваться. То есть, если у вас было несколько реплик, а потом один из серверов просто перестал работать, то до поднятия упавшей реплики, будут накапливаться ноды. Если реплика упала навсегда, то её придётся удалить из ZK вручную. (Это одна из неудобных особенностей. С изменениями в версии 1.1.54276 это не связано.) Вы пытаетесь сделать это в некотором интерфейсе, но он кидает исключение. Потому что не может получить большой список нод. Это проблема того интерфейса, с помощью которого вы пытаетесь удалить ноды. Чтобы всё-таки всё по-нормальному сделать, придётся воспользоваться каким-то другим интерфейсом. Через zkCli.sh получается? На крайний случай у нас есть специальная программа, которая может быстро удалить список нод... Если понадобится - расскажем, как воспользоваться.

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

SELECT toRelativeDayNum(toDate('2017-08-30')) - toRelativeDayNum(toDate('2017-08-29')) AS experienceInDays ┌─experienceInDays─┐ │ 1 │ └──────────────────┘

А есть какие-то примерные сроки когда появится релиз с фиксом удаления партиций в зукипере или тестовая сборка (v1.1.54284) в пакетах ?

там только 1.1.54283

после рестарта не поднимается ? 2017.08.30 00:28:12.256343 [ 1 ] <Error> Application: DB::Exception: Cannot create table from metadata file /opt/clickhouse/metadata/model//history_model_result_sharded.sql, error: DB::Exception: The local set of parts of table history_model_result_sharded doesn't look like the set of parts in ZooKeeper. There are 0 unexpected parts (0 of them is not just-written), 0 unexpectedly merged parts, 0 missing obsolete parts, 85 missing parts, stack trace:

Подскажите, а таблица с множеством Nested колонок и кол-вом значений в каждой Nested колонке от 1 до 300, но с маленьким кол-вом строк в самой таблице, до 250 000 это не сильно убьет производительность? Просто есть мысль симулировать update данных через ReplacingMergeTree. В общей сложности планируется в таблицу затолкать около 50 колонок из которых примерно 10 будут Nested.

Сильно тормозить не будет, но в целом для 250 000 строк использование ClickHouse неоправдано. Также есть вариант - развернуть массивы и писать в плоскую таблицу; для обновления писать новые строки, а старые не трогать; для получения последних данных использовать агрегатные функции argMax и тому подобное. Для маленького числа строк Ок.

Всем привет. Помогите решить задачу в рамках СН. Есть таблица по покупкам. В ней есть колонки order_id, order_datetime, client_id. Необходимо для каждой строки покупки посчитать количество совершенных покупок клиентом до момента текущей покупки. Раньше мы в MySQL имели агрегационную таблицу, где для кажой покупки клиента, подсчитывалось количество покупок ранее сделанное им же. Не хочется делать какие-то агрегации в СН, ведь как раз от них мы и хотели отказаться с переходом аналитики на СН. Помогите, пожалуйста