Не мат, обычные

Вопрос, создал матвью CREATE MATERIALIZED VIEW view ( ...., START_DATE_INDEX Date ) ENGINE = ReplacingMergeTree(START_DATE_INDEX, (...), 8192) POPULATE AS SELECT ..., toDate(START_DATE) FROM table

Создание прошло успешно

10 - вьюшки, они созданы на всём кластере

И что? Выбирать можно из любой?

Но в логе DB::Exception: There is no column with name toDate(START_DATE). There are columns: .... : while pushing to view

Но в логе DB::Exception: There is no column with name toDate(START_DATE). There are columns: .... : while pushing to view

Спасибо, сам разобрался :)

И что? Выбирать можно из любой?

да

да

Так дистрибьютид таблица тогда.

Так дистрибьютид таблица тогда.

поверх одинаковых вьюшек?

и из merge в неё ходить?

Мердж зачем? Просто дистрибьютид таблица и она проселекит одну из 10 реплик. Данные ведь одинаковые везде. Т.е. просто надо описать такой кластер в котором один шард и десять реплик и дистрибьютид таблица выберет один раз. Обычно в этом нет смысла потому что если есть локальная реплика , данные будут выбраны из нее. Ну можно описать кластер без текущего сервера. Проще запросы выполнять на разных серверах через какой-то балансировщик.

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

у кого 10, а у нас в сервисе за 0.05 и latency ощутимо

Ну то есть очень много запросов по 50 мс?

В целом это же сводится на нет пулом соединений до кх

Мердж зачем? Просто дистрибьютид таблица и она проселекит одну из 10 реплик. Данные ведь одинаковые везде. Т.е. просто надо описать такой кластер в котором один шард и десять реплик и дистрибьютид таблица выберет один раз. Обычно в этом нет смысла потому что если есть локальная реплика , данные будут выбраны из нее. Ну можно описать кластер без текущего сервера. Проще запросы выполнять на разных серверах через какой-то балансировщик.

Гм так смысл же в том, что бы при обращении к любой ноде в кластере получить аналогичную выборку... а merg использую для простоты авто-добавления данных для выдачи, сделал view on cluster которая попадает под регулярку - она автоматически подтянется в merge..

В продолжении темы. тестирую нагрузку: при подключении больше 140 rps теряется подключение к КХ

кто нибудь тестировал нагрузку более 1000 rps ? или выбрать другое решение для такой задачи?

1000 запросов в секунду на чтение ?

В продолжении темы. тестирую нагрузку: при подключении больше 140 rps теряется подключение к КХ

Лимит по умолчанию 100 одновременно

Коллеги, привет. После удаления materialized view табикс отказывается загружаться. Лог: 2018.06.10 08:31:38.678268 [ 29 ] <Error> HTTPHandler: Code: 60, e.displayText() = DB::Exception: Table default..inner.table doesn'$ Перезагрука не помогла. Никто не сталкивался?

Коллеги, привет. После удаления materialized view табикс отказывается загружаться. Лог: 2018.06.10 08:31:38.678268 [ 29 ] <Error> HTTPHandler: Code: 60, e.displayText() = DB::Exception: Table default..inner.table doesn'$ Перезагрука не помогла. Никто не сталкивался?

При создании матвью создается таблица с приставкой inner.

Её можно удалить обычным DROP TABLE

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

Любые запросы обрываются? Даже не связаные с этой матвью и таблицой?

Tima да на любые таблицы из дефолтной базы (матвью на ней была создана). Запросы к другим БД — норм идут.

а как поисследовать почему словари могут не грузиться? они там на основе обычных вью, зависает на reload, в логах на уровне Debug ничего

Tima да на любые таблицы из дефолтной базы (матвью на ней была создана). Запросы к другим БД — норм идут.

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

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

вот как решили: почистили все файлы связанные с этой вьюхой в папке с кх и все заработало

Лимит по умолчанию 100 одновременно

