Hacker News Digest

• HNSW критикуется за сложность балансировки, неэффективность кэширования и слабую поддержку фильтрации результатов поиска.
• Продвинутое квантование (особенно product quantization) значительно эффективнее простого (int8/binary) и является ключом к ускорению индексов; DiskANN часто предпочтительнее HNSW в продакшене.
• Иерархичность HNSW может быть избыточной; плоские структуры или модифицированные функции выбора уровней могут дать сопоставимую производительность.
• Важна прозрачность систем: предоставление программистам доступа к структуре данных и понимание компромиссов позволяет создавать более гибкие решения.
• В Redis векторы нормализуются для быстрого вычисления скалярного произведения вместо косинусного сходства; запись на диск выполняется точечно (RDB/AOF), а не непрерывно.

Геокодио перешло с MariaDB на ClickHouse, Kafka и Vector для обработки миллиардов запросов. Исходная система на MariaDB с движком TokuDB не справлялась с нагрузкой: токизация базы не обновлялась с 2021 года, производительность падала с ростом данных, а запросы к миллиардам записей приводили к таймаутам.

Новая архитектура распределяет поток данных через Kafka, который направляет их в ClickHouse для аналитики в реальном времени и долгосрочного хранения. Vector агрегирует данные перед загрузкой, что значительно ускоряет обработку.

В результате производительность увеличилась на порядки: запросы, занимавшие минуты, теперь выполняются за миллисекунды, а пользователи могут мгновенно просматривать свою статистику даже на пике нагрузки. Это решение, хоть и требовало переписывания некоторых запросов, полностью устранило проблемы с производительностью.

• Основной вывод: авторы обсуждают, как правильно организовать поток данных от источника к ClickHouse, используя Kafka, Vector или Redis в качестве буфера.
• Практика: вместо того чтобы писать в ClickHouse напрямую, они используют Kafka как очередь, а затем Vector для буферизации.
• Архитектура: ClickHouse не предназначен для очень больших объемов вставки, и поэтому требуется внешняя система буферизации.
• Альтернативы: обсуждаются такие варианты как async insert в ClickHouse, использование Redis вместо Kafka, или применение встроенной функции async insert в ClickHouse.

Обнаружена критическая уязвимость удалённого выполнения кода в Redis (CVE-2025-49844) с максимальным баллом CVSS 10.0. Проблема связана с ошибкой Use-After-Free, присутствующей в коде около 13 лет, которая позволяет аутентифицированному злоумышленнику выполнить произвольный код на хосте через специально сформированный Lua-скрипт.

Уязвимость затрагивает все версии Redis и представляет особую опасность, учитывая распространённость системы в 75% облачных сред. Атака позволяет получить полный контроль над системой, включая кражу, шифрование данных и перемещение внутри инфраструктуры. Эксплуатация требует лишь отправки вредоносного скрипта, что делает угрозу высокой для публично доступных экземпляров Redis.

• Уязвимость в Redis (CVE-2024-XXXX) позволяет выполнить произвольный код после аутентификации через уязвимость use-after-free в Lua-скриптах.
• Критичность уязвимости (CVSS 10) оспаривается, так как для эксплуатации требуется аутентификация или доступ к Lua-скриптам, что редко встречается в типичных конфигурациях.
• Проблема усугубляется большим количеством экземпляров Redis (десятки тысяч), публично доступных в интернете без настроенной аутентификации.
• Уязвимость существует в коде более десяти лет, исправлена в Redis 8.1.4 и форке Valkey, но многие системы остаются незащищенными.
• Обсуждаются проблемы безопасности по умолчанию в Docker-конфигурациях и необходимость обновления устаревшей версии Lua в проектах.

Redis показал заметно лучшую производительность по сравнению с Postgres при использовании в качестве кэша. В тестах на чтение Redis обрабатывал больше запросов в секунду, при этом нагрузка на CPU у сервера с Redis была умеренной (~1280mCPU из доступных 2000mCPU), а потребление памяти стабильно держалось на уровне ~3800 МБ. Сервер HTTP стал узким местом в случае Redis, исчерпав свои CPU-ресурсы.

