исправлены предыдущие ошибки, добавлен полностью блок по кликхаус и пет-проект

2026-09-15 15:34:46 +05:00
parent 297df348c1
commit fb0f37912d
11 changed files with 1235 additions and 2 deletions
@@ -0,0 +1,115 @@
+# Задачи на отработку:
+
+### **Задача 1.**
+
+**Таблица:** `logs(log_id UInt64, ts DateTime)`
+
+| log_id | ts |
+| --- | --- |
+| 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. Создай `ORDER BY ts`, добавь `minmax`индекс:
+    
+    ALTER TABLE logs ADD INDEX idx_ts ts TYPE minmax GRANULARITY 2;
+    
+        ГОТОВО
+
+2. Сделай запрос: `SELECT * FROM logs WHERE ts BETWEEN '2024-06-02' AND '2024-06-03'`
+        ГОТОВО
+
+3. Посмотри, сколько блоков было пропущено (в `system.query_log`, `rows_read`, `rows`).
+        НЕТ ПРАВ ДОСТУПА
+
+4. Что будет, если `ORDER BY log_id`, а не `ts`?
+        ТОГДА ДАННЫЕ НА ДИСКЕ БУДУТ ОТСОРТИРОВАНЫ ПО log_id, а первичный и вторичный индексы по ts перестанут помогать в поиске данных.
+
+
+### **Задача 2.**
+
+**Таблица:** `clicks(id UInt64, country String)`
+
+| id | country |
+| --- | --- |
+| 1 | RU |
+| 2 | US |
+| 3 | RU |
+| 4 | DE |
+| 5 | RU |
+1. Создай таблицу с `ORDER BY id`, добавь индекс:
+    
+    ALTER TABLE clicks ADD INDEX idx_country country TYPE set(1000) GRANULARITY 2;
+        
+        ДОБАВИЛ
+
+2. Выполни запрос `SELECT * FROM clicks WHERE country = 'RU'`.
+        ВЫПОЛНИЛ
+
+3. Посмотри `EXPLAIN` — индекс используется?
+
+        ИСПОЛЬЗУЕТСЯ
+
+        Expression ((Project names + Projection))
+  Expression ((WHERE + Change column names to column identifiers))
+    ReadFromMergeTree (dmedvedev.clicks)
+    Indexes:
+      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
+
+4. Как будет вести себя индекс, если `country` имеет 10M уникальных значений?
+        ОН НЕ БУДЕТ РАБОТАЬ, ТАК КАК МЫ ИНДЕКСЕ set МЫ УСТАНОВИЛИ ПОРОГ УНИКАЛЬНЫХ ЗНАЧЕНИЙ В 1000 ШТУК.
+        В ТАКИХ СЛУЧАЯХ НУЖНО БЫЛО БЫ ВОСПОЛЬЗОВАТЬСЯ БЛУМ ФИЛЬТРОМ.
+
+### **Задача 3.**
+
+**Таблица:** `users(id UInt64, email String)`
+
+| id | email |
+| --- | --- |
+| 1 | alice@mail.com |
+| 2 | bob@mail.com |
+| 3 | charlie@mail.com |
+| 4 | dave@mail.com |
+| 5 | eve@example.com |
+1. Добавь индекс:
+    
+    ALTER TABLE users ADD INDEX idx_email email TYPE bloom_filter(0.01) GRANULARITY 2;
+    ДОБАВИЛ
+
+2. Проверь поиск по точному email:
+    SELECT * FROM users WHERE email = 'alice@mail.com';
+    
+    РАБОТАЕТ
+    1	alice@mail.com
+    
+    Expression ((Project names + Projection))
+  Expression ((WHERE + Change column names to column identifiers))
+    ReadFromMergeTree (dmedvedev.users)
+    Indexes:
+      PrimaryKey
+        Condition: true
+        Parts: 1/1
+        Granules: 1/1
+      Skip
+        Name: idx_email
+        Description: bloom_filter GRANULARITY 2
+        Parts: 1/1
+        Granules: 1/1
+        Ranges: 1
+
+3. Почему этот индекс **не ускоряет** поиск по `LIKE '%mail%'`?
+        ПОТОМУ ЧТО ФИЛЬТР БЛУМА НЕ МОЖЕТ ИСКАТЬ ДАННЫЕ КОТОРЫЕ СОДЕРЖАТЬСЯ ВНУТРИ КАКИХ-ТО СТРОК, ЕМУ НУЖНО ПОНИМАТЬ КАКОЕ БУДЕТ НАЧАЛО, А ЗДЕСЬ ОНО НЕ УКАЗАНО.
+        ДЛЯ ТАКОГО ПОИСКА НУЖНО ПРИМЕНЯТЬ МОДЕРНИЗИРОВАННЫЙ ФИЛЬТР БЛУМА ПО ТОКЕНАМ.
+
+4. Что произойдёт при `LIKE 'alice%'`?
+        В ТАКОМ СЛУЧАЕ ОБЫКНОВЕННЫЙ ФИЛЬТР БЛУМА СРАБОТАЕТ.