Базы данных (Data Base)

🗄 Нормализация баз данных: от 1NF до 4NF Нормализация помогает правильно организовать данные, избавиться от дублирования и снизить риск ошибок при обновлении таблиц. 🔹 Первая нормальная форма — 1NF Каждая ячейка содержит только одно атомарное значение. Нельзя хранить несколько товаров в одном поле — каждый товар должен находиться в отдельной строке. 🔹 Вторая нормальная форма — 2NF Таблица соответствует 1NF, а каждый неключевой столбец полностью зависит от всего составного первичного ключа. Данные о заказе и его позициях обычно разделяются на разные таблицы. 🔹 Третья нормальная форма — 3NF Устраняются транзитивные зависимости. Например, имя и регион клиента лучше хранить в таблице клиентов, а в заказе оставить только идентификатор клиента. 🔹 Нормальная форма Бойса — Кодда, BCNF Усиленная версия 3NF: любой столбец, от которого зависят другие данные, должен быть потенциальным ключом. 🔹 Четвёртая нормальная форма — 4NF Устраняет независимые многозначные зависимости. Например, навыки сотрудника и его проекты следует хранить в отдельных таблицах. ✅ Результат нормализации — меньше дубликатов, проще обновление данных и более предсказуемая работа базы. А до какой нормальной формы вы обычно доводите структуру БД? #базыданных #SQL #нормализация #database #программирование #разработка 📲 Мы в MAX 👉 @database_info

Почему индекс в PostgreSQL не всегда спасает Индексы - мощный инструмент, но не панацея. Иногда запрос с индексом работает медленнее, чем без него. Почему? 1️⃣ Маленькая выборка - да, полное сканирование - нет Если таблица маленькая (до нескольких тысяч строк), PostgreSQL может решить, что быстрее прочитать всё целиком, чем прыгать по индексу. EXPLAIN ANALYZE SELECT * FROM users WHERE status = 'active'; План покажет Seq Scan, и это не баг. 2️⃣ Индекс не помогает с функциями в WHERE Запрос вида: SELECT * FROM orders WHERE DATE(created_at) = '2025-08-12'; не использует индекс по created_at. Решение — переписать условие: WHERE created_at >= '2025-08-12' AND created_at < '2025-08-13' 3️⃣ Селективность Если по условию отбирается больше ~5–10% строк, индекс становится невыгодным — чтение с диска и так почти сплошное. 4️⃣ Статистика устарела PostgreSQL выбирает план по статистике. Если она старая - план может быть неэффективным. ANALYZE table_name; - и жизнь наладится. 💡 Вывод: Индекс - не магическая кнопка «ускорить». Следи за планами запросов (EXPLAIN), обновляй статистику и оптимизируй условия. Сохрани, чтобы не наступить на этот грабельный индекс 🚀 📲 Мы в MAX #db 👉 @database_info

Почему Redis такой быстрый (несмотря на однопоточность)? 🔹 Хранение в памяти Redis хранит все данные в оперативной памяти, где время доступа измеряется наносекундами, а не миллисекундами. 🔹 Однопоточный цикл событий Redis обрабатывает команды в одном потоке, избегая блокировок, гонок и переключений контекста. Благодаря мультиплексированию ввода-вывода он эффективно обслуживает тысячи одновременных подключений через цикл событий. 🔹 Оптимизированные структуры данных Redis предоставляет специализированные реализации списков, множеств, отсортированных множеств и хешей, оптимизированные для производительности и экономии памяти. 🔹 Эффективность ввода-вывода Redis использует лёгкий текстовый протокол RESP для обработки сетевого I/O и поддерживает конвейеризацию, позволяя клиентам отправлять несколько команд в одном запросе. 🔹 Скрипты на стороне сервера Встроенный движок Lua даёт возможность выполнять сложные многошаговые операции атомарно на сервере, убирая необходимость лишних сетевых запросов. ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX #db 👉 @database_info

