DEV Community | CMD

Почему не стоит использовать `OFFSET` для пагинации? 📑 Когда мы делаем постраничный вывод, стандартный подход выглядит так: SELECT * FROM posts ORDER BY id LIMIT 10 OFFSET 50000. Кажется, что всё ок, но для базы данных это тяжелое испытание. 😰 В чем проблема? 📉 — Пропуск строк: Чтобы отдать 10 строк после OFFSET 50000, СУБД должна честно прочитать первые 50 000 строк с диска, отсортировать их и только потом выбросить, оставив нужный кусочек. — Нагрузка на диск: Чем дальше пользователь листает страницы, тем медленнее работает сайт. На больших офсетах запрос может занимать секунды. — Нестабильность: Если пока пользователь переходит с 1-й на 2-ю страницу, кто-то добавил новый пост, данные «сдвинутся», и юзер увидит один и тот же пост дважды. 🔄 Как делать правильно? (Keyset Pagination / Cursor) 🛠️ Вместо номера страницы передавай ID последнего элемента с предыдущей страницы: SELECT * FROM posts WHERE id > :last_id ORDER BY id LIMIT 10; Плюсы такого подхода: 🚀 — Скорость: База использует индекс по id и мгновенно находит нужную точку входа. Сложность запроса всегда одинакова, неважно, 1-я это страница или 10 000-я. — Консистентность: Новые записи в начале таблицы не сдвигают текущую выдачу для пользователя. — Идеально для бесконечных лент: Именно так работают ленты в соцсетях. 📱 > Когда оставить OFFSET? Только если у тебя маленькие таблицы (до пары тысяч строк) или если пользователю критично иметь возможность прыгнуть сразу на 574-ю страницу. В остальных случаях — используй курсоры. 💎

Почему `JSONB` в Postgres — это киллер-фича? 📄 Многие выбирают MongoDB только из-за гибкости схем, но Postgres со своим типом JSONB давно умеет работать с документами не хуже, сохраняя при этом все плюсы реляционной базы. В чем разница между JSON и JSONB? ⚖️ — JSON: Сохраняет текст «как есть». Быстрая запись, но медленный поиск, так как базе нужно парсить строку при каждом запросе. — JSONB (Binary): Сохраняет данные в скомпилированном бинарном формате. Запись чуть медленнее, зато поиск — реактивный. 🚀 Главные фишки JSONB: 🛠️ — Индексация: Ты можешь создать GIN-индекс на всё содержимое JSON-поля. После этого поиск по ключам внутри документа будет работать мгновенно. — Операторы: Postgres дает мощный синтаксис. Например, оператор @> проверяет, содержит ли JSON определенную пару ключ-значение. — Схема на лету: Нужно добавить поле «настройки уведомлений» только для 5% пользователей? Просто закинь это в JSONB, не делая тяжелых миграций ALTER TABLE. 🏗️ Когда НЕ стоит использовать JSONB? 🛑 — Если данные имеют четкую структуру и они всегда присутствуют — обычные колонки эффективнее и занимают меньше места. — Если тебе нужна строгая валидация типов на уровне БД (хотя в новых версиях можно вешать CHECK на структуру JSON). > Итог: JSONB — идеальный выбор для хранения метаданных, логов событий или динамических атрибутов товара. Это дает гибкость NoSQL без отказа от ACID и мощных JOIN-ов. 💎

Rate Limiting: Как защитить API от перегрузок и ботов 🛡️ Если твой эндпоинт открыт для всего интернета, рано или поздно кто-то начнет заваливать его запросами — будь то кривой скрипт коллеги или целенаправленная DDoS-атака. Чтобы сервер не лег, нужно ограничивать количество запросов. Популярные алгоритмы: ⚙️ — Token Bucket (Корзина токенов): У пользователя есть «корзина» с токенами. Каждый запрос забирает один. Токены пополняются с фиксированной скоростью. Если корзина пуста — запрос отклоняется. Позволяет обрабатывать небольшие всплески трафика. — Fixed Window (Фиксированное окно): Самый простой вариант. Разрешаем, например, 100 запросов в минуту. В 00:01 счетчик сбрасывается. — Минус: Если пользователь пришлет 100 запросов в 00:59 и еще 100 в 01:01, сервер получит 200 запросов за пару секунд. — Sliding Window Log (Скользящее окно): Самый точный, но дорогой по памяти метод. Мы храним таймстамп каждого запроса и считаем их количество за последние 60 секунд. Где настраивать? 🛠️ — Инфраструктура: На уровне Nginx или Cloudflare. Это самый эффективный способ, так как «плохие» запросы даже не доходят до твоего бэкенда. — Middleware: В самом коде приложения (через Redis). Удобно, если нужно ставить разные лимиты для разных пользователей (например, бесплатный тариф — 10 rpm, Premium — 1000 rpm). Что возвращать клиенту? 🚦 — Если лимит превышен, всегда возвращай статус 429 Too Many Requests. — Хорошим тоном считается добавлять хедер Retry-After, чтобы клиент знал, через сколько секунд можно повторить попытку. > Итог: Rate Limiting — это не только про безопасность, но и про предсказуемость работы твоей системы. Начинай с простых лимитов в Nginx, пока проект не вырос. 🚀

