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

Возьмем для примера приложение средней сложности: ежедневно генерируется 50-100КБ данных о состоянии и поведении. За год? 18-36ГБ. Плюс производные данные и резервные копии, реальный масштаб удваивается. Звучит просто как цифры, но проблема не в записи, а в том, что эти данные просто не могут остановиться. Они многократно читаются, проверяются, комбинируются друг с другом. Если связи между ними запутываются, вся сложность системы взрывается экспоненциально.

Это и есть исходная идея дизайна Walrus. Он не предполагает, что данные перестанут расти, и не надеется, что объекты будут записываться только один раз. Идея Walrus в том, что: при создании объект получает стабильный идентификатор, который никогда не меняется. Все изменения фиксируются как эволюция состояния одного и того же объекта. В небольших масштабах разницы не заметно, но со временем преимущества такого дизайна начинают постепенно усиливаться.

Посмотрим на данные, опубликованные в тесте: поддержка объектного хранения объемом в МБ, обеспечение доступности через многосерверное резервирование, стабильность общей доступности в тестовой сети выше 99%. Время задержки чтения — в секундах, реальные приложения могут обращаться напрямую, это не только холодное архивирование данных.

Более важно — изменения на уровне приложений. Когда ссылки на объекты перестают часто меняться, приложение может глубоко оптимизировать работу с стабильной структурой данных, что трудно реализовать в традиционных моделях хранения.