Автоматизация рабочих процессов с мониторингом серверов: xyops

👉 @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

Совет по 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;

👉 @BackendPortal

Я всегда хотел понять, как SQL-базы реально исполняют JOIN'ы. Теорию я знал, но какое-то время назад потратил пару часов на исходники MySQL, чтобы разобраться в деталях.

Оказалось, что MySQL строит join-планы инкрементально, чтобы найти оптимальный порядок соединений. Он идёт от однотабличных access paths к join'ам на 2 таблицы, затем на 3, и так далее. В качестве оптимизации он отбрасывает поддеревья, которые гарантированно дадут более высокий cost.

Интересно, что там заметны следы динамического программирования. MySQL кеширует промежуточные результаты, чтобы не считать cost заново при расширении join-плана.

Именно за это я люблю open source: если есть вопрос, можно просто зайти в код и найти ответ самому.

Если любопытно, начни с файла sql_optimizer, а в нём — с функции get_best_combination. И да, спокойно используй LLM, чтобы разбирать исходники; я делал так же.

Вот код, который находит оптимальный порядок соединения

👉 @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

Подборка учебных материалов для изучения программирования на примере проектов: чекаем

👉 @BackendPortal

Каждый раз когда ты работаешь с сайтом, транзакции в базе держат данные в порядке, не дают им ломаться и изолируют операции друг от друга.

Сделали интерактивный гайд про то как это работает

👉 @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

Вышел 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

Ты открываешь репу, видишь сотни папок, пару src, пару packages, и вопрос: кто дергает этот модуль?, куда утекает эта функция?, почему тут вообще есть эта зависимость? 😁

Лови костыль который решает это: расширение для VS Code, которое рисует кодовую базу как интерактивный граф прямо в редакторе. То есть вместо бесконечного кликанья по дереву проекта ты видишь карту: файлы, функции и зависимости, и как они между собой связаны.

👉 @BackendPortal

Если готовишься к system design / backend-интервью, можно прогнать этот чек-лист

👉 @BackendPortal

Загружает ресурсы веб-сайта с исходной структурой каталогов: https://github.com/timf34/pagesource

👉 @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

В Postgres есть функция age() чтобы быстро посчитать возраст (разницу) между timestamp или датами

👉 @BackendPortal

Если деревья тебя пугают, графы наверняка вообще вгоняют в ужас.

Это та тема, про которую большинство молится, лишь бы не попалась на собесе.

Единственная разница между деревом и графом это цикл. всё. если ты умеешь решать на деревьях, то на графах это то же самое: просто добавь массив 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

Хочешь хранить текст? Не используй char(n) или varchar(n).

В других базах это встречается постоянно, но для Postgres — не лучшая идея.

• фиксированная ширина работает медленнее
• TEXT — переменной длины и без лимита
• если нужен размер, ставь constraint и ограничивай полем, а не типом

В итоге TEXT почти всегда выигрывает по практичности и производительности.

👉 @BackendPortal

Весь Docker в одной шпаргалке : забираем

👉 @BackendPortal

Компилируем Go в TypeScript 😂

Этот тул работает на уровне AST-дерева, позволяя переиспользовать бизнес-логику, алгоритмы и структуры данных между бэкендом и фронтом без переписывания руками

Исходный код этого чуда

👉 @BackendPortal

Минималистичный клиент для SQL-баз данных

Называется Outerbase Studio:

✓ Совместим с MySQL, Postgres, SQLite и MongoDB
✓ Поддерживает сервисы вроде Turso и Cloudflare D1
✓ Доступен для Web, macOS и Windows
✓ Бесплатный и open source

→ [http://github.com/outerbase/studio]

👉 @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