Редко такое рекламируем, но решили поделиться. Наш знакомый ведёт закрытый канал по международным финансовым операциям: обмен, переводы, перестановка средств между странами. — Как не ловить блокировки — Как избежать комиссии при переводах — Как безопасно работать с зарубежными платёжками — Реальные кейсы и инструменты Владислав разбирает реальные кейсы, ошибки, которые приводят к блокировкам по 115-ФЗ и 161-ФЗ, и завтра покажет как открыть зарубежную карту с возможностью расплачиваться заграницей. Подписка ограничена, доступ периодически закрывается: https://t.me/+tfmfkq2rTag4MGNi

Sharding vs Partitioning: В чем разница? 🧩 Когда база данных начинает «задыхаться» от объема данных, бэкенд-инженер встает перед выбором: партиционировать или шардировать. Эти понятия часто путают, но они решают разные задачи. — Partitioning (Секционирование): Это разделение одной большой таблицы на части внутри одного сервера базы данных. 📦 — Как работает: Данные делятся по логическому признаку (например, по датам: один месяц — одна секция). — Зачем: Ускоряет запросы (база сканирует только нужную секцию) и упрощает обслуживание (можно быстро удалить старый месяц целиком). — Sharding (Шардирование): Это разделение данных между разными физическими серверами (узлами). 🌍 — Как работает: Таблица «разрезается» на куски, и каждый кусок уезжает на свой отдельный сервер. За распределение отвечает Sharding Key. — Зачем: Это единственный способ масштабироваться горизонтально, когда ресурсы одного сервера (CPU, RAM, Диск) исчерпаны. Главные отличия: ⚖️ — Сложность: Партиционирование обычно поддерживается БД «из коробки» (Postgres, MySQL). Шардирование требует сложной логики на стороне приложения или использования специальных прокси (Vitess, Citus). — Транзакции: Внутри партиций транзакции работают как обычно. Между шардами (разными серверами) поддерживать ACID крайне сложно и дорого. — Отказоустойчивость: Если упал сервер с партициями — лежит всё. Если упал один шард — остальные 90% данных всё еще доступны. > Золотое правило: Сначала попробуй оптимизировать индексы, затем примени Partitioning, и только если это не помогло — переходи к Sharding. Шардирование — это архитектурный «тяжеловес», который приносит много боли вместе с масштабом. 🚀

Сложные пароли — это не про `VARCHAR(255)` 🔐 Когда мы проектируем таблицу пользователей, часто ставим для пароля VARCHAR(255) по инерции. Но задумывался ли ты, что там происходит на самом деле? Почему длина имеет значение? 📏 — Алгоритм хэширования: Современные алгоритмы, такие как Argon2 или bcrypt, генерируют строку фиксированной длины. Например, bcrypt всегда выдает 60 символов. Использование слишком большого поля просто тратит место (хотя в современных БД это не критично). — Атака на отказ в обслуживании (DoS): Если ты не ограничишь длину входящего пароля в API (например, до 72 символов для bcrypt), злоумышленник может отправить пароль длиной в 1 МБ. Хэширование такой огромной строки сожрет CPU сервера и «положит» его. 🛑 Как делать правильно? 🛠️ — Храни только хэш: Никогда, ни при каких обстоятельствах не храни пароли в открытом виде. Даже если это «временное решение для тестов». 🙅‍♂️ — Соль (Salt): Всегда используй соль, чтобы защититься от радужных таблиц. Современные библиотеки делают это автоматически и включают соль в строку хэша. — Work Factor: Настраивай сложность хэширования (cost) так, чтобы проверка занимала около 200–500 мс. Этого достаточно, чтобы не бесить пользователя, но сделать перебор невыгодным. ⏳ > Совет: Используй тип данных TEXT в Postgres, если не хочешь мучиться с лимитами, но всегда делай валидацию длины входной строки на уровне приложения перед отправкой в хэш-функцию. 🚀