Чем отличаются друг от друга блокировки баз данных? В управлении базами данных блокировки — это механизмы, которые предотвращают одновременный доступ к данным, обеспечивая их целостность и согласованность. Основные типы блокировок: 🔴Shared Lock: позволяет нескольким транзакциям одновременно читать ресурс, но не модифицировать его 🔴Exclusive Lock: позволяет транзакции как читать, так и модифицировать ресурс 🔴 Update Lock: используется для предотвращения взаимоблокировки, когда транзакция намеревается обновить ресурс 🔴 Schema Lock: используется для защиты структуры объектов базы данных 🔴 Bulk Update Lock: используется во время массовых вставок 🔴 Key-Range Lock: используется в индексированных данных для предотвращения фантомных чтений 🔴 Row-Level Lock: блокирует конкретную строку в таблице 🔴 Page-Level Lock: блокирует конкретную страницу (фиксированный блок данных) в базе данных 🔴 Table-Level Lock: блокирует всю таблицу 📲 Мы в MAX #db 👉 @database_info

🔒 Почему одна "невинная" транзакция может положить продакшн Классическая ситуация: разработчик открывает транзакцию, делает выборку, потом какой-то API-запрос наружу (например, к платёжному шлюзу), и только потом коммитит. Транзакция висит открытой 3-5 секунд вместо миллисекунд. Локально всё ок, тесты зелёные. В проде — деградация через пару часов. Что происходит под капотом в PostgreSQL (MVCC): 1. VACUUM не может убрать мёртвые строки. Пока жива хоть одна старая транзакция, движок обязан хранить все версии строк, которые теоретически могут быть видны в её snapshot. UPDATE/DELETE копится в виде dead tuples, автовакуум работает, но эффективность падает. 2. Table bloat. Таблица физически растёт, индексы разбухают, страницы всё реже помещаются в shared_buffers — растёт I/O, падает cache hit ratio. 3. xmin horizon не двигается. Это глобальная граница, до которой можно чистить старые версии. Одна зависшая транзакция держит её на месте для ВСЕЙ базы, а не только для своей таблицы. 4. Реплики страдают отдельно. На hot standby с hot_standby_feedback = on долгая транзакция на реплике заставляет primary тоже не вакуумить нужные строки — эффект расползается по кластеру. Как ловить: SELECT pid, now() - xact_start AS duration, query FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC LIMIT 10; Плюс idle in transaction — отдельная категория боли: транзакция открыта, а коннекшен вообще ничего не делает (забыли закоммитить/роллбэкнуть). Лечится через idle_in_transaction_session_timeout. Правило для сеньора: транзакция должна жить ровно столько, сколько нужно для консистентности данных — не больше. Любой сетевой вызов, любая тяжёлая бизнес-логика — только вне транзакции или в отдельном коротком шаге. #postgresql #databases #mvcc 📲 Мы в MAX #db 👉 @database_info

