Облачные базы данных: Шпаргалка

В современном мире, основанном на данных, выбор правильной базы данных имеет решающее значение и в то же время сложен. Сейчас облако предлагает больше возможностей для структурированных, полуструктурированных и неструктурированных баз данных, чем когда-либо. Эта шпаргалка поможет выбрать наиболее подходящую для ваших нужд.

Структурированные базы данных📌

Структурированные базы данных организуют данные в предопределенные схемы и модели.

Реляционные базы данных, такие как MySQL и PostgreSQL, хранят данные в таблицах со строками и столбцами.

Колоночные базы данных, такие как Amazon Redshift и Google BigQuery, также имеют структурированную модель данных, но хранят их по-другому, оптимизируя для аналитических запросов.

Преимущества:
- Эффективные SQL-запросы
- Возможность применения ограничений и валидации
- Последовательность там, где это необходимо

Примеры использования: CRM-системы, управление запасами, бухгалтерский учет, аналитика


Полуструктурированные базы данных📌

Полуструктурированные базы данных обеспечивают гибкость, храня данные без соблюдения формальной схемы. Данные часто хранятся в виде JSON или других гибких форматов.

Примеры включают в себя документ-базы данных, такие как MongoDB, графовые базы данных, наподобие Neptune, широкие колоночные хранилища, такие как ScyllaDB, и хранилища ключ-значение, такие как DynamoDB.

Преимущества:
- Гибкость для изменяющихся данных
- Масштабируемость на разных серверах

Примеры использования: Электронная коммерция, ленты социальных сетей, данные IoT


Неструктурированные базы данных📌

Неструктурированные базы данных оптимизированы для хранения и обработки огромных объемов разнородных данных, таких как документы, изображения, видео. Примеры: AWS S3, Azure Blob Storage.

Преимущества:
- Хранение огромных объемов данных
- Высокая масштабируемость

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

#db

👉 @database_info

Шпаргалка по PostgreSQL

Перенес в my-mans

-- подключиться к postgres (утилита psql)
psql -U postgres

-- команды помощи
help
\h -- помощь по командам SQL
\? -- помощь по командам psql

-- выход из консоли postgres
\q

-- создать базу
CREATE DATABASE my_database;

-- подключиться к базе
\connect my_database;

-- создать таблицу my_table с полями field1 (тип целочисленный, обязательное для заполнения), field2 (тип строка 255 символов)
CREATE TABLE my_table (field1 INT NOT NULL, field2 VARCHAR(255));

-- вывести все таблицы
\d

-- удалить таблицу my_table
DROP TABLE my_table;

-- внести в таблицу запись
INSERT INTO my_table(field1, field2) VALUES(1,'Any text value');

-- вывести записи
SELECT * FROM my_table; -- все записи
SELECT * FROM my_table WHERE field1 = 1; -- все, где field1 = 1
SELECT * FROM my_table WHERE field1 != 1; -- и т д
SELECT * FROM my_table WHERE field1 > 1;
SELECT * FROM my_table LIMIT 100; -- первые 100 записей;
SELECT * FROM my_table LIMIT 100 OFFSET 200; -- запись с 201 по 300;

-- сортировка при выводе
SELECT * FROM my_table ORDER BY field1 ASC; -- вывести отсортировав в возрастающем порядке
SELECT * FROM my_table ORDER BY field1 DESC; -- вывести отсортировав в убывающем порядке

-- изменить запись таблицы (поле field2 строки, где field1 = 1);
UPDATE my_table SET field2 = 'Other text value' WHERE field1 = 1;

-- удаление данных
DELETE FROM my_table; -- удалить все записи;
DELETE FROM my_table WHERE field1 = 1; -- удалить запись где field1 = 1;


-- ***********************************
-- нормализация (разбиение таблиц на несколько)
-- ***********************************

-- Constraints - ограничения типов данных
CREATE TABLE my_table (
field1 INT NOT NULL, -- запись обязательна
field2 VARCHAR(255) NOT NULL UNIQUE, -- запись должна быть уникальной
field3 BOOLEAN NOT NULL DEFAULT TRUE -- значение по умолчанию - true
...
);