а где меняется данный лимит?

а где меняется данный лимит?

max_concurrent_queries

В продолжении темы. тестирую нагрузку: при подключении больше 140 rps теряется подключение к КХ

Поставить прокси надо

Поставить прокси надо

а как прокси тут поможет ?

а как прокси тут поможет ?

Прокси будет отдивать когда нагрузка слишком большая

У нас с прокси среднее время выполнение уменьшилось

интересно

Где вертикаль это кол-во rps а горизонталь время

С прокси вместо пиков видим стабильность по нагрузке(картинки нет под рукой)

Если прокси буферизирует ответ, то не удивительно

Для кх запрос уже отработан, и он отдал быстро тело ответа проксе, и освобождает пул для запросов

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

Привет! Не подскажете почему кликхаус может писать Database XXX doesn't exist. Диреткория /var/lib/clickhouse/data/XXX в наличии

а соответствующие метаданные есть?

а соответствующие метаданные есть?

неа ) если пересоздать таблицы, данные прочитаются же?

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

в любом случае - сделать бекап до всех действий

ок, попробую. спасибо!

@j3qq4_h7h2v_2hch4_m3hk8_6m8vw а по содержимому /data никак же метаданные не восстановить?

тут не в курсе - бекаплю всё разом.

@j3qq4_h7h2v_2hch4_m3hk8_6m8vw а по содержимому /data никак же метаданные не восстановить?

При сильной необходимости колонки и их типы лежат в каждом куске в файле columns.txt, но там, естественно, не совсем чтоб структура таблицы.

подскажите, как решить следующую проблему: 1. есть таблица MergeTree 2. над ней создается матвьюха AggregatingMergeTree 3. в этой матвьюхе есть вычисляемый через case (вложенные ifы) столбец 4. при создании матвьюхи на непустой существующей исходной таблице с ключом populate - все ок 5. но когда возобновляем запись в исходную таблицу, записывающий клиент получает исключения: ...Unknown identifier: error_type: while pushing to view default.exceptions1... at ru.yandex.clickhouse.except.ClickHouseExceptionSpecifier.specify(ClickHouseExceptionSpecifier.java:53) ~[clickhouse-jdbc-0.1.39.jar:?] error_type - имя вычисляемого столбца exceptions1 - имя матвьюхи как это лечить? полные sql и весь текст исключения здесь: https://pastebin.com/1AXNXQcg

подскажите, как решить следующую проблему: 1. есть таблица MergeTree 2. над ней создается матвьюха AggregatingMergeTree 3. в этой матвьюхе есть вычисляемый через case (вложенные ifы) столбец 4. при создании матвьюхи на непустой существующей исходной таблице с ключом populate - все ок 5. но когда возобновляем запись в исходную таблицу, записывающий клиент получает исключения: ...Unknown identifier: error_type: while pushing to view default.exceptions1... at ru.yandex.clickhouse.except.ClickHouseExceptionSpecifier.specify(ClickHouseExceptionSpecifier.java:53) ~[clickhouse-jdbc-0.1.39.jar:?] error_type - имя вычисляемого столбца exceptions1 - имя матвьюхи как это лечить? полные sql и весь текст исключения здесь: https://pastebin.com/1AXNXQcg

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

согласен, вроде прописано, но я решил аналогичный exception при помощи алиасов. так что видимо надо покопать в эту сторону

а может быть такое, что в задании алиаса слово AS иногда обязательно?

зачем вообще столько вложенности в запросах? может упростить?

вложенность лишняя, это понятно.

а может быть такое, что в задании алиаса слово AS иногда обязательно?

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

спасибо, буду пробовать.

