малость тупой вопрос ... могу ли я хранить в КХ данные по финансовым транзакциям, и подходит ли КХ для этой задачи?

малость тупой вопрос ... могу ли я хранить в КХ данные по финансовым транзакциям, и подходит ли КХ для этой задачи?

Если нет апдейтов транзакций, то можете

наверно неплохо будут храниться данные с биржи )

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

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

ну, сейчас, единственным ограничением может быть только UPDATE/DELETE но, как говорил уже кто-то тут в чате, в Q2 уже зарелизят

ну там не такие апдейты и делеты как в обычных базах )

да и инстерты тут тоже не такие как везде

про это вкурсе

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

Главное с флотами в ногу не стрельнуть

Главное с флотами в ногу не стрельнуть

так можно в любой БД

припоминаю хранение денежной информации в виде рубли*10^4 (требовались сотые доли копеек для последующей обработки).

малость тупой вопрос ... могу ли я хранить в КХ данные по финансовым транзакциям, и подходит ли КХ для этой задачи?

Хранить можете, нет, если у вас любая финансовая транзакция это 1 операция (что далеко не факт) то и жить с этим как-то вы сможете. А вообще нет, не подходит, как минимум у КХ нет транзакций.

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

а нет случаем под убунту 16.04 репозитория с chproxy ?

Недавно писал, что clickhouse-copier, если судить по докам, при попытке решардировать данные в уже существующем кластере удалит вообще все партиции с данными. Проводил тесты - всё так и получилось)). Хотелось бы уточнить у тех, кто, может, делал перешардирование кластера при добавлении нового шарда - как избежать такой проблемы? И у представителей разработки - clickhouse-copier вообще поддерживает решардирование данных по уже существующему кластеру, чтобы задействовать вновь добавленный шард?

Недавно писал, что clickhouse-copier, если судить по докам, при попытке решардировать данные в уже существующем кластере удалит вообще все партиции с данными. Проводил тесты - всё так и получилось)). Хотелось бы уточнить у тех, кто, может, делал перешардирование кластера при добавлении нового шарда - как избежать такой проблемы? И у представителей разработки - clickhouse-copier вообще поддерживает решардирование данных по уже существующему кластеру, чтобы задействовать вновь добавленный шард?

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

Если да, то не получится

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

Да. Не хотелось бы делать дубликаты таблиц с новыми названиями и отключать клиентов, переписывать логику ПО на новые имена таблиц только ради добавления нового шарда...

Если да, то не получится

Спасибо за ответ. Мы нашли другое решение для себя, не очень красивое, но eventually сбалансированное и главне рабочее Думал может с копиером что-то не так делаю...

Про удаление данных в доке описано даже. Копир я воспринимаю скорее как средство развертывания копии кластера, с неким числом данных

Про удаление данных в доке описано даже. Копир я воспринимаю скорее как средство развертывания копии кластера, с неким числом данных

Ага. Но также написано про решардинг, кроме этого в гите в issue к старым командам решардинга самим Clickhouse писали что-то вроде «это сломано, используйте копир». Поэтому и была надежда)

для удобства может симлинк из etc

Боюсь, я забыл закрыть свой pr и Лёша его принял. Так что лучше будет его вычистить, наверное. Ну и по поводу симлинков, мне лично не совсем понятно, как их правильно ставить, ведь data dir может быть где угодно и всё равно нужен рут для того, чтобы это сделать. ?

достаточно забавное поведение :) select 100; SELECT 100 ┌─100─┐ │ 100 │ └─────┘ 1 rows in set. Elapsed: 0.001 sec. :) select 0100; SELECT 64 ┌─64─┐ │ 64 │ └────┘ 1 rows in set. Elapsed: 0.001 sec. :)

достаточно забавное поведение :) select 100; SELECT 100 ┌─100─┐ │ 100 │ └─────┘ 1 rows in set. Elapsed: 0.001 sec. :) select 0100; SELECT 64 ┌─64─┐ │ 64 │ └────┘ 1 rows in set. Elapsed: 0.001 sec. :)

Вполне понятное. Автоматическое приведение типов данных. Есть у кх такая фича. Как и отсутствие ошибки при переполнении поля Int/UInt

Вполне понятное. Автоматическое приведение типов данных. Есть у кх такая фича. Как и отсутствие ошибки при переполнении поля Int/UInt