-- Первичный и внешние ключи
-- при создании записи таблицы с отсутствующим внешним ключом выведется запись об ошибке. будут выводится ошибки и в иных случаях, когда будут нарушаться связи.
CREATE TABLE IF NOT EXISTS my_table ( -- ключ IF NOT EXISTS проверяет, существует ли таблица.
field1 SERIAL INT PRIMARY KEY, -- при добавлении PRIMARY KEY поле автоматически наследует ограничения NOT NULL и UNIQUE, и создается индекс. SERIAL тип данных являющийся автоматически увеличивающимся счетчиком (аналог ключа AUTOINCREMENT в Sqlite)
field2 VARCHAR(255) NOT NULL UNIQUE,
field3 INT NOT NULL,
FOREIGN KEY(field3) REFERENCES other_table(field_name) -- поле ссылается на внешнюю таблицу other_table на поле field_name, которое обязательно должно быть с PRIMARY KEY
);

-- вывод данных из нескольких таблиц со связанными полями
SELECT * FROM table_1 LEFT JOIN table_2 ON (table_2.field = table_1.field);

-- алиасы, нужны для удобства. Также, при выводе наименование таблиц или полей выводится алиасом, при его наличии.
SELECT * FROM table_1 as tab1 LEFT JOIN table_2 as tab2 ON (tab1.field = tab2.field);


#Шпаргалка@linux_odmin

👉 @linux_odmin

Подборка Telegram каналов для программистов

Системное администрирование 📌
https://news.1rj.ru/str/sysadmin_girl Девочка Сисадмин
https://news.1rj.ru/str/srv_admin_linux Админские угодья
https://news.1rj.ru/str/linux_srv Типичный Сисадмин

https://news.1rj.ru/str/linux_odmin Linux: Системный администратор
https://news.1rj.ru/str/devops_star DevOps Star (Звезда Девопса)
https://news.1rj.ru/str/i_linux Системный администратор
https://news.1rj.ru/str/linuxchmod Linux
https://news.1rj.ru/str/sys_adminos Системный Администратор
https://news.1rj.ru/str/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
https://news.1rj.ru/str/sysadminof Книги для админов, полезные материалы
https://news.1rj.ru/str/i_odmin Все для системного администратора
https://news.1rj.ru/str/i_odmin_book Библиотека Системного Администратора
https://news.1rj.ru/str/i_odmin_chat Чат системных администраторов
https://news.1rj.ru/str/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
https://news.1rj.ru/str/sysadminoff Новости Линукс Linux

1C разработка 📌
https://news.1rj.ru/str/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С

Программирование C++📌
https://news.1rj.ru/str/cpp_lib Библиотека C/C++ разработчика
https://news.1rj.ru/str/cpp_knigi Книги для программистов C/C++
https://news.1rj.ru/str/cpp_geek Учим C/C++ на примерах

Программирование Python 📌
https://news.1rj.ru/str/pythonofff Python академия. Учи Python быстро и легко🐍
https://news.1rj.ru/str/BookPython Библиотека Python разработчика
https://news.1rj.ru/str/python_real Python подборки на русском и английском
https://news.1rj.ru/str/python_360 Книги по Python Rus

Java разработка 📌
https://news.1rj.ru/str/BookJava Библиотека Java разработчика
https://news.1rj.ru/str/java_360 Книги по Java Rus
https://news.1rj.ru/str/java_geek Учим Java на примерах

GitHub Сообщество 📌
https://news.1rj.ru/str/Githublib Интересное из GitHub

Базы данных (Data Base) 📌
https://news.1rj.ru/str/database_info Все про базы данных

Мобильная разработка: iOS, Android 📌
https://news.1rj.ru/str/developer_mobila Мобильная разработка
https://news.1rj.ru/str/kotlin_lib Подборки полезного материала по Kotlin

Фронтенд разработка 📌
https://news.1rj.ru/str/frontend_1 Подборки для frontend разработчиков
https://news.1rj.ru/str/frontend_sovet Frontend советы, примеры и практика!
https://news.1rj.ru/str/React_lib Подборки по React js и все что с ним связано

Разработка игр 📌
https://news.1rj.ru/str/game_devv Все о разработке игр

