Backend Portal | Программирование

Бесплатный инструмент для визуализации плана SQL : https://explain.datadoghq.com/ В настоящее время для PostgreSQL, MySQL, MSSQL и MongoDB 👉 @BackendPortal

Cursor недавно выкатил Composer, свою agentic-модель для кодинга, и заявил, что агент может быть примерно в 4 раза быстрее. Alex Xu пообщался с командой Cursor, в частности с Lee Robinson, чтобы разобраться, как это устроено внутри и за счет чего получается скорость. Кодовый агент это система, которая умеет взять задачу, изучить репозиторий, править сразу несколько файлов и итеративно доводить до состояния, где сборка и тесты проходят. Внутри Cursor сначала работает роутер: он выбирает подходящую модель для запроса (в том числе Composer), чтобы дальше она вела задачу. Дальше запускается цикл: вытягиваем самый релевантный код (retrieval контекста), через инструменты открываем и редактируем файлы, гоняем команды в песочнице. Как только тесты зеленые, задача закрыта. Чтобы этот цикл не тормозил, Cursor опирается на три техники: 1. Mixture-of-Experts (MoE): разреженная MoE-архитектура, где на каждый токен активируется только часть весов модели. 2. Спекулятивный декодинг: маленькая модель черновиком накидывает сразу несколько токенов, а большая модель параллельно их проверяет, чтобы снизить задержку. 3. Уплотнение контекста (context compaction): старые шаги суммаризируются, а в промпте остается только активный рабочий набор, чтобы контекст по мере итераций не раздувался и оставался максимально релевантным и коротким. Фулл статья 👉 @BackendPortal

Топовый лайфхак с GitHub: добавь 0 к URL pull request, и ИИ поможет тебе ревьюнуть и понять изменения, которые хотят влить. 👉 @BackendPortal

Не пиши в SQL = NULL или != NULL Для NULL всегда используй IS NULL / IS NOT NULL NULL это “нет значения / неизвестно”, и обычные операторы сравнения (=, !=, <, >) с ним не работают, потому что NULL не равен, не больше и не меньше вообще ничего. = / != сравнивают значения. А NULL это не значение, а отсутствие значения. Поэтому IS / IS NOT проверяют именно наличие или отсутствие значения. 👉 @BackendPortal

Хотите развивать продукты, которыми ежедневно пользуются миллионы людей, и напрямую влиять на их опыт? 😎 Авито ищет специалистов: 1️⃣ Старший Android-разработчик в команду Seller Experience Вместе с командой вы будете работать над Android-приложением в кросс-функциональной среде: тесно взаимодействовать с бэкенд-разработчиками и коллегами с других платформ, участвовать в принятии технических решений и планировании разработки, а также писать различные тесты — от Unit до E2E. 2️⃣ Старший Android-разработчик в команду монетизации Вам предстоит заниматься высоконагруженным мобильным приложением и напрямую влиять на пользовательский опыт. Вы будете развивать и улучшать архитектуру и брать на себя ответственность за часть функциональности, плотно взаимодействовать с продуктом, дизайнерами, бэкенд-разработчиками и QA. 3️⃣ Старший Python-разработчик в команду Авито Авто Вы станете улучшать архитектуру ассистента и работать с высоконагруженными компонентами: писать код, проводить Code Review и совершенствовать инженерные инструменты команды, а также погружаться в специфику бизнеса и взаимодействовать с продуктом, ML-командой и фронтендом. А ещё вас ждёт: - возможность реализовать свои идеи в проекте с многомиллионной аудиторией - талантливая команда, готовая поддержать ваши инициативы - мощное железо, дополнительные мониторы и всё для комфортной работы - прозрачная система премий и достойная зарплата (обсуждаем на собеседовании) - личный бюджет на обучение: книги, курсы и конференции - забота о здоровье: ДМС со стоматологией с первого дня, терапевт и массажист в офисе - удалёнка и уютные офисы в разных городах. Откликайтесь по ссылкам!

Датабейз штуки, которые я бы изучал, если бы хотел реально глубоко понять масштабирование: Сохрани в закладки. ▪️B+ деревья ▪️LSM-деревья ▪️Write-Ahead Logging (WAL) ▪️Двухфазный коммит (2PC) ▪️Трехфазный коммит (3PC) ▪️Реплики для чтения (read replicas) ▪️Репликация leader-follower ▪️Партиционирование (partitioning) ▪️Кэширование запросов (query caching) ▪️Вторичные индексы (secondary indexes) ▪️Векторные индексы (FAISS, HNSW) ▪️Распределенные join’ы (distributed joins) ▪️Материализованные представления (materialized views) ▪️Event Sourcing ▪️Change Data Capture (CDC) 👉 @BackendPortal

