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

Производительные или и выгодные базы данных в облаке Безопасные, масштабируемые и отказоустойчивые базы данных — одна из ключевых потребностей любого проекта. Именно такие предлагает Selectel. СУБД под разные запросы: от универсальной PostgreSQL до поисковой и аналитической БД Opensearch Новые клиенты сейчас могут получить до 30 000 бонусов на использование облачных баз данных Selectel. Провайдер гарантирует: 🔹Высокую производительность. Выбирайте оптимальную конфигурацию кластера на базе мощного железа и локальных NVMe-дисков. 🔹Надежность. Автоматические бесплатные бэкапы с восстановлением вплоть до секунды — на стороне Selectel. А создать отказоустойчивый кластер можно всего от двух нод и сэкономить до 33%. 🔹Гибкое масштабирование. При росте нагрузки можно поменять конфигурацию облачного сервера и количество реплик без простоя. Успейте зарегистрироваться и оставить заявку на участие в акции, чтобы протестировать сервис бесплатно: https://slc.tl/kgir7 Реклама. АО "Селектел". erid:2W5zFGxeTWp

🧠 Почему PostgreSQL иногда "зависает" на UPDATE и как это пофиксить Сегодня я расскажу про одну интересную особенность PostgreSQL, с которой сталкивался лично: внезапные подвисания при UPDATE большого количества строк. Причём CPU почти не загружен, а запрос как будто "висит". 📌 Проблема часто кроется в отсутствии индекса на колонку фильтра в WHERE. Пример:

    
        
UPDATE orders SET status = 'archived' WHERE created_at < '2022-01-01';
{}
    

Если на created_at нет индекса, то PostgreSQL делает sequential scan всей таблицы. А теперь внимание: если в таблице много "мертвых" строк, которых ещё не убрал autovacuum, то PostgreSQL должен: 1. Прочитать кучу ненужных версий строк (MVCC). 2. Проверять видимость каждой строки. 3. Иногда ещё и ждать завершения других транзакций, держащих старые снапшоты. 🛠 Что делать: - Проверить наличие индекса на колонку фильтра:

    
        
  CREATE INDEX idx_orders_created_at ON orders(created_at);
  {}
    

- Проверить состояние autovacuum:

    
        
  SELECT relname, n_dead_tup, last_vacuum, last_autovacuum 
  FROM pg_stat_user_tables ORDER BY n_dead_tup DESC;
  {}
    

- Можно вручную запустить:

    
        
  VACUUM ANALYZE orders;
  {}
    

🔥 Лайфхак: если UPDATE всё равно медленный, попробуй его разбить на батчи по 10 000 строк. Это снизит нагрузку и ускорит выполнение. 📲 Мы в MAX #db 👉 @database_info

Оптимизация запросов: как найти узкое место? 🔍 Привет, коллеги! Сегодня я покажу вам, как находить узкие места в SQL-запросах и оптимизировать их. Если ваш запрос работает медленно, скорее всего, проблема в одном из трех мест: 1️⃣ Неверные индексы - Проверьте EXPLAIN ANALYZE, если используется Seq Scan вместо Index Scan, значит, индексы либо отсутствуют, либо неэффективны. - Добавьте индексы на часто фильтруемые и соединяемые поля. 2️⃣ Проблемные JOIN'ы - Проверьте, какие типы JOIN используются. NESTED LOOP JOIN может быть проблемой на больших таблицах. - Используйте HASH JOIN или MERGE JOIN, если это возможно. 3️⃣ Громоздкие операции (GROUP BY, ORDER BY, DISTINCT) - Сортировка и группировка требуют много ресурсов. - Можно ли заменить DISTINCT на EXISTS? - Используйте индексированные столбцы в ORDER BY. 📲 Мы в MAX #db 👉 @database_info