Библиотеки 📌
https://news.1rj.ru/str/book_for_dev Книги для программистов Rus
https://news.1rj.ru/str/programmist_of Книги по программированию
https://news.1rj.ru/str/proglb Библиотека программиста
https://news.1rj.ru/str/bfbook Книги для программистов
https://news.1rj.ru/str/books_reserv Книги для программистов

БигДата, машинное обучение 📌
https://news.1rj.ru/str/bigdata_1 Data Science, Big Data, Machine Learning, Deep Learning

Программирование 📌
https://news.1rj.ru/str/bookflow Лекции, видеоуроки, доклады с IT конференций
https://news.1rj.ru/str/coddy_academy Полезные советы по программированию
https://news.1rj.ru/str/rust_lib Полезный контент по программированию на Rust
https://news.1rj.ru/str/golang_lib Библиотека Go (Golang) разработчика
https://news.1rj.ru/str/itmozg Программисты, дизайнеры, новости из мира IT
https://news.1rj.ru/str/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻
https://news.1rj.ru/str/nodejs_lib Подборки по Node js и все что с ним связано
https://news.1rj.ru/str/ruby_lib Библиотека Ruby программиста

QA, тестирование 📌
https://news.1rj.ru/str/testlab_qa Библиотека тестировщика

Шутки программистов 📌
https://news.1rj.ru/str/itumor Шутки программистов

Защита, взлом, безопасность 📌
https://news.1rj.ru/str/thehaking Канал о кибербезопасности
https://news.1rj.ru/str/xakep_1 Статьи из "Хакера"

Книги, статьи для дизайнеров 📌
https://news.1rj.ru/str/ux_web Статьи, книги для дизайнеров

Английский 📌
https://news.1rj.ru/str/UchuEnglish Английский с нуля

Математика 📌
https://news.1rj.ru/str/Pomatematike Канал по математике
https://news.1rj.ru/str/phis_mat Обучающие видео, книги по Физике и Математике

Excel лайфхак📌
https://news.1rj.ru/str/Excel_lifehack

https://news.1rj.ru/str/tikon_1 Новости высоких технологий, науки и техники💡
https://news.1rj.ru/str/mir_teh Мир технологий (Technology World)

Вакансии 📌
https://news.1rj.ru/str/sysadmin_rabota Системный Администратор
https://news.1rj.ru/str/progjob Вакансии в IT

Горизонтальное масштабирование базы данных. Репликация. Партицирование. Шардирование

В современном мире данных нагрузка на базы данных стремительно растёт. Когда один сервер перестаёт справляться с объёмом запросов, встаёт вопрос о масштабировании: как эффективно распределить нагрузку, сохранив высокую производительность и доступность?

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

https://habr.com/ru/articles/875708/

#db

👉 @database_info

NoSQL для начинающих на примере MongoDB

00:00 - Что такое NoSQL и где он применяется?
04:18 - Основные виды NoSQL
06:04 - Дополнительные темы
09:31 - SQL vs NoSQL
11:53 - Немного о MongoDB
14:37 - Практика. Моделирование структуры. Работа с shell и Compass

#db

👉 @database_info

🚀 Оптимизация запросов в 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

📕Открытый урок о преимуществах ClickHouse для архитекторов систем баз данных, специалистов по аналитике данных, руководителей IT-проектов

На открытом уроке 10 февраля в 20:00 мск мы узнаем, как архитектура и возможности ClickHouse превосходят конкурентов, таких как MongoDB, Cassandra и Elasticsearch, в задачах аналитики данных.

📗В результате вы:
- Разберетесь в преимуществах ClickHouse в контексте импортозамещения (открытый код, российская разработка, высокая производительность);
- Определите основные отличия ClickHouse от других популярных NoSQL решений (MongoDB, Cassandra, Elasticsearch);
- Построите аналитическую систему в ClickHouse на основе данных из таблицы.

Спикер Наталия Титова — эксперт банковской и продуктовой аналитики, а также клиентской аналитики в мобильном приложении и в web, 5+ лет преподавательского опыта в области баз данных, анализа данных и DS.

👉 Регистрируйтесь прямо сейчас, чтобы не пропустить мероприятие: https://vk.cc/cIke74

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

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

🔥 Оптимизация сложных 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

Оптимизация запросов: Индексы vs. Анализ плана выполнения 🚀

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

