Базы Данных (Data Base) | SQL & NoSQL. PostgreSQL, MySQL и Big Data. Уроки для Backend и Data Engineer. Архитектура БД, Оптимизация и Design.

⚡️ Индексы в базах данных: как заставить запросы летать

Представь, что тебе нужно найти нужную главу в техническом справочнике на 1000 страниц. Без оглавления придется листать всё подряд (в базах данных это называется Full Table Scan - страшный сон любого админа). Индекс - это и есть то самое оглавление.

Как это работает под капотом?
Чаще всего индексы строятся на основе B-деревьев (B-Tree) или хэш-таблиц. Суть в том, что БД создает отдельную компактную структуру данных, где значения нужной колонки заранее отсортированы, а рядом лежат быстрые указатели на физическое расположение строк на диске.

✅ Зачем нужны:

* Скорость поиска (SELECT с условием WHERE) возрастает в сотни раз.
* Мгновенно ускоряются операции сортировки (ORDER BY) и связывания таблиц (JOIN).

❌ Чем платим (минусы):

* Тормоза при записи: при каждом INSERT, UPDATE или DELETE базе приходится перестраивать индекс.
* Место на диске: индексы хранятся на диске и съедают оперативную память (RAM). Иногда массивные индексы весят больше, чем сами данные таблицы.

🛠 Чек-лист: индексировать или нет?

🟢 Обязательно индексируем:

1. Колонки, которые постоянно светятся в WHERE, JOIN, ORDER BY, GROUP BY.
2. Внешние ключи (Foreign Keys). Первичные (Primary Keys) СУБД индексирует автоматически.
3. Столбцы с высокой уникальностью значений (ID пользователей, email, артикулы).

🔴 НЕ индексируем:

1. Крошечные таблицы-справочники (прочитать их целиком быстрее, чем дергать индекс).
2. Колонки с низкой уникальностью значений (например, пол или статус active/inactive - индекс по ним практически бесполезен).
3. Таблицы с интенсивной записью (например, логирование). Индексы там убьют производительность INSERT.

💡Не создавай индексы «на всякий случай». Лови медленные запросы, читай вывод EXPLAIN (или EXPLAIN ANALYZE) и добавляй индексы только там, где они реально решают проблему.

#db

👉 @database_info

🦾 LLM умеют генерировать тексты, отвечать на вопросы и работать с документами. Но чтобы использовать их в реальных задачах, важно понимать, как модели принимают решения и почему иногда дают неожиданный результат.

🚀 На открытом уроке разберём, как устроены большие языковые модели и как применять эти знания на практике. Вы узнаете:

— как модель выбирает слова и формирует ответ;
— как развернуть LLM локально и проверить её работу через API;
— как модели используют контекст из документов и почему это важно для RAG-систем.

Урок подойдет начинающим разработчикам, аналитикам и менеджерам продукта, которые хотят понимать ИИ глубже и использовать его в рабочих задачах. Открытый урок проходит в преддверии старта курса «LLM-инженер».

📋 27 октября в 20:00 МСК.
➡️ Все участники получат скидку на обучение. Принять участие: https://vk.cc/d2Romz

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Антипаттерн: Ненормализованная схема в SQL

Когда нужно «быстро запилить фичу», руки тянутся сделать одну таблицу, где и заказ, и клиент, и товары — всё в куче.

Пример:

CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_email TEXT,
product_1_name TEXT,
product_1_price NUMERIC,
product_2_name TEXT,
product_2_price NUMERIC
);

😰 Что пойдет не так:

– Дублирование данных — имя клиента повторяется в каждом заказе.
– Нет масштабируемости — максимум 2 продукта? А если будет 3?
– Трудности с запросами — попробуй посчитать топ-5 товаров. Удачи.
– Адские апдейты — изменить email клиента надо во всех заказах.

✅ Как правильно:

1. Нормализуй. Раздели данные на сущности: customers, orders, products, order_items.
2. Используй внешние ключи.
3. Не бойся JOIN'ов — они для этого и придуманы.

Пример нормализованной структуры:

-- Таблица клиентов
CREATE TABLE customers (
id SERIAL PRIMARY KEY,
name TEXT,
email TEXT
);

-- Таблица заказов
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(id)
);

-- Таблица товаров
CREATE TABLE products (
id SERIAL PRIMARY KEY,
name TEXT,
price NUMERIC
);

-- Связка товаров и заказов
CREATE TABLE order_items (
order_id INT REFERENCES orders(id),
product_id INT REFERENCES products(id),
quantity INT
);

📌 Да, нормализация требует чуть больше времени. Зато потом вы не утонете в хаосе.

Сохрани, чтобы не забыть — и не повторять чужих ошибок.

#db

👉 @database_info