Hacker News Digest

Статья представляет пошаговое руководство по созданию простой key-value базы данных с нуля. Начальный подход предполагает хранение данных в обычном файле, где каждая строка содержит пару ключ-значение. Однако такой метод неэффективен для обновлений и удалений, так как требует перемещения всех последующих данных. Решением становится использование append-only файла, где записи являются неизменяемыми, а обновления и удаления обрабатываются через добавление новых записей и специальные "надгробные" метки.

Основные проблемы этого подхода — неограниченный рост файла и медленный поиск, так как для нахождения ключа может потребоваться просмотреть все записи. В примере показано, что файл базы данных может содержать множество записей, но только небольшая часть из них представляет актуальные данные, в то время как остальные являются удаленными или устаревшими. Для решения проблемы роста файла необходим механизм периодического "сжатия", который бы удалял нерелевантные данные и уменьшал размер файла.

• Обсуждение охватывает вопросы от дизайна и UX до фундаментальных концепций, таких как ACID, индексы и LSM-деревья, и даже до того, что не стоит писать свою СУБД, если можно использовать готовую.
• Участники обмениваются советами по инструментам вроде riak_core и Bitcask, обсуждают проблемы репликации и отказоустойчивости, и делятся личными историями о том, как они писали свои собственные базы данных.
• Некоторые комментарии поднимают вопросы о правильном подходе к обучению и документации, а также о том, как сделать так, чтобы читатели могли бы легко следить за обсуждением и не теряли нитку.
• Некоторые участники делятся ссылками на полезные ресурсы, такие как "Designing Data-Intensive Applications" и "Build Your Own Database".
• Некоторые участники поднимают вопросы о том, как лучше всего подавать контент, чтобы он был интерактивным и в то же время не перегружал читателя, и обсуждают, как лучше всего структурировать и визуализировать информацию.
• Некоторые участники делятся личными историями о том, как они писали свои собственные базы данных, и обсуждают, какие вызовы они встретились и как они их преодолели.

Исследователи обсуждают концепцию "оптического сжатия" — представления текста как изображений для обработки в больших языковых моделях. Согласно статье, DeepSeek продемонстрировал, что из одного токена изображения можно извлечь 10 текстовых токенов с точностью почти 100%, что делает внутреннее представление изображений в моделях в 10 раз эффективнее текстового. Этот подход уже используется некоторыми компаниями и open-source проектами, хотя не является штатным режимом работы существующих моделей.

Почему это может работать? Текстовые токены дискретны и ограничены (около 50 000), тогда как токены изображений непрерывны и могут выражать гораздо больше информации. Внутри модели текстовые токены преобразуются в неэффективное представление, в то время как изображение уже содержит компактную форму данных. Более того, обработка текста как изображений ближе к тому, как работает человеческий мозг, воспринимающий текст визуально. Однако автор отмечает, что многие теоретически перспективные идеи в ИИ не работают на практике, а обучение новых моделей на тексте в виде изображений представляет собой сложную задачу.

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

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

В примерах показано, как сократить размер данных в 4–8 раз по сравнению с традиционными подходами, например упаковывая несколько булевых значений в один байт или используя битовые маски для хранения состояний. Это не только экономит память, но и улучшает производительность за счёт лучшей локализации данных и уменьшения аллокаций. Практический вывод: для критичных к производительности задач стоит рассматривать низкоуровневую оптимизацию данных, даже если она усложняет код.

• Проблемы совместимости кода для x86 и ARM архитектур, включая необходимость использования библиотеки SIMDe для эмуляции x86 intrinsics на ARM.
• Обсуждение особенностей и ограничений NEON (ARM SIMD) по сравнению с SSE (x86 SIMD), включая отсутствие инструкции movemask и предложенные альтернативы.
• Потенциальные применения алгоритма для эффективной битовой упаковки и распаковки данных в задачах, чувствительных к пропускной способности памяти (например, в data warehouses).
• Критика методологии бенчмарков и сравнений в исходном исследовании, анонс собственной работы по схожей тематике.
• Рекомендации к дополнительным материалам по теме: научная статья обобщающая алгоритмы и статья о симуляции bit packing на NEON.

Современные колоночные форматы данных, такие как Parquet и ORC, созданные более десяти лет назад, не справляются с требованиями современных аналитических систем: они неэффективны для широких таблиц с тысячами столбцов, векторными эмбеддингами и большими бинарными объектами, а также не оптимизированы для случайного доступа или обновлений. Их ограниченная расширяемость и проблемы совместимости между версиями библиотек затрудняют внедрение новых методов сжатия, индексации и фильтрации.

Представлен формат F3, разработанный для обеспечения интероперабельности, расширяемости и эффективности. Ключевая инновация — встраивание декодеров в виде компактных WebAssembly-бинарников прямо в файл, что гарантирует совместимость на любой платформе без зависимостей от внешних библиотек. Это позволяет легко добавлять новые схемы кодирования через универсальный API, избегая необходимости переписывать формат при изменениях в обработке данных. Тесты показывают преимущества F3 в организации хранения и декодировании через Wasm по сравнению с существующими решениями.

• Обсуждение формата F3 сосредоточено на его использовании WebAssembly для встраивания декодеров в файлы, что обеспечивает будущую совместимость, но вызывает споры о производительности (10-30% замедление) и безопасности (риск вредоносных payload).
• Участники обсуждают преимущества и недостатки колоночного хранения данных по сравнению с другими подходами, а также сложности внедрения нового формата из-за инерции существующих экосистем (Parquet, ORC).
• Поднимаются вопросы о практичности формата, включая зависимость от WASM, увеличение сложности и потенциальные проблемы с обратной совместимостью интерфейсов для WASM-модулей.
• Отмечается участие известных экспертов (Уэс МакКинни, Энди Павло) как фактор доверия к проекту, но также выражается скептицизм по поводу его жизнеспособности и оптимизации.
• Обсуждаются альтернативы и похожие проекты (Vortex, Anyblox, Arrow), а также необходимость поддержки сообщества, коннекторов и интеграции с популярными инструментами для успеха F3.

• Участники делятся книгами и ресурсами по теории информации и кодированию: труд Шеннона, новые учебники, PhD-диссертация о сжатии без потерь и связи с генеративным ИИ.
• «Coding» здесь — это кодирование/декодирование данных для защиты от ошибок, сжатия и передачи, а не «программирование».
• Рекомендуются вводные тексты Пирса и Стоуна, а также классика Петерсона–Уэлдона и МакКея.
• Тема считается математически плотной и факультативной даже для старших курсов CS.

• Недавние записи
  Архив блога

• Одно из ключевых достижений вычислений — сжатие данных: мы уменьшаем размер, сохраняя всю информацию (без потерь), передаём и восстанавливаем исходник.

• Раньше сжатие было необходимо: носители малы, сети медленны. Сейчас это не всегда критично, но по‑прежнему полезно: эта страница почти наверняка пришла к вам в сжатом виде, что ускоряет загрузку и снижает нагрузку на сервер.

• Забавно, что в 2025 мы нередко делаем противоположное. Пример: Бобу нужен новый рабочий компьютер. Его просят написать 4 абзаца обоснования. Он просит LLM сгенерировать текст и отправляет менеджеру.

• Менеджер получает длинное письмо, копирует его в LLM и просит резюме в одном предложении: «Нужен новый компьютер, старый медленный и мешает продуктивности». Заявку одобряют.

• Я называю это «инфляцией LLM»: легко превращать короткое и простое в длинное и видимо глубокое — и обратно, длинное и «глубокое» в короткое и простое.

• Это не упрёк LLM. Но стоит задуматься, почему мы раздуваем контент: в лучшем случае поощряем туманность и трату времени; в худшем — скрываем отсутствие ясной мысли. LLM лишь обнажают масштаб. Возможно, это подтолкнёт нас к изменениям!

• 2025‑08‑06 10:50 — Более раннее

• Обновления: Mastodon, Twitter, RSS, e‑mail

• Сноски:
  И, разумеется, теория информации, но здесь важны практические эффекты.

• Комментарии

• Обсуждение вращается вокруг “инфляции текста” из‑за LLM: люди генерируют лишнюю прозу для бюрократических требований, а получатели затем используют LLM для сжатия обратно до сути.
• Многие считают проблему культурной и организационной: длинные форматы служили фильтром/сигналом усилий и «критического мышления», но с LLM этот сигнал обесценился.
• Часть участников утверждает, что инфляция текста существовала и раньше; LLM лишь ускорили процесс и обнажили масштаб пустых формальностей.
• Другие видят в этом шанс: нормализовать краткость, требовать брифы/буллеты, а при необходимости поручать LLM расширение текста на стороне читателя.
• Встречаются скепсис и критика вымышленных кейсов (например, про “4 абзаца” для покупки ПК) как нереалистичных или оправдывающих бюрократию.
• Предлагаются альтернативные метрики и взгляды: оценивать модели по способности к компрессии информации; замечается, что «формальная вежливость» и сигналы статуса в языке подпитывают многословие.
• Общий вывод: инструменты генерации/суммаризации меняют баланс доверия и сигналов в коммуникации; организациям стоит переосмыслить процессы и поощрять ясность и краткость.