🔹 Миф: индексы всегда ускоряют запросы
На самом деле, индекс может даже замедлить выполнение, если:
✅ Запрос возвращает слишком много строк — сканирование индекса будет дороже, чем полное сканирование таблицы.
✅ Индекс не покрывает весь запрос — приходится делать обращения к основной таблице.
✅ Слишком много индексов — это замедляет INSERT/UPDATE/DELETE.

🔹 Как правильно анализировать?
Используйте EXPLAIN ANALYZE (PostgreSQL) или EXPLAIN FORMAT=JSON (MySQL) для понимания:
🔍 Используется ли индекс?
🔍 Сколько строк проходит сканирование?
🔍 Есть ли операции сортировки, которые можно избежать с индексом?

🔹 Что делать, если запрос медленный?
1️⃣ Проверить план выполнения (не добавлять индекс вслепую!).
2️⃣ Подумать о составных индексах, если запрос фильтрует по нескольким полям.
3️⃣ Проверить, можно ли избежать сортировки (ORDER BY по индексу).
4️⃣ Рассмотреть материализованные представления для сложных агрегатов.

⚡ Задача для вас:
Поделитесь в комментариях, какие самые неожиданные случаи оптимизации запросов у вас были? Что помогло ускорить запрос?

#db

👉 @database_info

🔥 Оптимизация SQL-запросов: 5 ключевых техник

Сегодня я покажу вам, как ускорить выполнение SQL-запросов, ведь никто не любит ждать, пока база данных "думает". 🚀

1️⃣ Используйте индексы
Индексы – это ускоритель запросов. Если у вас часто выполняются WHERE, JOIN или ORDER BY по определенному столбцу – создайте для него индекс. Но не переборщите: индексы ускоряют чтение, но замедляют вставку и обновление данных.

2️⃣ Избегайте SELECT *
Выбирайте только нужные столбцы. SELECT * может загружать ненужные данные и нагружать сервер. Лучше указывать конкретные столбцы.

3️⃣ Нормализация или денормализация?
Иногда стоит разбивать таблицы (нормализация) для устранения дублирования данных. В других случаях – наоборот, объединять (денормализация) ради быстродействия. Анализируйте ситуацию!

4️⃣ Кеширование запросов
Если запрос выполняется часто и данные редко меняются, используйте QUERY CACHE или внешние кеширующие механизмы (Redis, Memcached).

5️⃣ Анализируйте планы выполнения
Команда EXPLAIN в MySQL/PostgreSQL покажет, как СУБД выполняет запрос. Это поможет найти узкие места: медленные JOIN'ы, сканы всей таблицы и т.д.

💡 Используете ли вы эти техники? Напишите, какой метод вам помог ускорить работу БД!

#db

👉 @database_info

Как эффективно работать с датами в SQL?

Привет, друзья! Сегодня разберем один из самых частых вопросов в SQL — работу с датами. Даты встречаются везде: в заказах, логах, отчетах. И если их неправильно хранить или использовать, можно напороться на серьезные проблемы с производительностью и логикой запросов.

Вот несколько ключевых моментов:

🔹 Используйте правильный тип данных
Не храните даты в VARCHAR! Всегда используйте DATE, DATETIME или TIMESTAMP. Это не только экономит место, но и ускоряет запросы.

🔹 Не используйте `NOW()` в `WHERE` без обработки
Запрос вида:

   SELECT * FROM orders WHERE order_date > NOW() - INTERVAL 7 DAY;
   

может привести к тому, что индексы не будут использоваться. Лучше заранее вычислить диапазон и передать его в запрос.

🔹 Сравнение по диапазону – ключ к оптимизации
Для фильтрации по дате лучше использовать BETWEEN:

   SELECT * FROM orders WHERE order_date BETWEEN '2024-02-01' AND '2024-02-07';
   

Это более понятно и эффективно.

🔹 Осторожно с часовыми поясами
Если ваш сервис работает глобально, храните время в UTC и конвертируйте на уровне приложения.

🔹 Агрегируйте правильно
Часто нужно сгруппировать данные по дням или месяцам:

   SELECT DATE(order_date) AS order_day, COUNT(*) FROM orders GROUP BY order_day;
   

