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

Оптимизация запросов: Индексы vs. Анализ плана выполнения 🚀 Сейчас я покажу вам, почему простое добавление индексов не всегда ускоряет запросы. Часто встречаю ситуацию, когда разработчики по умолчанию добавляют индексы на каждое поле WHERE, но запросы всё равно работают медленно. Давайте разберём…

Оптимизация запросов: Индексы vs. Анализ плана выполнения 🚀 Сейчас я покажу вам, почему простое добавление индексов не всегда ускоряет запросы. Часто встречаю ситуацию, когда разработчики по умолчанию добавляют индексы на каждое поле WHERE, но запросы всё равно работают медленно. Давайте разберёмся! 🔹 Миф: индексы всегда ускоряют запросы На самом деле, индекс может даже замедлить выполнение, если: ✅ Запрос возвращает слишком много строк - сканирование индекса будет дороже, чем полное сканирование таблицы. ✅ Индекс не покрывает весь запрос - приходится делать обращения к основной таблице. ✅ Слишком много индексов - это замедляет INSERT/UPDATE/DELETE. 🔹 Как правильно анализировать? Используйте EXPLAIN ANALYZE (PostgreSQL) или EXPLAIN FORMAT=JSON (MySQL) для понимания: 🔍 Используется ли индекс? 🔍 Сколько строк проходит сканирование? 🔍 Есть ли операции сортировки, которые можно избежать с индексом? 🔹 Что делать, если запрос медленный? 1️⃣ Проверить план выполнения (не добавлять индекс вслепую!). 2️⃣ Подумать о составных индексах, если запрос фильтрует по нескольким полям. 3️⃣ Проверить, можно ли избежать сортировки (ORDER BY по индексу). 4️⃣ Рассмотреть материализованные представления для сложных агрегатов. #db 👉 @database_info

🔥 Оптимизация сложных SQL-запросов: Как уменьшить время выполнения? 🛠 Основные проблемы: 🔹 Чрезмерное количество JOIN – могут приводить к тяжелым вычислениям. 🔹 Неправильные индексы – или их отсутствие вообще. 🔹 Подзапросы вместо JOIN – иногда работают хуже, чем соединения. 🔹 Ненужные SEL…

🔥 Оптимизация сложных SQL-запросов: Как уменьшить время выполнения? 🛠 Основные проблемы: 🔹 Чрезмерное количество JOIN – могут приводить к тяжелым вычислениям. 🔹 Неправильные индексы – или их отсутствие вообще. 🔹 Подзапросы вместо JOIN – иногда работают хуже, чем соединения. 🔹 Ненужные SELECT * – выбираем только нужные колонки. 🔹 Фильтрация после JOIN – фильтруем данные как можно раньше. ✅ Как ускорить запрос? 1️⃣ Проверьте индексы – используйте EXPLAIN перед выполнением запроса. Если сканируется весь таблица (Full Table Scan), значит, нужны индексы. 2️⃣ Разбейте сложный запрос на части – иногда лучше записать результат во временную таблицу. 3️⃣ Избегайте SELECT * – указывайте только нужные колонки. 4️⃣ Используйте EXISTS вместо IN – в подзапросах это часто работает быстрее. 5️⃣ Тестируйте с разными JOIN – попробуйте INNER JOIN, LEFT JOIN, а в некоторых случаях UNION. 6️⃣ Оптимизируйте сортировку – ORDER BY без индексов тормозит запрос. #db 👉 @database_info

Шпаргалка по оконным функциям в SQL #db 👉 @database_info

🚀 Оптимизация запросов в SQL: как не утонуть в данных Сегодня хочу поделиться мыслями на тему, которая часто становится болью для многих разработчиков баз данных — оптимизация SQL-запросов. Когда база данных растёт, а запросы становятся сложнее, даже небольшой промах может привести к тому, что…

