SS
спасибо за ответ, попробовал 0.01, быстрей не стало
Size: a a a
2019 November 29
SS
а какой тип колонки лучше всего использовать для сэмплирования и как его лучше хешить?
Mİ
Привет. Что оптимальнее использовать для хранения IPv4 адресов с точки зрения размера хранимух данных на диске с компрессией, String иди IPv4/Uint32 ?
DC
Sasha S
спасибо за ответ, попробовал 0.01, быстрей не стало
возможно что для такого запроса (который с условиями по индексу и считает только count, т.е. не трогает тяжелые колонки, не фильтрует), никакой семплинг не поможет.
мне кажется хеширование не влияет на селекты, там простое условие, типа для 0.5 будет половина пространства uint64 ~ sample < max_uin64/2
мне кажется хеширование не влияет на селекты, там простое условие, типа для 0.5 будет половина пространства uint64 ~ sample < max_uin64/2
DC
Maxim İanoglo
Привет. Что оптимальнее использовать для хранения IPv4 адресов с точки зрения размера хранимух данных на диске с компрессией, String иди IPv4/Uint32 ?
ну конечно число или Uint32 или ipv4
Mİ
ну конечно число или Uint32 или ipv4
Я почему спрашиваю. У меня есть таблица которая весит 6.9G. В ней IP адреса String типа. Предположил что с Uint32 долно приличнее меньше места занимать. Создал другую таблицу с той же структурой только IP адреса IPv4 типа. Скопировал данные из старой в новую с конверсией IPv4StringToNum, но таблица получилась больше 7.5G
Mİ
Вот пытаюсь понять почему.
DC
Maxim İanoglo
Я почему спрашиваю. У меня есть таблица которая весит 6.9G. В ней IP адреса String типа. Предположил что с Uint32 долно приличнее меньше места занимать. Создал другую таблицу с той же структурой только IP адреса IPv4 типа. Скопировал данные из старой в новую с конверсией IPv4StringToNum, но таблица получилась больше 7.5G
так а колонки что ? system.parts_columns, там column_data_compressed_bytes
Mİ
так а колонки что ? system.parts_columns, там column_data_compressed_bytes
Там все как и ожидал. Данных меньше занимает. du показывает больше почему-то. Я по нему ориентировался.
DC
Maxim İanoglo
Там все как и ожидал. Данных меньше занимает. du показывает больше почему-то. Я по нему ориентировался.
du показывает и активные и неактивные парты.
Вы сделали insert создалось много партов, они помержились в крупные, мелкие первичные парты стали неактивными, du их видит, через 8 мин. они будут удалены.
Вы сделали insert создалось много партов, они помержились в крупные, мелкие первичные парты стали неактивными, du их видит, через 8 мин. они будут удалены.
DC
ну правда system.parts_columns тоже есть нективные парты, если запрос написать без system.parts_columns where active
Mİ
system.parts говорит, что все партиции активны. И там больше партов еще чем в "оригинальной" таблице. Чтобы не было как-то связано с тем, что у меня CH запущен в докере
Mİ
А можно как-то посмотреть когда он собирается мерджить данные и все такое ?
DC
du должен показывать ровно то число что и system.parts
докер никак не влияет
кол-во партов значения не имеет и это слабо влияет на общий размер
нельзя узнать когда будет мержить, это зависит от частоты будущих инсертов в эту и другие таблицы.
докер никак не влияет
кол-во партов значения не имеет и это слабо влияет на общий размер
нельзя узнать когда будет мержить, это зависит от частоты будущих инсертов в эту и другие таблицы.
S
Есть таблица
делаю простейшую операцию
получаю ошибку
в документации такое ограничение не описано
https://clickhouse.yandex/docs/en/query_language/alter/#alter_modify-column
может что надо что-то еще добавить MODIFY ORDER BY ?
CREATE TABLE IF NOT EXISTS REPORTING.device_families
(
device_family_id Int32,
nom String
)
ENGINE = MergeTree() ORDER BY device_family_id
делаю простейшую операцию
ALTER TABLE REPORTING.device_families MODIFY COLUMN device_family_id UInt8;
получаю ошибку
Code: 44, e.displayText() = DB::Exception: ALTER of key column device_family_id must be metadata-only (version 19.17.4.11)
в документации такое ограничение не описано
https://clickhouse.yandex/docs/en/query_language/alter/#alter_modify-column
может что надо что-то еще добавить MODIFY ORDER BY ?
YY
Кажется, на данный момент нельзя просто так взять и изменить этот поле, т.к. по нему физически лежат данные. Вам нужно создать новую таблицу с правильным типом и перелить туда данные.
S
=( обидно что про это ничего в документации нет
я понимаю что через INSERT INTO SELECT можно сделать ;(
я понимаю что через INSERT INTO SELECT можно сделать ;(
YY
Изменение типа у столбцов, входящих в первичный ключ возможно только в том случае, если это изменение не приводит к изменению данных (например, разрешено добавление значения в Enum или изменение типа с DateTime на UInt32).
Если возможностей запроса ALTER не хватает для нужного изменения таблицы, вы можете создать новую таблицу, скопировать туда данные с помощью запроса INSERT SELECT, затем поменять таблицы местами с помощью запроса RENAME, и удалить старую таблицу. В качестве альтернативы для запроса INSERT SELECT, можно использовать инструмент clickhouse-copier.
MR
Всем привет. Подскажите пожалуйста как сделать push в массив с условием в агрегации?
D
Добрый день!
Помогите пожалуйста устранить ошибку:
[ 2023 ] {d18544fc-d088-426e-8667-561be5f7e04d} <Error> executeQuery: Code: 368, e.displayText() = DB::Exception: Bad cast from type DB::ColumnVector<unsigned long> to DB::ColumnVector<long> (version 19.7.3.9 (official build)) (from [::ffff:10.0.0.5]:49630) (in query: INSERT INTO pp.logs_sends_local (push_id, site_id, created_at, subscribe_at, subscribe_day, user_id, device, push_type, country_id, service_id, sub_type) VALUES), Stack trace:
Помогите пожалуйста устранить ошибку:
[ 2023 ] {d18544fc-d088-426e-8667-561be5f7e04d} <Error> executeQuery: Code: 368, e.displayText() = DB::Exception: Bad cast from type DB::ColumnVector<unsigned long> to DB::ColumnVector<long> (version 19.7.3.9 (official build)) (from [::ffff:10.0.0.5]:49630) (in query: INSERT INTO pp.logs_sends_local (push_id, site_id, created_at, subscribe_at, subscribe_day, user_id, device, push_type, country_id, service_id, sub_type) VALUES), Stack trace: