Бэкенд

Временные (промежуточные) данные - те, которые нужны для обработки в течение транзакции, сессии или ограниченное время. После истечения срока такие данные не нужны. Причина использования временных данных в том, что в одном запросе не всегда можно обработать все данные. Логика приложения может предусматривать обработку данных по частям - разными запросами. В статье рассматриваются и сравниваются способы хранения временных данных в:
1) обычных таблицах;
2) нежурналируемых таблицах;
3) материализованных представлениях;
4) временных таблицах;
5) в памяти серверного процесса, используя расширение pg_variables

Поводом задуматься был небольшой пет проект для корпоративной отчетности, где вручную вносят данные в таблицы, формат которых для гибкости задается в Excel.

TL;DR: Оказалось проще формализовать и реализовать с нуля свой потокобезопасный движок формул Excel, чем оптимизировать мутабельный движок. Хотя позже я реализовал более простой в кодировании вариант, но гораздо более сложный с точки зрения архитектуры.

Привет, Хабр!

Давайте признаемся: порог входа в Data Engineering довольно высок. И дело не только в знании SQL или Python. Настоящая боль начинается, когда ты пытаешься собрать на своей машине хотя бы простенький пайплайн.

Нужно поднять Kafka, рядом поставить Zookeeper (или обойтись Kraft, если ты хипстер), прикрутить Debezium для CDC, развернуть Spark для обработки, где-то хранить результат (привет, MinIO!), а потом всё это оркестрировать через Airflow и визуализировать в Superset. Каждый инструмент — это отдельный Docker-контейнер, своя конфигурация, свои порты и свои зависимости. Через пару часов борьбы с docker-compose.yml и сетевыми настройками желание учиться и экспериментировать улетучивается.

Знакомо? А что, если я скажу, что весь этот зоопарк можно поднять одной командой, и он просто... заработает?

Сегодня я хочу рассказать о проекте, который стал для меня настоящей находкой — Data Forge. Это готовая песочница для дата-инженера, или, как называет её автор, "Data Engineering Playground".

Многие энтузиасты разворачивают open source-инструменты у себя дома и экспериментируют с «домашним облаком», решая личные задачи.

Мы в Beeline Cloud подобрали примечательные материалы, которые помогут погрузиться в тему, познакомиться с кастомными сборками.

В этой статье мы рассмотрим процесс создания AppImage — универсального формата для распространения Linux-приложений. Ниже представлена ссылка на набор скриптов, который автоматизирует сборку AppImage, включая поиск зависимостей, копирование библиотек и упаковку приложения.

Привет, Хабр! Если вы работаете с большими данными, то для вас, скорее всего, Parquet — это как воздух. Стандарт де-факто для колоночного хранения в экосистеме Hadoop, Spark, и вообще всего, что связано с аналитикой. Он эффективен, надёжен и поддерживается практически всеми инструментами. Казалось бы, живи и радуйся.

Но что, если я скажу, что в мире современных SSD, многоядерных CPU и вездесущих векторных баз данных старый добрый Parquet начинает показывать свой возраст? Он был спроектирован в эпоху, когда узким местом были HDD и сетевые задержки, а не скорость процессора. Сегодня железо изменилось, задачи тоже, и на сцену выходят новые, амбициозные форматы.

Давайте разберёмся, где именно Parquet даёт слабину и кто эти дерзкие новички, которые метят на его трон.

За основу взята статья Dipankar Mazumdar.

Статья о реализации сервиса на C++ с применением TDD, DDD и событийно-ориентированной архитектуры. Проект переносит идеи из книги «Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура» на C++.

Всем привет! Меня зовут Илья. Я давно читаю habr, не так долго занимаюсь программированием и еще чуть меньше времени хочу написать здесь статью. Не то, чтобы это идея фикс (или hotfix), но лучше опубликоваться и жалеть, чем поставить в план на «когда-нибудь потом», ничего не сделать, и «получить за это премию». Таких задач у меня уже накопилось на несколько жизней вперед, поэтому, приняв волевое решение, я выделил время на графоманию.

В прошлом мне доводилось писать околонаучные статьи и вести блог про путешествия, совершенные в разных стадиях трезвости (на рецензируемые статьи ВАК про пьяные авантюры, к сожалению, не хватило грантов). Но поскольку срок давности по этим событиям давно прошел, а все самое значимое я забыл, то опишу свой недавний опыт, связанный с OpenSource. 

Идея открытого программного обеспечения мне нравится. Люди, создающие OpenSource проекты вызывают интерес, особенно, когда их продукты востребованы и конкурентноспособны. Двигать индустрию IT в свободное от работы время, вместо того, чтобы предаваться гедонизму — достойно уважения. Особенно, когда сам активно пользуешься подобными продуктами, вместо платных аналогов или ручного труда.

 Для начала синхронизируемся по таймингу, когда я это пишу на дворе начало октября 2025г. Я искренне надеюсь, дорогой читатель, что читая мою заметку через пару лет, рынок окреп, снова перешел к работнику и все стало лучше.

Представьте ситуацию: ваше приложение работает в продакшене, как вдруг происходит критическая ошибка. Вы узнаете о ней только через несколько часов, когда пользователи начинают массово жаловаться. Идёте проверять консоль, а тут всего лишь трассировка стека, которая мало что говорит о проблеме. Из-за кого и когда возникла это ошибка? Чтобы предотвратить такие сценарии, необходима активная система уведомлений. В этом руководстве мы создадим пользовательский обработчик, который предоставит возможность создания системы уведомлений об ошибках, которая гарантирует, что вы всегда будете в курсе состояния вашей системы.

Всем привет! Сегодня хочу зажечь настоящий холивар — но с практическим уклоном. Речь пойдет о нашем большом рефакторинге, вернее, о почти полном переписывании ядра нашего API-гейтвея.

