И автоматическое удаление, чтобы диск не засорялся тоже можно?

>Запрос на чтение не сразу видит данные, булкинсертом вставленные.

тогда такого быть не может. КХ возвращает управление инсерту когда все данные уже видны селектам

Друзья, не подскажете, как правильнее вставить в КХ много данных, типа пару ТБ?

а insert не работает?

падает по памяти? может я чтото не так делаю
Code: 240. DB::ErrnoException: Allocator: Cannot mremap memory chunk from 2.00 GiB to 16.00 EiB., errno: 12, strerror: Cannot allocate memory

как инсерт выглядит? Какой тип данных? Какой клиент используется?

clickhouse-client -d db -q 'insert into db.table_log format TabSeparated'

интересно, это 100% баг
а версия КХ ?

попробуйте
clickhouse-client --input_format_parallel_parsing=0 -d db -q 'insert into db.table_log format TabSeparated'

Да, вроде сработало
version 20.5.2.7

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

Я читал на github'e уже, увидел что закрыт и старый, и даже не попробовал с флагом

какие типы данных в таблице?  DDL можете показать? А TSV большой?  Строк в нем много? Они широкие?

У меня ошибка парсинга, файл битый — не могу сказать что точно отработало уже

session_start DateTime64(3, 'Etc/UTC'),
        session_end   DateTime64(3, 'Etc/UTC'),
        filter_ip     IPv4,
        local_ipv4    Nullable(IPv4),
        local_ipv6    Nullable(IPv6),
        local_port    UInt16,
        remote_ipv4   Nullable(IPv4),
        remote_ipv6   Nullable(IPv6),
        remote_port   UInt16,
        dpi_protocol_code_list  Array(UInt32)
    ) engine = ReplicatedMergeTree('/clickhouse/tables/{shard}/session_log.session_signature_log_local', '{replica}')
    partition by toStartOfDay(session_start)
    order by (session_start, filter_ip);

размер 2ТБ, вот как раз сломан файл там слишком длинная первая строка выяснил только что

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

Привет! Если join on mySuperString, но в select нет mySuperString, CH будет строить таблицу со строками или приведет к какому-то hash?

наличие hash-а не решает проблему коллизий, разруливается на уровне реализации hash-таблицы (сам join отдельно хранить строку не будет достанет из hash-мапы):
       std::unique_ptr<FixedHashMap<UInt8, Mapped>>   key8;
       std::unique_ptr<FixedHashMap<UInt16, Mapped>> key16;
       std::unique_ptr<HashMap<UInt32, Mapped, HashCRC32<UInt32>>>                     key32;
       std::unique_ptr<HashMap<UInt64, Mapped, HashCRC32<UInt64>>>                     key64;
       std::unique_ptr<HashMapWithSavedHash<StringRef, Mapped>>                        key_string;
       std::unique_ptr<HashMapWithSavedHash<StringRef, Mapped>>                        key_fixed_string;
       std::unique_ptr<HashMap<UInt128, Mapped, UInt128HashCRC32>>                     keys128;
       std::unique_ptr<HashMap<UInt256, Mapped, UInt256HashCRC32>>                     keys256;
       std::unique_ptr<HashMap<UInt128, Mapped, UInt128TrivialHash>>                   hashed;

я скорее не про коллизии, а про размер данных при объединении. Т.е. стоит ли мне join on xxHash64(mySuperString) сделать руками или CH сам умеет это?

^ специализации хэш таблиц в join-е для ключей разных размеров и типов

ну по хэшу руками вы получите join с коллизиями, которые как-то надо пофильтровать