Disaggregated databases становятся ответом на требования cloud-экономики. Разбираем, почему разделение compute и storage меняет архитектуру и поведение систем.
Система начинает деградировать в момент, когда compute и storage остаются жёстко связаны. У них разная природа нагрузки: compute дорогой и волатильный, storage дешевый и растущий. В монолитных и даже ранних cloud-архитектурах это приводит к избыточным затратам и неэффективному масштабированию. Например, при росте данных приходится масштабировать compute, даже если он не нужен. Это нарушает принцип разделения ответственности и бьёт по cost efficiency.
Ответом стала архитектура disaggregated databases, где compute и storage разделяются. Такой подход позволяет независимо масштабировать ресурсы: compute — эластично, вплоть до scale-to-zero, storage — как стабильный слой. Это компромисс между производительностью и экономикой. Появляется новый bottleneck — сеть (network), но современные технологии (высокая пропускная способность, RDMA, SmartNIC) делают этот trade-off приемлемым. В результате архитектура начинает лучше соответствовать модели pay-per-use.
Реализация опирается на несколько ключевых принципов. Compute становится статeless и взаимодействует со storage по сети. Storage превращается в общий слой с логической сегментацией, например Log Store и Page Store. Запись данных идёт через redo log, который сначала реплицируется в storage-кворум, а затем подтверждается клиенту. Это снижает объём передаваемых данных и уменьшает нагрузку на сеть. При этом часть логики материализации данных переносится в storage, что усложняет эволюцию системы и требует согласованности между слоями.
Архитектуры вроде Amazon Aurora показывают этот подход на практике. Primary compute отправляет redo log в storage и ждёт подтверждения от кворума. Реплики (read-only nodes) могут обслуживать запросы, материализуя состояние из логов. Это снижает latency для чтения и распределяет нагрузку. Однако возникает новый класс проблем: как минимизировать сетевые round-trip, как распределить CPU между compute и storage, и где держать границы ответственности.
Отдельный слой сложности — отказоустойчивость (fault isolation). В disaggregated systems сбой compute не затрагивает storage. Это ускоряет recovery и упрощает операции. Compute-ноды можно быстро пересоздать поверх общего storage. Но цена — зависимость от сети и необходимость тщательно проектировать протоколы взаимодействия.
Интересно, что идеи disaggregation не новы. Роли в Paxos уже фактически разделяли compute и storage обязанности. Это показывает, что современные cloud-архитектуры часто эволюционируют из классических distributed systems концепций. Новизна здесь не в идее, а в масштабе и экономике.
С практической точки зрения, disaggregated databases уже стали индустриальным паттерном. Разные реализации сходятся в базовых принципах: shared storage, stateless compute и сеть как основной канал I/O. Это подтверждает, что архитектурный сдвиг обусловлен не модой, а фундаментальными ограничениями и требованиями инфраструктуры.
Метрики в исходных данных не приводятся, но качественные эффекты очевидны: улучшение cost efficiency, гибкость масштабирования, повышение отказоустойчивости. При этом цена — рост сложности системы и усиление роли сети как критического ресурса.
В итоге disaggregation — это прагматичный выбор. Он не устраняет все проблемы, но переводит их в более управляемую плоскость. Для архитекторов это означает смену фокуса: от локального I/O к сетевым взаимодействиям, от монолитных узлов к распределённым слоям.