From 297df348c141290485670bb959431b47177d1e66 Mon Sep 17 00:00:00 2001 From: Dmitry Medvedev Date: Wed, 5 Aug 2026 23:51:40 +0500 Subject: [PATCH] fixed mistakes --- dmedvedev/10.3.Optimization of select.sql | 6 +-- dmedvedev/10.4.Explain.sql | 8 ++-- dmedvedev/10.5.Porydok.sql | 2 +- dmedvedev/2.1.theory_bd_indexes.sql | 2 +- dmedvedev/2.6.theory_bd_acid_base.sql | 4 +- dmedvedev/4.4.greenplum_external_tables.sql | 6 ++- dmedvedev/4.5.greenplum_pet_project.sql | 47 +++++++++------------ 7 files changed, 36 insertions(+), 39 deletions(-) diff --git a/dmedvedev/10.3.Optimization of select.sql b/dmedvedev/10.3.Optimization of select.sql index 3c06a7d..51da339 100644 --- a/dmedvedev/10.3.Optimization of select.sql +++ b/dmedvedev/10.3.Optimization of select.sql @@ -46,13 +46,13 @@ WHERE EXTRACT(YEAR FROM created_at) = 2026 AND LOWER(country) = 'россия' AND age + 10 > 35; - +CREATE INDEX users_lower_country_idx ON users (LOWER(country)); SELECT id, name, age FROM users WHERE created_at >= '2026-01-01' AND created_at < '2027-01-01' - AND country IN ('россия', 'Россия', 'РОССИЯ') + AND LOWER(country) = 'россия' AND age > 25; -Исправлено: выдача колонок "все" заменено на "определенные", логика в where с числами переработана, соответствие определенному году переработано и убрал функцию LOWER. +Исправлено: Добавлен индекс, который приведет все строки данного столбца в нижний регистр и дальнейший поиск будет производиться только по индексу. diff --git a/dmedvedev/10.4.Explain.sql b/dmedvedev/10.4.Explain.sql index e1b450a..d4ddfc0 100644 --- a/dmedvedev/10.4.Explain.sql +++ b/dmedvedev/10.4.Explain.sql @@ -12,7 +12,7 @@ WHERE id = 1; -- Строка означает фильтрацию столбца по индексу, который есть в столбце id. Почему база использует индекс, а не читает всю таблицу? ---В моем случае БД читает всю таблицу, но обычно если индексы расставлены верно и таблица больших размеров, то БД лучше использовать индексы для повышенной производительности. +--Потому что по полю есть индекс и таким образом оптимизатор ускоряет чтение. ---------- --Задача 2 — Seq Scan vs Index Scan @@ -33,13 +33,13 @@ WHERE id = 1; --Задача 4 — До и после индекса Запиши Execution Time и тип сканирования. ---Seq Scan, 0.059 мс, после создания индекса запрос составил 0.026мс +--Index Scan, 0,06 мс после создания индекса. Изменился ли тип сканирования? --- Нет, не изменился, не могу понять почему. +-- да, изменился. Стал ли запрос быстрее? На сколько? ---Да, в 2 раза +--Да, в 21 раза Почему индекс помог? --Потому что не пришлось искать по всей таблице. diff --git a/dmedvedev/10.5.Porydok.sql b/dmedvedev/10.5.Porydok.sql index 5b1c3de..a6ba4d7 100644 --- a/dmedvedev/10.5.Porydok.sql +++ b/dmedvedev/10.5.Porydok.sql @@ -278,7 +278,7 @@ FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE u.country = 'Россия' - GROUP BY u.name, u.age + GROUP BY u.id, u.name, u.age ORDER BY orders_count DESC; Второй запрос через JOIN выполняется быстрее (0.13 и 0.1 мс соответственно) \ No newline at end of file diff --git a/dmedvedev/2.1.theory_bd_indexes.sql b/dmedvedev/2.1.theory_bd_indexes.sql index 828f386..80bd56b 100644 --- a/dmedvedev/2.1.theory_bd_indexes.sql +++ b/dmedvedev/2.1.theory_bd_indexes.sql @@ -200,4 +200,4 @@ В чём выгода индекса и где он не поможет Индекс помогает искать данные быстрее (индекс это как содержание в книге) за счет плана в виде дерева. - Индекс не поможет в тех столбцах, где уникальность данных мала, а также где есть сортировка по знакам >, < или поиск по части строки = "%abc". + Индекс не поможет в тех столбцах, где уникальность данных мала, а также где есть сортировка по части строки, например "%abc" или если индекс не по функции . diff --git a/dmedvedev/2.6.theory_bd_acid_base.sql b/dmedvedev/2.6.theory_bd_acid_base.sql index 287bd5d..9591278 100644 --- a/dmedvedev/2.6.theory_bd_acid_base.sql +++ b/dmedvedev/2.6.theory_bd_acid_base.sql @@ -7,9 +7,9 @@ **Нужно:** - указать, какие свойства ACID здесь особенно важны и почему; - АТОМАРНОСТЬ, ДЮРАБИЛИТИ (ОТСУТСТВУЕТ НАДЕЖНОСТЬ У ДАННОЙ ТРАНЗАКЦИИ), СОГЛАСОВАННОСТЬ - НЕЛЬЗЯ ПРОВЕСТИ ОДНУ ОПЕРАЦИЮ И ЗАСЧИТАТЬ ЕЕ ДВАЖДЫ. + СОГЛАСОВАННОЙ ЧЕРЕЗ УНИКАЛЬНЫЙ КЛЮЧ ОБНАРУЖИВАЕТ ПОВТОРНЫЙ ЗАПРОС, А АТОМАРНОСТЬ ГАРАНТИРУЕТ, ЧТО ЭТА НЕУДАВШАЯСЯ ПОПЫТКА НЕ ИЗМЕНИТ БАЛАНС - описать, какие проблемы могут возникнуть, если этих свойств не будет (например, нет атомарности или изолированности). - ЕСЛИ ЭТИХ СВОЙСТВ НЕ БУДЕТ, ТО ПРОИЗОЙДУТ ОШИБКИ, ДВА ОДИНАКОВЫХ ЗАПРОСА ИЛИ НЕИСПОЛНЕНИЕ ЗАПРОСА ВООБЩЕ. + ЕСЛИ ЭТИХ СВОЙСТВ НЕ БУДЕТ, ТО ПРОИЗОЙДУТ ОШИБКИ, ДВА ОДИНАКОВЫХ ЗАПРОСА ИЛИ НЕИСПОЛНЕНИЕ ЗАПРОСА ВООБЩЕ. - **Задание 2. Лента новостей и лайки** diff --git a/dmedvedev/4.4.greenplum_external_tables.sql b/dmedvedev/4.4.greenplum_external_tables.sql index 02f964e..9cf7ebc 100644 --- a/dmedvedev/4.4.greenplum_external_tables.sql +++ b/dmedvedev/4.4.greenplum_external_tables.sql @@ -21,7 +21,7 @@ Greenplum ↔ PXF ↔ Hive Metastore 1. Где реально хранятся данные? ЖАННЫЕ ХРАНЯТСЯ В ХРАНИЛИЩЕ HIVE. 2. Можно ли писать обратно в Hive? - ДА, КОНЕЧНО. + НЕТ, НЕЛЬЗЯ. 3. Что если структура таблицы в Hive изменилась? В ТАКОМ СЛУЧАЕ ПРИ ЗАПРОСЕ МОГУТ БЫТЬ ОШИБКИ ИЛИ ПУСТЫЕ СТОЛБЦЫ СО ЗНАЧЕНИЯМИ, ТАК КАК GREENPLUM НИКАКИМ ОБРАЗОМ НЕ СМОЖЕТ УСЗНАТЬ КАКИЕ ИЗМЕНЕНИЯ ПРОИЗОШЛИ. ПОЭТОМУ НЕОБХОДИМО ПЕРЕСОЗДАТЬ ВНЕШНЮЮ ТАБЛИЦУ ПУТЕМ УДАЛЕНИЯ И СОЗДАНИЯ. @@ -47,4 +47,6 @@ Greenplum ↔ PXF ↔ S3 1. Данные копируются в Greenplum? НЕТ, ДАННЫЕ НЕ КОПИРУЮТСЯ. 2. Что быстрее: EXTERNAL или `CREATE TABLE AS SELECT`? - CREATE TABLE AS SELECT БЫСТРЕЕ, НО МЕНЕЕ ЭФФЕКТИВНЕЕ В ДОЛГУЮ, ТАК КАК РАСХОДУЮТСЯ ОБЪЕМЫ ПАМЯТИ И ДОП МОЩНОСТИ. \ No newline at end of file + ВСЕ ЗАВИСИТ ОТ ЦЕЛЕЙ. + ДЛЯ РАЗОВОГО ИСПОЛЬЗОВАНИЯ МОЖНО ВЫБРАТЬ EXTERNAL, СОЗДАНИЕ ТАБЛИЦЫ БУДЕТ ПРАКТИЧЕСКИЕ МОМЕНТАЛЬНЫМ ПОТОМУ ЧТО СОЗДАЕТСЯ ПРОСТО ССЫЛКА НА ТАБЛИЦУ, А ВОТ ЧТЕНИЕ БУДЕТ НЕ ОЧЕНЬ ЭФФЕКТИВНЫМ. + ДЛЯ МНОГОКРАТНОГО ИСПОЛЬЗОВАНИЯ ЛУЧШЕ ВЫБРАТЬ CTAS, ХОТЬ МЫ И ДОЛГО КОПИРУЕМ (СОЗДАЕМ) ТАБЛИЦУ, ЗАТО ПОСЛЕДУЮЩИЕ ЧАСТЫЕ ОБРАЩЕНИЯ БУДУТ ПРОИСХОДИТЬ ГОРАЗДО БЫСТРЕЕ ЧЕМ ПРИ EXTERNAL. \ No newline at end of file diff --git a/dmedvedev/4.5.greenplum_pet_project.sql b/dmedvedev/4.5.greenplum_pet_project.sql index 5feb6a6..f746c5e 100644 --- a/dmedvedev/4.5.greenplum_pet_project.sql +++ b/dmedvedev/4.5.greenplum_pet_project.sql @@ -1,48 +1,43 @@ --Добавление raw-таблиц в GREENPLUM CREATE TABLE raw.pet_users ( - id INT PRIMARY KEY NOT NULL, - name VARCHAR(50) NOT NULL, + id INT, + name VARCHAR(50), age INT, - email VARCHAR(100) NOT NULL, - registration_date DATE NOT NULL + email VARCHAR(100), + registration_date DATE ); CREATE TABLE raw.pet_courses ( - id INT PRIMARY KEY NOT NULL, - title VARCHAR(100) NOT NULL, - category VARCHAR(50) NOT NULL, - created_at DATE NOT NULL + id INT, + title VARCHAR(100), + category VARCHAR(50), + created_at DATE ); CREATE TABLE raw.pet_lessons ( - id INT PRIMARY KEY NOT NULL, - course_id INT NOT NULL, - FOREIGN KEY (course_id) REFERENCES raw.pet_courses (id), + id INT, + course_id INT, title VARCHAR(50), - duration_min INT NOT NULL + duration_min INT ); CREATE TABLE raw.pet_enrollments ( - id INT PRIMARY KEY NOT NULL, - user_id INT NOT NULL, - FOREIGN KEY (user_id) REFERENCES raw.pet_users (id), - course_id INT NOT NULL, - FOREIGN KEY (course_id) REFERENCES raw.pet_courses (id), - enrolled_at DATE NOT NULL + id INT, + user_id INT, + course_id INT, + enrolled_at DATE ); CREATE TABLE raw.pet_lesson_views ( - id INT PRIMARY KEY NOT NULL, - user_id INT NOT NULL, - FOREIGN KEY (user_id) REFERENCES raw.pet_users (id), - lesson_id INT NOT NULL, - FOREIGN KEY(lesson_id) REFERENCES raw.pet_lessons (id), - viewed_at TIMESTAMPTZ NOT NULL + id INT, + user_id INT, + lesson_id INT, + viewed_at TIMESTAMPTZ ); --Создание core-таблиц (измерений - dimension) в GREENPLUM @@ -105,12 +100,12 @@ CREATE TABLE core.enrollments INSERT INTO core.dim_user (user_id, name, age, email, registration_date) SELECT DISTINCT - user_id::INT, + id::INT, name::TEXT, age::INT, email::TEXT, registration_date::DATE -FROM raw.users; +FROM raw.pet_users; --переброска для dim_course INSERT INTO core.dim_course