Для Postgres основным ограничением стал CPU самой базы данных, который постоянно работал на максимуме. Это подтверждает, что Redis эффективнее справляется с высоконагруженными сценариями кэширования, особенно когда требуется низкая задержка и высокая пропускная способность операций чтения.

• Критика методологии бенчмарка: сравнение ненастроенных Postgres и Redis считается некорректным, так как Postgres требует тонкой настройки под железо для серьёзных тестов.
• Сомнения в целесообразности использования Postgres как кэша: отсутствие встроенного TTL, нагрузка на основную БД и сложности с вакуумом делают Redis более надёжным решением.
• Подчёркивается важность контекста: для небольших нагрузок (<1000 RPS) и упрощения стека использование Postgres может быть оправдано.
• Замечания о специфике теста: сравнение ограниченного Postgres (2 ядра) с неограниченным Redis, малый размер данных и отсутствие пайплайнинга искажают результаты.
• Обсуждаются альтернативы: использование UNLOGGED таблиц, специализированных клиентов (rueidis) или встроенного кэша приложения вместо распределённого решения.

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

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

• Обсуждаются альтернативы Redis, такие как kvrocks, Garnet и Redka, с поддержкой хранения данных на диске и работой в условиях ограниченной памяти.
• Участники дискутируют о стабильности языка Zig для реальных проектов, отмечая частые изменения в стандартной библиотеке и отсутствие версии 1.0.
• Поднимается вопрос о названии проекта "RiiZ" и возможном нарушении торговой марки Redis из-за схожести имен.
• Отмечается, что проект является учебным для изучения Zig, а не коммерческим продуктом, и пока не поддерживает все функции Redis (например, аутентификацию, поиск ключей).
• Обсуждаются технические детали реализации памяти и деструкторов в Zig, а также возможность использования LLM для генерации кода на этом языке.

Разрабатывайте самое простое, что только может работать.
Это правило годится и для исправления багов, и для новых систем.

Многие инженеры мечтают о «идеальной» архитектуре: масштабируемой, распределённой, красивой. Это ошибка. Лучше глубже понять текущую систему и сделать самое простое решение.

Простое может выглядеть скучно
Джуны любят рисовать сложные схемы из кэшей, очередей, прокси. Настоящее мастерство — уметь делать меньше. Великий дизайн выглядит тривиально: «О, задача оказалась простой».
Unicorn и стандартный Rails REST API — примеры: всё нужное достигается очевидными средствами.

Практика
Нужно ограничение частоты запросов в Go-сервисе?

• Вариант 1: Redis + алгоритм «протекающего ведра».
• Вариант 2: счётчики в памяти (теряются при рестарте).
• Вариант 3: включить rate-limit в edge-прокси одной строкой конфига.
  Если последнее покрывает требования — выбирайте его.

Развивайте продукт, начиная с минимума и усложняя только по новым требованиям. Это YAGNI как высший принцип.

Возражения

1. Слякоть из костылей
   Костыль не прост — он добавляет сложности. Настоящее простое решение требует понимания всей системы и часто сложнее придумать.

2. Что такое «просто»?
   Простота — это минимум сущностей, минимум переходов, минимум новых инструментов. Она не всегда очевидна и требует инженерной работы.

3. Масштабирование
   Простое не значит «только сейчас». Unix-сокеты, CGI, файлы — примитивы, на которых построены крупные системы. Если завтра потребуется масштаб, выясните новые факты и добавьте минимально необходимое.

Делайте самое простое, что только может работать — и будете удивлены, как далеко это вас заведёт.

• Участники сходятся в том, что «делай самое простое, что может работать» — полезная эвристика, но не универсальный закон.
• Опытные разработчики подчеркивают: простота ≠ легкость; требует глубокого понимания задачи и контекста.
• На больших системах «простое» быстро ломается из-за edge-case’ов и масштаба, поэтому часто приходится усложнять.
• Частая ошибка — проектировать «на вырост»: реакт, k8s и прочее для сайта из трёх страниц, лишь бы «в портфолио».
• Самый практичный совет: фиксируй реальные требования здесь и сейчас и строй под них, а не под гипотетическое будущее.

