📕 Практические кейсы использования ClickHouse для разработчиков, администраторов, специалистов по базам данных, Data engineers, Backend и FullStack-разработчиков

На открытом уроке 24 июля в 20:00 мск мы погрузимся в тонкости работы с ClickHouse:

📗 На вебинаре разберём:
1. Основные принципы работы, архитектура и преимущества использования ClickHouse;
2. Реальные кейсы использования ClickHouse для анализа веб-логов, IoT данных и финансовых транзакций;

📘 В результате на практике разберетесь в настройке и использовании ClickHouse для обработки больших объемов данных.

👉 Регистрация и подробности о курсе NoSQL: https://vk.cc/cNQL7R

Все участники открытого урока получат скидку на курс "NoSQL"

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

Как понять, что вашему проекту нужен полнотекстовый поиск, а не ILIKE

Часто разработчики в PostgreSQL начинают с простого:

SELECT * FROM articles WHERE title ILIKE '%postgres%';

Но уже при 10k+ строк и регулярных запросах начинаются тормоза. Значит, пора на следующий уровень — полнотекстовый поиск.

🔍 Когда ILIKE — плохо:
– Сложные запросы с несколькими ILIKE
– Не масштабируется: без индексов → full scan
– Нет нормализации слов: postgres, PostgreSQL, постгрес — всё разное

💡 Решение: to_tsvector + to_tsquery

SELECT * FROM articles
WHERE to_tsvector('russian', title) @@ to_tsquery('russian', 'postgres');

📈 Плюсы:
– Работают GIN-индексы
– Поддержка морфологии и синонимов
– Быстрее и точнее на больших объемах

⚠️ Подводные камни:
– Нужна настройка языкового словаря
– tsquery не такая гибкая, как regex
– Требуется обновление индекса при INSERT/UPDATE

🛠 Как включить GIN-индекс:

CREATE INDEX idx_articles_title_search
ON articles USING GIN (to_tsvector('russian', title));

👉 Если пользователи ищут по тексту — не тормозите ILIKE, внедряйте полнотекст!

Сохрани, чтобы потом не мучиться с explain-ами 😉

#db

👉 @database_info

Отказоустойчивость от двух нод в облачных базах данных
 
Если вам важна бесперебойная работа вашего проекта, самое время позаботиться об отказоустойчивости. Selectel поможет сделать это проще и выгоднее — у провайдера можно создать отказоустойчивый кластер баз данных всего от двух нод.
 
Выгода очевидна: использование двух нод в кластере вместо стандартных трех позволяет сократить расходы на 33%.
 
Почему это надежно?
 
▪️SLA отказоустойчивого кластера — 99,95% на запись и 99,99% на чтение.
▪️Доступно автоматическое резервное копирование кластера «из коробки» и без доплат. Ежедневно создаются инкрементальные бэкапы, а полные копии кластера — раз в неделю.
▪️Можно создавать реплики в разных сегментах пула для большей надежности. При этом серверы кластера размещаются на разных физических хостах и имеют разные контуры питания.
 
Разверните отказоустойчивые кластеры облачных баз данных в Selectel: https://slc.tl/80ecr

Реклама, АО «Селектел», ИНН: 7810962785, ERID: 2VtzqxjxEBa

🧱 Антипаттерн: использование 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. Удобно и производительно.


#db

👉 @database_info

Хотите узнать секрет оптимизации SQL-запросов?

Очень важно понимать порядок выполнения.
В SQL-запросе операторы выполняются в следующем порядке:

1. FROM / JOIN
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
6. DISTINCT
7. ORDER BY
8. LIMIT / OFFSET

#db

👉 @database_info

Бесплатный курс по PostgreSQL от практиков рынка

Присоединяйтесь к бесплатному курсу по основам PostgreSQL от Selectel и Эльбрус Буткемп. Он будет полезен Junior- и Middle-специалистам: администраторам баз данных, разработчикам, DevOps-инженерам и аналитикам.
 
Вы научитесь:
🔹создавать и связывать таблицы,
🔹выполнять базовые операции с данными,
🔹работать с РСУБД.

Бонусы: вы можете получить сертификат о прохождении курса, а также промокоды для практики на мощностях Selectel.

Начните обучение уже сегодня.

Реклама. АО «Селектел», ИНН 7810962785, ERID: 2VtzqxH9jwE

Индексы в 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 = '[email protected]';

Запрос не будет сканировать всю таблицу — он сразу пойдёт по дереву.

Подводные камни:

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).

Сохрани, чтобы не забыть!

#db

👉 @database_info