подскажите, как решить следующую проблему: 1. есть таблица MergeTree 2. над ней создается матвьюха AggregatingMergeTree 3. в этой матвьюхе есть вычисляемый через case (вложенные ifы) столбец 4. при создании матвьюхи на непустой существующей исходной таблице с ключом populate - все ок 5. но когда возобновляем запись в исходную таблицу, записывающий клиент получает исключения: ...Unknown identifier: error_type: while pushing to view default.exceptions1... at ru.yandex.clickhouse.except.ClickHouseExceptionSpecifier.specify(ClickHouseExceptionSpecifier.java:53) ~[clickhouse-jdbc-0.1.39.jar:?] error_type - имя вычисляемого столбца exceptions1 - имя матвьюхи как это лечить? полные sql и весь текст исключения здесь: https://pastebin.com/1AXNXQcg

если у кого-нибудь есть еще идеи, как это исправить, будет здорово.

А кто-нибудь собирал документацию из исходником? Как вообще туда вносить дополнения?

Но при переходе на документацию получаю такое

https://clickhouse.yandex/docs/ru/getting_started/example_datasets/ontime/ Друзья, а почему тут везде count(*), т.е. со звёздочкой, а не просто count()? https://clickhouse.yandex/docs/ru/agg_functions/reference/ тут написано 0 аргументов у count. На гитхаб в ишью с этим сходить? Или сразу PR?

https://clickhouse.yandex/docs/ru/getting_started/example_datasets/ontime/ Друзья, а почему тут везде count(*), т.е. со звёздочкой, а не просто count()? https://clickhouse.yandex/docs/ru/agg_functions/reference/ тут написано 0 аргументов у count. На гитхаб в ишью с этим сходить? Или сразу PR?

разницы нет

разницы нет

непорядок(с)

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

в общем это фича и так задумано , думаю тут ишью и пр неуместны

Привет, а какие есть тулзы для миграций на КХ?

Руки

Из монги проще что-то написать на условном python. Из вертики через tsv перегоняли. Из пг пока не приходилось

При миграции лучше писать в буферную таблицу, естественно, чтобы избежать частых мержей

Скажите, а почему запрос max для array(int, внутри 5 элементов) примерно в 8 раз медленее, чем max для обычного unit'а? 419.02 million rows/s vs 15.84 million rows/s?

@tarabanton руками в 2к18 не комильфо). Часто нужно, например, добавить таблицу/поле/схему одновременно на 10 баз.

Можно ли где то найти метрики как часто Buffer в действительности скидывает даные в таблицу?

@tarabanton руками в 2к18 не комильфо). Часто нужно, например, добавить таблицу/поле/схему одновременно на 10 баз.

Для этого есть ON CLUSTER.

Можно ли где то найти метрики как часто Buffer в действительности скидывает даные в таблицу?

В логах при уровне в TRACE (это неудобно, нужноделать какой-нибудь SHOW TABLE STATUS, бывает нужно что-то посмотреть).

Скажите, а почему запрос max для array(int, внутри 5 элементов) примерно в 8 раз медленее, чем max для обычного unit'а? 419.02 million rows/s vs 15.84 million rows/s?

Как минимум нужно прочитать больше данных.

... При этом если я делаю max(r) for ARRAY join(some_array), то оно отрабатывает быстрее, чем max(some_array). Раза в три быстрее.

... При этом если я делаю max(r) for ARRAY join(some_array), то оно отрабатывает быстрее, чем max(some_array). Раза в три быстрее.

И результаты разные получаете

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

Точнее, не стоит ли этот array порезать на 5 отдельных колонок?

Добрый день

... При этом если я делаю max(r) for ARRAY join(some_array), то оно отрабатывает быстрее, чем max(some_array). Раза в три быстрее.

можно и без arrayjoin select max(a) from (select maxArray([1,2,3,4]) as a)

Где затык? show tables SHOW TABLES Ok. 0 rows in set. Elapsed: 0.001 sec. CREATE TABLE default.MetricsDistributed (..... Received exception from server (version 1.1.54383): Code: 337. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Table default.MetricsDistributed is creating or attaching right now.

Тоест таблиц нет

И создать не дает

Пишет что в процессе

Пробовал сервер рестартануть, не помогает