11238
Обсуждаем ClickHouse
Вот кусок из preprocessed_configs/config.xml с описанием тестового кластера. Он одинаковый на обеих нодах из него:
<test_cluster>Читать полностью…
<secret>my_secret_value</secret>
<shard>
<internal_replication>True</internal_replication>
<replica>
<host>clickhouse1...</host>
<port>9000</port>
</replica>
</shard>
<shard>
<internal_replication>True</internal_replication>
<replica>
<host>clickhouse2...</host>
<port>9000</port>
</replica>
</shard>
</test_cluster>
Покажите кусок XML. Замените креды на ...
Читать полностью…
Это ямловый конфиг клика, символы корректные. Пробовал просто цифры указывать, без результата.
В preprocessed_configs точно та же строчка, что указана в remote_servers, на обеих нодах...
в строке secret сделайте asci буквы и цифры, не используйте @ и $
Читать полностью…
Сикреты указываю одинаковые. Когда указываю пустую строку, клик использует дефолтную учетку, тут ожидаемое поведение и видно что он использует ключ.
Как только ставлю непустую одинаковую строку на обе тестовые ноды, ловлю такую ошибку...
100% secret разный
посмотрите что xml конфигах КХ
Добрый вечер. У меня есть тестовый кластер из двух шардов, запросы идут через техническую учетку
remote_servers:
test_cluster:
shard:
- internal_replication: "True"
replica:
- host:
port:
user:
password:
shard:
- internal_replication: "True"
replica:
- host:
port:
user:
password:
Code: 32. DB::Exception: Received from localhost:9000. DB::Exception: Attempt to read after eof: while receiving packet from <other_node>, (ATTEMPT_TO_READ_AFTER_EOF)
Добрый день
Вопрос про консистентность при dictGet() в ClickHouse
Есть витрина, обновляющаяся 1.5 часа, и словарь (users), который обновляется каждую минуту. В процессе обновления витрины dictGet() возвращает разные значения, т.к. словарь меняется
Как можно гарантировать, чтобы всё обновление витрины использовало единый снимок словаря на момент начала (атомарность / консистентность при dictGet)?
Добрый день, коллеги!
Кто-то сталкивался с такой проблемой:
- В CH создана таблица на движке PostgreSQL;
- Объем: 35 млн;
- При попытке извлечь данные в ETL дает ошибку
"SQLException when reading resultSet
CRLF expected at end of chunk"
Из 35 млн извлекает 15-25 млн и дает ошибку.
- ClickHouse 25.3.2.39
- PostgreSQL 11.15
Стек в файле
Аналогичная таблица с объемом < 1 млн работает без проблем
надо клику нативную поддержку типа protobuf : )
не в смысле на вхлоп и выхлоп, а как тип колонки. json здорового человека
починить источник данных как я предложил...
Читать полностью…
=)) медленно ж будет... лучше все таки починить, не?
Читать полностью…
https://github.com/ClickHouse/ClickHouse/issues/81132
allow_simdjson=0
https://github.com/ClickHouse/ClickHouse/issues/49895
;)) ну стандарты такие стандарты... проблема в интерпретации...
все таки нельзя в double это преобразовать... потому и фейлится парсер
https://www.perplexity.ai/search/pokazhi-kusok-json-rfc-kotoryi-N1nIN_2SSwmuRH6gJimVDA#0
ну... если почитать RFC, то о чиселках больше чем binary64 хотя и предупреждается, хотя и не рекомендуется, но явного запрета нет
Читать полностью…
Да, конечно. Сейчас отошёл, минут через 20-30 скину
Читать полностью…
Если оставить один шард с одной репликой в кластере, то локально с этой реплики distributed запрос работает. А вот со второй падает, хотя если вернуть вместо сикрета техническую учетку - проблем не будет
Читать полностью…
а это yaml КХ-за ? или это altinity operator ?
посмотрите тут /var/lib/clickhouse/preprocessed_configs/config.xml
КХ возможно неправильно yaml переписывает в xml, это уже фиксили несколько раз
и плюс secret можно задавать в разных местах
1) использование final это ОК
2) для coalescing надо использовать FINAL , last_value(value_string) не гарантирует что оно будет last, потому что эта функция для window functions не для groupby
3) так уже 1000 , а не 100
Добрый вечер.
Давно не заходил в документацию, все оч сильно поменялось)
Вопрос возник по движккам MergeTree - Replacing/Coalescing
кроме как использовать FINAL в запросе как есть способы получить только последние записанные данные ?
запросов в моменте может быть много, очень не хочется использовать FINAL.
В документации есть пример:
SELECT key, last_value(value_int), last_value(value_string), last_value(value_date) FROM test_table GROUP BY key; -- Not recommended.
Not recommended - смущает)
И еще помнится была настройка, max_concurrent_select_queries - по умолчанию вроде 100.
Насколько ее вообще можно увеличить ? исходя из ресурсов сервера, точнее как корректно считать? приблизительно.
никак видимо к сожалению это асинхронные процессы
как workaround
использовать какую то mirror clickhouse таблицу в качестве источника словаря и обновлять ее из реального источника через какой нибудь rename/exhange table
а тут ошибка не в КХ. У сервера ошибка всегда содержит либо DB:Exception либо Net:Exception, нету вариантов
> SQLException when reading resultSet CRLF expected at end of chunk
-- это сообщение от clickhouse-jdbc и даже в этом я не уверен, потому что clickhouse-jdbc не использует CRLF (CSV/TSV) там используется RowBinary
либо очень старый clickhouse-jdbc
попробуйте тоже самое через dbeaver, и clickhouse-client
node показывает
> {"xxx": 9999999999999999583119736832}
{ xxx: 1e+28 }
непонятно где вообще можно такой json использовать
починить simdjson ?
эта библиотека не от КХ https://github.com/simdjson/simdjson
ради идиотов у которых в json всякое говно менять библиотеку которая экономит электричества на миллион баксов ежедневно?
даже наверное обынчными регулярками клика можно починить
https://fiddle.clickhouse.com/d199ad70-306e-4dd4-afee-b6d9d23f5c5f
ну тут только надо фиксить
что нибудь типа
Пример скрипта (fix_big_numbers_json.py):
#!/usr/bin/env python3
import sys
import re
# Регулярное выражение для поиска больших чисел вне кавычек
big_number_pattern = re.compile(r'(:\s*)(\d{15,})(\s*[,}])')
for line in sys.stdin:
# Оборачиваем большие числа в кавычки
fixed = big_number_pattern.sub(r'\1"\2"\3', line)
print(fixed, end='')
sys.stdout.flush()
<functions>
<function>
<type>executable</type>
<name>fix_big_numbers_json</name>
<return_type>String</return_type>
<argument>
<type>String</type>
</argument>
<format>TabSeparated</format>
<command>fix_big_numbers_json.py</command>
</function>
</functions>
SELECT fix_big_numbers_json('{"xxx": 9999999999999999583119736832, "y": 123}') AS fixed_json;
Читать полностью…
это не CH считает, это стандарт JSON так считает... большие числа репрезентуются как строки...
просто вы в clickhouse как то положили в строку, я хочу понять как именно
я взял его из базы посгрес, где он лежит в поле JSONB
его невалидным считает кх
остальные валидары его корректно жуют