15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Если 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
Компилируем Go в TypeScript 😂
Этот тул работает на уровне AST-дерева, позволяя переиспользовать бизнес-логику, алгоритмы и структуры данных между бэкендом и фронтом без переписывания руками
Исходный код этого чуда
👉 @BackendPortal
👩💻 В сеть вывалилась гигантская куча курсов и книг
Держи сотни гигабайт свежих уроков, и каждую неделю мы подкидываем ещё!
• 1612 ГБ — DevOps
• 1402 ГБ — Python
• 1300 ГБ — C, C++
• 1815 ГБ — Frontend
• 1515 ГБ — Backend
• 898 ГБ — ИБ, Хакинг
• 996 ГБ — Kotlin, Swift
• 212 ГБ — JavaScript
• 315 ГБ — Flutter
• 820 ГБ — Go, PHP
• 419 ГБ — Java, Rust
• 648 ГБ — GameDev
• 517 ГБ — Windows, Linux
• 998 ГБ — Дизайн (UX/UI)
• 617 ГБ — Нейросети (ML/RL)
• 546 ГБ — БД (SQL & NoSQL)
• 687 ГБ — Аналитика данных
• 115 ГБ — QA-тестирование
Подписывайся и не плати за то, что можно получить бесплатно
Если деревья тебя пугают, графы наверняка вообще вгоняют в ужас.
Это та тема, про которую большинство молится, лишь бы не попалась на собесе.
Единственная разница между деревом и графом это цикл. всё. если ты умеешь решать на деревьях, то на графах это то же самое: просто добавь массив visited.
Я разобрал 350+ задач по графам и они все укладываются в 7 шаблонов
1. BFS (поиск в ширину)
алгоритм “кратчайшего пути”. если спрашивают shortest path в невзвешенном графе (лабиринт, соцсеть) это он.
хак: очередь. волной, слой за слоем.
2. DFS (поиск в глубину)
алгоритм “исследователь”. когда надо перебрать все варианты или проверить связность.
хак: рекурсия (или стек) + visited, чтобы не зациклиться.
3. Union Find (Disjoint Set)
самый приятный паттерн. для “группировок” и проверки, связаны ли две вершины.
хак: идеально для “number of provinces” и “redundant connection”. path compression делает почти O(1) на операцию.
4. Топологическая сортировка (алгоритм Кана)
звучит сложно, но это просто “упорядочить зависимости”.
как узнать: “course schedule”, “build order”. если A должно быть раньше B, это сюда.
5. Алгоритм Дейкстры
паттерн “google maps”. кратчайший путь во взвешенном графе (у ребер разные веса).
хак: это BFS, только вместо обычной очереди Priority Queue (min-heap).
6. Bellman-Ford
редко, но важно. если есть “отрицательные веса”.
хак: медленнее Дейкстры, зато умеет ловить отрицательные циклы.
7. Floyd-Warshall
паттерн “для ленивых”. находит кратчайшие пути между всеми парами вершин.
хак: просто 3 вложенных цикла. O(N³). юзать только на маленьких графах (N < 500).
👉 @BackendPortal
Деревья это точка, где 90% людей сдаются на DSA
Рекурсия ломает мозг, и на собесе ты просто виснешь
Но как и с массивами, ты просто усложняешь себе жизнь
Я разобрал больше 400 задач по деревьям
И там реально крутятся одни и те же 6 паттернов
1. Level Order Traversal (BFS)
Если задача просит пройти дерево по уровням или найти кратчайший путь в невзвешенном дереве — это оно
Хак: не пытайся всё решать рекурсией, тут нужна очередь
2. Depth First Search (DFS)
Базовая штука. Если надо идти в глубину перед тем как обходить соседей (например проверка пути от корня до листа) — бери это
Хак: выучи Pre-order, In-order и Post-order. Это покрывает процентов 70 задач
3. Path Sum
"найти путь который даёт сумму k". Выглядит страшно, но это просто DFS с накопленной суммой
Хак: вычитай значение узла из цели пока спускаешься вниз. Если на листе цель стала 0 — задача решена
4. Tree Construction
"построить дерево из двух массивов". По сути проверка логики
Хак: ищешь корень (обычно первый или последний элемент обхода), режешь массивы и рекурсишь
5. Lowest Common Ancestor (LCA)
Самый частый вопрос на собесах
Хак: если оба узла меньше текущего — иди влево. Если оба больше — вправо. Если расходятся — вот ответ
6. Serialize & Deserialize
Как сохранить дерево в файл и восстановить обратно
Хак: выбираешь любой обход (например Pre-order) и вставляешь null для пустых детей
400+ страшных задач превращаются в 6 блоков логики
Хватит гриндить 100 рандомных вопросов
Выучи эти 6 и закроешь всю категорию
👉 @BackendPortal
Если готовишься к system design / backend-интервью, можно прогнать этот чек-лист
👉 @BackendPortal
Вышел Go 1.26 Release Candidate 2!
Включает фиксы по безопасности для archive/zip (CVE-2025-61728), net/http (CVE-2025-61726), crypto/tls (CVE-2025-68121, CVE-2025-61730), cmd/go (CVE-2025-61731, CVE-2025-68119).
Скачать: https://go.dev/dl/#go1.26rc2
👉 @BackendPortal
Когда ты используешь ORDER BY, SQL должен решить, куда девать значения NULL.
NULL часто означает:
✅отсутствующие данные
✅неполные записи
✅значение неприменимо
По умолчанию:
✅ одни СУБД ставят NULL в начале
✅другие ставят NULL в конце
Из-за этого один и тот же запрос может выглядеть по-разному в результатах, в зависимости от того, где он выполняется.
Но ты можешь явно указать, как сортировать NULL.
Например:
➡️ORDER BY score ASC NULLS FIRST
Значит: сортировать по score по возрастанию и показывать NULL первыми.
➡️ORDER BY score DESC NULLS LAST
Значит: сортировать по score по убыванию и показывать NULL последними.
👉 @BackendPortal
Подборка учебных материалов для изучения программирования на примере проектов: чекаем
👉 @BackendPortal
Я всегда хотел понять, как SQL-базы реально исполняют JOIN'ы. Теорию я знал, но какое-то время назад потратил пару часов на исходники MySQL, чтобы разобраться в деталях.
Оказалось, что MySQL строит join-планы инкрементально, чтобы найти оптимальный порядок соединений. Он идёт от однотабличных access paths к join'ам на 2 таблицы, затем на 3, и так далее. В качестве оптимизации он отбрасывает поддеревья, которые гарантированно дадут более высокий cost.
Интересно, что там заметны следы динамического программирования. MySQL кеширует промежуточные результаты, чтобы не считать cost заново при расширении join-плана.
Именно за это я люблю open source: если есть вопрос, можно просто зайти в код и найти ответ самому.
Если любопытно, начни с файла sql_optimizer, а в нём — с функции get_best_combination. И да, спокойно используй LLM, чтобы разбирать исходники; я делал так же.
Вот код, который находит оптимальный порядок соединения
👉 @BackendPortal
PostgreSQL позволяет клонировать базу на 6 ГБ за 212 миллисекунд вместо 67 секунд. Вот как это работает.
Клонирование баз данных полезно в нескольких сценариях:
* тестирование миграций без трогания продакшн-данных
* поднятие свежих копий под каждый прогон тестов
* сброс sandbox-окружения между сессиями
* воспроизводимые снапшоты для отладки
Когда база весит несколько мегабайт, pg_dump вполне справляется. Но когда речь идёт о сотнях гигабайт, «просто сделать копию» превращается в серьёзный узкий момент.
В PostgreSQL система шаблонов была всегда. Каждый CREATE DATABASE тихо клонирует template1 под капотом, и вместо template1 можно использовать любую базу.
В версии 15 появился параметр STRATEGY, и по умолчанию включили WAL_LOG — поблочное копирование через журнал предзаписи (WAL). I/O становится ровнее, но для больших баз это медленнее.
В PostgreSQL 18 появилась опция file_copy_method = clone. На современных файловых системах вроде XFS, ZFS или APFS она использует операцию FICLONE. Вместо копирования байтов файловая система создаёт новые метаданные, которые указывают на те же физические блоки. Обе базы используют одно и то же хранилище, пока вы ничего не меняете.
Всю магию здесь делает файловая система, создавая copy-on-write (CoW) клон файлов.
Когда вы обновляете строку, файловая система запускает copy-on-write только для затронутых страниц. Всё остальное остаётся общим. Клон на 6 ГБ изначально не занимает дополнительного места и растёт только по мере расхождения данных.
Важно помнить один момент: у исходной базы не должно быть активных подключений во время клонирования. Это ограничение PostgreSQL, а не файловой системы.
Довольно круто.
👉 @BackendPortal
Где получить навыки, для старта карьеры в ИТ?
Развивайтесь в аналитике и разработке на бесплатной программе от экспертов из Т-Банка.
В Т-Академии вы погрузитесь в решение практических задач, схожих с теми, над которыми работают в крупных ИТ-компаниях.
А еще:
— онлайн-обучение в удобное время;
— нагрузка от 14 часов в неделю — можно совмещать с учебой или работой;
— мастер-классы, экскурсии в офисы и встречи в ИТ-хабах;
— чат с обсуждением заданий.
В процессе обучения участники получат шанс пройти собеседование в Т-Банке.
Успейте подать заявку до 23 января
Эта open-source система для управления проектами реально впечатляет
Работает через веб, бесплатная и закрывает весь базовый набор: планирование, задачи, таймлайны, прогресс команды.
Если нужен мощный PM-инструмент без дорогих SaaS — стоит глянуть :)
👉 @BackendPortal
Бэкапит базы на несколько хранилищ сразу, плюс умеет присылать нотификации.
https://github.com/RostislavDugin/postgresus
👉 @BackendPortal
Все надоело и пропал интерес, чувствуешь себя амебой и хочется только залипать в телефоне. Бывает?
Homo Manifestans — канал для айтишников, у которых периодически опускаются руки и отключается мозг, ибо переработки и постоянная тревожность не приводят к другим исходам 🤗
✓ Как научиться отвлекаться от работы и отдыхать?
✓ Как совместить кучу рабочих задач и время с семьей?
✓ Как справиться с прокрастинацией?
✓ Как не растерять запал, даже если начальник и коллеги 💩 и кажется, что ничего не выходит?
Подписывайтесь на канал @vadimpetrovpsi и научитесь работать без упахивания, выгорания и ущерба для личной жизни!
Псс. Заходите в закреп — там много полезного, и даже бесплатный мини-курс по выходу из апатии:
👉 /channel/+LEEr5GHeBHFlMWZi
Минималистичный клиент для SQL-баз данных
Называется Outerbase Studio:
✓ Совместим с MySQL, Postgres, SQLite и MongoDB
✓ Поддерживает сервисы вроде Turso и Cloudflare D1
✓ Доступен для Web, macOS и Windows
✓ Бесплатный и open source
→ [http://github.com/outerbase/studio]
👉 @BackendPortal
Весь Docker в одной шпаргалке : забираем
👉 @BackendPortal
Хочешь хранить текст? Не используй char(n) или varchar(n).
В других базах это встречается постоянно, но для Postgres — не лучшая идея.
• фиксированная ширина работает медленнее
• TEXT — переменной длины и без лимита
• если нужен размер, ставь constraint и ограничивай полем, а не типом
В итоге TEXT почти всегда выигрывает по практичности и производительности.
👉 @BackendPortal
В Postgres есть функция age() чтобы быстро посчитать возраст (разницу) между timestamp или датами
👉 @BackendPortal
Загружает ресурсы веб-сайта с исходной структурой каталогов: https://github.com/timf34/pagesource
👉 @BackendPortal
Ты открываешь репу, видишь сотни папок, пару src, пару packages, и вопрос: кто дергает этот модуль?, куда утекает эта функция?, почему тут вообще есть эта зависимость? 😁
Лови костыль который решает это: расширение для VS Code, которое рисует кодовую базу как интерактивный граф прямо в редакторе. То есть вместо бесконечного кликанья по дереву проекта ты видишь карту: файлы, функции и зависимости, и как они между собой связаны.
👉 @BackendPortal
Поздравляем, вы на 1 шаг ближе к работе мечты 🥳
Осталось только прочитать этот пост, подписаться на канал и откликнуться на вакансию 😉
Avito Career — место, где Авито делится актуальными вакансиями и стажировками для бэкенд-разработчиков.
Подписывайтесь, чтобы найти ту самую работу ✨
Каждый раз когда ты работаешь с сайтом, транзакции в базе держат данные в порядке, не дают им ломаться и изолируют операции друг от друга.
Сделали интерактивный гайд про то как это работает
👉 @BackendPortal
9 принципов софт-дизайна, которые стоит знать каждому разработчику:
1. DRY (Don’t Repeat Yourself). Избегай дублирования кода. Логику лучше держать в одном месте, так кодовая база намного проще в обслуживании.
2. KISS (Keep It Simple, Stupid). Тянись к простоте. Не городи архитектуру без реальной необходимости и не добавляй лишние уровни.
3. YAGNI (You Aren’t Gonna Need It). Реализуй только то, что нужно сейчас. Не трать время на потенциальные фичи, до которых может так и не дойти.
4. LOD (Law of Demeter). Общайся только с ближайшими соседями. Избегай бесконечных цепочек вызовов.
SOLID принципы:
5. SRP (Single Responsibility Principle). Класс должен отвечать только за одну вещь. Компоненты должны быть узкими и целостными.
6. OCP (Open/Closed Principle). Код должен быть открыт для расширения, но закрыт для модификации. Новое добавляем через расширение, а не переписывание старого.
7. LSP (Liskov Substitution Principle). Подклассы должны нормально подменять родительские без поломок в поведении.
8. ISP (Interface Segregation Principle). Разделяй интерфейсы на небольшие и сфокусированные, вместо огромных интерфейсов на все случаи.
9. DIP (Dependency Inversion Principle). Высокоуровневые модули не должны зависеть от низкоуровневых. Оба должны зависеть от абстракций.
👉 @BackendPortal
Совет по Postgres: используй filter вместо case when для условных агрегатов. Читается проще, выглядит более идиоматично для SQL и часто работает быстрее.
-- не делай так: громоздко и хуже читается
select
count(case when status = 'active' then 1 end) as active_count,
count(case when status = 'archived' then 1 end) as archived_count
from projects;
-- лучше так: чище и оптимизируется Postgres
select
count(*) filter (where status = 'active') as active_count,
count(*) filter (where status = 'archived') as archived_count
from projects;
Автоматизация рабочих процессов с мониторингом серверов: xyops
👉 @BackendPortal
R-trees это мощная структура для индексации геометрических данных.
Их используют в MySQL, а Postgres применяет похожий на R-tree подход через GiST в PostGIS.
По сути они работают похоже на B-tree: это древовидная структура, где на каждом узле страницы хранится несколько записей. Такой дизайн держит дерево неглубоким и позволяет эффективно искать миллионы элементов на диске. Данные обычно лежат только в листьях, как у B+tree.
Записи в R-tree это ограничивающие прямоугольники. Сами геометрические фигуры обычно сложнее прямоугольников, поэтому на уровне листьев хранят минимальный ограничивающий прямоугольник (MBR) для каждой фигуры, плюс ссылку на полную геометрию, которая лежит отдельно на диске. Родительский узел для листового MBR хранит прямоугольник, который полностью покрывает все дочерние.
Чем выше по дереву, тем больше становятся bounding-прямоугольники. В корне обычно остаётся несколько больших bounding-боксов.
Ключевое отличие от B-tree: поиск одного прямоугольника может потребовать обхода нескольких путей в дереве. В идеале B-tree даёт O(log n) на поиск, но из-за перекрытий у R-tree худший случай может быть O(n).
R-tree также можно использовать в 3D и выше, обобщая ту же идею ограничивающих регионов.
👉 @BackendPortal
Бесплатный опенсорсный Postman-подобный тестер API, который запускается локально. Умеет записывать запросы из браузера и автогенерировать чейненные тесты на Go-бэкенде и туллинге.
👉 @BackendPortal
Сборник документации множества языков программирования, библиотек и фреймворков в одном интерфейсе
Экономим время ✌️
👉 @BackendPortal