Статья разбирает, как построить key-value базу данных, у которой основным слоем хранения является объектное хранилище вроде S3, на примере движка IsleDB на Go, и почему наивная замена "файлов на диске" на "объекты в бакете" не работает. СУБД неявно полагается на атомарное переименование, дешевые случайные чтения и понятный ответ на вопрос "записалось ли?".
Ключевая идея в том, что LSM-дерево уже идеально ложится на объектную модель, а видимость состояния задается не перечислением бакета, а маленьким мутабельным объектом заголовком, который обновляется условной записью (используется CAS), дополняется токеном для защиты от "оживших" старых писателей и ограниченным маркером коммита для разрешения ситуации "запись прошла, но ответ потерялся".
Объектное хранилище вот совсем не убирает сложные проблемы СУБД. Наборот, концентрирует их в небольшом наборе протоколов публикации и жизненного цикла, которые и становятся настоящим "транзакционным движком"
