Вопрос еще один очень интересный вопреки рекомендациями не использовать CH

для хренения текстовых документов я все равно не могу объяснить этот эффект ?
SELECT internal_id
FROM articles
WHERE internal_id = '6f58fa93be8424153cc0a4e27a42dc8649d98a1a'
┌─internal_id──────────────────────────────┐
│ 6f58fa93be8424153cc0a4e27a42dc8649d98a1a │
└──────────────────────────────────────────┘
1 rows in set. Elapsed: 0.108 sec. Processed 3.27 million rows, 151.11 MB (30.39 million rows/s., 1.40 GB/s.)
clickhouse-db-03.dmetrics.internal 🙂 SELECT internal_id,content
:-] FROM articles where internal_id = '6f58fa93be8424153cc0a4e27a42dc8649d98a1a';
SELECT
internal_id,
content
FROM articles
WHERE internal_id = '6f58fa93be8424153cc0a4e27a42dc8649d98a1a'
┌─internal_id──────────────────────────────┬─content────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ 6f58fa93be8424153cc0a4e27a42dc8649d98a1a │ One selling point for Harris, is that her experience with cyber crimes could give her a leg up as someone qualified to protect our cyber security from hostile nations.Even if you accept the idiotic idea that Trump didn't collude with Putin, the nicest thing you can say about Trump is that he has failed to take any action to protect our elections , our power grid, nuclear power plants etc etc. In other words, he is either an agent of Putin, or a sniveling coward. There is a government report that states that China and Russia have the capabilities to shut down our power grid and interupt our gas suplly lines. Imagine if they had done this during this current freeze. Thousands would have died │
└──────────────────────────────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
1 rows in set. Elapsed: 10.399 sec. Processed 3.27 million rows, 14.89 GB (314.48 thousand rows/s., 1.43 GB/s.)
Первый запрос по индексу берет 100 мс а тот же самой запрос который по индексу но и приносит текстовое поле дополнительное отвеает в 100 раз медленее ? Есть ли идеи почему ?

первый запрос читает только из одной колонки: internal_id второй запрос читает из двух колонок: internal_id, content при этом content сильно больше по размеру - это можно увидеть в статистике по запросам: Processed 3.27 million rows, 151.11 MB против Processed 3.27 million rows, 14.89 GB

^^^

Кх по минимуму читает одну гранулу. Т.е. если в ней 1000 строк, он прочтет 1000 гигантских текстов из другой колонки

Processed 3.27 million rows -- по индексу? Что ? ну и сто раз тут уже показывали как сделать подзапрос который вернет PK и потом по PK выберет

Спасибо,

ну мы новинькие только в начале пути можете направить о чем речь ?

1. у вас не работает индекс. SELECT internal_id FROM articles WHERE internal_id = '6f58fa93be8424153cc0a4e27a42dc8649d98a1a' должет возвращать малое кол-во прочитанных строк проверьте ДДЛ таблицы 2. после того как почините индекс, должно быть быстро.

если по индексу то processed rows будут тысячи а не миллионы show create table в студию

CREATE TABLE fgi.articles_data ( internal_id String, timestamp Nullable(DateTime('UTC')), content String, url Nullable(String), data_provider String, document_length UInt32, domain_name String, is_near_duplicate UInt8, publish_date DateTime('UTC'), tags.name Array(String), tags.score Array(Float64), tags.tagger Array(String) ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/replicated/fgi/articles_data', 'srv1.internal') PARTITION BY toYYYYMMDD(publish_date) ORDER BY internal_id SETTINGS index_granularity = 8192

если бы индекс не работал то 100 мс не было было для internal_id

ясно PARTITION BY toYYYYMMDD(publish_date) ORDER BY internal_id SETTINGS index_granularity = 8192 т.е. каждый парт в каждом шарде дает 8129 (или 16384) строк., чтобы получить Processed 3.27 million rows надо иметь 199 партов, т.е. конечно это можно все поправить, и партиционирование шардирование, и т.д. наверное вам придется делать два запроса select publish_date, internal_id FROM articles WHERE internal_id = '6f58fa93be8424153cc0a4e27a42dc8649d98a1a' SELECT internal_id, content FROM articles WHERE internal_id = '6f58fa93be8424153cc0a4e27a42dc8649d98a1a' and publish_date = .... одним запросом вроде прунинг сделать не получится а да, еще можно попробовать PREWHERE вместо WHERE

было бы, колонка сжатая... маленькая. из кеша норм.

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