15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Postgres 18 теперь поддерживает OAUTH 2.0 для аутентификации пользователей.
👉 @BackendPortal
Dockerfile доктор уже тут: переписывает файлы Dockerfile для уменьшения размера и повышения безопасности
👉 @BackendPortal
Не пиши в SQL = NULL или != NULL
Для NULL всегда используй IS NULL / IS NOT NULL
NULL это “нет значения / неизвестно”, и обычные операторы сравнения (=, !=, <, >) с ним не работают, потому что NULL не равен, не больше и не меньше вообще ничего.
= / != сравнивают значения. А NULL это не значение, а отсутствие значения. Поэтому IS / IS NOT проверяют именно наличие или отсутствие значения.
👉 @BackendPortal
Как работает NAT
👉 @BackendPortal
Бесплатный инструмент для визуализации плана SQL : https://explain.datadoghq.com/
В настоящее время для PostgreSQL, MySQL, MSSQL и MongoDB
👉 @BackendPortal
Топовый лайфхак с GitHub: добавь 0 к URL pull request, и ИИ поможет тебе ревьюнуть и понять изменения, которые хотят влить.
👉 @BackendPortal
Хотите развивать продукты, которыми ежедневно пользуются миллионы людей, и напрямую влиять на их опыт?
😎 Авито ищет специалистов:
1️⃣ Старший Android-разработчик в команду Seller Experience
Вместе с командой вы будете работать над Android-приложением в кросс-функциональной среде: тесно взаимодействовать с бэкенд-разработчиками и коллегами с других платформ, участвовать в принятии технических решений и планировании разработки, а также писать различные тесты — от Unit до E2E.
2️⃣ Старший Android-разработчик в команду монетизации
Вам предстоит заниматься высоконагруженным мобильным приложением и напрямую влиять на пользовательский опыт. Вы будете развивать и улучшать архитектуру и брать на себя ответственность за часть функциональности, плотно взаимодействовать с продуктом, дизайнерами, бэкенд-разработчиками и QA.
3️⃣ Старший Python-разработчик в команду Авито Авто
Вы станете улучшать архитектуру ассистента и работать с высоконагруженными компонентами: писать код, проводить Code Review и совершенствовать инженерные инструменты команды, а также погружаться в специфику бизнеса и взаимодействовать с продуктом, ML-командой и фронтендом.
А ещё вас ждёт:
- возможность реализовать свои идеи в проекте с многомиллионной аудиторией
- талантливая команда, готовая поддержать ваши инициативы
- мощное железо, дополнительные мониторы и всё для комфортной работы
- прозрачная система премий и достойная зарплата (обсуждаем на собеседовании)
- личный бюджет на обучение: книги, курсы и конференции
- забота о здоровье: ДМС со стоматологией с первого дня, терапевт и массажист в офисе
- удалёнка и уютные офисы в разных городах.
Откликайтесь по ссылкам!
Каждый разработчик должен понимать: изоляция арендаторов это не проблема базы данных.
Это проблема масштаба последствий.
Я понял это на практике.
Один пропущенный фильтр по арендатору.
И обычный выклад превращается в инцидент безопасности.
Любая система с несколькими арендаторами рано или поздно выбирает один из трёх уровней изоляции.
У каждого свой баланс между безопасностью, ценой и операционной проблемой.
1. Отдельная база данных на арендатора
Самая сильная изоляция. У каждого арендатора своя база. Никаких общих таблиц. Никакого общего состояния.
Плюсы очевидны.
Баг в одном арендаторе не утечёт в данные другого. Проверки проще. Разговоры про соответствие требованиям короче. Если что-то ломается, масштаб последствий небольшой.
Минусы приходят позже.
Нагрузка на сопровождение растёт очень быстро. Сотни или тысячи баз. Миграции превращаются в оркестрацию. Стоимость растёт вместе с числом арендаторов, а не с реальным использованием.
Подходит, когда арендаторы крупные, сильно регулируемые или с высоким риском. Плохо работает, если бездумно применять к “длинному хвосту” мелких клиентов.
2. Отдельная схема на арендатора
Средний вариант, который многие недооценивают.
Одна база на всех, но у каждого арендатора отдельная схема. Таблицы изолированы, а инфраструктура остаётся более-менее управляемой.
Границы яснее, чем при изоляции по строкам. Нет взрыва количества баз. Проверки остаются разумными. Большинство случайных утечек просто исчезают.
Но сложность всё равно накапливается.
Миграции нужно прогонять по множеству схем. Отчёты по всем арендаторам сразу становятся неудобными. Автоматизация не опция, а необходимость. Без неё модель разваливается под собственным весом.
Хорошо подходит, когда арендаторы сильно отличаются по размеру и хочется изоляцию без полной физической раздельности.
3. Изоляция по строкам
Самый дешёвый и самый опасный вариант.
Все арендаторы сидят в одних таблицах. Изоляция держится на столбце tenant_id и на том, как ты пишешь запросы. Инфраструктура простая, цена низкая, масштабировать легко.
Риск жесткий.
Один пропущенный фильтр и утечка данных. Один рефакторинг и изоляция сломалась. Один спешный хотфикс и можно открыть доступ ко всему. Безопасность зависит от того, что каждый слой всегда всё делает правильно.
Это работает только если поставить мощные “перила”: жёсткое ограничение запросов по арендатору, политики на уровне базы, принудительная проверка на уровне сервисов, и тесты, которые специально пытаются выйти за границы арендатора.
Без этого ты ставишь компанию на дисциплину.
Изоляция арендаторов это не выбор способа хранения. Это решение про доверие.
Запомни: это классический вопрос на собеседованиях.
👉 @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
JavaScript, Ruby и Go используют сборщик мусора для управления памятью.
Но ты знал, что у SSD тоже есть свой GC?
SSD с большим количеством записей и удалений постоянно “перекладывает” данные, и этим занимается сборщик мусора, встроенный прямо в прошивку, которая крутится на контроллере SSD.
Из-за этого последовательная запись до сих пор предпочтительнее случайной, даже если у тебя не HDD.
👉 @BackendPortal
Колонарное хранилище vs построчное (row store) наглядно
Берем простую агрегацию и сравниваем, как она выполняется в row store и columnar store.
В row store данные лежат строками, поэтому движку приходится читать каждую строку целиком, чтобы из нее вытащить значение колонки age.
В columnar store данные лежат по колонкам, поэтому он читает сразу только значения колонки age, без трогания остальных полей и без лишнего I/O.
👉 @BackendPortal
Учись программированию, Cloud и DevOps через практику
Бесплатные серверы и реальные задания.
✓ Практикуй Git и Linux-серверы
✓ Создавай и тестируй ресурсы AWS без страха
✓ Kubernetes, Docker, Terraform и другое
Регистрация не нужна: вперёд
👉 @BackendPortal
Познакомься с Devin Review: это переосмысленный интерфейс для понимания сложных PR.
Современные инструменты для код-ревью на деле не делают чтение кода проще. Devin Review прокачивает понимание и помогает перестать пропускать слоп.
Вместо алфавитного списка файлов он группирует связанные изменения и раскладывает их в логическом порядке, плюс дает короткое описание каждой группы. Отдельно умеет находить перемещенный и скопированный код, отделяя сигнал от шума.
Еще внутри есть агент, который ловит потенциальные баги и помечает их по уверенности и критичности. Причем он подсвечивает не только прямые баги, но и спорные решения/паттерны, которые потом превращаются в техдолг. Маркировка простая: красный срочно смотреть, оранжевый стоит глянуть, серый просто к сведению.
Плюс можно обсудить PR в чате с Devin, с контекстом всего репо. ⌨️
Как зайти:
- прямо на devinreview.com (можно без аккаунта)
- или заменить github на devinreview в ссылке PR
- или дернуть из репы: npx devin-review {pr-link}
👉 @BackendPortal
Алгоритм ленты рекомендаций X/Twitter теперь опенсорс
👉 @BackendPortal
Все надоело и пропал интерес, чувствуешь себя амебой и хочется только залипать в телефоне. Бывает?
Homo Manifestans — канал для айтишников, у которых периодически опускаются руки и отключается мозг, ибо переработки и постоянная тревожность не приводят к другим исходам 🤗
✓ Как научиться отвлекаться от работы и отдыхать?
✓ Как совместить кучу рабочих задач и время с семьей?
✓ Как справиться с прокрастинацией?
✓ Как не растерять запал, даже если начальник и коллеги 💩 и кажется, что ничего не выходит?
Подписывайтесь на канал @vadimpetrovpsi и научитесь работать без упахивания, выгорания и ущерба для личной жизни!
Псс. Заходите в закреп — там много полезного, и даже бесплатный мини-курс по выходу из апатии:
👉 /channel/+LEEr5GHeBHFlMWZi
Строки в PostgreSQL неизменяемые и хранятся в heap. У каждой строки есть скрытый идентификатор CTID, который указывает на ее физическое местоположение на диске.
CTID это идентификатор-кортеж из двух частей: номер страницы и индекс (позиция) внутри этой страницы. Посмотреть его можно простым запросом:
SELECT ctid, * FROM your_table;
(0,1), (0,2), (1,1), где первое число это страница, а второе это позиция.
В этом туториале объясняется, что такое JWT, как они работают, какие бывают техники подписи и какие есть best practices по безопасности.
👉 @BackendPortal
Твои Postgres-серваки сейчас плавятся? Поздравляю. И да, тебе нужен PG Dog.
Его основатель Lev один из самых сильных ребят в теме масштабирования и шардинга БД. Он делал это для Instacart, и его софт может сделать это и для тебя.
Если реплики начинают отставать, а IOPS упёрся в потолок, значит, пора.
https://pgdog.dev/
👉 @BackendPortal
GitHub хранит миллионы репозиториев примерно так же, как они лежат у нас локально: буквально как git-репозитории. Ничего особо сверхъестественного
Только вместо одной копии GitHub хранит минимум три копии каждого репозитория, чтобы код никогда не потерялся. Эта система репликации у них называется Spokes.
Когда мы пушим код, запись не принимается, пока строгая “большинство” реплик не сможет применить изменение и получить тот же результат, то есть минимум 2 из 3.
Интересно, что система следит за реальным прикладным трафиком, чтобы детектить сбои. Если три запроса подряд падают на одном из серверов репозитория, сервер помечается оффлайн, и трафик уходит на другие реплики за секунды. Никаких heartbeat-ов, просто мониторинг реальных операций пользователей.
Каждая реплика живёт в отдельной стойке. Если падает целая стойка, репозитории остаются доступными, потому что другие копии лежат в других местах. А когда нужно чиниться после падения сервера, помогает весь кластер: чем больше кластер, тем быстрее он восстанавливается.
Spokes отказывает в write-операциях, если не может закоммитить их хотя бы в двух местах. Это гарантирует, что если твой push прошёл, код уже в безопасности.
И поэтому же GitHub отклоняет пуши при частичных авариях. Чтение ещё может работать, а запись падает, потому что система не готова рисковать потерей данных.
Примерно так GitHub хранит репозитории и, что важнее, выбирает простой дизайн с упором на консистентность, а не на “лишь бы запись прошла” при просадках по доступности/надёжности.
Надеюсь, тебе тоже было интересно.
👉 @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
Не пиши в SQL = NULL или != NULL
Для NULL всегда используй IS NULL / IS NOT NULL
NULL это “нет значения / неизвестно”, и обычные операторы сравнения (=, !=, <, >) с ним не работают, потому что NULL не равен, не больше и не меньше вообще ничего.
= / != сравнивают значения. А NULL это не значение, а отсутствие значения. Поэтому IS / IS NOT проверяют именно наличие или отсутствие значения.
👉 @BackendPortal
Датабейз штуки, которые я бы изучал, если бы хотел реально глубоко понять масштабирование:
Сохрани в закладки.
▪️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
А что если можно копировать гигабайты данных, вообще не копируя их?
Базы, рантаймы языков и ОС по сути так и делают через copy-on-write (COW).
Классический пример: fork процесса.
Когда ты форкаешь unix-процесс, формально создается полная копия памяти родителя. Но реально дублировать гигабайты RAM было бы адски медленно и тупо расточительно.
Поэтому сначала оба процесса просто указывают на одни и те же страницы памяти. А настоящая копия страницы делается только в момент записи, когда кто-то пытается ее поменять. В итоге копирование откладывается, и ты вообще не платишь за те данные, которые не меняются.
Языки программирования типа PHP и Ruby используют похожую идею. Когда ты присваиваешь уже существующее значение новой переменной, копия не создается сразу, она появляется только если значение потом модифицируют.
👉 @BackendPortal
JSON и JSONB колонки удобны тем, что туда можно просто закинуть любые “безсхемные” данные, но иногда хочется хоть немного это зажать правилами.
Для этого можно использовать расширение pg_jsonschema: задаешь JSON Schema и получаешь больше контроля над тем, какой формы данные вообще имеют в этих колонках.
👉 @BackendPortal
👩💻 Всем программистам посвящается!
Вот 14 авторских обучающих IT каналов по самым востребованным областям программирования:
Выбирай своё направление:
👩💻 Python — t.me/python_ready
🤔 InfoSec & Хакинг — t.me/hacking_ready
🖥 SQL & Базы Данных — t.me/sql_ready
🤖 Нейросети — t.me/neuro_ready
👩💻 Frontend — t.me/frontend_ready
👩💻 IT Новости — t.me/it_ready
👩💻 C/C++ — /channel/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
📌 Гайды, шпаргалки, задачи, ресурсы и фишки для каждого языка программирования!
Если я говорю “горизонтальное масштабирование”, ты, скорее всего, автоматически думаешь про load balancer.
Вот 2 способа масштабироваться дальше, чем просто балансировщик.
При горизонтальном дублировании ты копируешь часть системы, чтобы переваривать больше нагрузки, и распределяешь работу между этими копиями.
Самый очевидный вариант горизонтального дублирования это как раз load balancer. Он:
• распределяет запросы
• видит, когда нода умерла, и убирает ее из пула
1. Competing Consumer Pattern
Суть паттерна в том, чтобы раскидать нагрузку и поднять throughput.
Идеально, когда у тебя есть обработчики задач. Например, система должна давать пользователям импортировать и обрабатывать большие файлы.
Ты кладешь каждый загруженный файл в очередь, и много консьюмеров “соревнуются” за то, кто заберет задачу и обработает ее.
2. Read Replicas для read-нагрузки
Чтобы разгрузить primary базу по чтениям, ты поднимаешь read replicas.
Работает отлично, если основная нагрузка на систему в основном чтение.
Пример: e-commerce. Primary база принимает все записи, а реплики обслуживают тяжелые чтения, типа карточек товара или истории заказов пользователя.
Горизонтальное дублирование обычно довольно прямолинейное.
Если вертикально масштабироваться уже нельзя, это обычно следующее, куда я бы смотрел.
Если ты можешь нормально “разрезать” работу между копиями, это очень элегантный способ разнести нагрузку и снизить конкуренцию за ресурсы.
Но есть нюанс: нужно больше инфраструктуры, и это, конечно, дороже.
Ты делал что-то из этого?
👉 @BackendPortal
Фан-факт: OpenAI тянет 800 млн пользователей в ChatGPT всего на одном primary PostgreSQL и 50 read-репликах 🤯
Сегодня OpenAI выкатили инженерный пост о том, как они масштабировали Postgres, чтобы обслуживать эти 800 млн пользователей: один primary и 50 мульти-региональных реплик.
Внутри разбирают свой подход к масштабированию, прокси PgBouncer, локи вокруг кэша и каскадные read-реплики. Реально выглядит аккуратно и впечатляюще.
ВОТ короткое видео на YouTube, где разбирают этот пост и раскладывают нюансы по полочкам.
Зацени, видос короткий
👉 @BackendPortal
Uber выложили в опенсорс свою платформу метрик M3, и пока я бегло смотрел, как она устроена, наткнулся на подход под названием LTTB downsampling. Вот о чём речь...
LTTB расшифровывается как Largest Triangle Three Buckets. Это алгоритм даунсэмплинга, который помогает эффективно запрашивать и визуализировать миллионы точек таймсерий. Идея в том, чтобы сохранить визуальную форму графика, но сильно сократить число точек, которые нужно рендерить.
За счёт этого фронтенду легче: меньше точек для отрисовки и меньше данных надо гонять по сети.
Работает так: временной ряд делится на “бакеты”, и из них выбираются точки, которые сохраняют максимальную “визуальную площадь”. То есть вместо случайной выборки или простого усреднения, LTTB оставляет точки так, чтобы на графике не потерялись пики, провалы и общий тренд.
Механика простая: берутся три точки за раз (предыдущая, текущая, следующая) и считается площадь треугольника, который они образуют. Выбирается та точка, которая даёт самый большой треугольник. В итоге важные визуальные особенности переживают даунсэмплинг.
С таким подходом можно ужать 10 000 точек до 500 и всё равно получить график, который выглядит почти так же, как исходный. Помимо M3, системы вроде Grafana, InfluxDB и Prometheus тоже взяли LTTB или похожие техники даунсэмплинга.
Забавно, что такая, казалось бы, простая штука как “какие точки оставить?” внезапно превращается в реально интересную задачу.
👉 @BackendPortal
Если protobuf уже компактный бинарный формат, есть ли вообще смысл дополнительно жать его Snappy? Вот что на самом деле делает Uber M3...
Uber M3 принимает больше миллиарда датапоинтов в секунду (масштаб реально дикий) и при этом принимает данные по HTTP/1.1 в виде Snappy-сжатого protobuf.
Protobuf сам по себе эффективный, да. Но у телеметрии есть особенность: она очень повторяющаяся. Одни и те же имена метрик, похожие наборы тегов, повторяющиеся hostnames, одинаковая структура полей в тысячах точек. Из-за этой избыточности такие данные отлично сжимаются даже быстрым алгоритмом вроде Snappy.
M3 использует Snappy-сжатый protobuf поверх HTTP для своего Prometheus remote write endpoint. Причина простая: на огромном масштабе тебе нужна компрессия, которая не станет узким местом.
* Snappy очень быстро сжимает и разжимает
* он ставит скорость выше коэффициента сжатия
* CPU-оверхед и на клиенте, и на коллекторе остается минимальным
* клиентам телеметрии не стоит жечь CPU на компрессию, когда они должны заниматься реальной работой
Забавный факт: на масштабе бутылочным горлышком становится вообще все. Ты пытаешься экономить каждый бит и каждый CPU-цикл. Нужно просто хорошо понимать кейс, замечать паттерны и выбирать то, что подходит именно тебе.
👉 @BackendPortal
7 обязательных сложностей по времени для собесов:
1. O(1) - константное время
* Время не меняется независимо от размера входа.
* Пример: доступ к элементу массива по индексу.
2. O(log n) - логарифмическое время
* Растет медленно по мере увеличения входа. Обычно в алгоритмах, которые на каждом шаге делят задачу пополам.
* Пример: бинарный поиск в отсортированном массиве.
3. O(n) - линейное время
* Растет линейно вместе с размером входа.
* Пример: поиск элемента в массиве перебором.
4. O(n log n) - линеарифмическое время
* Растет чуть быстрее, чем линейное. Для каждого элемента входа делается логарифмическое число операций.
* Пример: сортировка массива quick sort или merge sort.
5. O(n^2) - квадратичное время
* Растет пропорционально квадрату размера входа.
* Пример: bubble sort, который сравнивает и при необходимости меняет местами каждую пару элементов.
6. O(2^n) - экспоненциальное время
* Время удваивается при добавлении каждого элемента во вход. Для больших n становится непрактично.
* Пример: генерация всех подмножеств множества.
7. O(n!) - факториальное время
* Время пропорционально факториалу размера входа.
* Пример: генерация всех перестановок множества.
👉 @BackendPortal