Hacker News Digest

Регистр текста существенно влияет на размер QR-кодов. Алгоритм кодирования интерпретирует смешанный регистр как бинарные данные (8 бит на символ), а верхний регистр — как алфавитно-цифровые данные (5.5 бит на символ). Это связано с тем, что QR-коды используют специальный алфавит из 44 символов (цифры, заглавные буквы и несколько знаков), где два символа кодируются в 11 битах. Любой символ вне этого алфавита, включая строчные буквы, переключает режим кодирования на 8-битный.

Практический пример демонстрирует разницу: QR-код для предложения "The quick brown fox jumps over the lazy dog" в смешанном регистре занимает 33×33 пикселя (1089), а в верхнем регистре — всего 29×29 (841 пикселя), что составляет сокращение примерно на 30%. Этот принцип применяется в криптографии: Bech32-кодирование Bitcoin-адресов (32 символа) требует меньше пикселей в QR-коде, чем Base58 (58 символов), несмотря на меньший алфавит, так как использует только строчные буквы, которые перед кодированием преобразуются в заглавные.

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

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

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

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