LISTEN/NOTIFY в Postgres масштабируется — если точно определить масштаб
Статья DBOS утверждает, что уведомления PostgreSQL выдерживают больше, чем принято считать. HN напомнил: масштабируемость зависит от нагрузки, а у LISTEN/NOTIFY есть ограничения payload и доставки.
LISTEN/NOTIFY может обслуживать высокую нагрузку при правильной архитектуре, но лимит уведомления 8 КБ определяет область применимости.
Главный вывод обсуждения: реальные ограничения и контекст эксплуатации важнее громкого заголовка.
К слову «масштабируется» нужно добавить нагрузку
Статья DBOS оспаривает мнение, будто PostgreSQL LISTEN/NOTIFY подходит только для крошечных нагрузок. Встроенные примитивы базы часто отвергают ещё до измерения настоящего узкого места системы. Источник
HN напомнил о лимите уведомления в 8 КБ и о том, что временные крупные события не всегда удобно сводить к строке базы. Масштаб — это непрерывная шкала: скорость, огромная для одного продукта, может быть недостаточной для другого.
Практическое правило становится яснее: уведомление должно идентифицировать или будить работу, сохранённую надёжно. Очередь, пакетирование и модель потребителей — часть системы, а не мелкие детали реализации.
Измерение DBOS не опровергается этим уточнением; обсуждение лишь не даёт превратить один результат в универсальное обещание. Система, обрабатывающая 60 000 событий в секунду, может быть избыточной для одной команды и недостаточной для другой. Уведомление поэтому разумно трактовать как сигнал, а не как неограниченную шину сообщений.
Измерение DBOS не опровергается этим уточнением; обсуждение лишь не даёт превратить один результат в универсальное обещание. Система, обрабатывающая 60 000 событий в секунду, может быть избыточной для одной команды и недостаточной для другой. Уведомление поэтому разумно трактовать как сигнал, а не как неограниченную шину сообщений.
Получайте такие разборы каждый день
Главные истории Hacker News — на email, в Telegram или RSS.
Ограничения ADB на Android разделили удобство и физическую безопасность
Android может ограничить ADB на самом устройстве. Это классический компромисс: убрать путь автоматизации атак или сохранить возможность, которой осознанно пользуются опытные владельцы.