6213
Базы данных (Data Base). По всем вопросам @evgenycarter
Отказоустойчивость от двух нод в облачных базах данных
Если вам важна бесперебойная работа вашего проекта, самое время позаботиться об отказоустойчивости. Selectel поможет сделать это проще и выгоднее — у провайдера можно создать отказоустойчивый кластер баз данных всего от двух нод.
Выгода очевидна: использование двух нод в кластере вместо стандартных трех позволяет сократить расходы на 33%.
Почему это надежно?
▪️SLA отказоустойчивого кластера — 99,95% на запись и 99,99% на чтение.
▪️Доступно автоматическое резервное копирование кластера «из коробки» и без доплат. Ежедневно создаются инкрементальные бэкапы, а полные копии кластера — раз в неделю.
▪️Можно создавать реплики в разных сегментах пула для большей надежности. При этом серверы кластера размещаются на разных физических хостах и имеют разные контуры питания.
Разверните отказоустойчивые кластеры облачных баз данных в Selectel: https://slc.tl/80ecr
Реклама, АО «Селектел», ИНН: 7810962785, ERID: 2VtzqxjxEBa
📕 Практические кейсы использования ClickHouse для разработчиков, администраторов, специалистов по базам данных, Data engineers, Backend и FullStack-разработчиков
На открытом уроке 24 июля в 20:00 мск мы погрузимся в тонкости работы с ClickHouse:
📗 На вебинаре разберём:
1. Основные принципы работы, архитектура и преимущества использования ClickHouse;
2. Реальные кейсы использования ClickHouse для анализа веб-логов, IoT данных и финансовых транзакций;
📘 В результате на практике разберетесь в настройке и использовании ClickHouse для обработки больших объемов данных.
👉 Регистрация и подробности о курсе NoSQL: https://vk.cc/cNQL7R
Все участники открытого урока получат скидку на курс "NoSQL"
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Антипаттерн: использование SELECT * в продакшене
Кажется безобидным, правда? Особенно на этапе прототипирования. Но как только ваш запрос с SELECT * уходит в прод, начинаются проблемы:
🔻 Почему это плохо:
– Избыточные данные. Вы тянете всё, включая ненужные поля. Это бьёт по сети, памяти и CPU.
– Ломкость кода. Добавили колонку в таблицу — и, внезапно, старый код падает, потому что ожидал другую структуру.
– Плохая читаемость. Непонятно, какие поля реально нужны. Это мешает отладке и сопровождению.
– Невозможно использовать covering index — индекс по нужным колонкам не спасёт, если вы вытаскиваете всё подряд.
📌 Как правильно:
✅ Явно указывайте нужные поля:
SELECT id, name, created_at FROM users;
select() или .only() (в зависимости от фреймворка).SELECT * в проде? Или, может, сам когда-то писал так?
❌ Антипаттерн: UUID как PK без учёта последствий
Выглядит красиво: глобально уникальный идентификатор, можно генерировать на клиенте, удобно в распределённых системах. Но...
💣 Проблемы:
– Большой размер (16 байт vs 4 байта у INT)
– Плохая локальность: индекс B-Tree фрагментируется
– Медленнее вставки, особенно при высоких нагрузках
– Нагружает сеть, если часто передаёшь PK
📉 В PostgreSQL это особенно заметно: индекс на UUID-ключе может вести себя гораздо хуже, чем на BIGSERIAL.
✅ Как делать правильно:
1. Если всё в одной БД: используй BIGINT или BIGSERIAL
2. Если нужен UUID:
– генерируй UUID v7 (появился в 2022, содержит компонент времени → лучше упорядочен)
– либо UUID v1 (временной, но с оговорками по безопасности)
– или комбинируй автоинкремент + случайный суффикс
3. Храни UUID как UUID, а не как VARCHAR(36) — это экономит место и CPU
🧠 UUID — мощный инструмент, но не серебряная пуля. Прежде чем делать его PRIMARY KEY, подумай: что ты реально выигрываешь?
Сохрани, чтобы не собирать фрагментированные индексы вручную 😅
#db
👉 @database_info
SQL vs NoSQL: что выбрать для реального проекта?
Один из самых частых вопросов:
«Нам вообще SQL нужен? Может, сразу MongoDB?»
Разберёмся коротко и по делу 👇
🔷 SQL (PostgreSQL, MySQL, etc.)
Плюсы:
– Строгая схема → меньше ошибок на проде
– Сложные запросы (JOIN, агрегаты) — легко
– ACID-гарантии → важно для денег, заказов, логистики
– Большое комьюнити, mature-тулинги, репликация, индексы
Когда выбирать:
✅ Чёткая структура данных
✅ Много взаимосвязей (нормализация)
✅ Сложные аналитические выборки
✅ Транзакции критичны
🔶 NoSQL (MongoDB, Redis, DynamoDB, etc.)
Плюсы:
– Гибкая схема (можно быстро пихать JSON как есть)
– Горизонтальное масштабирование — встроено
– Подходит для high-load, real-time, event-based систем
Когда выбирать:
✅ Частые изменения структуры данных
✅ Скорость важнее связности
✅ Огромные объёмы с минимальными связями
✅ Event storage, логирование, IoT, временные данные
❗️Частые ошибки:
– "Берём Mongo, потому что модно" — а потом страдаем с джоинами руками
– "Только SQL, потому что так всегда делали" — и не справляемся с масштабом
🔧Часто лучший вариант — гибрид.
Например:
– PostgreSQL → для core бизнес-логики
– Redis → для кеша
– MongoDB → для логов или гибких анкет
Вывод:
Никто не лучше сам по себе. Всё зависит от данных и задач.
А ты чем пользуешься чаще — SQL или NoSQL?
Поделись с командой, если на старте нового проекта 🧠
#db
👉 @database_info
⚡️Пошаговый план: как стать аналитиком данных в 2025
Хотите попасть в аналитику, но теряетесь в море информации и не понимаете, какие навыки действительно важны? Боитесь, что без опыта вас не возьмут на работу? И да, ещё один популярный вопрос — а что, если мне 30/40/50+ лет?
Андрон Алексанян — эксперт по аналитике с 8 летним опытом и по совместительству CEO Simulative — покажет рабочие схемы и четкий план, как устроиться в аналитику быстрее, даже если у вас нет опыта.
Что будет на вебинаре?
🟠 Разберем полный роадмап: что учить, в каком порядке, до какого уровня;
🟠 Лайфхаки трудоустройства:
— Покажем реальные примеры, как оформить резюме и портфолио, чтобы привлекать внимание;
— Обсудим какие отклики работают, а какие сразу отправляют в корзину;
— Изнанка найма: инсайдерский взгляд на процессы отбора
🟠 Практические техники для новичков: разберём, как компенсировать недостаток опыта и быстро закрывать пробелы в знаниях.
🕗 Важно досмотреть вебинар до конца, чтобы получить бонус от нас, который поможет бустануть карьеру.
😶Зарегистрироваться на бесплатный вебинар
Мини-гайд: VACUUM в PostgreSQL — когда, зачем и как?
PostgreSQL не удаляет строки сразу при DELETE или UPDATE. Вместо этого они помечаются как "мертвые", а данные продолжают занимать место. Со временем таблицы раздуваются, индексы тормозят, запросы тянут ресурсы.
⠀
💡 VACUUM — инструмент для уборки "мусора" и поддержания БД в форме.
Варианты:
VACUUM — убирает мусор, но не возвращает место ОС.
VACUUM FULL — перезаписывает таблицу и реально освобождает диск (но блокирует таблицу!).
ANALYZE — обновляет статистику планировщика запросов.
VACUUM ANALYZE — два в одном: чистка + статистика.
Когда запускать вручную?
– Если autovacuum не справляется (часто видно по pg_stat_user_tables).
– После больших батчевых удалений/обновлений.
– Перед бэкапом (особенно VACUUM FULL для экономии места).
⠀
Пример:
VACUUM VERBOSE my_table;
VACUUM FULL my_table;
FULL — он тяжёлый.autovacuum под нагрузки: autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor и т.д.pgstattuple и pg_bloat_check.
Как выполняется SQL-запрос в базе данных?
#db
👉 @database_info
🎯 Типы баз данных — кратко и по делу
Выбирая базу данных для проекта, важно понимать их ключевые особенности. Ниже — наглядная классификация:
🔷 Реляционные (Relational)
Классика: таблицы со строгими схемами и связями.
📌 ACID, SQL, целостность данных
📌 Идеальны для: финансов, e-commerce, CRM, ERP, банков и инвентаризации
🔷 Документные (Document)
Гибкие NoSQL-базы на основе JSON-документов
📌 Горизонтальное масштабирование, вложенные структуры
📌 Подходят для: CMS, каталогов, мобильных и веб-приложений
🔷 In-Memory
Хранят данные в оперативной памяти — максимум скорости
📌 Используются как кэш, для сессий, real-time аналитики
📌 Примеры: Redis, Memcached
🔷 Графовые (Graph)
Работают с узлами и связями — мощные запросы по связности
📌 Идеальны для соцсетей, рекомендаций, мошеннических схем
📌 Пример: Neo4j
🔷 Временные (Time-Series)
Оптимизированы под работу с временными метками
📌 Подходят для метрик, IoT, логов, финансовых данных
📌 Примеры: InfluxDB, TimescaleDB
🔷 Пространственные (Spatial)
Работают с геоданными и координатами
📌 Используются в GIS, логистике, экологии, городском планировании
🔷 Колончатые (Columnar)
Хранят данные по колонкам — супер для аналитики
📌 Быстрые агрегации, параллельная обработка
📌 Используются в BI, отчетах, хранилищах данных
📌 Пример: ClickHouse
🔷 Ключ-Значение (Key-Value)
Простые NoSQL-базы — пара ключ-значение
📌 Идеальны для кэшей, предпочтений, сессий
📌 Примеры: Redis, DynamoDB
🔍 Правильный выбор базы — залог производительности и масштабируемости проекта.
#db
👉 @database_info
Антипаттерн: N+1 запросов и как его избежать
Что такое N+1?
При выборке связанных данных ORM (или вручную) сначала делается 1 запрос за основными записями, а потом N дополнительных — по одной для каждой записи, чтобы получить связанные объекты. Например, получить 10 пользователей и для каждого — список их заказов ⇒ 1 запрос к users + 10 запросов к orders. 🚩
# SQLAlchemy-пример “N+1”:
users = session.query(User).all() # 1 запрос
for u in users:
print(u.orders) # для каждого пользователя — отдельный запрос
# SQLAlchemy, joinedload — делает JOIN и подтягивает данные сразу
from sqlalchemy.orm import joinedload
users = session.query(User).options(joinedload(User.orders)).all()
for u in users:
print(u.orders) # не генерирует дополнительных запросов
-- 1: получить user_id
SELECT id FROM users WHERE active = true;
-- 2: получить все заказы для этих пользователей
SELECT * FROM orders WHERE user_id IN (...список id...);
LIMIT/OFFSET или курсоры.
📕 Сравнение индексации в PostgreSQL и ClickHouse для разработчиков, администраторов баз данных, инженеров и аналитиков данных
На открытом уроке 3 июня в 20:00 мск мы обсудим различия в механизмах индексации между PostgreSQL и ClickHouse:
📗 На вебинаре разберём:
1. Основы и сравнение производительности разных подходов к индексации;
2. Для каких сценариев распространено использование этих подходов;
📘 В результате на практике разреберете и сравните подходы, производительность и архитектуру индексации PostgreSQL и ClickHouse.
👉 Регистрация и подробности о курсе ClickHouse для инженеров и архитекторов БД: https://vk.cc/cMuQbb
Все участники открытого урока получат скидку на курс "ClickHouse для инженеров и архитекторов БД"
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Мини-гайд: Как не превратить индексы в PostgreSQL в ловушку для производительности
Добавил пару-тройку индексов — стало быстрее? Отлично! Но помни: индексы — это не бесплатная магия. Вот что важно учитывать:
1. Индексы ускоряют SELECT, но тормозят INSERT/UPDATE/DELETE.
Каждая модификация данных требует обновления всех связанных индексов. Чем их больше — тем медленнее запись.
2. Следи за “мертвыми” индексами.
Иногда индексы создают “на всякий случай”, а потом не используют. PostgreSQL сам не удаляет неиспользуемые индексы. Проверь через
SELECT * FROM pg_stat_user_indexes WHERE idx_scan = 0;
idx_scan ноль, пора чистить!
Кейс: Тонкости работы с транзакциями в распределённых БД
Многие знают, что ACID — основа транзакций в классических СУБД. Но как только переходишь к распределённым решениям (например, CockroachDB, Yugabyte, Spanner), возникают интересные нюансы.
Проблема:
В распределённой БД транзакции могут “подвисать” из-за сетевых задержек, split-brain, clock skew и частых реконнектов между узлами. Строгая согласованность (strong consistency) может негативно влиять на производительность и отклик.
Типичные сложности:
– Distributed deadlocks (где одна часть транзакции ждёт другую через сеть)
– Аномалии времени (например, при использовании синхронизации через NTP)
– Цена глобального commit (двухфазный коммит медленный, а трифазный сложный)
Best practices:
– Минимизируй объём данных внутри одной транзакции
– Используй idempotent-операции, чтобы безопасно повторять неудачные транзакции
– Если возможно, проектируй систему под eventual consistency и асинхронные паттерны (saga, outbox)
– Следи за timeouts и обрабатывай partial failures (например, через retry с exponential backoff)
Кодовый пример (Saga-паттерн для микросервисов):
# Пример на псевдокоде
try:
step1()
step2()
step3()
except Exception:
compensating_action()
Индексы в PostgreSQL: когда и как ставить, чтобы ускорить запросы
🔍 Что такое индекс?
Индекс в PostgreSQL — это структура данных (обычно B-tree), позволяющая быстро находить строки по значению столбца, не сканируя всю таблицу.
⚙️ Пример создания простого B-tree-индекса
-- Ускоряем поиск по полю email
CREATE INDEX idx_users_email
ON users (email);
BTREE — по умолчанию, для большинства операций сравнения (=, <, >, BETWEEN).GIN/GiST — для полнотекстового поиска (tsvector), работы с массивами и геоданных.HASH — для строго равенств (=), но редко нужен.
SELECT * FROM orders
WHERE user_id = 42
ORDER BY created_at DESC;
CREATE INDEX idx_orders_user_created
ON orders (user_id, created_at DESC);
pg_stat_user_indexes и pg_stat_user_tables через pg_stat_statements перед добавлением.
CREATE INDEX idx_active_users_email
ON users (email)
WHERE active = true;
REINDEX или VACUUM ANALYZE для больших таблиц, чтобы индекс не фрагментировался.
-- Плохо: много маленьких индексов, мало пользы, много затрат
CREATE INDEX idx1 ON table(a);
CREATE INDEX idx2 ON table(b);
CREATE INDEX idx3 ON table(c);
...
❌ Антипаттерн: булевы значения как строки
В таблице users встречал такое:
is_active VARCHAR(5) -- значения 'true' или 'false'
'tru', 'yes', '0',BOOLEAN,
is_active BOOLEAN DEFAULT true
WHERE is_activeCOUNT(*) FILTER (WHERE is_active) для отчётовENUM, а не строку.
Как понять, что вашему проекту нужен полнотекстовый поиск, а не ILIKE
Часто разработчики в PostgreSQL начинают с простого:
SELECT * FROM articles WHERE title ILIKE '%postgres%';
ILIKE — плохо:ILIKEpostgres, PostgreSQL, постгрес — всё разноеto_tsvector + to_tsquery
SELECT * FROM articles
WHERE to_tsvector('russian', title) @@ to_tsquery('russian', 'postgres');
tsquery не такая гибкая, как regex
CREATE INDEX idx_articles_title_search
ON articles USING GIN (to_tsvector('russian', title));
ILIKE, внедряйте полнотекст!
🔴 Антипаттерн: игнорирование поведения NULL в SQL
Когда ты пишешь WHERE column != 'value', ты можешь думать, что фильтруешь всё, что не равно 'value'. Но если в колонке есть NULL, такие строки выпадут из выборки. Почему? Потому что NULL != 'value' даёт… UNKNOWN, а не TRUE.
❌ Пример проблемы:
SELECT * FROM users
WHERE status != 'active';
status у кого-то NULL — он не попадёт в результат. Неочевидно, но критично.
SELECT * FROM users
WHERE status != 'active' OR status IS NULL;
SELECT * FROM users
WHERE COALESCE(status, '') != 'active';
=: NULL = 'value' → UNKNOWNCOUNT, AVG`) тоже игнорируют `NULL — помни об этом при аналитикеNULL. Пиши явный код, особенно в проде.
Почему одна и та же БД летает на staging и тормозит в проде
Знакомо? На staging сервере — отклик 100мс, на проде — секундные таймауты. Хотя база одна и та же, схема такая же. Что не так?
Вот 5 частых причин:
1. Разный объём данных
На staging — 10k строк, на проде — 10 млн. Индексы, которые "и так нормально", внезапно перестают справляться.
2. Отсутствие/различие индексов
DevOps мог не раскатить нужные индексы в прод. Или, наоборот, staging набит экспериментальными индексами.
3. Параметры конфигурации БД
work_mem, shared_buffers, max_connections — часто в staging минимальны, но в проде тоже забывают подкрутить.
4. Статистика устарела
На проде реже делается ANALYZE, планировщик начинает строить неэффективные планы. Итог — ползёт.
5. Разное поведение приложения
Прод нагружается параллельно десятками потоков. Staging — ты и Postman.
🛠 Что делать:
– Сравни настройки сервера (SHOW ALL;)
– Проверь EXPLAIN ANALYZE
– Не доверяй staging — тестируй на продоподобных данных
#db
👉 @database_info
📕 Архитектура и дизайн систем на основе NoSQL в облаках для разработчиков, администраторов, специалистов по базам данных, Data engineers, Backend и FullStack-разработчиков
На открытом уроке 10 июля в 20:00 мск мы погрузимся в тонкости работы с системами на основе NoSQL в облачных средах:
📗 На вебинаре разберём:
1. Основы NoSQL и его применение в облачных средах;
2. Реальные примеры и кейсы использования NoSQL в облаках;
📘 В результате на практике разберетесь в настройке и развертывании NoSQL баз данных в популярных облачных платформах (Сберклауд, Яндекс Облако, AWS, Google Cloud, Azure) и освоите применение основных операции с данными, масштабирования и управления производительностью NoSQL.
👉 Регистрация и подробности о курсе NoSQL: https://vk.cc/cNsUyb
Все участники открытого урока получат скидку на курс "NoSQL"
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Какой тип индекса выбрать в PostgreSQL?
Индексы — мощный инструмент для ускорения запросов, но не все они одинаково полезны. В PostgreSQL есть несколько типов индексов, и вот как не промахнуться с выбором:
🔹 B-tree (по умолчанию)
📌 Лучший выбор для: =, <, >, BETWEEN, ORDER BY.
✅ Поддерживает сортировку.
💡 Используется в 90% случаев.
CREATE INDEX idx_users_name ON users(name);
=.LIKE.=.
CREATE INDEX idx_users_email_hash ON users USING hash(email);
jsonb, full-text search.
CREATE INDEX idx_data_tags ON posts USING gin(tags);
tsvector.
CREATE INDEX idx_events_location ON events USING gist(location);
CREATE INDEX idx_logs_timestamp ON logs USING brin(timestamp);
Антипаттерн: значения по умолчанию NULL везде, где можно
Кажется безобидным: "Ну не знаю я сейчас значение — пусть будет NULL". Но потом:
– Джоины начинают возвращать меньше строк, чем ты ожидал.
– WHERE column = 'X' не находит ничего, потому что там NULL.
– COUNT(column) искажает статистику.
– IS NULL и COALESCE() плодятся по всему коду.
🧱 В чем корень проблемы?
По умолчанию большинство СУБД позволяют NULL, если явно не указано NOT NULL. Это приводит к схеме, где половина полей может быть «ничем», хотя такого смысла в данных нет.
📌 Как избежать?
1. Всегда указывай NOT NULL, если поле обязательно.
2. Думай, нужен ли NULL вообще. Иногда лучше завести отдельный флаг или значение по умолчанию (например, '' или 0).
3. Добавляй ограничения (CHECK), если значение должно быть в определённом диапазоне.
4. Следи за миграциями — новые поля по умолчанию тоже могут быть NULL.
✅ Вывод:
Проектируя схему, подходи к NULL осознанно. Это не просто "ничего" — это потенциальная боль при запросах и анализе.
Сохрани, чтобы не зарываться в NULL -хаос спустя полгода разработки!
#db
👉 @database_info
🚀 Подборка Telegram каналов для программистов
Системное администрирование, DevOps 📌
/channel/bash_srv Bash Советы
/channel/win_sysadmin Системный Администратор Windows
/channel/sysadmin_girl Девочка Сисадмин
/channel/srv_admin_linux Админские угодья
/channel/linux_srv Типичный Сисадмин
/channel/devopslib Библиотека девопса | DevOps, SRE, Sysadmin
/channel/linux_odmin Linux: Системный администратор
/channel/devops_star DevOps Star (Звезда Девопса)
/channel/i_linux Системный администратор
/channel/linuxchmod Linux
/channel/sys_adminos Системный Администратор
/channel/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
/channel/sysadminof Книги для админов, полезные материалы
/channel/i_odmin Все для системного администратора
/channel/i_odmin_book Библиотека Системного Администратора
/channel/i_odmin_chat Чат системных администраторов
/channel/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
/channel/sysadminoff Новости Линукс Linux
1C разработка 📌
/channel/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
/channel/DevLab1C 1С:Предприятие 8
/channel/razrab_1C 1C Разработчик
/channel/buh1C_prog 1C Программист | Бухгалтерия и Учёт
/channel/rabota1C_rus Вакансии для программистов 1С
Программирование C++📌
/channel/cpp_lib Библиотека C/C++ разработчика
/channel/cpp_knigi Книги для программистов C/C++
/channel/cpp_geek Учим C/C++ на примерах
Программирование Python 📌
/channel/pythonofff Python академия.
/channel/BookPython Библиотека Python разработчика
/channel/python_real Python подборки на русском и английском
/channel/python_360 Книги по Python
Java разработка 📌
/channel/BookJava Библиотека Java разработчика
/channel/java_360 Книги по Java Rus
/channel/java_geek Учим Java на примерах
GitHub Сообщество 📌
/channel/Githublib Интересное из GitHub
Базы данных (Data Base) 📌
/channel/database_info Все про базы данных
Мобильная разработка: iOS, Android 📌
/channel/developer_mobila Мобильная разработка
/channel/kotlin_lib Подборки полезного материала по Kotlin
Фронтенд разработка 📌
/channel/frontend_1 Подборки для frontend разработчиков
/channel/frontend_sovet Frontend советы, примеры и практика!
/channel/React_lib Подборки по React js и все что с ним связано
Разработка игр 📌
/channel/game_devv Все о разработке игр
Библиотеки 📌
/channel/book_for_dev Книги для программистов Rus
/channel/programmist_of Книги по программированию
/channel/proglb Библиотека программиста
/channel/bfbook Книги для программистов
БигДата, машинное обучение 📌
/channel/bigdata_1 Big Data, Machine Learning
Программирование 📌
/channel/bookflow Лекции, видеоуроки, доклады с IT конференций
/channel/rust_lib Полезный контент по программированию на Rust
/channel/golang_lib Библиотека Go (Golang) разработчика
/channel/itmozg Программисты, дизайнеры, новости из мира IT
/channel/php_lib Библиотека PHP программиста 👨🏼💻👩💻
/channel/nodejs_lib Подборки по Node js и все что с ним связано
/channel/ruby_lib Библиотека Ruby программиста
/channel/lifeproger Жизнь программиста. Авторский канал.
QA, тестирование 📌
/channel/testlab_qa Библиотека тестировщика
Шутки программистов 📌
/channel/itumor Шутки программистов
Защита, взлом, безопасность 📌
/channel/thehaking Канал о кибербезопасности
/channel/xakep_2 Хакер Free
Книги, статьи для дизайнеров 📌
/channel/ux_web Статьи, книги для дизайнеров
Математика 📌
/channel/Pomatematike Канал по математике
/channel/phis_mat Обучающие видео, книги по Физике и Математике
/channel/matgeoru Математика | Геометрия | Логика
Excel лайфхак📌
/channel/Excel_lifehack
/channel/mir_teh Мир технологий (Technology World)
Вакансии 📌
/channel/sysadmin_rabota Системный Администратор
/channel/progjob Вакансии в IT
📕 Управление ресурсами в ClickHouse для разработчиков, администраторов баз данных, инженеров и аналитиков данных
На открытом уроке 17 июня в 20:00 мск мы разберем тонкости управления ресурсами и профилирования запросов в ClickHouse:
📗 На вебинаре разберём:
1. Методы управления ресурсами в ClickHouse: настройка квот, ограничений и профилей пользователей;
2. Детальное профилирование запросов для выявления узких мест и оптимизации их выполнения;
📘 В результате на практике разберете важные аспекты для обеспечения высокой производительности и стабильности работы системы в ClickHouse.
👉 Регистрация и подробности о курсе ClickHouse для инженеров и архитекторов БД: https://vk.cc/cMSOpO
Все участники открытого урока получат скидку на курс "ClickHouse для инженеров и архитекторов БД"
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Мини-гайд по трём ключевым сущностям PostgreSQL: соединения, буфер и WAL
1. Соединения (Connections)
PostgreSQL по умолчанию позволяет одновременно до 100 соединений (max_connections).
🔹 Проблема: слишком много прямых соединений создают нагрузку на память и CPU.
🔹 Решение: используйте пуллинг через PgBouncer или Pgpool-II.
[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb
[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
pool_mode = transaction
max_client_conn = 500
default_pool_size = 20
max_connections < 200 и масштабируйте через пуллер.shared_buffers – основной буфер кэша:
shared_buffers = 4GB # ≈25% от RAM на выделенном сервере
work_mem – память на сортировку/слияние одного потока:
work_mem = 64MB # для сложных запросов с сортировками и хэш-джоинами
maintenance_work_mem = 512MB # для VACUUM/CREATE INDEX
shared_buffers ≈ 25% RAM.work_mem исходя из числа параллельных операций, не превышайте общий объём памяти.wal_level – детальность логирования:
wal_level = replica # для потоковой репликации
checkpoint_timeout и max_wal_size:
checkpoint_timeout = 10min
max_wal_size = 1GB
archive_mode = on
archive_command = 'cp %p /mnt/backup/wal/%f'
max_wal_size, если у вас большие всплески нагрузки.
NoSQL vs SQL в реальных проектах
Краткий обзор
SQL (реляционные СУБД): данные хранятся в таблицах со строго заданной схемой (schema-on-write). Пример: PostgreSQL, MySQL, Oracle.
NoSQL (нереляционные СУБД): гибкие модели данных (документ, ключ–значение, граф, колоночные) и отсутствие жёсткой схемы (schema-on-read). Пример: MongoDB (документы), Redis (ключ–значение), Cassandra (колоночная), Neo4j (граф).
➡️Читать статью
#db
👉 @database_info
Продвинутые методы оптимизации запросов в PostgreSQL: профилирование, планирование и тюнинг
1. Профилирование производительности: не догадки, а данные
2. План выполнения: глубокий анализ и вмешательство
3. Индексы: beyond B-tree
4. Умные техники партиционирования и кластеризации
5. Расширенные приёмы оптимизации на уровне SQL
6. Архитектурные паттерны и практический пример
7. Мониторинг и поддержка на «зрелом» этапе
➡️Читать статью
#db
👉 @database_info
Почему мы решили писать собственный Object Storage для новой платформы MWS?
🔗Рассказываем в статье в хабе DevCloud от MWS на Хабр
Вы узнаете:
⏺️Почему нам не подошли даже зрелые решения вроде Ceph RGW
⏺️С какими техническими ограничениями и компромиссами мы столкнулись при оценке альтернатив
⏺️Как устроено наше собственное S3-совместимое хранилище — и зачем мы вообще его делаем
⏺️Как архитектура с Golang, PostgreSQL и Kafka даёт гибкость и масштабируемость
⏩️Подписаться на хаб
🔗 Сравнение: Типы JOIN в SQL и когда их применять
Зачем понимать JOIN’ы?
Правильный выбор типа соединения таблиц позволяет получать необходимые данные эффективно и избегать неожиданных «пустых» или дублирующихся строк.
1. Основные типы JOIN и их поведение
INNER JOIN Возвращает только строки, у которых есть совпадения в обеих таблицах. Когда нужно только пересечение данных.
LEFT JOIN Берёт все строки из левой таблицы и совпадающие из правой (NULL, если нет). Когда важно сохранить все данные «слева» даже без пары.
RIGHT JOIN Аналог LEFT, но берёт все из правой таблицы. Редко используется, чаще удобнее поменять местами таблицы.
FULL JOIN Объединяет LEFT и RIGHT: все строки из обеих таблиц, NULL там, где нет пары. Когда нужны все данные из обеих, и нет явного «лево/право».
CROSS JOIN Декартово произведение: каждая строка левой с каждой строкой правой. При генерации матриц или тестовых наборов.
2. Примеры синтаксиса
-- INNER: только общие заказы и клиенты
SELECT o.id, c.name
FROM orders o
INNER JOIN customers c ON o.customer_id = c.id;
-- LEFT: все заказы, даже если клиента нет (NULL)
SELECT o.id, c.name
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.id;
-- FULL: все заказы и все клиенты
SELECT o.id AS order_id, c.id AS customer_id
FROM orders o
FULL JOIN customers c ON o.customer_id = c.id;
WHERE, ON) до JOIN, чтобы не нагружать соединение лишними данными.NULL через COALESCE или дополнительные условия.
Не знаешь на кого пойти учиться ?💥
🛑Пройди бесплатные онлайн-курсы
🛑Узнай о самых востребованных профессиях
🛑Получи уникальную возможность поступить в «Алабуга Политех» после 9 или 11 класса
ПРОЙДИ КУРС ПРЯМО СЕЙЧАС!
🔧 Mini-гайд: ускоряем JOIN-ы в больших таблицах
JOIN-ы — мощный инструмент SQL, но на больших объёмах данных могут стать узким горлышком. Вот 5 проверенных способов ускорить их:
1. Индексы по ключам соединения
Без индекса — каждый JOIN превращается в полный перебор.
➤ Пример:
CREATE INDEX idx_user_id ON orders(user_id);
SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE u.country = 'DE';
WITH german_users AS (
SELECT id FROM users WHERE country = 'DE'
)
SELECT * FROM orders o JOIN german_users g ON o.user_id = g.id;
INNER JOIN обычно быстрее OUTER JOIN, особенно при наличии NOT NULL. Иногда EXISTS работает быстрее, чем LEFT JOIN.JOIN по полям с разными типами (например, int и varchar) = неэффективный cast + тормоза.EXPLAIN ANALYZE — твой друг.