не очень понятно правило, по которому 0100 переводится в 64

Бинарный вид видимо

Это как с ip адресами в ping

восьмеричная система счисления же

да, что и не совсем ожидаешь хотя, возможно, это где-то в документации есть

А я правильно понимаю, что чтобы приджойнить несколько таблиц, нужно иерархически плодить select from ( (select from)any left join (select from) using) any left join (select from) using ? Можно ли плоско сделать? select from () any left join () any left join () using

Уже на две таблицы в джойне — под 50 строк запрос, дальше просто страшно приджойнивать ))

Денормализация :)

Привет, а как можно почистить clickhouse-server.err.log

echo > clickhouse-server.err.log

ну или удалить его и перезапустить кх

ну или удалить его и перезапустить кх

спасибо

да, что и не совсем ожидаешь хотя, возможно, это где-то в документации есть

мне вот страннее, что КХ знает нотацию "010", "0x10", но вот о "0b10" не догадывается =)

в программировании с с++ сказать честно не помню чтобы испольховал бинарную нотацию, вероятно это как то связано

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

:) select 010 format TSKV SELECT 8 FORMAT TSKV 8=8 1 rows in set. Elapsed: 0.005 sec. select 0x10 format TSKV SELECT 16 FORMAT TSKV 16=16 1 rows in set. Elapsed: 0.004 sec. select 0b10 format TSKV Syntax error: failed at position 8: select 0b10 format TSKV

Денормализация :)

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

в программировании с с++ сказать честно не помню чтобы испольховал бинарную нотацию, вероятно это как то связано

включена с с++14 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf

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

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

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

Скажите пожалуйста, а такое поведение корректно? Есть зукипер кластер, а 3 нодах. Я останавливаю службу зукипера (лидер) И сразу же в кликхаул ловлю DB::Exception: ZooKeeper session has been expired.. как только появляется новый лидер зукипер (ок 20 сек ), ошибка пропадает

Скажите пожалуйста, а такое поведение корректно? Есть зукипер кластер, а 3 нодах. Я останавливаю службу зукипера (лидер) И сразу же в кликхаул ловлю DB::Exception: ZooKeeper session has been expired.. как только появляется новый лидер зукипер (ок 20 сек ), ошибка пропадает

Конечно нормально. У вас лидера в зк нет

rate

всем привет, есть ATTACH PARTITION и DETACH PARTITION, а можно ли заменить партицию? например, для изменения данных я бы подготовил измененную партицию, а потом заменил ею существующую. надо чтобы замена атомарно сработала(или не сработала)

Добрый день, есть таблица с событиями, есть поле datetime, есть ли возможность посчитать rate ( событие в секунду/минуту) из CH? Так же есть другой кейс: есть startdatetime, duration. Нужно посчитать сколько МАКСИМАЛЬНО активных (ПИКИ) событий было в момент времени с группировокой по минуте/часу.

всем привет, есть ATTACH PARTITION и DETACH PARTITION, а можно ли заменить партицию? например, для изменения данных я бы подготовил измененную партицию, а потом заменил ею существующую. надо чтобы замена атомарно сработала(или не сработала)

Есть в мастере https://github.com/yandex/ClickHouse/commit/c888903488fa995245dcbe8db63c261343ac1ffb . Сейчас можно сделать "руками" переместив партицию на диске

Добрый день, есть таблица с событиями, есть поле datetime, есть ли возможность посчитать rate ( событие в секунду/минуту) из CH? Так же есть другой кейс: есть startdatetime, duration. Нужно посчитать сколько МАКСИМАЛЬНО активных (ПИКИ) событий было в момент времени с группировокой по минуте/часу.

AVG/MAX + GROUP BY

Rate считается легко, туплю(еще не проснулся)

а вот с пиками активных событий не все так просто, в минуте может быть 3 события а все по времени они не пересеклись, соответсвенно пик в этом отрезке времени будет 1

День добрый всем. Кто-нибудь работал с движком MySQL? Есть особенности?

А подскажите, были какие-нибудь статьи о том какими файловыми системами лучше пользоваться для кликхауса? Бенчи какие-нибудь.

в целом на 2тб данных нормально работает на дефолтном ext4 без тюннинга