Почему Redis такой быстрый (несмотря на однопоточность)?

🔹 Хранение в памяти
Redis хранит все данные в оперативной памяти, где время доступа измеряется наносекундами, а не миллисекундами.

🔹 Однопоточный цикл событий
Redis обрабатывает команды в одном потоке, избегая блокировок, гонок и переключений контекста. Благодаря мультиплексированию ввода-вывода он эффективно обслуживает тысячи одновременных подключений через цикл событий.

🔹 Оптимизированные структуры данных
Redis предоставляет специализированные реализации списков, множеств, отсортированных множеств и хешей, оптимизированные для производительности и экономии памяти.

🔹 Эффективность ввода-вывода
Redis использует лёгкий текстовый протокол RESP для обработки сетевого I/O и поддерживает конвейеризацию, позволяя клиентам отправлять несколько команд в одном запросе.

🔹 Скрипты на стороне сервера
Встроенный движок Lua даёт возможность выполнять сложные многошаговые операции атомарно на сервере, убирая необходимость лишних сетевых запросов.

♻️ Сделай репост, чтобы помочь другим.

#db

👉 @database_info

Базы данных. Школа бэкенд-разработки 2025

На лекции обсудим основные понятия и принципы работы с базами данных. Рассмотрим факторы, влияющие на выбор подходящей базы данных для конкретной задачи. Познакомимся с индексами и их ролью в ускорении запросов. Поделимся советами по оптимальному использованию баз данных и рекомендациями для эффективной работы

источник

#db

👉 @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), обновляй статистику и оптимизируй условия.

Сохрани, чтобы не наступить на этот грабельный индекс 🚀

#db

👉 @database_info

Антипаттерны JOIN-ов в SQL и как их избежать

JOIN - мощная штука, но может легко превратиться в генератор тормозов и дублей. Вот топ-4 ловушек:

1️⃣ Забыли условие соединения

SELECT *
FROM orders
JOIN customers;

Без ON это картезианское произведение - каждая строка первой таблицы умножается на все строки второй. Легко получить миллионы ненужных записей.
✅ Как избежать: Всегда указывай условие соединения.


2️⃣ JOIN по неиндексированным колонкам
Если соединяешь большие таблицы по полю без индекса - готовься ждать.
✅ Как избежать: Добавь индекс на ключи соединения.

CREATE INDEX idx_orders_customer_id ON orders(customer_id);

3️⃣ Фильтры в WHERE вместо ON

-- Плохо
FROM orders
LEFT JOIN customers ON orders.customer_id = customers.id
WHERE customers.region = 'EU';

LEFT JOIN превратился в INNER JOIN, потому что фильтр в WHERE отсекает NULL-строки.
✅ Как избежать: Фильтруй в ON, если хочешь сохранить LEFT JOIN:

LEFT JOIN customers 
  ON orders.customer_id = customers.id AND customers.region = 'EU';

4️⃣ SELECT *** в сложных JOIN-ах
Такая выборка тянет все колонки всех таблиц. Много лишних данных + риск коллизии имён колонок.
✅ Как избежать: Явно указывай нужные поля.


💡 Вывод: JOIN - как скальпель. В умелых руках ускоряет, в неумелых - режет производительность.

Сохрани, чтобы не резануть базу не туда ✂️

#db

👉 @database_info

Немного юмора)

#db

👉 @database_info

Конференция, на которую нужно прийти Data Engineers🔥

23 сентября пройдет Data Internals X 2025 — единственная в России конференция, где создатели СУБД и движков обработки данных делятся опытом работы с реальными production-системами экстремального масштаба. Вас ждёт по-настоящему "хардкорная" программа.

🎯 Глубина технических решений

Программа конференции сфокусирована на внутренних механизмах работы с данными — от разработки СУБД до оптимизации запросов и устойчивости к высоким нагрузкам. Это редкая возможность погрузиться в технические детали, которые обычно остаются за кадром.

🏭 Практический опыт масштабирования

Все доклады основаны на реальном опыте работы с петабайтными данными, высоконагруженными системами и решением production-задач в крупных компаниях (Яндекс, Сбер, VK, Т-Банк).

🔧 Импортозамещение и Open Source

Особый акцент на отечественные решения и open-source технологии, что критически важно в текущих реалиях.

🧠 Концентрированный опыт

Максимум пользы для повышения квалификации за один день: 20+ докладов, рекордная плотность экспертных знаний и нетворкинг с 300+ участниками.

📌Изучить расписание и забронировать билеты на сайте конференции

Приходите сами и приглашайте своих коллег 🔥

До встречи 23 сентября в Москве!