Graceful Degradation: Падаем красиво 📉 В распределенных системах ошибки неизбежны. Вопрос не в том, «упадет ли сервис», а в том, «как приложение поведет себя в этот момент». Graceful Degradation — это стратегия, при которой система отключает второстепенные фичи, чтобы сохранить работоспособность главных. Примеры из жизни: — Онлайн-магазин: Если сервис персональных рекомендаций «приуныл», мы не показываем 500 ошибку. Мы просто скрываем блок «Вам также может понравиться» и даем пользователю купить товар. 🛒 — Netflix: Если сервис превью-картинок тормозит, интерфейс покажет стандартные заглушки или просто текст, но позволит запустить само видео. 🎬 — Поиск: Если тяжелый полнотекстовый поиск перегружен, система может переключиться на простой поиск только по заголовкам. 🔍 Как это реализовать? — Тайм-ауты: Не жди ответа от внешнего API вечно. Ставь жесткий лимит (например, 200мс для фич, которые не критичны). ⏱️ — Fallbacks (Заглушки): Всегда имей план Б. Нет данных из кэша? Покажи статичный список. Нет списка валют? Используй вчерашний курс из БД. 🛡️ — Asynchronous: Выноси всё, что можно, в фон. Если сервис статистики недоступен, сохрани событие в локальную очередь и отправь позже. 📩 > Суть: Лучше работающее приложение на 80%, чем полностью «мертвый» сервис из-за одной незначительной ошибки. Пользователь простит отсутствие рекомендаций, но не простит неработающую кнопку «Оплатить». 🚀

Database Migrations: Почему `ALTER TABLE` на проде — это опасно? ⚠️ Когда проект растёт, менять структуру базы "руками" через консоль — прямой путь к даунтайму. Одна забытая колонка или заблокированная таблица может уронить весь бэкенд. Главные правила безопасных миграций: — Никаких дефолтов в тяжелых таблицах: В старых версиях Postgres добавление колонки с DEFAULT могло заблокировать таблицу на чтение и запись, пока база переписывает все строки на диске. 🛑 — Используй транзакции: Миграция должна быть атомарной. Либо применилось всё, либо ничего. Если на середине процесса вылетит ошибка, база не должна остаться в "промежуточном" состоянии. 🔄 — Разделяй код и миграции: Сначала деплоим миграцию, которая добавляет новую колонку, и только вторым этапом — код, который начинает в неё писать. Так мы избежим ошибок, если старый код увидит незнакомую структуру. 🛠️ — Обратимость (Rollback): На каждую миграцию UP должна быть написана миграция DOWN. Если что-то пошло не так, у тебя должен быть план быстрого отката. ⏪ Инструменты, которые маст-хэв: — Go: golang-migrate или goose — Python: Alembic — Node.js: Knex или Sequelize > Совет: Перед запуском на проде всегда проверяй миграцию на копии реальных данных. То, что на 10 строках летит за миллисекунду, на 10 миллионах может выполняться часы. ⏳

👩‍💻 Всем программистам посвящается! Вот 14 авторских обучающих IT каналов по самым востребованным областям программирования: Выбирай своё направление: 👩‍💻 Python — t.me/python_ready 🤔 InfoSec & Хакинг — t.me/hacking_ready 🖥 SQL & Базы Данных — t.me/sql_ready 🤖 AI & ML — t.me/neuro_ready 👩‍💻 Frontend — t.me/frontend_ready 👩‍💻 IT Новости — t.me/it_ready 👩‍💻 C/C++ — https://t.me/cpp_ready 👩‍💻 C# & Unity — t.me/csharp_ready 👩‍💻 Linux — t.me/linux_ready 👩‍💻 Java — t.me/java_ready 📖 IT Книги — t.me/books_ready 📱 JavaScript — t.me/javascript_ready 🖼️ DevOps — t.me/devops_ready 🖥 Design — t.me/design_ready 📌 Гайды, шпаргалки, задачи, ресурсы и фишки для каждого языка программирования!

Circuit Breaker: Как не дать упавшему сервису добить остальных 🔌 В микросервисах бывает так: сервис А вызывает сервис Б. Сервис Б начал тормозить или прилег отдохнуть. Что делает сервис А? Он продолжает слать запросы, забивая свои потоки ожиданиями, пока тоже не падает. 📉 Решение: Паттерн «Предохранитель» (Circuit Breaker) Работает как автомат в электрощите. У него есть три состояния: 1. Closed (Закрыт): Все хорошо, запросы проходят штатно. ✅ 2. Open (Открыт): Если процент ошибок или таймаутов превысил порог (например, 50% за минуту), предохранитель «выбивает». Запросы к сервису Б больше не шлются — сервис А сразу возвращает ошибку или дефолтное значение (кэш). Это дает сервису Б время «прийти в себя». 🛑 3. Half-Open (Полуоткрыт): Через некоторое время сервис А пробует отправить ОДИН тестовый запрос. Если он прошел успешно — предохранитель закрывается обратно. Если нет — снова уходит в Open. 🔄 Зачем это нужно? * Resilience: Твое приложение не падает целиком из-за одной «приунывшей» интеграции. 🛡️ * User Experience: Пользователь получает мгновенную ошибку или старые данные из кэша вместо бесконечного «колесика» загрузки. ⏳ > Популярные библиотеки: Hystrix (архив), Resilience4j (Java), Gobreaker (Go), Opossum (Node.js).