В новой статье на Хабре Алексей Кременьков, бэкенд-разработчик в Яндекс 360, рассказывает о создании и эволюции сервиса динамического шардирования Sharpei для масштабирования PostgreSQL под нагрузкой в 300К+ RPS. Пошагово разберём, как: • Создали собственный инструмент для управления 700+ шардами PostgreSQL • Справились с пиковыми нагрузками при миграциях • Автоматизировали перенос пользователей между шардами и переехали в облако без даунтайма Сервис Sharpei позволил Яндекс Почте перейти к гибкому горизонтальному масштабированию, полностью автоматизировать управление шардами и добиться четырёх девяток отказоустойчивости. ↘️ Подробнее читайте на Хабре

SQL JOINs наглядно: как работать с объединением таблиц Хотите лучше понимать SQL JOIN? Вот наглядная шпаргалка с примерами и визуализацией! 🔹 INNER JOIN – пересечение двух таблиц, возвращает только совпадающие строки. SELECT * FROM A INNER JOIN B ON A.key = B.key; 🔹 FULL JOIN – объединяет все данные из обеих таблиц, заполняя пропущенные значения NULL. SELECT * FROM A FULL JOIN B ON A.key = B.key; 🔹 FULL JOIN с фильтрацией NULL – выбирает только строки, которые есть только в одной из таблиц. SELECT * FROM A FULL JOIN B ON A.key = B.key WHERE A.key IS NULL OR B.key IS NULL; 🔹 LEFT JOIN – возвращает все строки из A и совпадающие строки из B. SELECT * FROM A LEFT JOIN B ON A.key = B.key; 🔹 LEFT JOIN (только уникальные в A) – возвращает только строки из A, которых нет в B. SELECT * FROM A LEFT JOIN B ON A.key = B.key WHERE B.key IS NULL; 🔹 RIGHT JOIN – аналогично LEFT JOIN, но с приоритетом B. SELECT * FROM A RIGHT JOIN B ON A.key = B.key; 🔹 RIGHT JOIN (только уникальные в B) – выбирает строки, которые есть в B, но отсутствуют в A. SELECT * FROM A RIGHT JOIN B ON A.key = B.key WHERE B.key IS NULL; Сохраняйте в закладки и пользуйтесь! ⚡ 📲 Мы в MAX #db 👉 @database_info

Андрей Бородин, руководитель разработки СУБД с открытым исходным кодом в Yandex Cloud, вошел в топ-50 главных контрибьюторов PostgreSQL Разработчик получил статус major contributor за многолетний вклад в развитие сообщества и кодовой базы PostgreSQL: ревью патчей, менторинг младших разработчиков и улучшение инструментов WAL‑G, Odyssey и SPQR. По данным Stack Overflow 2025 PostgreSQL используют более 55,6% опытных разработчиков баз данных в компаниях разного масштаба Особенно активно она применяется в ИИ-проектах. Команда разработки СУБД Yandex Cloud работает в тесной связке с сообществом PostgreSQL — каждый год в релиз проекта попадает множество доработок от сотрудников компании. При этом процесс принятия изменений в ядро PostgreSQL считается одним из самых строгих в сообществе, поэтому успешный апстрим-патч — знак качества кода. Помимо вклада в PostgreSQL, команда Андрея разработала решение с открытым исходным кодом SPQR. На его основе в 2025 году в режиме превью был запущен Managed Service for Shared PostgreSQL. Он обеспечивает горизонтальное масштабирование баз данных через шардирование — разделение данных между разными серверами.

Визуализация SQL-запросов Ментальная модель, помогающая представить, как выполняются SQL-запросы. Фактическая последовательность выполнения может отличаться от этой модели из-за стратегий оптимизации, применяемых оптимизатором запросов. 📲 Мы в MAX #db 👉 @database_info

Как индекс может замедлить запрос? Сейчас разберём интересный парадокс: почему индекс может замедлить выполнение запроса? 🤔 Обычно индекс ускоряет поиск данных, но есть ситуации, когда его использование ведёт к ухудшению производительности. Давайте рассмотрим несколько таких случаев. 🚀 1. Неправильный выбор индекса Допустим, у нас есть индекс по created_at, а мы выполняем запрос:

    
        
SELECT * FROM orders WHERE YEAR(created_at) = 2024;
{}
    

Проблема в том, что функция YEAR(created_at) делает так, что индекс не используется эффективно. База данных должна пройтись по всем строкам, применяя функцию ко всем значениям. Лучше переписать так:

    
        
SELECT * FROM orders WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01';
{}
    

Теперь индекс сможет работать оптимально. 🔥 🏗 2. Слишком широкий индекс (Over-indexing) Если у нас слишком много индексов на таблице, это приведёт к замедлению операций INSERT, UPDATE, DELETE. Почему? Потому что каждый раз при изменении данных БД должна обновлять все индексы. Поэтому добавляйте индексы осознанно! 📦 3. Низкая селективность индекса Допустим, у нас есть индекс по status, но всего три возможных значения ('new', 'processing', 'done'). Если в таблице миллионы строк, но мало уникальных значений, индекс бесполезен — оптимизатор может решить, что проще выполнить полный скан таблицы. ⚠️ 4. Ошибка с покрывающим индексом Иногда индекс покрывает все нужные колонки (INDEX(col1, col2, col3)), но запрос выбирает ещё одну (col4). Тогда база вынуждена обращаться к самой таблице, что убивает эффективность индекса. 📌 Вывод: индекс — мощный инструмент, но его неправильное использование может навредить. Перед добавлением индексов всегда анализируйте планы выполнения запросов (EXPLAIN в MySQL, EXPLAIN ANALYZE в PostgreSQL). 📲 Мы в MAX #db 👉 @database_info

🚀 Подборка Telegram каналов для программистов Системное администрирование, DevOps 📌 https://t.me/bash_srv Bash Советы https://t.me/win_sysadmin Системный Администратор Windows https://t.me/sysadmin_girl Девочка Сисадмин https://t.me/srv_admin_linux Админские угодья https://t.me/linux_srv Типичный Сисадмин https://t.me/devopslib Библиотека девопса | DevOps, SRE, Sysadmin https://t.me/linux_odmin Linux: Системный администратор https://t.me/devops_star DevOps Star (Звезда Девопса) https://t.me/i_linux Системный администратор https://t.me/linuxchmod Linux https://t.me/sys_adminos Системный Администратор https://t.me/tipsysdmin Типичный Сисадмин (фото железа, было/стало) https://t.me/sysadminof Книги для админов, полезные материалы https://t.me/i_odmin Все для системного администратора https://t.me/i_odmin_book Библиотека Системного Администратора https://t.me/i_odmin_chat Чат системных администраторов https://t.me/i_DevOps DevOps: Пишем о Docker, Kubernetes и др. https://t.me/sysadminoff Новости Линукс Linux 1C разработка 📌 https://t.me/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С https://t.me/DevLab1C 1С:Предприятие 8 https://t.me/razrab_1C 1C Разработчик https://t.me/buh1C_prog 1C Программист | Бухгалтерия и Учёт https://t.me/rabota1C_rus Вакансии для программистов 1С Программирование C++📌 https://t.me/cpp_lib Библиотека C/C++ разработчика https://t.me/cpp_knigi Книги для программистов C/C++ https://t.me/cpp_geek Учим C/C++ на примерах Программирование Python 📌 https://t.me/pythonofff Python академия. https://t.me/BookPython Библиотека Python разработчика https://t.me/python_real Python подборки на русском и английском https://t.me/python_360 Книги по Python Java разработка 📌 https://t.me/BookJava Библиотека Java разработчика https://t.me/java_360 Книги по Java Rus https://t.me/java_geek Учим Java на примерах GitHub Сообщество 📌 https://t.me/Githublib Интересное из GitHub Базы данных (Data Base) 📌 https://t.me/database_info Все про базы данных Мобильная разработка: iOS, Android 📌 https://t.me/developer_mobila Мобильная разработка https://t.me/kotlin_lib Подборки полезного материала по Kotlin https://t.me/androidspb Разработка под Android: Kotlin, Java. Фронтенд разработка 📌 https://t.me/frontend_1 Подборки для frontend разработчиков https://t.me/frontend_sovet Frontend советы, примеры и практика! https://t.me/React_lib Подборки по React js и все что с ним связано Разработка игр 📌 https://t.me/game_devv Все о разработке игр Библиотеки 📌 https://t.me/book_for_dev Книги для программистов Rus https://t.me/programmist_of Книги по программированию https://t.me/proglb Библиотека программиста https://t.me/bfbook Книги для программистов БигДата, машинное обучение 📌 https://t.me/bigdata_1 Big Data, Machine Learning Программирование 📌 https://t.me/bookflow Лекции, видеоуроки, доклады с IT конференций https://t.me/rust_lib Полезный контент по программированию на Rust https://t.me/golang_lib Библиотека Go (Golang) разработчика https://t.me/itmozg Программисты, дизайнеры, новости из мира IT https://t.me/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 https://t.me/nodejs_lib Подборки по Node js и все что с ним связано https://t.me/ruby_lib Библиотека Ruby программиста https://t.me/lifeproger Жизнь программиста. Авторский канал. QA, тестирование 📌 https://t.me/testlab_qa Библиотека тестировщика Шутки программистов 📌 https://t.me/itumor Шутки программистов Защита, взлом, безопасность 📌 https://t.me/thehaking Канал о кибербезопасности https://t.me/xakep_2 Хакер Free Книги, статьи для дизайнеров 📌 https://t.me/ux_web Статьи, книги для дизайнеров Математика 📌 https://t.me/Pomatematike Канал по математике https://t.me/phis_mat Обучающие видео, книги по Физике и Математике https://t.me/matgeoru Математика | Геометрия | Логика Excel лайфхак📌 https://t.me/Excel_lifehack https://t.me/mir_teh Мир технологий (Technology World) Вакансии 📌 https://t.me/sysadmin_rabota Системный Администратор https://t.me/progjob Вакансии в IT