А подскажите, были какие-нибудь статьи о том какими файловыми системами лучше пользоваться для кликхауса? Бенчи какие-нибудь.

Яндекс советует Ext4 — самый проверенный вариант, стоит указывать опции монтирования noatime,nobarrier

hdd/ssd ? или не критично?

Яндекс советует Ext4 — самый проверенный вариант, стоит указывать опции монтирования noatime,nobarrier

nobarrier? Seriously? Барьеры записи позволяют поддерживать согласованность журнала и данных на диске, я бы не стал это отключать.

Есть опыт, когда так пол раздела превращалось в тыкву и многие файлы даже в lost+found потом отсутствовали :).

hdd/ssd ? или не критично?

зависит от нагрузки у нас хорошо крутится и на хдд

зависит от нагрузки у нас хорошо крутится и на хдд

спасибо)

hdd/ssd ? или не критично?

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

nobarrier? Seriously? Барьеры записи позволяют поддерживать согласованность журнала и данных на диске, я бы не стал это отключать.

У Яндекса, который это советует, небось отказоустойчивость уровнем выше расположена — если что не так с сервером или диском, то его выкидывают и настраивают новый. А nobarrier для производительности.

У Яндекса, который это советует, небось отказоустойчивость уровнем выше расположена — если что не так с сервером или диском, то его выкидывают и настраивают новый. А nobarrier для производительности.

В принципе, да, репликация решает эту проблему, но всё равно неприятно, когда нужно полностью ресинкать всю стойку, если питание моргнуло, например.

Господа, есть ли какие-либо варианты ротаций для query log? Чет я все бьюсь над проблемой того, что он разъедается до немыслимых размеров

Господа, есть ли какие-либо варианты ротаций для query log? Чет я все бьюсь над проблемой того, что он разъедается до немыслимых размеров

Можете просто удалять старые партиции у него.

Можете просто удалять старые партиции у него.

а там есть партиционирование?

я имею в виду, что эта таблица системная и в ней можно это настроить?

Ага, по дефолту месяц, но можно и настроить.

данные только придется переливать

или уже можно нет ?

Придётся

Точнее должна новая таблица создаться.

А старая переименуется с суффиксом

У Яндекса, который это советует, небось отказоустойчивость уровнем выше расположена — если что не так с сервером или диском, то его выкидывают и настраивают новый. А nobarrier для производительности.

По поводу nobarrier, если в приложении используется полноценный fsync, а не fdatasync, проблем с потерей данных не должно быть. Также проблем не должно быть, если используется контроллер дисков с политикой кеширования WriteBack и с батарейный кешем.

Ага, по дефолту месяц, но можно и настроить.

https://clickhouse.yandex/docs/ru/operations/server_settings/settings/#part_log

это не то?

https://clickhouse.yandex/docs/ru/operations/server_settings/settings/#query_log

part_log это лог операций с кусками в MergeTree-таблицах

Кстати, за кастомное партиционирование в query_log спасибо @kshvakov :)

Кстати, за кастомное партиционирование в query_log спасибо @kshvakov :)

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

Я задал параметры партицирования

но чет новая таблица не создалась а старая не переименовалась

что посоветуете делать с периодическими ошибками: 2018.05.28 13:40:09.227034 [ 15 ] <Error> SspStats..inner.SspDealLogAggr_local (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Timeout: connect timed out: 10.136.14.220:9009, e.what() = Timeout

но чет новая таблица не создалась а старая не переименовалась

Ага, значит недоработано. Можно вручную переименавать: rename table system.query_log to system.query_log_0, а новая таблица с новым партиционированием автоматически создастся.

Ага, значит недоработано. Можно вручную переименавать: rename table system.query_log to system.query_log_0, а новая таблица с новым партиционированием автоматически создастся.

переименовал. А новой таблицы все нет(

Не нужно же для этого рестартить весь КХ, правда?

А какая версия у вас?

что посоветуете делать с периодическими ошибками: 2018.05.28 13:40:09.227034 [ 15 ] <Error> SspStats..inner.SspDealLogAggr_local (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Timeout: connect timed out: 10.136.14.220:9009, e.what() = Timeout

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

А какая версия у вас?

1.1.54327

Это было добавлено в 1.1.54378

А насколько оно нормально обновляется?