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

А что если можно копировать гигабайты данных, вообще не копируя их? Базы, рантаймы языков и ОС по сути так и делают через 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

JavaScript, Ruby и Go используют сборщик мусора для управления памятью. Но ты знал, что у SSD тоже есть свой GC? SSD с большим количеством записей и удалений постоянно “перекладывает” данные, и этим занимается сборщик мусора, встроенный прямо в прошивку, которая крутится на контроллере SSD. Из-за этого последовательная запись до сих пор предпочтительнее случайной, даже если у тебя не HDD. 👉 @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++ — 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 📌 Гайды, шпаргалки, задачи, ресурсы и фишки для каждого языка программирования!

Колонарное хранилище vs построчное (row store) наглядно Берем простую агрегацию и сравниваем, как она выполняется в row store и columnar store. В row store данные лежат строками, поэтому движку приходится читать каждую строку целиком, чтобы из нее вытащить значение колонки age. В columnar store данные лежат по колонкам, поэтому он читает сразу только значения колонки age, без трогания остальных полей и без лишнего I/O. 👉 @BackendPortal

Если я говорю “горизонтальное масштабирование”, ты, скорее всего, автоматически думаешь про load balancer. Вот 2 способа масштабироваться дальше, чем просто балансировщик. При горизонтальном дублировании ты копируешь часть системы, чтобы переваривать больше нагрузки, и распределяешь работу между этими копиями. Самый очевидный вариант горизонтального дублирования это как раз load balancer. Он: • распределяет запросы • видит, когда нода умерла, и убирает ее из пула 1. Competing Consumer Pattern Суть паттерна в том, чтобы раскидать нагрузку и поднять throughput. Идеально, когда у тебя есть обработчики задач. Например, система должна давать пользователям импортировать и обрабатывать большие файлы. Ты кладешь каждый загруженный файл в очередь, и много консьюмеров “соревнуются” за то, кто заберет задачу и обработает ее. 2. Read Replicas для read-нагрузки Чтобы разгрузить primary базу по чтениям, ты поднимаешь read replicas. Работает отлично, если основная нагрузка на систему в основном чтение. Пример: e-commerce. Primary база принимает все записи, а реплики обслуживают тяжелые чтения, типа карточек товара или истории заказов пользователя. Горизонтальное дублирование обычно довольно прямолинейное. Если вертикально масштабироваться уже нельзя, это обычно следующее, куда я бы смотрел. Если ты можешь нормально “разрезать” работу между копиями, это очень элегантный способ разнести нагрузку и снизить конкуренцию за ресурсы. Но есть нюанс: нужно больше инфраструктуры, и это, конечно, дороже. Ты делал что-то из этого? 👉 @BackendPortal

Учись программированию, Cloud и DevOps через практику Бесплатные серверы и реальные задания. ✓ Практикуй Git и Linux-серверы ✓ Создавай и тестируй ресурсы AWS без страха ✓ Kubernetes, Docker, Terraform и другое Регистрация не нужна: вперёд 👉 @BackendPortal

Фан-факт: OpenAI тянет 800 млн пользователей в ChatGPT всего на одном primary PostgreSQL и 50 read-репликах 🤯 Сегодня OpenAI выкатили инженерный пост о том, как они масштабировали Postgres, чтобы обслуживать эти 800 млн пользователей: один primary и 50 мульти-региональных реплик. Внутри разбирают свой подход к масштабированию, прокси PgBouncer, локи вокруг кэша и каскадные read-реплики. Реально выглядит аккуратно и впечатляюще. ВОТ короткое видео на YouTube, где разбирают этот пост и раскладывают нюансы по полочкам. Зацени, видос короткий 👉 @BackendPortal