🚀 Оптимизация запросов в SQL: как не утонуть в данных Сегодня хочу поделиться мыслями на тему, которая часто становится болью для многих разработчиков баз данных — оптимизация SQL-запросов. Когда база данных растёт, а запросы становятся сложнее, даже небольшой промах может привести к тому, что ваш сервер начнёт "плакать" под нагрузкой. Вот несколько советов, которые помогут вам держать запросы в тонусе: 1. Индексы — ваш лучший друг (и враг, если использовать неправильно) Индексы ускоряют поиск данных, но их избыток может замедлить вставку и обновление. Используйте их с умом: - Индексируйте только те столбцы, которые часто используются в условиях WHERE, JOIN и ORDER BY. - Избегайте индексов на столбцах с низкой селективностью (например, пол с значениями "М" и "Ж"). 2. Анализируйте план выполнения запроса Перед тем как оптимизировать, нужно понять, что именно тормозит. Используйте EXPLAIN (или EXPLAIN ANALYZE в PostgreSQL) для анализа плана выполнения. Обратите внимание на: - Полноценные сканирования таблиц (Seq Scan). - Вложенные циклы (Nested Loop), которые могут быть медленными на больших данных. - Использование временных таблиц и сортировок. 3. Избегайте N+1 проблемы Если вы работаете с ORM, убедитесь, что не делаете лишних запросов. Например, вместо того чтобы выбирать связанные данные в цикле, используйте JOIN или prefetch_related (в Django). 4. Кэшируйте то, что можно кэшировать Не все данные нужно каждый раз запрашивать из базы. Используйте кэширование для часто запрашиваемых данных. Redis или Memcached — отличные инструменты для этого. 5. Нормализация — это хорошо, но не всегда Нормализация базы данных помогает избежать дублирования данных, но иногда денормализация может значительно ускорить запросы. Например, если у вас есть сложные агрегации, подумайте о создании материализованных представлений. 6. Следите за статистикой Базы данных часто используют статистику для оптимизации запросов. Убедитесь, что она актуальна. Например, в PostgreSQL можно обновить статистику с помощью команды ANALYZE. 7. Не забывайте про мониторинг Используйте инструменты для мониторинга производительности базы данных, такие как pg_stat_activity в PostgreSQL или Performance Schema в MySQL. Это поможет вовремя выявить "узкие" места. #db 👉 @database_info

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора …

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика Программирование Go📌 https://max.ru/golang_lib Библиотека Go (Golang) разработчика Программирование React📌 https://max.ru/react_lib React Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии 📌 https://max.ru/progjob Вакансии в IT Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Бонус 📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы

Безумные и забавные факты о SQLite ▪️SQLite — самая часто разворачиваемая и используемая база данных. На текущий момент активно используется более одного триллиона (1000000000000 или миллиона миллионов) баз данных SQLite. ▪️Её поддерживают три человека. Они не допускают внешних контрибьюторов. Ско…

Безумные и забавные факты о SQLite ▪️SQLite — самая часто разворачиваемая и используемая база данных. На текущий момент активно используется более одного триллиона (1000000000000 или миллиона миллионов) баз данных SQLite. ▪️Её поддерживают три человека. Они не допускают внешних контрибьюторов. Скорее всего, SQLite используется больше, чем все остальные движки баз данных суммарно. В мире работают миллиарды копий SQLite. Её можно встретить повсюду. https://habr.com/ru/companies/ruvds/articles/873816/ #db 👉 @database_info

Как лучше всего изучать язык SQL? В 1986 году язык SQL (Structured Query Language) стал стандартом. В течение последующих 40 лет он стал доминирующим языком для систем управления реляционными базами данных. Чтение последнего стандарта (ANSI SQL 2016) может занять много времени. Как я могу его выучи…

Как лучше всего изучать язык SQL? В 1986 году язык SQL (Structured Query Language) стал стандартом. В течение последующих 40 лет он стал доминирующим языком для систем управления реляционными базами данных. Чтение последнего стандарта (ANSI SQL 2016) может занять много времени. Как я могу его выучить? В состав языка SQL входят 5 компонентов: - DDL: data definition language, such as CREATE, ALTER, DROP - DQL: data query language, such as SELECT - DML: data manipulation language, such as INSERT, UPDATE, DELETE - DCL: data control language, such as GRANT, REVOKE - TCL: transaction control language, such as COMMIT, ROLLBACK Для бэкенд-инженера может потребоваться знание большинства из них. Аналитику данных может потребоваться хорошее понимание DQL. Выберите те темы, которые наиболее актуальны для вас. #db 👉 @database_info

Шардирование базы данных на пальцах Популярные приложения рано или поздно должны масштабироваться для ускорения доступа к данным и увеличения трафика. Чтобы распределить данные на несколько серверов и обеспечить им безопасность и целостность, нужна база данных с соответствующей архитектурой — шарди…

Шардирование базы данных на пальцах Популярные приложения рано или поздно должны масштабироваться для ускорения доступа к данным и увеличения трафика. Чтобы распределить данные на несколько серверов и обеспечить им безопасность и целостность, нужна база данных с соответствующей архитектурой — шардированная база данных. Шардирование (шардинг) базы данных — это деление данных на разные фрагменты с целью повышения производительности и надежности. Иногда это понятие путают с репликацией и партицированием, но на самом деле это разные направления масштабирования, которые могут быть реализованы в пределах одной базы данных. Существует два вида шардирования: ▪Вертикальное (по столбцам): каждый шард содержит часть столбцов массива и все связанные с ними строки данных. ▪Горизонтальное (по каким-либо критериям строки): каждый шард содержит одинаковые столбцы, но разные строки данных. https://architecturenotes.co/database-sharding-explained/ #db 👉 @database_info

Визуализация SQL-запроса #db 👉 @database_info

Базы данных классифицируются в первую очередь по методу организации данных, способу их поиска и хранения, производительности при доступе к данным и способности распределять данные по нескольким узлам для повышения доступности и устойчивости #db 👉 @database_info