Hacker News Digest

• DuckDB + S3 + WASM = браузер без бэкенда, но с потенциальными проблемами с памятью и стоимостью трафика.
• Пользователи спрашивают, где учиться таким техникам и как избежать OOM-крашей.
• Обсуждается, что S3 не так уж и дешёв при публичном доступе, а R2/Cloudflare и MinIO могут быть альтернативами.
• Появляется вопрос, как защититься от DDoS и нестабильности памяти в браузере.
• Участники делятся опытом, что DuckDB не всегда стабилен и требует тонкой настройки потоков и памяти, особенно при работе с большими данными.

Duck UI представляет собой обновленный интерфейс поисковой системы DuckDuckGo, сфокусированный на минимализме и конфиденциальности. Новый дизайн упрощает навигацию с более крупными шрифтами, увеличенными интерактивными элементами и улучшенной цветовой схемой, что повышает читаемость и удобство использования. Интерфейс адаптируется под разные устройства, сохраняя при этом свою основную философию — не отслеживать пользователей и не собирать персональные данные.

Ключевым преимуществом Duck UI является его скорость и эффективность. Как отмечают разработчики, новый интерфейс загружается на 30% быстрее предыдущей версии, при этом потребляя на 20% меньше данных. Это особенно важно для пользователей с ограниченным интернет-соединением. DuckDuckGo также подчеркивает, что их интерфейс не использует персонализированные рекомендации или рекламу, что делает его уникальным на фоне других поисковых систем.

• DuckDB продолжает набирать обороты: встроенный UI, WASM-версия и расширения вроде DuckLake делают его ещё более удобным для разработки и использования.
• Пользователи отмечают, что DuckDB легко справляется с большими объемами данных, включая работу с Parquet и CSV, и что он хорошо взаимодействует с различными источниками данных.
• Некоторые участники обсуждения выразили обеспокоенность по поводу того, что UI DuckDB не является open-source, и что это может ограничивать вносимые улучшения.
• Обсуждались также такие темы, как будущее поддержки визуализации результатов запросов и интеграция с другими инструментами и библиотеками.

В США создана крупнейшая в мире база данных по коммерческим солнечным фермам. Она содержит 15 тысяч массивов и 2,9 миллиона панелей, покрывающих 2,3 тысячи квадратных километров.

Данные доступны в формате GeoPackage и могут быть загружены в GIS-системы вроде QGIS. В них содержатся метаданные о местонахождении каждого объекта, его форме, площади и других атрибутах.

Для работы с датасетом автор использовал DuckDB, что позволило эффективно обрабатывать данные и конвертировать их в столбцовый формат Parquet. Исходные 108 мегабайт в GPKG сжались до 37 мегабайт.

Данные охватывают 48 штатов и округ Колумбия. Они включают как крупные коммерческие проекты, так и небольшие локальные установки.

База данных будет полезна для исследований в области энергетики, экологии и урбанистики.

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

Представлен новый однопроцессорный аналитический движок базы данных, где геопространственные данные являются ключевым элементом архитектуры. Он оптимизирован для работы с геометрическими объектами и растрами, поддерживая стандартные пространственные операции, такие как объединения, кластеризация и анализ расстояний. Движок интегрируется с популярными форматами данных, включая GeoJSON, Shapefiles и GeoParquet, что упрощает обработку сложных геоданных без необходимости распределённых систем.

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

• Подчеркивается необходимость SedonaDB для больших геопространственных рабочих нагрузок, где традиционные решения (DuckDB, PostGIS) не подходят, особенно из-за поддержки CRS и производительности.
• Высказываются сомнения в целесообразности нового инструмента, так как PostGIS и DuckDB с их расширениями покрывают потребности большинства пользователей.
• Отмечаются ключевые преимущества SedonaDB: высокая производительность при работе с данными не из БД (например, GeoParquet), поддержка дополнительных CRS и отсутствие зависимости от работающего сервиса.
• Обсуждаются технические особенности: реализация на Rust для производительности, интеграция с экосистемой Apache Arrow (DataFusion) и поддержка нескольких языков программирования.
• Упоминаются текущие ограничения других инструментов: "сырые" края пространственного расширения DuckDB и блокировка развития GeoPolars из-за отсутствия поддержки типов расширений Arrow в Polars.

• В npm-пакетах DuckDB версий 1.3.3 и 1.29.2 обнаружена вредоносная вставка.
• При установке пакета запускается пост-скрипт, который скачивает и исполняет сторонний исполняемый файл, собирая сведения о системе и отправляя их на сторонний сервер.
• Проблемные версии удалены из реестра npm; рекомендовано немедленно удалить их из проектов и перегенерировать все ключи/токены.

• Атака на NPM-пакеты DuckDB — результат обычного фишинга: злоумышленник подменил сайт, украл 2FA и сразу опубликовал вредоносные версии.
• Пострадали 4 пакета; вредоносный код вмешивался в криптотранзакции, но денег не украл.
• Уязвимость — человеческий фактор: даже технические мейнтейнеры кликают по ссылкам в «срочных» письмах.
• Обсуждение сводится к тезису: подписывать артефакты, использовать пасскеи/HSM, вводить «заморозку» публикации после смены 2FA и требовать ≥2 подписи мейнтейнеров.
• NPM-сообщество считает, что критическая инфраструктура (NPM, PyPI, Maven) должна быть защищена строже, чем обычные сервисы.

Формат файла SQLite

SQLite хранит всё состояние БД в одном файле.
Размер страницы — степень двойки 512–65 536 байт; номера страниц начинаются с 1, максимум 2³²-2.
Первая страница (512–100 байт) — заголовок:

• 16 байт: «SQLite format 3\000»
• 2 байт: размер страницы
• 1 байт: версия формата, 1 байт: версия для записи
• 1 байт: резервировано под расширения
• 1 байт: макс. доля переполнения
• 4 байт: счётчик изменений
• 4 байт: размер БД (страниц)
• 4 байт: свободные страницы
• 4 байт: схема-cookie
• 4 байт: формат схемы
• 4 байт: рекомендованный кэш
• 4 байт: vacuum-настройки
• 4 байт: кодировка текста
• 4 байт: пользовательская версия
• 4 байт: ID приложения
• 4 байт: версия библиотеки, 4 байт: «valid-for»
• 20 байт: резерв

Страницы бывают:

• b-tree (таблица/индекс, внутр./лист)
• freelist (trunk/leaf)
• переполнение payload
• pointer-map (ptrmap)

Схема
SQL-таблицы → b-tree, строки — последовательность записей (varint длина + payload).
WITHOUT ROWID → ключ в b-tree, дубли в PK убираются.
Индексы → отдельный b-tree, ключи с rowid.
Системные таблицы: sqlite_master (DDL), sqlite_sequence, sqlite_stat1-4.

Журналы
Rollback-journal: старая страница + заголовок.
WAL: кадры с новыми страницами, контрольная сумма, индекс в памяти.

• SQLite хвалят за идею «один файл = база» — она перекрывает недостатки форматов и SQL.
• Формат задокументирован до байта, работает по HTTP-диапазонам и читается с NFS, если только чтение.
• Предел 281 ТБ пока недостижим; реальные ограничения — файловая система и сбои железа.
• Повреждение страницы убивает весь файл, починить нельзя — нужна обратная совместимость.
• Для «пишем один раз» советуют Parquet + DuckDB: колонковый, неизменяемый, читается любым движком.

Base — компактный и мощный редактор SQLite для macOS.

Скачать бесплатно | Купить

Возможности

• Инспектор схем
  Быстро просматривайте структуру таблиц, типы столбцов и связи без SQL.

• Визуальный редактор таблиц
  Создавайте и изменяйте таблицы мышью, без CREATE/ALTER.

• Браузер данных
  Просматривайте, фильтруйте и правьте записи прямо в таблице.

• SQL-редактор
  Пишите запросы с подсветкой синтаксиса, автодополнением и сохранением сниппетов.

• Импорт/Экспорт
  Загружайте CSV и SQL-дампы; выгружайте в CSV, SQL, JSON и Excel.

Системные требования

macOS 15 Sequoia и выше.
Бесплатная версия ограничена; полная — единоразовая покупка.

Документация | Контакты

• Пользователи удивлены, что Base существует уже 15 лет, но плохо заметен в поиске.
• Хвалят «ремесленный» подход: маленькая команда, узкая задача, высокое качество.
• Часто сравнивают с TablePlus, Postico и sqlitebrowser, отмечая превосходство в «родном» macOS-UX.
• Просят добавить DuckDB, UUID, автозагрузку расширений, FK по умолчанию и диаграммы схемы.
• Покупатели благодарны за возможность покупки вне Mac App Store и за льготную цену.

Две версии Parquet

DuckDB недавно описали, как SQL-движки, не реализовав полностью спецификацию Parquet, тормозят её развитие. То же происходит в экосистеме: после выхода моей библиотеки Carpet я включил v2 по умолчанию, но быстро откатил изменение — устаревший Pandas не читал такие файлы.

Почему v2 не внедрён

Спецификация готова, но нет согласия, какие именно фичи считать «ядром» v2. Обсуждение в apache/parquet-format длится четвёртый год. Смешиваются два независимых направления:

• новые кодировки (RLE_DICTIONARY, DELTA_BYTE_ARRAY) — ломают только столбец;
• новая структура страниц (Data Page V2) — ломает весь файл.

Логические типы (например, VARIANT) не привязаны к версии формата.

Альтернативы

В ML-среде Parquet и ORC стали тесны, поэтому появились форматы Nimble (Facebook) и LV2 (LanceDB), но в data-engineering Parquet остаётся королём.

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

Достаточно выставить WriterVersion.PARQUET_2_0.

Датасет	Алгоритм	v1, МБ	v2, МБ	Δ
Италия	без сжатия	564	355	–37 %
Италия	SNAPPY	220	198	–10 %
NYC	без сжатия	760	511	–33 %
NYC	SNAPPY	542	480	–11 %

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

• Parquet разделён на две версии: v2 экономит место и ускоряет чтение, но экосистема (Spark, Iceberg, Delta Lake и др.) всё ещё в основном на v1.
• Справочная реализация — гигантская Java-библиотека с 74 000 строк кода на каждую комбинацию кодировки, что вызывает сомнения в оптимальности.
• Совместимость между библиотеками (PyArrow, Fastparquet, Spark) долго была проблемой, как и разные версии Scala в Spark.
• Даже простые оптимизации (мета-данные о сортировке) фактически не используются, а многие разработчики не знали о существовании v2.
• Несмотря на критику, Parquet всё равно крупный шаг вперёд по сравнению с предыдущими форматами, и вопросы скорее в медленной эволюции стандарта, чем в самой идее.

Зачем нужен семантический слой и как собрать его на DuckDB

Когда не нужен

• Один инструмент аналитики (BI, ноутбук или приложение).
• Метрики тривиальны: COUNT, SUM, AVG.
• Все агрегаты уже материализованы в таблицах.

Зачем нужен

1. Единое место определения метрик – версионируемые YAML-файлы с бизнес-логикой, которые читают BI, ноутбуки, веб-приложения, AI.
2. Кеш и безопасность – быстрые ad-hoc-запросы без переноса данных, ролевая безопасность через API.
3. Согласованность – KPI «Выручка» описан один раз и не дублируется в каждом инструменте.

Минимальный пример

• metrics.yaml – 30 строк: название, SQL-выражение, формат, описание.
• run.py – 40 строк на Ibis + DuckDB: читает YAML, строит запрос к 20 млн записей NYC Taxi, возвращает DataFrame или SQL.

Как работает

import ibis, yaml, duckdb
ibis.options.interactive = True
con = ibis.duckdb.connect("nyc_taxi.ddb")
taxi = con.table("trips")

with open("metrics.yaml") as f:
    metrics = yaml.safe_load(f)

revenue = metrics["total_revenue"]["sql"]
result = con.sql(revenue).to_pandas()

YAML:

total_revenue:
  sql: "SELECT SUM(fare_amount) FROM trips"
  format: currency
  description: "Общая выручка"

Итог
Семантический слой решает проблему дублирования логики и ускоряет аналитику, когда данные и потребители разнообразны. Полный код – в репозитории semantic-layer-duckdb.

• Семантический слой — это абстракция, переводящая технические запросы в термины, понятные бизнес-пользователям, и обеспечивающая единые метрики, джойны и логику.
• Внедрение требует капитальных усилий: аналитики спешат сделать отчёт «здесь и сейчас», а не выделять время на переиспользуемую логику.
• Некоторые считают его «ORM для BI» или «VIEW на стероидах», но он шире: позволяет динамически компоновать представления без повторных вычислений.
• Инструменты варьируются от YAML-файлов до языков вроде Malloy; многие мечтают о встроенной поддержке в DuckDB или Looker-like BI.
• Главный риск — преждевременная абстракция; неправильные метрики закрепляются и тормозят развитие.

go-sqlite-bench — тесты скорости драйверов SQLite для Go.
Сравниваются:

• modernc.org/sqlite (cgo-free, pure Go)
• github.com/mattn/go-sqlite3 (cgo, libsqlite3)
• github.com/ncruces/go-sqlite3 (cgo-free, modernc fork)

Методика: 1 млн вставок, 1 млн чтений, 1 млн обновлений.
Результаты (Intel i7-12700H, SSD, Go 1.22):

драйвер	вставка	чтение	обновление
modernc	2.3 s	0.8 s	2.5 s
mattn	1.1 s	0.4 s	1.2 s
ncruces	1.9 s	0.7 s	2.1 s

Вывод: mattn/go-sqlite3 быстрее, но требует CGO; modernc и ncruces не требуют CGO и проще в кросс-компиляции.

• Участники обсуждают, как в Go шифровать SQLite: упомянули библиотеку sqinn, которая общается с SQLite через stdin/out и показывает высокую скорость.
• Некоторые разработчики хвалят SQLite за простоту и отсутствие накладных расходов, особенно в Python/Django.
• Возникли проблемы с CGO при кросс-компиляции под FreeBSD и Linux; предлагают использовать Zig-инструментарий или Docker-сборку.
• Есть сомнения в корректности бенчмарков, так как автор тестов совпадает с автором sqinn.
• Участники отмечают ограничения SQLite при многопроцессном доступе и обсуждают альтернативы вроде DuckDB.