🔥 Оптимизация индексов: частая ошибка DBA 🔥 Сегодня разберём распространённую ошибку, которую совершают многие администраторы баз данных — избыточные индексы. 💡Проблема Добавление индексов — это полезно, но если их становится слишком много, то база данных начинает тормозить при вставке, обновлении и удалении данных. Почему? Потому что каждый индекс требует дополнительного обслуживания при изменениях в таблице. 💡Пример ошибки Представим таблицу orders:

    
        
CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    customer_id INT NOT NULL,
    order_date DATE NOT NULL,
    total DECIMAL(10,2) NOT NULL
);
{}
    

Допустим, мы добавляем индексы:

    
        
CREATE INDEX idx_customer ON orders(customer_id);
CREATE INDEX idx_order_date ON orders(order_date);
CREATE INDEX idx_customer_order_date ON orders(customer_id, order_date);
{}
    

На первый взгляд, всё логично, но есть проблема: индекс idx_customer_order_date покрывает оба предыдущих индекса! 💡Как исправить? Можно удалить idx_customer и idx_order_date, так как составной индекс (idx_customer_order_date) способен выполнять их работу. 📌 Как проверить ненужные индексы? 1️⃣ В PostgreSQL:

    
        
SELECT indexrelid::regclass, pg_size_pretty(pg_relation_size(indexrelid))
FROM pg_stat_user_indexes
ORDER BY pg_relation_size(indexrelid) DESC;
{}
    

2️⃣ В MySQL:

    
        
SHOW INDEX FROM orders;
{}
    

Здесь ищем индексы, которые дублируют друг друга. Вывод: Чем меньше избыточных индексов — тем быстрее работает ваша база данных. Проверьте свои индексы прямо сейчас! 📲 Мы в MAX #db 👉 @database_info