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

В .NET живёт старый, понятный инструмент для конкурентной обработки — BlockingCollection<T>. Коллекция, которая упрощает модель producer–consumer, даёт строгую ограниченную вместимость и предсказуемую блокировку при пустоте или переполнении. Да, у нас есть Channel<T>, есть TPL Dataflow, есть миллион самодельных очередей на SemaphoreSlim. Но когда нужны простые правила и железный backpressure без BlockingCollection по-прежнему закрывает задачи хорошо.

Механизм реализации транзакций - основная часть реляционных баз данных. Он упрощает разработку приложений, в которых гарантируется целостность данных. Стандарт SQL регламентирует, часть свойств по поддержке транзакций, но многие детали не стандартизованы. Как следствие, реализация поддержки транзакций в разных базах данных может существенно различаться. В настоящее время, многие пытаются перейти с Oracle на PostgreSQL. Для миграции приложений важно понимать различия в реализации работы транзакций, иначе можно столкнуться с неприятными сюрпризами, которые могут поставить под угрозу производительность и целостность данных. Поэтому Лоренс Альбе решил, что полезно сравнить реализацию работы транзакций в Oracle и PostgreSQL и свести различия в одной статье.

Разбирая взаимоблокировки, Лоренс вспомнил, насколько опасным может быть использование SELECT FOR UPDATE при конкурентном доступе. В этом нет ничего нового, но Лоренс заметил, что многие не знают о режимах блокировки строк в PostgreSQL. Лоренс решил подробно описать, когда следует избегать SELECT FOR UPDATE.

Привет! Без лишнего: в статье расскажу про атаки на кэш-память в процессорах семейства ARMv8. Подробно изучил их для совершенствования безопасности KasperskyOS: познакомлю с теорией и практикой, механизмами работы и способами митигации. Также кратко расскажу, как мы тестировали каждый способ атаки на KasperskyOS, какие из них оказались неприменимы, какие могут представлять угрозу и как микроядро с подобными угрозами справляется. Если интересно гранулярно погрузиться в типологию атак на кэш — добро пожаловать!

Беспилотные автомобили, продвинутые голосовые ассистенты, рекомендательные системы – это только малая часть тех классных продуктов, которые создаются с помощью инженеров по машинному обучению и, думаю, не для кого не секрет, что за кулисами сего чуда стоит математика. Именно она играет главную роль в понимании алгоритмов машинного и глубокого обучения.

Машинное обучение держится на трёх основных столпах:

В этой статье мы расскажем о том, как эффективно реализовать полнотекстовый поиск с помощью PostgreSQL. Узнайте, как улучшить скорость и точность поиска по текстовым данным, используя такие инструменты, как tsvector, tsquery и индексы GIN, и как эти возможности могут значительно повысить производительность вашего приложения.

Продолжаю цикл статей про использование Greenmask - инструмента, который написан на Go специально для безопасной работы с данными PostgreSQL: он помогает делать логические бэкапы, восстанавливать таблицы и при необходимости — анонимизировать чувствительную информацию.

В первой части описаны базовые сценарии использования данного инструмента, а в этой части опишу что такое database subsets и как использовать данный функционал для радикального снижения размера дампа базы данных.

Я думаю, что многие, кто занимается разработкой в стеке Go + PgBouncer + PostgreSQL, уже примерно поняли, о чём будет статья — о проблеме выполнения prepared statements и сравнении работы двух популярных драйверов для PostgreSQL: lib/pq и jackc/pgx.

Если интересно — добро пожаловать под кат.

Когда в проекте используется составной B-tree индекс, важно не просто "создать индекс", а сделать это правильно — иначе запросы могут не только не ускориться, но и начать работать медленнее. Возникает логичный вопрос: как выбрать порядок колонок, чтобы индекс действительно работал эффективно? Брутфорсом? По интуиции? По селективности?

В этой статье я расскажу, как подходить к построению составных индексов в PostgreSQL, на что реально влияет порядок колонок. Также разберём простое правило ESR, которое помогает упростить выбор и получать стабильный прирост производительности на всех стендах.

Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных.

Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

Привет, Хабр! Это Алексей Деев, backend-разработчик в компании Avanpost. В этой статье я коротко расскажу о мире параллельной обработки данных с помощью акторной модели, приведу примеры кода на разных реализациях акторов под .net.

Сегодня разберёмся, как сделать видеозвонки — ту самую фичу, без которой сложно представить современное общение в 2025 году, на примере реализации мессенджера.

Для этого мы познакомимся с WebRTC — технологией, которая позволяет приложениям устанавливать прямое соединение друг с другом для обмена аудио, видео и другими данными. Это мощный, но местами капризный инструмент, который требует понимания архитектуры, сигналинга и сетевых нюансов вроде NAT и ICE.

Нечасто встречаются истории, когда причины и следствия сплетаются в один клубок, связывающий проблемы и с памятью, и с CPU, и с тредпулом. А инструментально затрагивающие и пулы объектов, и Lazy, и работу с асинхронностью, и длительные вычисления. А ещё реже встречаются те, где всё это распутывается и исправляется буквально несколькими строчками кода.

Как реализовать хранение и работу каталога папок в PostgreSQL? Есть большое количество вариантов. Но хочется, чтобы реализация выглядела лаконично, не нарушала прозрачность выполняемых операций, не вызывала блокировок, не требовала большого вовлечения клиента в специфику работы и т.д. Потому сегодня попробуем реализовать хранение древовидных структур и работу с ними без использования триггеров, блокировок, дополнительных таблиц (представлений) и внешних инструментов в SQL.

Чтобы до конца разобраться с содержанием Поста: How Async/Await Really Works in C#, который мы начали анализировать в предыдущей статье, неплохо бы познакомиться с изначальным определением концепции SynchronizationContext, на которую ссылается автор этого поста, без которой, по мнению того же автора, нельзя понять реализацию Async/Await.

Это перевод Поста: Parallel Computing - It's All About the SynchronizationContext

Трейсинг (возможность отслеживания пути запроса между сервисами в микросервисной архитектуре) - критический важное требование функционирования более-менее крупных систем.

У Uber - тысячи микросервисов. А у Netflix - несколько тысяч

В каком сервисе возникла ошибка? Сервис упал или просто ошибка сети? Что за ошибка возникла?

Стоп!
Рим не за один день был построен

Поэтому начнем с малого и подключим трейсинг к обычной микросервисной системе на ASP.NET Core.

Поможет нам в этом OpenTelemetry

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

В одной из предыдущих статей я описал Push-based Outbox Pattern (шаблон исходящих сообщений на основе push с логической репликацией Postgres). Идея заключается в том, чтобы сохранить исходящее сообщение (например, событие) в той же транзакции базы данных вместе с изменением состояния. Благодаря этому мы гарантируем, что сообщение не будет потеряно, а наш бизнес-процесс будет продолжаться и станет согласованным.

Postgres может помочь и проинформировать нас, когда добавляется новое сообщение. Мы можем использовать встроенный механизм журнала упреждающей записи (WAL, Write-Ahead Log) вместе с логической репликацией.