Но если поле order_date – DATETIME, такие операции могут игнорировать индексы. Лучше использовать GROUP BY DATE_FORMAT(order_date, '%Y-%m-%d') или завести отдельное `DATE`-поле.

Работа с датами — мощный инструмент, но требует внимательности. Как вы решаете проблемы с обработкой времени в SQL? Делитесь в комментариях!

#db

👉 @database_info

🔥 Шпаргалка по SQL с основными командами и примерами

1. Основные команды SQL

SELECT column1, column2 FROM table_name;  -- Выборка данных
SELECT * FROM table_name;  -- Выборка всех данных
INSERT INTO table_name (column1, column2) VALUES ('value1', 'value2');  -- Добавление данных
UPDATE table_name SET column1 = 'value' WHERE condition;  -- Обновление данных
DELETE FROM table_name WHERE condition;  -- Удаление данных

2. Фильтрация данных (WHERE, AND, OR, LIKE, IN, BETWEEN)

SELECT * FROM users WHERE age > 18;  -- Возраст больше 18
SELECT * FROM users WHERE city = 'Москва' AND age > 18;  -- Два условия
SELECT * FROM users WHERE name LIKE 'A%';  -- Начинается с 'A'
SELECT * FROM users WHERE age BETWEEN 18 AND 30;  -- Возраст от 18 до 30
SELECT * FROM users WHERE city IN ('Москва', 'Санкт-Петербург');  -- Город Москва или Питер

3. Группировка и агрегатные функции (GROUP BY, HAVING, COUNT, SUM, AVG, MAX, MIN)

SELECT city, COUNT(*) FROM users GROUP BY city;  -- Количество пользователей в каждом городе
SELECT city, AVG(age) FROM users GROUP BY city HAVING AVG(age) > 25;  -- Средний возраст > 25
SELECT MAX(salary) FROM employees;  -- Максимальная зарплата
SELECT SUM(sales) FROM orders WHERE date >= '2024-01-01';  -- Сумма продаж с 2024 года

4. Сортировка (ORDER BY)

SELECT * FROM users ORDER BY age ASC;  -- Сортировка по возрасту (по возрастанию)
SELECT * FROM users ORDER BY age DESC;  -- Сортировка по убыванию

5. Соединение таблиц (JOIN)

SELECT users.name, orders.amount 
FROM users 
JOIN orders ON users.id = orders.user_id;  -- Внутреннее соединение

SELECT users.name, orders.amount 
FROM users 
LEFT JOIN orders ON users.id = orders.user_id;  -- Левый JOIN (все из users)

SELECT users.name, orders.amount 
FROM users 
RIGHT JOIN orders ON users.id = orders.user_id;  -- Правый JOIN (все из orders)

6. Создание и изменение таблиц (CREATE, ALTER, DROP)

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    age INT
);  -- Создание таблицы

ALTER TABLE users ADD COLUMN email VARCHAR(100);  -- Добавление колонки
ALTER TABLE users DROP COLUMN email;  -- Удаление колонки
DROP TABLE users;  -- Удаление таблицы

7. Работа с индексами (INDEX)

CREATE INDEX idx_users_name ON users(name);  -- Создание индекса
DROP INDEX idx_users_name;  -- Удаление индекса

8. Ограничения (PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK, DEFAULT)

CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INT REFERENCES users(id),  -- Внешний ключ
    amount DECIMAL(10,2) CHECK (amount > 0),  -- Ограничение CHECK
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP  -- Значение по умолчанию
);

9. Подзапросы (SUBQUERY)

SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE amount > 1000);  

10. Транзакции (BEGIN, COMMIT, ROLLBACK)

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;  -- Завершение транзакции
ROLLBACK;  -- Откат изменений

#db

👉 @database_info

🔥 Оптимизация запросов: Как убрать тормоза в SQL?

Сейчас покажу вам, как ускорить медленный SQL-запрос, который выполняется слишком долго. Если у вас в проекте есть запросы, которые выполняются секундами, а не миллисекундами, пора что-то менять!

🚀 Разбор примера
Допустим, у нас есть такой запрос:

SELECT * 
FROM orders 
WHERE customer_id = 123 
ORDER BY order_date DESC;

Кажется простым, но выполняется медленно. В чём может быть проблема?

📌 Основные причины тормозов:
1️⃣ Нет нужного индекса – если customer_id или order_date не индексированы, база будет делать полный скан таблицы.
2️⃣ Слишком много данных – если таблица огромная, ORDER BY без индекса будет работать медленно.
3️⃣ Использование SELECT * – загружает ненужные колонки и увеличивает нагрузку.

✅ Как ускорить?
✔ Добавляем индекс (если его нет):

CREATE INDEX idx_orders_customer ON orders(customer_id, order_date DESC);

✔ Выбираем только нужные колонки:

SELECT order_id, order_date 
FROM orders 
WHERE customer_id = 123 
ORDER BY order_date DESC;

✔ Лимитируем выборку (если нужен только последний заказ):

SELECT order_id, order_date 
FROM orders 
WHERE customer_id = 123 
ORDER BY order_date DESC 
LIMIT 1;

🔥 Итог
Добавление индекса + правильный выбор колонок + LIMIT = в разы быстрее! 🚀

А какие приёмы оптимизации запросов используете вы? Делитесь в комментариях!

#db

👉 @database_info

🔥 Оптимизация индексов: частая ошибка 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;

Здесь ищем индексы, которые дублируют друг друга.

⚡ Вывод
Чем меньше избыточных индексов — тем быстрее работает ваша база данных. Проверьте свои индексы прямо сейчас!

#db

👉 @database_info

🔍 Как ускорить SELECT в больших таблицах?

Сегодня расскажу, как можно ускорить выборку данных из больших таблиц. Если у вас запрос SELECT тормозит, попробуйте эти методы:

1️⃣ Индексы
Без индексов даже самый мощный сервер не спасёт. Используйте B-Tree для точных совпадений (=) и диапазонов (BETWEEN). Для полнотекстового поиска — GIN или Full-Text Index.

2️⃣ EXPLAIN ANALYZE
Перед оптимизацией всегда проверяйте план запроса:

EXPLAIN ANALYZE SELECT * FROM orders WHERE status = 'pending';

Ищите Seq Scan (последовательное сканирование) – оно медленное. Заменяйте его на Index Scan или Bitmap Index Scan.

3️⃣ Ограничение выборки
Не грузите тысячи строк, если нужно 10 записей:

SELECT * FROM logs ORDER BY created_at DESC LIMIT 10;

Такой запрос работает быстрее, чем выборка всего.

4️⃣ Партиционирование
Разделяйте большие таблицы по дате, ID или другому критерию. Например, если у вас логи за 5 лет, можно хранить их по месяцам.

5️⃣ Материализованные представления
Если отчёты строятся медленно, попробуйте кэшировать результат:

CREATE MATERIALIZED VIEW fast_report AS
SELECT status, COUNT(*) FROM orders GROUP BY status;

Обновлять можно по расписанию:

REFRESH MATERIALIZED VIEW fast_report;

#db

👉 @database_info

Оптимизируем SQL-запросы – индексы, которые вы могли забыть

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

✅ Составные индексы
Ошибка: делать индекс на одно поле, если запрос использует WHERE col1 = X AND col2 = Y.
Правильный индекс:

CREATE INDEX idx_example ON table_name (col1, col2);

📌 Запрос ускорится, потому что БД не будет делать лишние проверки.

✅ Индекс для ORDER BY
Ошибка: сортировка без индекса приводит к сканированию всей таблицы.
Решение – индекс в порядке сортировки:

CREATE INDEX idx_order ON table_name (col1 ASC);

✅ Индекс на FOREIGN KEY
Ошибка: внешний ключ без индекса – медленный джойн.
Исправляем:

CREATE INDEX idx_fk ON table_name (foreign_key_column);

🔍 Бонус: если не знаете, какой индекс поможет – посмотрите EXPLAIN ANALYZE в PostgreSQL или EXPLAIN в MySQL.

#db

👉 @database_info

Комплексное техническое руководство для опытных администраторов баз данных: Обеспечение целостности данных

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

https://bookflow.ru/kompleksnoe-tehnicheskoe-rukovodstvo-dlya-opytnyh-administratorov-baz-dannyh-obespechenie-tselostnosti-dannyh/

#db

👉 @database_info