Индексы в PostgreSQL: Часть 1 — B-Tree Если ты создавал индекс в PostgreSQL по умолчанию, значит, это B-Tree. Но как он работает и когда он реально полезен? Что это такое? B-Tree индекс — сбалансированное дерево поиска. PostgreSQL автоматически использует его для: =\` (равенство) > < >= <= (сравнения) BETWEEN LIKE 'abc%' (только префикс, без %abc%). Пример: CREATE INDEX idx_users_email ON users (email); SELECT * FROM users WHERE email = 'test@example.com'; Запрос не будет сканировать всю таблицу — он сразу пойдёт по дереву. Подводные камни: 1. Не работает для произвольных LIKE: LIKE '%abc%' → индекс не поможет. 2. Осторожно с функциями: WHERE LOWER(email) = 'abc' — индекс не используется. Нужен функциональный индекс: CREATE INDEX idx_users_email_lower ON users (LOWER(email)); 3. Многоколонковые индексы: Порядок важен. (a, b) используется при фильтре по a или по a AND b, но не только по b. Когда ставить? - Уникальные поля (email, username). - Часто используемые фильтры и JOIN-колонки. - Сортировки (ORDER BY created_at DESC). Вывод: B-Tree — твой “универсальный солдат”. Но не пихай его на всё подряд. Перед добавлением — смотри EXPLAIN (ANALYZE). Сохрани, чтобы не забыть! 📲 Мы в MAX #db 👉 @database_info

Как упростить работу с кластером через веб‑интерфейс OpenSearch Dashboards Присоединяйтесь к вебинару от Selectel, чтобы разобраться на практике, как развернуть кластер СУБД OpenSearch в облаке за несколько минут и управлять им с помощью веб-интерфейса OpenSearch Dashboards. Узнаете, как легко настроить мониторинг, визуализировать данные и метрики, работать с бэкапами, управлять пользователями и доступами. 📍 Онлайн ⏰ 16 июля в 15:00 👤 Кому будет полезно: сисадминам, архитекторам, администраторам баз данных, бэкэнд-разработчикам, техлидам Регистрируйтесь ➡️ https://slc.tl/3po0z Больше мероприятий для ИТ-специалистов в канале @selectel_events. Подписывайтесь! Реклама. АО "Селектел". erid:2W5zFK5Svmo

Хотите узнать секрет оптимизации SQL-запросов? Очень важно понимать порядок выполнения. В SQL-запросе операторы выполняются в следующем порядке: 1. FROM / JOIN 2. WHERE 3. GROUP BY 4. HAVING 5. SELECT 6. DISTINCT 7. ORDER BY 8. LIMIT / OFFSET 📲 Мы в MAX #db 👉 @database_info

🧱 Антипаттерн: использование UUID как Primary Key без оглядки На первый взгляд, UUID — классный способ генерировать уникальные идентификаторы: – не зависят от последовательности – удобны для распределённых систем – безопасны для внешнего экспонирования Но если ты просто заменишь SERIAL или BIGINT на UUID в качестве PK — жди сюрпризов: ❌ В чём подвох: – Производительность INSERT'ов резко падает: UUID случайные → нет locality → индекс (обычно B-Tree) постоянно фрагментируется – Индексы пухнут: UUID = 16 байт, BIGINT = 8 байт. Разница кажется небольшой, но на больших объёмах — это боль – Чтение медленнее: за счёт увеличенного размера индексов и меньшего кэш-хита ✅ Как избежать: 1. Если нет жёсткой необходимости в UUID — не используй их как PK 2. Нужен UUID? Сделай его вторичным индексом, а PK оставь автоинкрементным 3. Или хотя бы используй UUID v7 (новый стандарт с time-based префиксом) — он улучшает локальность по сравнению с v4 Пример: CREATE TABLE users ( id BIGSERIAL PRIMARY KEY, public_id UUID DEFAULT gen_random_uuid() UNIQUE, name TEXT ); → Внутри БД — быстрый BIGINT, → Для внешних API — UUID. Удобно и производительно. 📲 Мы в MAX #db 👉 @database_info

Что мощнее — S3 или локальные диски? Разбираем сценарии использования S3-хранилища в связке с Postgres Pro На вебинаре узнаете о лучших практиках эксплуатации в продакшн-средах. Эксперты Selectel и Postgres Pro разберут все: от резервного копирования через pg_probackup и S3 Selectel до хранения паркетных данных с Postgres Pro AXE и результатов TPC-тестов. Особенно интересно будет архитекторам, техлидам и всем, кто отвечает за надежность и экономику хранения данных. 📍 Онлайн ⏰ 14 июля в 12:00 Регистрируйтесь ➡️ https://slc.tl/hh3pe Больше мероприятий для ИТ-специалистов в канале @selectel_events. Подписывайтесь! Реклама. АО "Селектел". erid:2W5zFJxhbub