Мы перенесли Docker-реестр в собственный дата-центр на Harbor, отказавшись от Docker Hub и ECR.
Причины: счета за лицензию и трафик, 45-секундные задержки деплоя, риски утечек, лимиты API.

Критерии нового решения: надёжность, скорость, простота, open-source.
Выбрали Harbor: богаче функций, чем «голый» distribution, ставится через docker-compose.

v1-дизайн

• Хранилище: S3-совместимый Pure FlashBlade.
• Две независимые копии в Ashburn и Chicago (пока без HA PostgreSQL/Redis).
• Политики очистки для экономии места.

Минимальные права на бакет
s3:AbortMultipartUpload, DeleteObject, GetBucketLocation, GetObject, ListBucket, ListBucketMultipartUploads, ListMultipartUploadParts, PutObject

harbor.yml (фрагмент)

hostname: "#{node['fqdn']}"
http: { port: 80 }
data_volume: /data
storage_service:
  s3:
    bucket: docker-registry-bucket
    accesskey: "#{bucket_credentials['access_key']}"
    secretkey: "#{bucket_credentials['secret_key']}"
    regionendpoint: "https://purestorage.#{node['domain']}"
metric: { enabled: true, port: 9090, path: /metrics }

Конфиг разворачивается Chef на выделенных нодах, SSL-терминация на F5.

• Harbor удобен: SSO, Terraform-провайдер, но нет API для токена при docker login, приходится создавать robot-аккаунты.
• Ресурсы 32 CPU / 64 GB RAM выглядят завышенными для 32 000 пуллов за два месяца; скорее всего, просто оверпровижн.
• Многие используют один «источник истины» Harbor + региональные кэши или просто registry в режиме pull-through-cache.
• У Harbor нет OIDC-доступа из GitHub Actions, апгрейды ручные; Nexus проще для Maven/NuGet, но тоже прожорлив и иногда не чистит блобы.
• ECR в AWS дешёв (~3 $/мес) и без хостинга, но не on-prem; для S3-подобного хранилища советуют SeaweedFS, Garage или Pure Flashblade.

SDS — библиотека динамических строк на C от автора Redis.
Предоставляет удобный API: создание, копирование, конкатенация, форматирование, сравнение, обрезку и пр.
Скрывает ручное управление памятью, хранит длину и оставшийся буфер в заголовке, что ускоряет операции и делает буфер-переполнение невозможным.
Совместима с обычными char* (нулём-терминатором), поэтому строки можно передавать в любые функции стандартной библиотеки.
Используется в Redis, хорошо протестирована, распространяется под BSD-лицензией.

• Пользователи обсуждают, почему в SDS предпочитают sdscat(s, "...") вместо stscat(&s, "..."): главное — производительность и простота.
• Некоторые удивлены, что sds — это char* без const, что может привести к ошибкам при передаче в libc-функции, не обновляющие метаданные.
• Автор antirez напоминает: актуальная версия SDS живёт внутри Redis, куда она мигрировала и развивалась дальше.
• Разгорелся спор «зачем вообще писать на C, если есть C++ и string_view»; ответы: embedded, совместимость, «не платишь за то, что не используешь», а также исторические причины (Redis начинался в 2009, string_view появился в C++17).
• Подчёркивают: C-код можно встраивать куда угодно, а C++ уже требует рантайма и ограничивает переносимость.

Материализованные представления очевидно полезны

Разработчики постоянно перетасовывают данные между системами и форматами.
Возьмём таск-трекер: нужно показывать количество задач в каждом проекте. Сначала всё просто:

const getTaskCountForProject = (id) =>
  db.query('select count(1) from tasks where project_id = $1', [id]);

Скорость не устраивает → добавляем Redis-кеш:

const getTaskCountForProject = async (id) => {
  const key = `project:${id}:task-count`;
  let cnt = await redis.get(key);
  if (cnt !== null) return +cnt;
  cnt = await db.query('select count(1) ...', [id]);
  await redis.set(key, cnt, { ex: 3600 });
  return cnt;
};

Пользователи жалуются: счётчик устаревает. Приходится чистить кеш при каждом insert/delete.
Делаем инкрементальные обновления:

await redis.incr(`project:${id}:task-count`);

Но если сервер упадёт между записью в БД и Redis, счётчик сломается навсегда.
Переносим счётчик в ту же БД и обновляем в транзакции, либо пишем триггер — логика в БД снова в моде.

Итог: из одной строки кода выросла куча кода, который нужно поддерживать и синхронизировать.
Таких «побочных» вычислений в приложениях тысячи; они скрывают суть и мешают рефакторингу.

• Пост хвалят за честность, но автор не уточняет СУБД, хотя SQL выглядит как Postgres.
• Postgres-материализованные представления требуют ручного REFRESH; авто-обновления дают коммерческие продукты (Materialize, Snowflake, MSSQL, ReadySet, Feldera, RisingWave) и расширение pg_ivm.
• Convex, Zero и др. используют инкрементное обслуживание представлений (IVM) «под капотом».
• Счётчики через COUNT(*) без IVM не масштабируются; кто-то предлагает денормализацию и триггеры, кто-то — индексы по FK.
• ScyllaDB-материализованные представления считаются багованными; важно понимать конкретную реализацию.

Почему появился Apache Kafka
LinkedIn, 2012 г.

Проблема интеграции
LinkedIn нужно было передавать данные активности (лайки, просмотры, публикации) в десятки систем: антифрод, ML-модели, веб-функции, витрины, Hadoop. Эти потоки — критичная инфраструктура, а не просто аналитика.

Старые трубы

• Пакетный конвейер: приложения писали XML на HTTP-сервер; раз в час файлы собирались, парсились и грузились в Oracle + Hadoop.
• Realtime-конвейер: метрики и логи уходили в Zenoss, но туда нельзя было добавить новые данные без ручной работы, а данные были изолированы.

Общие боли

• ручное сопровождение и добавление источников;
• постоянные бэклоги;
• point-to-point архитектура без обмена между системами.

Вывод
LinkedIn понял, что нужен один надёжный, масштабируемый и универсальный «шина событий», куда пишут все, а читают кто угодно. Так родился Kafka.

• LinkedIn отказался от Kafka и создал собственную систему Northguard из-за невозможности масштабировать 32 трлн записей/день, 17 ПБ/день и 400 тыс. топиков.
• Участники спорят: Kafka мощна для «огненных шлангов» данных и многократного потребления, но требует экспертизы и ресурсов; для большинства задач достаточно Redis, NATS, RabbitMQ.
• Названа главная фишка Kafka — возможность переигрывать сообщения и строить разные консьюмеры поверх одного лога.
• Сравнивают NATS (Jetstream) и Apache Pulsar как более лёгкие альтернативы; Redpanda тоже упоминается.
• Мнения разделились: кто-то считает Kafka переоценённой и «бюрократичной», кто-то — незаменимой для больших данных.

Основы

• Определите цель: чётко сформулируйте задачу перед генерацией кода.
• Начинайте с README: описание проекта помогает ИИ и команде.
• Используйте шаблоны: готовые структуры (FastAPI, React) экономят время.

Промпты

• Контекст: указывайте язык, фреймворк, стиль (PEP8, camelCase).
• Мелкие задачи: дробите фичи на куски по 50–100 строк.
• Примеры: прикладывайте JSON-ответы или SQL-запросы.
• Итерации: улучшайте код по одному аспекту за раз.

Рабочий процесс

• Сессии: 30-минутные циклы «запрос-ревью-запуск».
• Git-коммиты после каждого шага для отката.
• Линтеры/тесты сразу: pytest, eslint, mypy.
• Code Review: проверяйте всё, даже «очевидное».

Инструменты

