Hacker News Digest

UUIDv7, новая версия универсального уникального идентификатора на основе временных меток, появится в PostgreSQL 18. Она решает ключевые проблемы традиционных UUID: отсутствие сортируемости и низкую локальность индексов. В отличие от UUIDv4 со случайной структурой, UUIDv7 содержит временной компонент, что обеспечивает последовательную вставку в B-деревья и снижает фрагментацию. Это особенно полезно для распределенных систем, где клиенты генерируют ID без координации с сервером.

Хотя размер UUID остаётся 128-битным (больше, чем INT или BIGINT), современные CPU эффективно обрабатывают такие значения через SIMD-инструкции. Важно использовать бинарное представление UUID, а не строковое, для оптимизации производительности. UUIDv7 также подходит для публичных идентификаторов, так как их сложно угадать, в отличие от автоинкрементных чисел. Это делает его идеальным выбором для шардированных баз данных и сред с минимальной серверной координацией.

• Обсуждаются проблемы безопасности UUIDv7 из-за экспозиции времени создания в публичных идентификаторах, что может упростить угадывание соседних записей.
• Предлагаются решения для сокрытия времени создания на границе API, например, преобразование UUIDv7 в UUIDv4 или шифрование временной метки.
• Отмечается, что 62 бита случайности в UUIDv7 при наличии лимита запросов обеспечивают достаточную безопасность для большинства веб-приложений.
• Поднимается вопрос о негативном влиянии UUID (по сравнению с последовательными целыми числами) на производительность БД из-за отсутствия оптимизаций для последовательных ключей.
• Утверждается, что безопасность не должна зависеть от формата первичного ключа, а проблемы угадывания ID указывают на ошибки в проектировании системы.

Патент OrioleDB теперь свободен для сообщества Postgres.

• Supabase открыла патент на B+-tree-структуру под Apache 2.0, заявляя, что это «щит» против IP-исков.
• Критики называют предыдущую лицензию «poison pill»: лицензия прекращалась при судебном иске к Supabase.
• CEO Supabase признал ошибку, быстро перелицензировал OrioleDB на Apache 2.0 и готов даже отдать патент сообществу.
• Некоторые участники всё равно не доверяют: считают, что 99 % «новизны» взято из старых научных работ и что щит защищает только компанию.
• Практические вопросы: пока нет SERIALIZABLE-уровня, совместимость не со всеми расширениями, зато высокая производительность на запись.

Формат файла 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: колонковый, неизменяемый, читается любым движком.

Поисковый индекс Marginalia переписан, чтобы лучше использовать NVMe-накопители.
Основные изменения:

• Объём: после ослабления фильтров и добавления рекламного детектора база выросла с 350 до 800 млн документов; ожидается дальнейший рост при добавлении новых языков.
• Структура: обратный индекс остался «картой терм → список (документ, позиции)», но B-дерево теперь читается в режиме O_DIRECT, минуя кэш страниц.
• Чтение:
  • Буферизованные чтения неэффективны при случайном доступе к файлам, превышающим RAM.
  • Прямые чтения требуют выравнивания по 512/4096 Б, но дают стабильную задержку и не копируют данные лишний раз.
  • В Linux появляется RWF_DONTCACHE, но поддержка пока неполная.

Первая оптимизация — переписать B-дерево под O_DIRECT; дальнейшие шаги ещё описываются.

• 128–256 КБ считаются «классическим» оптимальным размером блока, но в 2024 г. всё чаще замеряют индивидуально: всё зависит от архитектуры I/O.
• Для NVMe при высокой параллельности 4 КБ работает не хуже, если использовать AsyncIO/IO_uring или SPDK и выдавать много одновременных запросов.
• Меньшие блоки экономят чтение, но не избавляют от внутреннего read-amplification SSD; нужно знать минимальный физический размер чтения контроллера.
• Формат LBA (512 B vs 4 КБ+) и опции sysfs (optimal_io_size) влияют на производительность и стоит их проверять.
• В задачах индексного поиска параллельность ограничена, поэтому крупные блоки остаются практичным выбором при отсутствии точных данных о «железе».