Каждый разработчик должен понимать: изоляция арендаторов это не проблема базы данных. Это проблема масштаба последствий. Я понял это на практике. Один пропущенный фильтр по арендатору. И обычный выклад превращается в инцидент безопасности. Любая система с несколькими арендаторами рано или поздно выбирает один из трёх уровней изоляции. У каждого свой баланс между безопасностью, ценой и операционной проблемой. 1. Отдельная база данных на арендатора Самая сильная изоляция. У каждого арендатора своя база. Никаких общих таблиц. Никакого общего состояния. Плюсы очевидны. Баг в одном арендаторе не утечёт в данные другого. Проверки проще. Разговоры про соответствие требованиям короче. Если что-то ломается, масштаб последствий небольшой. Минусы приходят позже. Нагрузка на сопровождение растёт очень быстро. Сотни или тысячи баз. Миграции превращаются в оркестрацию. Стоимость растёт вместе с числом арендаторов, а не с реальным использованием. Подходит, когда арендаторы крупные, сильно регулируемые или с высоким риском. Плохо работает, если бездумно применять к “длинному хвосту” мелких клиентов. 2. Отдельная схема на арендатора Средний вариант, который многие недооценивают. Одна база на всех, но у каждого арендатора отдельная схема. Таблицы изолированы, а инфраструктура остаётся более-менее управляемой. Границы яснее, чем при изоляции по строкам. Нет взрыва количества баз. Проверки остаются разумными. Большинство случайных утечек просто исчезают. Но сложность всё равно накапливается. Миграции нужно прогонять по множеству схем. Отчёты по всем арендаторам сразу становятся неудобными. Автоматизация не опция, а необходимость. Без неё модель разваливается под собственным весом. Хорошо подходит, когда арендаторы сильно отличаются по размеру и хочется изоляцию без полной физической раздельности. 3. Изоляция по строкам Самый дешёвый и самый опасный вариант. Все арендаторы сидят в одних таблицах. Изоляция держится на столбце tenant_id и на том, как ты пишешь запросы. Инфраструктура простая, цена низкая, масштабировать легко. Риск жесткий. Один пропущенный фильтр и утечка данных. Один рефакторинг и изоляция сломалась. Один спешный хотфикс и можно открыть доступ ко всему. Безопасность зависит от того, что каждый слой всегда всё делает правильно. Это работает только если поставить мощные “перила”: жёсткое ограничение запросов по арендатору, политики на уровне базы, принудительная проверка на уровне сервисов, и тесты, которые специально пытаются выйти за границы арендатора. Без этого ты ставишь компанию на дисциплину. Изоляция арендаторов это не выбор способа хранения. Это решение про доверие. Запомни: это классический вопрос на собеседованиях. 👉 @BackendPortal

А что если можно копировать гигабайты данных, вообще не копируя их? Базы, рантаймы языков и ОС по сути так и делают через copy-on-write (COW). Классический пример: fork процесса. Когда ты форкаешь unix-процесс, формально создается полная копия памяти родителя. Но реально дублировать гигабайты RAM было бы адски медленно и тупо расточительно. Поэтому сначала оба процесса просто указывают на одни и те же страницы памяти. А настоящая копия страницы делается только в момент записи, когда кто-то пытается ее поменять. В итоге копирование откладывается, и ты вообще не платишь за те данные, которые не меняются. Языки программирования типа PHP и Ruby используют похожую идею. Когда ты присваиваешь уже существующее значение новой переменной, копия не создается сразу, она появляется только если значение потом модифицируют. 👉 @BackendPortal

SYN Flood это одна из самых старых DoS-атак, и она до сих пор работает. Вот что происходит под капотом. TCP-соединение поднимается через three-way handshake: клиент шлет SYN, сервер отвечает SYN-ACK, клиент завершает ACK. Фишка в том, что на этом этапе сервер держит состояние для каждой “полуоткрытой” сессии в очереди backlog и под это выделяются ресурсы. В SYN Flood атакующий шлет тысячи SYN-пакетов, но рукопожатие не завершает. Сервер продолжает ждать ACK, backlog забивается, и когда очередь переполнена, легитимные клиенты уже не могут подключиться. Получается DoS. Почему атака такая живучая: из-за асимметрии. Нападающий кидает крошечные пакеты почти бесплатно, а серверу на каждый приходится тратить ресурсы. Даже слабая машина может уложить куда более мощный сервер. Факт: SYN-флуды в прошлом валили GitHub, Cloudflare и разные базы. Защита обычно такая: 1. лимитить SYN от одного IP 2. дропать пакеты от известных плохих источников 3. и самое эффективное: SYN cookies С SYN cookies сервер вообще ничего не хранит на этапе “полуоткрыто”. Он кодирует нужную инфу (IP клиента, порт, таймстамп и т.д.) в initial sequence number у SYN-ACK, который отправляет в ответ. Номер генерируется криптографически, подделать его сложно. В итоге handshake становится по сути stateless со стороны сервера, пока клиент не докажет, что он реальный. Ресурсы резервируются только после верификации. Кстати, в большинстве современных ОС поддержка SYN cookies уже встроена. В Linux это включается так: net.ipv4.tcp_syncookies = 1. Если хочется копнуть глубже, статьи в Wikipedia по теме реально норм, плюс можно добить деталями через любимую LLM. 👉 @BackendPortal

JSON и JSONB колонки удобны тем, что туда можно просто закинуть любые “безсхемные” данные, но иногда хочется хоть немного это зажать правилами. Для этого можно использовать расширение pg_jsonschema: задаешь JSON Schema и получаешь больше контроля над тем, какой формы данные вообще имеют в этих колонках. 👉 @BackendPortal