это не имеет отношения к кх.  Файл это цепочка блоков и inode. В inode есть счетчик ссылок. В каталоге создается имя файла и ссылается на inode. Имен может быть сколько угодно. Если имен 6 то в счетчике ссылок будет 6. Если файл открыть например в 2 приложениях то ссылок будет еще +2. Содержимое файла удаляется с диска когда ссылок 0.  Т.е. надо удалить 6 файлов которые ссылаются на тот inode и закрыть файл в 2 приложениях.

Потому что партиции и парты это разные вещи
Партиция это логическое разделение
А парты физическое один парт на один insert и дальше они в фоне через merge sort сливаются

Парты иммутабельны это значит они пишутся один раз и потом не меняются

При удалении парта хардлинк останется  и ничего не потеряется

Всем привет

Таблица:

CREATE TABLE IF NOT EXISTS test (
 docId String,
 userId String,
 date Date
)
 ENGINE = MergeTree(date, (userId, docId), 8192)

Данных в таблице ~67 миллионов

Запрос:

SELECT COUNT(DISTINCT(userId))
FROM test
WHERE docId IN
   (SELECT DISTINCT docId
    FROM test
    WHERE userId = '7682068d-a33f-4226-9f63-a301c97c3e26'
      AND NOT docId = 'n/a'
      AND NOT docId = ''
      AND docId IS NOT NULL)
 AND userId IS NOT NULL
 AND NOT userId = ''
 AND NOT userId = '7682068d-a33f-4226-9f63-a301c97c3e26'

Проблема: выполнение запроса в среднем ~20-25 секунд

(Вопрос - Как сделать выполнение запроса быстрее?)

К примеру отдельный запрос:

SELECT DISTINCT docId
    FROM test
    WHERE userId = '7682068d-a33f-4226-9f63-a301c97c3e26'
      AND NOT docId = 'n/a'
      AND NOT docId = ''
      AND docId IS NOT NULL

Выполнение - 0.021 sec.

Другой запрос:

SELECT COUNT(DISTINCT(userId)) FROM test WHERE docId IN ('Berkshire', 'Avon')

Выполнение ~8-9 sec.

Что пробовал?

- Secondary Indexes (ADD INDEX). Возможно пробовал криво
- MergeTree(date, (userId), 8192)
- MergeTree(date, (docId), 8192)
- MergeTree(date, (docId, userId), 8192)

(работаю редко с КХ; неопытный; спасибо за помощь)

спасибо, это понял.

Ок, получается при резервировании партиции, не фиксируется состояние на тот момент времени? Если вставка 1 инсерт в секунду, к примеру, то получается через секунду после окончания резервирования каталог в shadow тоже изменится и будет содержать уже новые данные?

То есть те данные, что я зарезервировал, и то что заберу из shadow позже - будет разными данными?

сколько у вас уникальных docId?

AND docId IS NOT NULL смысла не несёт, т.к. тип не Nullable

195

Понял

ну тогда проблемы не должно быть, индексы никак на скорость не повлияют т.к. идёт полное чтение таблицы

хотя я может не так понял, что вы хотите посчитать?

У пользователей есть ID документов

Задача - получить пересечение по документам

К примеру:

В интерфейсе (личный кабинет) открыли пользователя с ID = 1

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

Формально, данные:

- userId: 1, docId: 1
- userId: 1, docId: 2
- userId: 1, docId: 3

- userId: 2, docId: 1 (есть такой документ у пользователя ID = 1)
- userId: 2, docId: 4
- userId: 2, docId: 5

- userId: 3, docId: 2 (есть такой документ у пользователя ID = 1)
- userId: 3, docId: 10
- userId: 3, docId: 11

На выходе получаем список:

- userId: 2
- userId: 3

файлы и парты иммьютебл, они не меняются. То что попало в shadow никогда не изменится.

create table S (A Int64) Engine=MergeTree order by A;
insert into S values(1);

был парт  
ls -l /var/lib/clickhouse/data/default/S/
all_1_1_0

alter table S freeze;

ls -l /var/lib/clickhouse/shadow/1/data/default/S/all_1_1_0/

в shadow попадает парт с файлами all_1_1_0

insert into S values(1);
insert into S values(2);

инсерт всегда создает новый парт ls -l /var/lib/clickhouse/data/default/S/
all_1_1_0
all_2_2_0
all_3_3_0

дальше мержер мержит optimize table S final
ls -l /var/lib/clickhouse/shadow/1/data/default/S/all_1_1_0/
all_1_1_0
all_1_3_1
all_2_2_0
all_3_3_0

три исходных парта  all_1_1_0  all_2_2_0  all_3_3_0 слились в all_1_3_1
через 8 минут КХ удалит каталоги all_1_1_0  all_2_2_0  all_3_3_0

каталог в shadow all_1_1_0 останется навсегда, неизменным, пока вы его не удалите.

В общем суть в том что файлы записанные кликхаузом никогда не изменяются, ничего в них не дописывается ни в середину ни в конец. Поэтому в shadow лежат те эталонные файлы которые КХ создал при первой записи (инсерте или мерже).

2020.07.11 13:02:40.635369 [ 35938 ] {} <Error> Application: DB::Exception: external dictionary - удаляю как написано в баге файл с медатанными, запускаю кх, он опять на него ругается

копи пасту ошибки в студию
копи пасту команды которой удаляете

SELECT COUNT(DISTINCT(userId))
FROM test
PREWHERE docId IN
   (SELECT DISTINCT docId
    FROM test
    WHERE userId = '7682068d-a33f-4226-9f63-a301c97c3e26'
      AND NOT docId = 'n/a'
      AND NOT docId = ''
      AND docId IS NOT NULL)
 WHERE userId IS NOT NULL
 AND NOT userId = ''
 AND NOT userId = '7682068d-a33f-4226-9f63-a301c97c3e26'

без двух таблиц отсортированных по разному (да данные будут хранится два раза) такое не исправить.
И вообще надо брать постре или мускуль для таких задач, КХ тут как слон на кухне

То есть в /var/lib/clickhouse/shadow/1/data/default/S/all_1_1_0/ будет еще all_1_3_1 и в нем будут новые данные?

КХ навсегда забыл про /var/lib/clickhouse/shadow/1/data/default/S/all_1_1_0/
Он удалил (с задержкой 8мин.) свой inactive парт all_1_1_0 после того как все из него перелил в all_1_3_1