Индексы и сжатие - Индексы

2026-05-04 08:09:54 +04:00
parent 209cce48b2
commit 1de11c1d5e
1 changed files with 166 additions and 0 deletions
@@ -0,0 +1,166 @@
+--		Индексы и сжатие - Индексы		--
+
+-- #1
+/*
+3. Посмотри, сколько блоков было пропущено (в `system.query_log`, `rows_read`, `rows`).
+Не посмотрю, так как нет доступа system.query_log, rows_read, rows (ACCESS_DENIED)
+4. Что будет, если `ORDER BY log_id`, а не `ts`?
+ORDER BY log_id → данные физически отсортированы по log_id. Значения ts расположены хаотично относительно физической сортировки. 
+Индекс minmax по ts будет почти бесполезен. Minmax индекс будет иметь широкие диапазоны 
+*/
+
+DROP TABLE IF EXISTS dsolovianov.logs ON CLUSTER clickhouse_cluster SYNC;
+
+CREATE TABLE dsolovianov.logs
+ON CLUSTER clickhouse_cluster
+(
+    log_id UInt64,
+    ts DateTime
+)
+ENGINE = ReplicatedMergeTree(
+    '/clickhouse/tables/{shard}/dsolovianov/logs',
+    '{replica}'
+)
+ORDER BY ts 
+PARTITION BY toYYYYMM(ts) 
+PRIMARY KEY (ts);  
+
+INSERT INTO dsolovianov.logs (log_id, ts) VALUES
+(1, '2024-06-01 10:00:00'),
+(2, '2024-06-01 11:00:00'),
+(3, '2024-06-02 12:00:00'),
+(4, '2024-06-03 13:00:00'),
+(5, '2024-06-04 14:00:00');
+
+-- 1. Добавляем minmax индекс:
+ALTER TABLE dsolovianov.logs ADD INDEX idx_ts ts TYPE minmax GRANULARITY 2;
+
+-- 2. Сделай запрос: `SELECT * FROM logs WHERE ts BETWEEN '2024-06-02' AND '2024-06-03'`
+SELECT 	* 
+FROM 	dsolovianov.logs 
+WHERE 	ts 
+		BETWEEN '2024-06-02' AND '2024-06-03';
+
+-- Раз нет доступа, но можно предположить, что вот такой запрос сработает:
+SELECT query, read_rows, result_rows 
+FROM system.query_log 
+WHERE query LIKE '%logs%' 
+ORDER BY event_time DESC 
+LIMIT 1;
+
+
+-- #2
+/*
+1. Создай таблицу с `ORDER BY id`, добавь индекс:
+    
+    ```sql
+    ALTER TABLE clicks ADD INDEX idx_country country TYPE set(1000) GRANULARITY 2;
+    ```
+    
+
+3. Посмотри `EXPLAIN` — индекс используется?
+Данные отсортированы по id, а не по country. Значения country распределены хаотически относительно физического порядка. 
+4. Как будет вести себя индекс, если `country` имеет 10M уникальных значений?
+Будет создано 10M партиций, что убьёт производительность.
+**/
+DROP TABLE IF EXISTS dsolovianov.clicks ON CLUSTER clickhouse_cluster SYNC;
+
+CREATE TABLE dsolovianov.clicks
+ON CLUSTER clickhouse_cluster
+(
+    id UInt64,
+    country String
+)
+ENGINE = ReplicatedMergeTree(
+    '/clickhouse/tables/{shard}/dsolovianov/clicks',
+    '{replica}'
+)
+ORDER BY id
+PARTITION BY country 
+PRIMARY KEY (id);
+
+INSERT INTO dsolovianov.clicks (id, country) VALUES
+(1, 'RU'),
+(2, 'US'),
+(3, 'RU'),
+(4, 'DE'),
+(5, 'RU');
+
+ALTER TABLE dsolovianov.clicks ON CLUSTER clickhouse_cluster 
+ADD INDEX idx_country country TYPE set(1000) GRANULARITY 2;
+
+-- 2. Выполни запрос `SELECT * FROM clicks WHERE country = 'RU'`.
+EXPLAIN indexes = 1
+SELECT * FROM dsolovianov.clicks WHERE country = 'RU';
+
+EXPLAIN 
+SELECT * FROM dsolovianov.clicks WHERE country = 'RU';
+
+/*
+Expression ((Project names + Projection))
+  Expression ((WHERE + Change column names to column identifiers))
+    ReadFromMergeTree (dsolovianov.clicks)
+    Indexes:
+      MinMax
+        Keys:
+          country
+        Condition: (country in ['RU', 'RU'])
+        Parts: 1/3
+        Granules: 1/3
+      Partition
+        Keys:
+          country
+        Condition: (country in ['RU', 'RU'])
+        Parts: 1/1
+        Granules: 1/1
+      PrimaryKey
+        Condition: true
+        Parts: 1/1
+        Granules: 1/1
+      Skip
+        Name: idx_country
+        Description: set GRANULARITY 2
+        Parts: 1/1
+        Granules: 1/1
+        Ranges: 1
+ */
+
+-- #3
+
+DROP TABLE IF EXISTS dsolovianov.users ON CLUSTER clickhouse_cluster SYNC;
+
+CREATE TABLE dsolovianov.users
+ON CLUSTER clickhouse_cluster
+(
+    id UInt64,
+    email String
+)
+ENGINE = ReplicatedMergeTree(
+    '/clickhouse/tables/{shard}/dsolovianov/users',
+    '{replica}'
+)
+ORDER BY id
+PRIMARY KEY (id);
+
+INSERT INTO dsolovianov.users (id, email) VALUES
+(1, 'alice@mail.com'),
+(2, 'bob@mail.com'),
+(3, 'charlie@mail.com'),
+(4, 'dave@mail.com'),
+(5, 'eve@example.com');
+
+ALTER TABLE dsolovianov.users ADD INDEX idx_email email TYPE bloom_filter(0.01) GRANULARITY 2;
+
+EXPLAIN indexes = 1
+SELECT * FROM users WHERE email = 'alice@mail.com';
+-- Bloom filter может пропустить некоторые гранулы, но не все, ибо данные не отсортированы по email и индексные блоки покрывают случайные email'ы
+
+EXPLAIN indexes = 1
+SELECT * FROM users WHERE email LIKE '%mail%';
+
+EXPLAIN indexes = 1
+SELECT * FROM users WHERE email LIKE 'alice%';
+/*
+Bloom filter не поддерживает частичные совпадения (LIKE '..%', LIKE '%..', LIKE '%..%'). Из-за этого ClickHouse не может пропустить гранулы.
+Клику становится сложно вычислить хэш для проверки, если подходящих значений по LIKE будет больше одного. Нет гарантии, что данные на выходе будут корректные.
+*/