Немного контекста: У нас классический монолит на Java (Spring Boot), который неплохо служил нам лет 5. Но с ростом нагрузки до 100k+ RPS мы уперлись в лимиты:

Мы живём в дивном мире, где: IDE подсказывает код быстрее, чем тимлид успевает сказать «создай тикет»; LLMы пишут тесты, доку и миграции, а вы наконец-то занимаетесь смыслом, а не бойлерплейтом; автономные агенты берут на себя скучную рутину — собирают пайплайны, гоняют CI и сами признаются в сломанных сборках человеческим языком; прототипы появляются за день, а не за спринт, потому что макеты, тексты и даже моковые данные генерируются «по кнопке»; инфраструктура разворачивается из шаблонов IaC, а наблюдаемость отвечает в чате, почему всё упало (и как поднять); маленькие команды выпускают MVP быстрее отделов, потому что цикл обратной связи короче и трения меньше; и даже саппорт закрывает первую линию бот, пока разработчик спит. Короче, теперь «команда из пяти» — это вы и четыре невидимых ИИ-коллеги.

Enum’ы в PHP с нами уже давно, но вы задумывались, как они реально работают внутри? Давайте разберёмся, что там происходит под капотом.

Это был обычный понедельник. Я пил кофе, проверял почту, и вдруг — волна уведомлений в Slack. «Сайт не грузится!», «Отчеты зависли!», «Что происходит?».

Наш проект, который успешно работал с несколькими сотнями тысяч записей, перешагнул психологически важный рубеж — 10 миллионов строк в таблице заказов. И PostgreSQL, который раньше летал, внезапно начал ползти как улитка.

Всем привет! Меня зовут Константин. Моя карьера в сетевой разработке началась со времен Symbian OS, когда я участвовал в создании сетевого стека этой платформы. С 2010 года я работаю в «Лаборатории Касперского», разрабатывая мобильные и сетевые продукты, а последний год плотно погружен в проект NGFW. В мои задачи входит как проработка архитектурных решений, так и написание кода ключевых модулей. 

В этой статье я хочу рассказать об архитектуре сетевого экрана следующего поколения (NGFW), над которым работаю. В частности, расскажу:

- об архитектуре передающего слоя (data plane) нашего продукта, основанной на связке DPDK/VPP;
- о пути сетевого пакета в рамках data plane NGFW;
- о частых ошибках при разработке решений на базе VPP;
- о разработке и сценариях встраивания в высокоскоростной конвейер обработки пакетов VPP некоторых из наших движков безопасности;
- об истории создания наших собственных движков безопасности DPI и IDPS (хочу выразить благодарность за неоценимую помощь в подготовке материала для данного раздела коллегам из команды IDPS и лично Евгению Прусову);
- об интеграции data plane с протоколами динамической маршрутизации.

Материал будет полезен архитекторам и разработчикам, участвующим в создании высокопроизводительных и отказоустойчивых сетевых решений.

Привет, Хабр!

Хочу поделиться своим путём в блокчейн. К 2023 году за плечами было уже 7 лет строгого режима веб-разработки, и она начала казаться рутиной. Хотелось нового. В идеале — области, где можно было бы применить свою любовь к математике. Выбор стоял между датой и блокчейном. Я выбрал второе — во многом потому, что несколько моих друзей уже погрузились в этот «тёмный лес» и своими проектами пробудили во мне интерес. Это решение привело меня к неожиданным открытиям, трем разным проектам, нескольким месяцам жизни на доширак и к пониманию, что блокчейн — это идеальный полигон для любого разработчика, увлеченного математикой.

Привет, Хабр! Это моя вторая статья, посвященная нашему проекту. 

Мы создаем продукт, который, как мы верим, изменит рынок труда в Рунете — AI-ассистента для поиска работы, забирающего на себя всю рутину. А рутины, как выяснилось, очень много.

В этой статье я постараюсь открыть больше внутрянки про техническую часть проекта и продолжу рассказывать про наши факапы (а куда без них?:)

Все уже прекрасно понимают, что Amplicode — неотъемлемая часть тулинга для разработки в OpenIDE, IntelliJ IDEA Community Edition и GigaIDE на Spring Boot. Но стоит установить Amplicode в IntelliJ IDEA Ultimate и ваша, казалось бы, идеальная IDE станет ещё мощнее и удобнее.

Команда Go for Devs подготовила перевод статьи, в которой автор шаг за шагом решает классическую задачу об обедающих философах на Go. Вы узнаете, почему наивный подход ведёт к взаимной блокировке, как нарушить симметрию, чтобы избежать deadlock’а, и почему даже «рабочее» решение может оставить одного философа голодать вечно.

C# — гибкий язык. На нём можно писать мобильные и десктопные приложения, игры, веб-сайты, сервисы и API. Можно писать на нём, как на Java, со всеми абстракциями и AbstractionFactoryClassProvider. Но, в отличие от Java, на нём также можно писать низкоуровневый и небезопасный код. И когда я говорю о низкоуровневом, то имею в виду отсутствие сборщика мусора и сырые указатели.

Низкоуровневый код обычно требуется для высокой производительности или взаимодействия с библиотеками C/операционной системой. Низкоуровневый код помогает повысить производительность благодаря тому, что с его помощью можно избавиться от проверок доступа к памяти в среде исполнения.

Для безопасности доступ к элементам массивов выполняется в C# с проверкой границ. Но из-за этого страдает производительность, если только, конечно, компилятор не сможет избавиться от операции проверки границ. Логика устранения проверок границ должна гарантировать, что проверка границ индекса массива уже выполнялась раньше или что во время компиляции индекс точно будет находиться в границах. Для примера возьмём простую функцию: