Hacker News Digest

/dev/null в Unix-системах с юмором представлена как база данных, полностью соответствующая принципам ACID. Атомарность обеспечивается тем, что любые записанные данные либо полностью исчезают, либо не записываются вовсе. Согласованность поддерживается инвариантом пустоты — файл всегда остаётся в одинаковом состоянии, независимо от операций. Изолированность проявляется в том, что множественные процессы могут одновременно писать в /dev/null без конфликтов, так как данные никогда не сохраняются. Долговечность гарантирует, что после сбоя система сохраняет своё главное свойство — полное отсутствие данных.

Эта шуточная статья подчёркивает, что /dev/null идеально соответствует всем требованиям ACID-совместимой базы данных, с единственным недостатком — нулевым объёмом хранения. Автор иронизирует, что для расширения пространства нужно обратиться в "корпоративные продажи", которые на самом деле являются им самим. Этот пример демонстрирует, как технические концепции можно рассматривать с неожиданной и забавной стороны.

• Обсуждение вокруг /dev/null как "база данных" выявило, что это скорее метафора, чем реальная технология, и подчеркнуло важность различать хранилище и СУБД.
• Участники обсуждали, что /dev/null не является базой данных, но при этом подчеркнули, что он обеспечивает ACID-свойства и масштабируемость.
• Были подняты вопросы о масштабируемости, отказоустойчивости и соответствии с ACID, а также о том, что такое "база данных" и как она отличается от просто носителя.
• Участники также обсудили, что /dev/null действительно обеспечивает высокую доступность и согласованность, но не является базой данных в строгом смысле.

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

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

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

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

В статье демонстрируется сравнительный анализ производительности между UUIDv4 и UUIDv7 через создание двух таблиц для "магазина крабов" с использованием Aiven for PostgreSQL. Авторы предоставляют практические примеры кода для создания сервиса и таблиц, а также функцию для вставки случайных данных. Тесты показывают, что UUIDv7 может значительно улучшить производительность операций вставки по сравнению с UUIDv4, особенно при работе с большими объемами данных.

• UUIDv7 раскрывает время создания записи, что может быть критично для приватности и безопасности, особенно если первичный ключ публично доступен.
• Эксперты рекомендуют использовать UUIDv7 только для внутренних ключей и выставлять отдельный UUIDv4 как публичный идентификатор.
• Но в большинстве случаев, когда выбор между UUIDv7 и v4, важно учитывать, что v7 предоставляет лучшую производительность при вставке и сортировке, но требует дополнительных усилий для защиты приватности.

Всё, что я знаю о хорошем системном дизайне

Системный дизайн — это то, как мы собираем сервисы, а не строки кода. Его примитивы: серверы, БД, кэши, очереди, прокси и т.д.

Хороший дизайн выглядит скучно: ничего не ломается, задачи решаются проще, чем ожидалось. Сложные системы с CQRS, консенсусом и прочими фокусами часто компенсируют плохие решения. Сложное должно расти из простого, а не строиться сразу.

Состояние и его минимизация
Сложность — в управлении состоянием. Stateless-сервисы (например, конвертер PDF → HTML) перезапускаются и живут вечно. Stateful-сервисы могут «испортиться» и требуют ручного лечения. Поэтому:

• Один сервис пишет в БД, остальные общаются с ним по API/событиям.
• Чтение иногда проще делать напрямую, но писать — только через «владельца» данных.

Базы данных
Главный компонент.

• Схема: читаемая человеком, достаточно гибкая, но не «всё в JSON».
• Индексы: под самые частые запросы, не больше.
• Узкие места: обращения к БД часто тормозят всё.

• Сложность ≠ хороший дизайн: большинство участников согласны, что переусложнённые системы часто свидетельствуют о слабом проектировании, но на собеседованиях это лучше не озвучивать.
• Главный критерий — пригодность (fit for purpose): универсальных «правильных» архитектур не существует, нужно исходить из задач команды и бизнеса.
• Простота и KISS ценятся выше модных паттернов; монолит или «скучные» технологии часто эффективнее микросервисов и самописных очередей.
• Ключевые боли — синхронизация состояний и транзакционность между сервисами; чем меньше распределённого состояния, тем проще жить.
• Не забывать людей: Conway’s Law и топология команд влияют на архитектуру не меньше, чем технические решения.