Hacker News Digest

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

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

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

PostgreSQL может быть как чтением, так и записью интенсивной в зависимости от бизнес-логики приложения. Для социальных сетей характерно чтение интенсивное, а для IoT логгеров — запись интенсивная. Определение профиля нагрузки критично для эффективной настройки: чтение интенсивные БД выигрывают от индексации, кэширования запросов и реплик, тогда как запись интенсивные требуют оптимизации хранилищ, управления WAL и дизайна таблиц.

Чтения и записи в PostgreSQL не равны по стоимости: чтение происходит 8kb блоками, часто из памяти, в то время как запись включает WAL, индексы, TOAST таблицы и требует больше ресурсов. Автор предлагает запрос для оценки соотношения чтения/записи на основе внутренних метаданных PostgreSQL, где по умолчанию используется соотношение 5:1 (чтение:запись).

• Обсуждение критикует статью за то, что она не сравнивает PostgreSQL с другими СУБД и не дает практических советов по тюнингу под конкретную нагрузку.
• Участники обсуждают, что статья не учитывает, что большинство приложений имеют смешанную нагрузку на чтение и запись, а не чисто чтение или запись.
• Некоторые комментаторы отмечают, что статья не упоминает OLTP и OLAP, что делает ее менее полезной для практического использования.
• Также обсуждается, что статья не дает ясного определения, что считается "read-heavy" или "write-heavy" в контексте PostgreSQL.
• Наконец, участники обсуждают, что статья не предоставляет конкретных советов по тюнингу PostgreSQL под конкретную нагрузку.

pgEdge выпустил open-source-утилиту spock — логическую репликацию PostgreSQL с поддержкой multi-master. Проект позиционируется как замена Bucardo и Slony, но с фокусом на высокую доступность и отказоустойчивость. Под капотом — использование логической репликации, что позволяет конфликтам разрешаться на уровне транзакции, а не на уровне отдельных запросов. Это делает spock пригодным для кластеров, где каждая нода может принимать запись.

Проект написан на C и Python, распространяется под лицензией PostgreSQL. Поддерживает PostgreSQL 12-16 и требует расширение pglogical.

• Разработчики подчеркнули, что multi-master репликация не обеспечивает такую же строгую согласованность, как PostgreSQL, и что это важно учитывать при выборе решения.
• Участники обсуждали, что при использовании multi-master репликации важно понимать, какие именно edge cases могут возникнуть и как они решаются.
• Были упомянуты такие решения, как CockroachDB и pgEdge, и обсуждались их плюсы и минусы по сравнению с другими решениями.
• Также обсуждались вопросы лицензии и лицензионной политики, а также то, какие именно ограничения могут быть связаны с использованием таких решений.
• В конце обсуждения было отмечено, что важно понимать, что multi-master репликация не решает всех проблем масштабирования и что важно тщательно оценивать, подходит ли она для конкретного use case.

Raft — алгоритм консенсуса, проще в понимании, чем Paxos, с той же отказоустойчивостью и производительностью. Он разбит на независимые подзадачи и покрывает все практические аспекты.

Консенсус — соглашение нескольких серверов о значении; решение становится окончательным. Кластер из 5 машин работает, пока живы ≥3. Используется в реплицированных конечных автоматах: каждый сервер имеет журнал команд, которые консенсус выстраивает в одинаковом порядке, чтобы все автоматы оставались синхронизированы.

Визуализации

• RaftScope — интерактивная пятисерверная модель в браузере.
• The Secret Lives of Data — более мягкое, пошаговое объяснение.

Публикации

• Основная статья: In Search of an Understandable Consensus Algorithm (USENIX ATC’14 Best Paper).
• Диссертация Диего Онгаро: расширенное описание, формальная спецификация TLA+, упрощённое изменение состава кластера.
• Дополнительные работы: верификация (Woos et al., 2016), фреймворк Verdi (Wilcox et al., 2015), автогенерация кода (Evrard & Lang, 2015), анализ Raft (Howard, 2014–2015).

Доклады

• John Ousterhout, UIUC Distinguished Lecture, 2016 (видео, слайды).
• Jin Li, Dr. TLA+ Series, 2016 (видео, слайды).

• Обсуждение показало, что Raft сделал распределённый консенсус понятным и реализуемым, в отличие от Paxos.
• Участники делятся опытом: кто-то использует Raft для отказоустойчивой репликации состояния игры, кто-то — для промышленных систем.
• Упоминаются альтернативы и тонкая настройка: спектр дизайнов репликации Алекса Миллера, Viewstamped Replication, Consul-подход с батчами.
• Разобраны нюансы выборов лидера, сетевых разделов и гарантий «одной записи».
• Google использует и Paxos (Spanner), и ранние внутренние варианты VR; Raft тоже реализуют повсеместно.