... писать без транзакций?
... сохранять без кворума?
... стирать прод без бэкапов?
... сливать базу самому?
И всё это безопасно, надёжно, доступно!
Видео
Это — выступление на Scientific Open Source Meetup 2025. Можете глянуть видео запись:
Или почитать далее текстовую расшифровку.
Знакомимся
Серийный инноватор
---
Жертвы:
---
На счету:
100+ статей и спичей
Полчища хейтеров
---
Изобретения:
Об идеях, заложенных, в последнюю речь далее и пойдёт.
Проблема: Нельзя просто так взять и изменить файл
Разные накопители, файловые и операционные системы дают разные и довольно слабые гарантии. Подробнее об этом можно почитать в этой обстоятельной статье:
Методы безопасной записи
WAL: Write Ahead Log — предварительно пишем инфу для восстановления
- UNDO LOG — инфа для отката
- REDO LOG — инфа для доката
COW: Copy On Write — пишем в свободное место, затем меняем ссылки
LSS: Log Structured Storage — аппендим обновления, не стирая
От сбоя питания, конечно, защищены, а вот от сбоя диска, например, - нет. Тут мог бы помочь RAID, но есть вариант интересней..
Yin-Yan Mirrors
💡 Что если попеременно писать наживую в 2 зеркальные копии?
Имеем две копии: Yin и Yan.
Пишем в них попеременно: изменения + FSync.
Каждый раз — 2 последних пакета изменений.
Предпоследняя всегда консистентна.
Последнюю всегда можно удалить для экономии места.
Сравнение подходов
Профиль нагрузки: изменение горячих данных.
YYM | REDO WAL | UNDO WAL | COW | LSS | |
FSync / Write | ✅ 1 | ✅ 1 | ⭕ 2 | ❌ 2+ | ✅ 1 |
Total Write Amp | ⭕ ×2 | ⭕ ×2 | ⭕ ×2 | ❌ ×Path | ✅ ×1 |
Over Size | ✅ ×1 | ⭕ +News | ✅ ×1 | ✅ ×1 | ❌ +History |
Regular Tasks | ✅ — | ❌ Compact | ✅ — | ✅ — | ❌ GC |
Recovery | ✅ Just | ⭕ Fast | ⭕ Fast | ❌ Slow | ⭕ Fast |
Fragmentation | ⭕ Write | ⭕ Write | ⭕ Write | ❌ Read/Write | ⭕ Read |
Проблема: Данные всё равно теряются
📛 Накопитель побился
📛 Дата-центр затопило
📛 Троян зашифровал
📛 Админ скриворучил
📛 Баги погрызли
Бэкапы
Админы делятся на следующие типы:
🥳 Кто ещё не делает бэкапы
🧐 Кто уже делает бэкапы
😎 Кто ещё и проверяет, что бэкапы рабочие
🥴 Кто уже не делает бэкапы и грохает базу по приколу
Восстановление данных с клиентов
💡 Что если доверять данным с недоверенных узлов?
Все изменения подписываем цифровой подписью.
Реплицируем между серверами, дата-центрами, клиентами.
При утрате данных - восстанавливаем ото всюду... автоматом.
Два узла коннектятся, узнают, у кого чего нет, и начинают слать друг другу обновления.
Сравнение подходов
С подписями | Без подписей | |
Возможность подделки на сервере | ✅ Нет | ❌ Есть |
Восстановление с недоверенных узлов | ✅ Возможно | ❌ Риск подделки |
Коммуникация по открытым каналам | ✅ Безопасна | ❌ Риск подделки |
Аутентификация / авторизация | ✅ Локальная | ❌ Удалённая |
Накладные расходы | ❌ Криптография | ✅ Нет |
Проблема: Слив данных
Есть много путей утечки. Рано или поздно где-то прорвётся.
❌ Производитель железа
❌ Хостер сервера
❌ Хитрый хакер
❌ Случайный троян
❌ Коварный админ
❌ Любой сотрудник
Методы борьбы со сливами
💦 Жёсткие наказания сотрудников и организаций.
💦 Многоуровневые изолированные периметры.
💦 Хитровыдуманные протоколы безопасности.
💦 Группа быстрого юридического реагирования.
Всегда открытая база данных
💡 Что если не дожидаясь слива, слить базу самому?
Но хранить в ней лишь крипто-контейнеры.
И использовать End-to-End шифрование.
И даже на сервере мёржить без дешифровки.
Доступ ко крипто-контейнерам не даёт доступа к заложенной в них информации. Та что базу можно хоть торрентами раздавать, чтобы, если что, всегда можно было её восстановить.
Проблема: Рассинхронизация узлов
Консенсус - это согласие группы участников касательно значения некоторого состояния. Например, если все считают Боба мужчиной, но сам он считает себя гендерфлюидным ветросексуалом, то согласия тут не наблюдается. Консенсус не достигнут! Даже если большинство может быть и правы.
Методы конкурентного консенсуса
⛓ Единый источник истины
🔱 Единая точка отказа.
🍾 Бутылочное горлышко.
🕸 Протоколы голосования: Block-Chain, Paxos, Raft...
🛑 Без большинства ничего не сделать.
💦 Лавина сообщений между узлами.
💥 Ломаются в краевых случаях.
Конвергентный консенсус
💡 Что если писать в реплику без транзакций и кворумов?
На диаграмме вы видите хранение текста не слепком состояния, а мелкогранулярно: каждое слово знает кто его написал, когда, куда и тд. Это позволяет сохранять намерения пользователей, благодаря чему объединять правки разных пиров без потерь, с получением одинакового финального состояния.
Полная классификация методов консенсуса
Подробный анализ особенностей конкуренции за единый источник истины и конвергенции множества источников истины:
Классификация подходов обеспечения согласия между параллельными агентами
Сравнение конвергентных алгоритмов
Самая первая появилась неупорядоченная конвергенция — OT. Самая популярная сейчас — полуупорядоченная конвергенция (CmRDT). Но самая прогрессивная - беспорядоченная конвергенция (CvRDT).
OT | CmRDT | CvRDT | |
Ограниченный объём | ❌ | ❌ | ✅ |
Откат на любой момент | ❌ | ✅ | ⭕ |
Простые алгоритмы | ❌ | ✅ | ✅ |
Быстрое получение состояния | ❌ | ❌ | ✅ |
Итоги
💡 Запись в хранилище - Инь-Янь зеркала
💡 Аутентификация - цифровые подписи
💡 Авторизация записи - смарт-контракты
💡 Авторизация чтения - e2e-шифрование
💡 Консенсус - конвергенция данных
Но есть нюанс...
💢 Большой размер мета-данных
💢 Ресурсоёмкая криптография
💢 Никаких серверных миграций
Нано-технологии для гипер-задач
Спасибо за внимание, на этом моё короткое выступление подходит к концу. Можете оставить свой отзыв в сервисе сбора обратной связи, построенном как раз на базе Гипер Базы. С сообществом Гипер Дев мы планируем сделать на ней целый Гипер Веб - экосистему продуктов, закрывающих все цифровые потребности человечества. Так что следите за новостями!
giper.dev - Гипер Дев
crus.hyoo.ru - Гипер База
web.giper.dev - Гипер Веб
jin.hyoo.ru - Гипер Дед
