Базы данных (Data Base)
Kanalga Telegram’da o‘tish
Базы данных (Data Base). По всем вопросам @evgenycarter
Ko'proq ko'rsatish
Tarmoq:8 085
Obunachilar
-224 soatlar
-67 kunlar
-2330 kunlar
Postlar arxiv
🔥 Оптимизация SQL-запросов: 5 ключевых техник
Сегодня я покажу вам, как ускорить выполнение SQL-запросов, ведь никто не любит ждать, пока база данных "думает". 🚀
1️⃣ Используйте индексы
Индексы – это ускоритель запросов. Если у вас часто выполняются
WHERE, JOIN или ORDER BY по определенному столбцу – создайте для него индекс. Но не переборщите: индексы ускоряют чтение, но замедляют вставку и обновление данных.
2️⃣ Избегайте SELECT *
Выбирайте только нужные столбцы. SELECT * может загружать ненужные данные и нагружать сервер. Лучше указывать конкретные столбцы.
3️⃣ Нормализация или денормализация?
Иногда стоит разбивать таблицы (нормализация) для устранения дублирования данных. В других случаях – наоборот, объединять (денормализация) ради быстродействия. Анализируйте ситуацию!
4️⃣ Кеширование запросов
Если запрос выполняется часто и данные редко меняются, используйте QUERY CACHE или внешние кеширующие механизмы (Redis, Memcached).
5️⃣ Анализируйте планы выполнения
Команда EXPLAIN в MySQL/PostgreSQL покажет, как СУБД выполняет запрос. Это поможет найти узкие места: медленные JOIN'ы, сканы всей таблицы и т.д.
💡 Используете ли вы эти техники? Напишите, какой метод вам помог ускорить работу БД!
📲 Мы в MAX
#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 Библиотека Системного Администратора
https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др.
https://max.ru/tipsysdmin Типичный Сисадмин
https://max.ru/channel_win_sysadmin Системный Администратор Windows
https://max.ru/channel_linux_admin Linux: Системный администратор
https://max.ru/channel_linuxmod Linux
https://max.ru/channel_i_linux Системный администратор
https://max.ru/channel_devopslib DevOps, SRE, Sysadmin
https://max.ru/channel_devops_star DevOps Star (Звезда Девопса)
Excel лайфхак 📌
https://t.me/Excel_lifehack Excel лайфхак
Английский с нуля 🇬🇧
https://max.ru/UchuEnglish
1C разработка 📌
https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://max.ru/channel_DevLab1C 1С:Предприятие 8
Программирование C++📌
https://max.ru/cpp_lib Библиотека C/C++ разработчика
https://max.ru/channel_cpp_geek C++ geek
Программирование Go📌
https://max.ru/golang_lib Библиотека Go (Golang) разработчика
Программирование React📌
https://max.ru/react_lib React
Программирование Rust📌
https://max.ru/channel_rust_lib
Программирование Python 📌
https://max.ru/python_of Python академия.
https://max.ru/BookPython Библиотека Python разработчика
Java разработка 📌
https://max.ru/bookjava Библиотека Java разработчика
https://max.ru/channel_java_geek Java Geek
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 Обучающие видео, книги по Физике и Математике
Вакансии в IT📌
https://max.ru/progjob
https://max.ru/channel_rabotait
Мир технологий 📌
https://max.ru/mir_teh Канал для любознательных
Городские📌
https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга
https://max.ru/mockva_life Свежие новости Москвы
https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП
https://max.ru/channel_krasnodar_novosty Краснодар Новости
https://max.ru/channel_novosibirsk_novosti Новосибирск
https://max.ru/channel_samara_novosti Новости Самары
https://max.ru/channel_ekaterinburg_novosti Новости Екатеринбурга
https://max.ru/channel_kazan_novosti Новости Казани
https://max.ru/channel_omsk_novosti Новости Омска
https://max.ru/channel_moskva_24 Москва 24
Оптимизация запросов: Индексы vs. Анализ плана выполнения 🚀
Сейчас я покажу вам, почему простое добавление индексов не всегда ускоряет запросы. Часто встречаю ситуацию, когда разработчики по умолчанию добавляют индексы на каждое поле WHERE, но запросы всё равно работают медленно. Давайте разберёмся!
🔹 Миф: индексы всегда ускоряют запросы
На самом деле, индекс может даже замедлить выполнение, если:
✅ Запрос возвращает слишком много строк - сканирование индекса будет дороже, чем полное сканирование таблицы.
✅ Индекс не покрывает весь запрос - приходится делать обращения к основной таблице.
✅ Слишком много индексов - это замедляет INSERT/UPDATE/DELETE.
🔹 Как правильно анализировать?
Используйте
EXPLAIN ANALYZE (PostgreSQL) или EXPLAIN FORMAT=JSON (MySQL) для понимания:
🔍 Используется ли индекс?
🔍 Сколько строк проходит сканирование?
🔍 Есть ли операции сортировки, которые можно избежать с индексом?
🔹 Что делать, если запрос медленный?
1️⃣ Проверить план выполнения (не добавлять индекс вслепую!).
2️⃣ Подумать о составных индексах, если запрос фильтрует по нескольким полям.
3️⃣ Проверить, можно ли избежать сортировки (ORDER BY по индексу).
4️⃣ Рассмотреть материализованные представления для сложных агрегатов.
📲 Мы в MAX
#db
👉 @database_info
🔥 Оптимизация сложных 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 без индексов тормозит запрос.
📲 Мы в MAX
#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. Это поможет вовремя выявить "узкие" места.
📲 Мы в MAX
#db
👉 @database_info
Безумные и забавные факты о SQLite
⚫️SQLite — самая часто разворачиваемая и используемая база данных. На текущий момент активно используется более одного триллиона (1000000000000 или миллиона миллионов) баз данных SQLite.
⚫️Её поддерживают три человека. Они не допускают внешних контрибьюторов.
Скорее всего, SQLite используется больше, чем все остальные движки баз данных суммарно. В мире работают миллиарды копий SQLite. Её можно встретить повсюду.
https://habr.com/ru/companies/ruvds/articles/873816/
📲 Мы в MAX
#db
👉 @database_info
Как лучше всего изучать язык 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. Выберите те темы, которые наиболее актуальны для вас.
📲 Мы в MAX
#db
👉 @database_info
Шардирование базы данных на пальцах
Популярные приложения рано или поздно должны масштабироваться для ускорения доступа к данным и увеличения трафика. Чтобы распределить данные на несколько серверов и обеспечить им безопасность и целостность, нужна база данных с соответствующей архитектурой — шардированная база данных.
Шардирование (шардинг) базы данных — это деление данных на разные фрагменты с целью повышения производительности и надежности. Иногда это понятие путают с репликацией и партицированием, но на самом деле это разные направления масштабирования, которые могут быть реализованы в пределах одной базы данных.
Существует два вида шардирования:
▪Вертикальное (по столбцам): каждый шард содержит часть столбцов массива и все связанные с ними строки данных.
▪Горизонтальное (по каким-либо критериям строки): каждый шард содержит одинаковые столбцы, но разные строки данных.
https://architecturenotes.co/database-sharding-explained/
📲 Мы в MAX
#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 Библиотека Системного Администратора
https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др.
https://max.ru/tipsysdmin Типичный Сисадмин
https://max.ru/channel_win_sysadmin Системный Администратор Windows
https://max.ru/channel_linux_admin Linux: Системный администратор
https://max.ru/channel_linuxmod Linux
https://max.ru/channel_i_linux Системный администратор
https://max.ru/channel_devopslib DevOps, SRE, Sysadmin
https://max.ru/channel_devops_star DevOps Star (Звезда Девопса)
Excel лайфхак 📌
https://t.me/Excel_lifehack Excel лайфхак
Английский с нуля 🇬🇧
https://max.ru/UchuEnglish
1C разработка 📌
https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://max.ru/channel_DevLab1C 1С:Предприятие 8
Программирование C++📌
https://max.ru/cpp_lib Библиотека C/C++ разработчика
https://max.ru/channel_cpp_geek C++ geek
Программирование Go📌
https://max.ru/golang_lib Библиотека Go (Golang) разработчика
Программирование React📌
https://max.ru/react_lib React
Программирование Rust📌
https://max.ru/channel_rust_lib
Программирование Python 📌
https://max.ru/python_of Python академия.
https://max.ru/BookPython Библиотека Python разработчика
Java разработка 📌
https://max.ru/bookjava Библиотека Java разработчика
https://max.ru/channel_java_geek Java Geek
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 Обучающие видео, книги по Физике и Математике
Вакансии в IT📌
https://max.ru/progjob
https://max.ru/channel_rabotait
Мир технологий 📌
https://max.ru/mir_teh Канал для любознательных
Городские📌
https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга
https://max.ru/mockva_life Свежие новости Москвы
https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП
https://max.ru/channel_krasnodar_novosty Краснодар Новости
https://max.ru/channel_novosibirsk_novosti Новосибирск
https://max.ru/channel_samara_novosti Новости Самары
https://max.ru/channel_ekaterinburg_novosti Новости Екатеринбурга
https://max.ru/channel_kazan_novosti Новости Казани
https://max.ru/channel_omsk_novosti Новости Омска
https://max.ru/channel_moskva_24 Москва 24
7 SQL-запросов, которые решают 90% всех задач на работе
Каждый день одно и то же. Открываешь клиент базы данных, чтобы что-то проверить, посчитать или найти. И снова пишешь почти тот же SELECT, что и вчера, с тем же WHERE и JOIN. Знакомо?
SQL в большинстве случаях не требует сложные 100-строчные запросы с вложенными подзапросами на три уровня глубины. Чаще всего нам нужны простые, отточенные и, главное, эффективные конструкции.
В этой статье я собрал 7 таких запросов-«рабочих лошадок». Это не какой-то там справочник, а готовая шпаргалка для реальных задач.
https://habr.com/ru/companies/timeweb/articles/943298/
📲 Мы в MAX
#db
👉 @database_info
Продвинутый курс SQL за час - проще некуда
Сегодня я продолжу рассказывать про SQL и мы погрузимся уже в чуть более интересные запросы, связи и я попробую рассказать максимально просто о связях join и о группировках, на мой взгляд две не самые простые темы.
Содержание:
00:00 - Поехали
01:14 - Сортировка по номеру
03:23 - Ограничение вывода limit
06:30 - Уникальность данных distinct
08:18 - Сложение колонок
11:00 - Псевдонимы
15:35 - join - связи таблиц
27:45 - Left join
29:38 - Right join
35:00 - Быть или не быть (exists)
39:32 - Объединения union
41:42 - Глобальный поиск
43:45 - Агрегатные функции
54:00 - Группировка данных group by
источник
📲 Мы в MAX
#db #SQL
👉 @database_info
Типы JOIN в SQL и когда их применять
- INNER JOIN - пересечение множеств (только совпавшие строки).
- LEFT JOIN - все слева + совпавшие справа (несовпавшие →
NULL).
- RIGHT JOIN - симметричен LEFT, лучше переворачивать под LEFT.
- FULL OUTER JOIN - все слева и справа (где нет пары → NULL).
- CROSS JOIN — декартово произведение (каждая со всеми).
- SELF JOIN - таблица соединяется сама с собой.
- SEMI / ANTI JOIN - “есть/нет соответствия” (через EXISTS / NOT EXISTS).
- LATERAL / APPLY - зависимая подзапросная таблица на строку слева.
1️⃣ INNER JOIN - «строго есть пара»
«Покажи оплаченные заказы с данными клиента».
SELECT o.id, c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.status = 'paid';
SELECT c.id, c.name, COALESCE(COUNT(o.id), 0) AS orders_cnt
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.id, c.name;
-- было:
-- SELECT ... FROM A RIGHT JOIN B ON ...
-- стало:
SELECT ...
FROM B
LEFT JOIN A ON ...
SELECT COALESCE(c.id, o.customer_id) AS customer_key, c.name, o.id AS order_id
FROM customers c
FULL JOIN orders o ON o.customer_id = c.id;
SELECT r.region, q.quarter
FROM regions r
CROSS JOIN quarters q;
SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m ON m.id = e.manager_id;
SELECT c.*
FROM customers c
WHERE EXISTS (
SELECT 1 FROM orders o
WHERE o.customer_id = c.id
AND o.created_at >= CURRENT_DATE - INTERVAL '30 day'
);
JOIN + DISTINCT.
8️⃣ ANTI JOIN (NOT EXISTS) - «кто без соответствий»
«Товары, которые ни разу не покупали в этом году».
SELECT p.*
FROM products p
WHERE NOT EXISTS (
SELECT 1 FROM order_items oi
JOIN orders o ON o.id = oi.order_id
WHERE oi.product_id = p.id
AND o.created_at >= date_trunc('year', CURRENT_DATE)
);
NOT IN с NULL - может дать пустой результат.
9️⃣ LATERAL / APPLY - «топ-N на строку»
«Последний заказ на клиента» (PostgreSQL: LATERAL, SQL Server: APPLY).
SELECT c.id, c.name, o_last.id AS last_order_id
FROM customers c
LEFT JOIN LATERAL (
SELECT o.id
FROM orders o
WHERE o.customer_id = c.id
ORDER BY o.created_at DESC
LIMIT 1
) o_last ON true;
ON:
-- ❌ неверно
SELECT ... FROM c LEFT JOIN o ON o.customer_id = c.id
WHERE o.status = 'paid';
-- ✅ верно
SELECT ... FROM c LEFT JOIN o
ON o.customer_id = c.id AND o.status = 'paid';
LOWER(col)) ломают sargability - лучше нормализовать данные заранее.
- EXISTS чаще лучше, чем JOIN + DISTINCT для фильтрации.
- Проверяйте план. EXPLAIN (ANALYZE, BUFFERS) и сравнение альтернатив.
Сохрани, чтобы не забыть. А как вы чаще фильтруете - через JOIN+DISTINCT или EXISTS?
📲 Мы в MAX
#db #SQL
👉 @database_infoАнтипаттерн: N+1 запросов — как заметить и починить
Вы берёте список сущностей, а потом в цикле для каждой тянете связанные данные. В итоге - 1 запрос за «родителями» + N запросов за «детьми». Латентность растёт линейно от размера выборки.
Симптомы
- В логах много одинаковых коротких запросов.
- Кол-во запросов ≈ размеру списка.
- Страница/endpoint сильно «замедляется» при росте данных.
Плохой пример (SQL + псевдокод)
-- Берём пользователей
SELECT id, name FROM users WHERE active = true;
-- Потом в цикле по каждому:
SELECT count(*) FROM orders WHERE user_id = :id;
SELECT u.id,
u.name,
count(o.*) AS orders_cnt
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name;
# Плохо: в шаблоне/цикле обращаемся к user.orders -> N+1
users = User.objects.filter(active=True)
# Хорошо: подгрузим связи заранее
users = (User.objects
.filter(active=True)
.prefetch_related('orders')) # для 1:N
# для 1:1 / ForeignKey используйте select_related('profile')
# Агрегация без цикла
from django.db.models import Count
users = (User.objects.filter(active=True)
.annotate(orders_cnt=Count('orders')))
from sqlalchemy.orm import selectinload, joinedload
# 1:N — безопаснее selectinload (батчирует IN (...))
users = (session.query(User)
.options(selectinload(User.orders))
.filter(User.active.is_(True))
.all())
# 1:1 — joinedload
user = (session.query(User)
.options(joinedload(User.profile))
.get(user_id))
⚔️ SQL vs NoSQL: Что выбрать для вашего проекта?
Выбор базы данных - одно из ключевых архитектурных решений. Нет универсальной "серебряной пули", есть инструменты под разные задачи. Давайте разберем основные отличия и когда что использовать.
🐘 SQL (Реляционные БД): Порядок и Транзакции
Примеры: PostgreSQL, MySQL, MS SQL, Oracle.
Основа: жесткая схема данных, таблицы, строки, отношения, поддержка ACID транзакций (атомарность, согласованность, изолированность, долговечность).
-- SQL Пример: JOIN трех таблиц
SELECT u.name, o.order_date, p.product_name
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id
WHERE u.country = 'KZ';
// NoSQL Пример (MongoDB): вставка документа пользователя
db.users.insertOne({
name: "Aliya",
age: 28,
address: {
city: "Almaty",
street: "Abay Ave"
},
tags: ["dev", "database"]
});
JOIN-ы (lookup) дорогие и не так эффективны, как в реляционных. Модель данных часто приходится "денормализовать" (дублировать данные).
• Отложенная согласованность: Если вам критично видеть самое последнее записанное значение сразу после записи, будьте осторожны с NoSQL конфигурациями по умолчанию.
Итог:
Выбирайте инструмент под задачу. SQL - для транзакций и структуры, NoSQL - для масштаба и гибкости. Часто в современном мире используют полиглот-архитектуру: SQL для ядра данных, а NoSQL для кэширования (Redis) или хранения логов/аналитики.
Сохрани пост, чтобы освежить в памяти перед проектированием следующей системы! 👇
📲 Мы в MAX
#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 Библиотека Системного Администратора
https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др.
https://max.ru/tipsysdmin Типичный Сисадмин
https://max.ru/channel_win_sysadmin Системный Администратор Windows
https://max.ru/channel_linux_admin Linux: Системный администратор
https://max.ru/channel_linuxmod Linux
https://max.ru/channel_i_linux Системный администратор
https://max.ru/channel_devopslib DevOps, SRE, Sysadmin
https://max.ru/channel_devops_star DevOps Star (Звезда Девопса)
Excel лайфхак 📌
https://t.me/Excel_lifehack Excel лайфхак
Английский с нуля 🇬🇧
https://max.ru/UchuEnglish
1C разработка 📌
https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://max.ru/channel_DevLab1C 1С:Предприятие 8
Программирование C++📌
https://max.ru/cpp_lib Библиотека C/C++ разработчика
https://max.ru/channel_cpp_geek C++ geek
Программирование Go📌
https://max.ru/golang_lib Библиотека Go (Golang) разработчика
Программирование React📌
https://max.ru/react_lib React
Программирование Rust📌
https://max.ru/channel_rust_lib
Программирование Python 📌
https://max.ru/python_of Python академия.
https://max.ru/BookPython Библиотека Python разработчика
Java разработка 📌
https://max.ru/bookjava Библиотека Java разработчика
https://max.ru/channel_java_geek Java Geek
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 Обучающие видео, книги по Физике и Математике
Вакансии в IT📌
https://max.ru/progjob
https://max.ru/channel_rabotait
Мир технологий 📌
https://max.ru/mir_teh Канал для любознательных
Бонус 📌
https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга
https://max.ru/mockva_life Свежие новости Москвы
https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП
🔥 Неправильные типы данных в БД — тихий убийца производительности
Одна из самых частых ошибок — выбирать тип “на всякий случай побольше”.
❌ Примеры антипаттернов:
-
VARCHAR(255) для всего подряд, даже если поле — код из 10 символов.
- TEXT для email-адресов.
- BIGINT для счётчика, где максимум 1000 записей.
- FLOAT для денег (теряешь точность).
✅ Как лучше:
- Размер строки под задачу: VARCHAR(50) для email, CHAR(2) для кода страны.
- Для денег → NUMERIC(10,2) или DECIMAL.
- Для булевых значений → BOOLEAN, а не INT.
- Для дат → DATE или TIMESTAMP, а не строка.
📌 Пример:
-- Плохо
price FLOAT;
-- Хорошо
price NUMERIC(10,2);
🏁До старта обработки миллиарда записей 3… 2… 1… клик
Выбирайте не просто СУБД, а гоночный болид для работы с данными.
ClickHouse® в облаке Selectel — машина, адаптированная под предельные нагрузки и сложные трассы. Отлично работает с векторными типами данных, эффективна в запросах для задач поиска семантического сходства, кластеризации или RAG.
Под капотом — SSD-накопители стандарта NVMe, оперативная память DDR5 и процессоры Intel® Xeon®Gold и AMD EPYC™. Мощное железо для максимальной производительности вашей баз данных.
Пройдемся по базе. Что вас ждет после запуска кластера ClickHouse в облаке Selectel?
⚡Скорость. Кластеры рассчитаны на хранение и быструю обработку даже петабайтов данных и обработку тяжелых аналитических запросов.
⚡Надежность. В Multi-AZ кластерах ноды размещены в разных дата-центрах, чтобы инфраструктура продолжила работу даже при отключении одного из узлов.
⚡Экономичный расход. Может выполнять запросы к данным, хранящимся в S3 в формате Iceberg, без их копирования. Это позволяет сократить расходы более чем в два раза по сравнению с использованием только локальных дисков.
На вас — пилотирование, а обслуживание кластера забирает на себя Selectel.
Ускорьте работу с базами данных в облаке Selectel: https://slc.tl/ywhx8
Реклама. АО "Селектел". erid:2W5zFJF5Fkm
🚨 Антипаттерн: Почему
OFFSET убивает твою базу (и как делать пагинацию правильно)
Привет! Если вы когда-нибудь реализовывали каталог товаров или ленту новостей, то наверняка писали запрос с LIMIT и OFFSET. Для небольших таблиц это работает отлично, но как только проект взлетает и данных становится много, база начинает задыхаться. Давайте разберем, почему так происходит и как это лечить.
❌ Как мы делаем обычно:
SELECT id, title, created_at
FROM articles
ORDER BY created_at DESC
LIMIT 50 OFFSET 100000;
SELECT id, title, created_at
FROM articles
WHERE created_at < '2023-10-25 14:00:00' -- дата из последней записи на предыдущей странице
ORDER BY created_at DESC
LIMIT 50;
created_at не уникально (две статьи вышли в одну секунду), предыдущий запрос может пропустить данные. Используйте уникальный «тайбрейкер» - например, id. В PostgreSQL это можно сделать очень элегантно с помощью кортежей (Row Values):
SELECT id, title, created_at
FROM articles
WHERE (created_at, id) < ('2023-10-25 14:00:00', 10543)
ORDER BY created_at DESC, id DESC
LIMIT 50;
OFFSET / LIMIT: Ок для админок с небольшим трафиком и малым объемом данных (до ~10-50к строк).
• Keyset Pagination: Must-have для бесконечных скроллов (infinite scroll), публичных API и таблиц на миллионы записей.
👇 Скинь ссылку на этот пост фронтендеру, который просит «просто добавить номер страницы» в API. А какой метод пагинации чаще всего используете вы в своих текущих проектах? Делитесь в комментариях!
📲 Мы в MAX
#db
👉 @database_info