• Copilot Chat в IDE для быстрых правок.
• Cursor / Windsurf для многофайлового рефакторинга.
• Playwright для e2e-спек, сгенерированных из текста.
• Docker для воспроизводимого окружения.

Качество

• Типы: добавляйте аннотации (TypedDict, Pydantic).
• Док-строки: пишите для всех публичных функций.
• Тесты: покрывайте критические пути ≥80 %.
• Логи: структурированные (structlog) для отладки.

Безопасность

• Секреты: проверяйте .env и git history.
• OWASP Top 10: сканируйте зависимости (pip-audit, npm audit).
• RBAC: реализуйте роли и разрешения сразу.

Производительность

• Профилирование: cProfile, py-spy для горячих точек.
• Кеш: Redis для частых запросов.
• CDN для статики фронтенда.

Деплой

• CI/CD: GitHub Actions → Docker → ECS/Fargate.
• Feature flags для постепенного релиза.
• Мониторинг: CloudWatch + Grafana.

Советы

• Не доверяйте 100 %: всегда читайте сгенерированный код.
• Учитесь у ИИ: спрашивайте «почему так» для роста навыков.

• Подавляющее большинство участников считает «vibe-coding» либо вредным, либо вообще не тем, что описано в документе.
• Настоящий vibe-coding — это «не смотреть код, а принимать результат, если визуально работает»; любые советы «тщательно читайте код» противоречат самому термину.
• Многие предпочитают писать чёткие спецификации и использовать LLM как «парного программиста», но подчёркивают, что это уже не «vibe», а обычная работа с AI.
• Частый риск — накопление непонятного, неотрефакторенного кода и «отравление» контекста при изменении требований.
• Итоговый совет большинства: «Don’t go full vibe» — даже при активном использовании LLM нужно понимать и контролировать результат.

Почему в 2025 году мы всё ещё пишем на Ruby

Стартуя с Lago, мы выбрали Ruby on Rails — у команды был десятилетний опыт, и это был самый быстрый путь к рабочему API. Сегодня система обрабатывает миллионы вызовов в день, пережила множество обновлений Ruby/Rails, и, если бы начинали заново, выбор остался бы тем же.

Скорость как главное преимущество
Rails больше не «тренд» для стартапов, но его используют Shopify, GitHub, GitLab — зрелые компании, которым важна надёжность и скорость разработки. Мы взяли Rails в API-only режиме: без лишнего middleware и рендеринга, но с миграциями, валидациями, Active Record и фоновыми задачами. Это позволило тратить время на продукт, а не на костыли.

Масштабируемость
Rails не масштабируется? Это проблема архитектуры, а не фреймворка.

• Rails 8 упрощает деплой без PaaS.
• Redis + Sidekiq проверен временем.
• Ruby Fibers добавляют асинхронность.
• Puma, автомасштабирование и кеширование справляются с нагрузкой.

Недостатки, с которыми живём

• Производительность и память: ошибки дорого обходятся.
• GIL CRuby: один поток Ruby-кода за раз, поэтому тяжёлые задачи уходят в Go/Rust.
• «Магия» Rails: избегаем лишних гемов и пишем максимально явный код.

Все языки компромиссы; мы выбрали Rails, потому что знаем его настолько хорошо, что умеем обходить ограничения и получать максимум скорости разработки.

• Участники жалуются на рутину вокруг JS/TS-стека: тройное дублирование типов, самописная интеграция auth и прочие «reinventing wheels».
• Многие называют Rails «скучным, но рабочим» инструментом, который до сих пор быстро даёт полный вертикал функционала без бойлерплейта.
• Популярность Rails страдает из-за ассоциаций с «устаревшей» эпохой 10-летней давности и отсутствия хайпа, хотя кодовая база активно развивается (YJIT, ZJIT).
• На практике Rails используется для бизнес-логики и API, а Go/Rust — для I/O- или CPU-ёмких задач; Shopify и GitHub живут по такой же схеме.
• Некоторые мечтают о «Rails на другом языке» (Clojure, Gleam) или ждут, что AI сделает быстрые языки такими же удобными, как Ruby.