S3/object storage vs block storage: latency, consistency, throughput, TCO и выбор под задачи

Вопрос «s3 vs block storage» возникает каждый раз, когда нужно хранить данные не «где-нибудь», а с понятными гарантиями по задержкам, отказоустойчивости и бюджету. На практике спор обычно упирается в три метрики: latency (как быстро читается/пишется), throughput (сколько данных в секунду реально прокачать) и consistency (насколько предсказуемо вы увидите только что записанные данные).

Но есть и четвертая — TCO (total cost of ownership): сколько это будет стоить в эксплуатации с учетом трафика, запросов, ретраев, версионирования/ретеншна, времени админов и цены простоя.

Ниже — практичное сравнение объектного (S3-совместимого) и блочного хранилища, с привязкой к кейсам бэкапов, статики и задачам, где block storage действительно незаменим.

Коротко о терминах: объектное vs блочное

Object storage (S3-совместимое, «объектное») хранит данные как объекты: payload + метаданные + ключ (имя). Доступ — через API (обычно HTTP): PUT/GET/LIST. Это не файловая система и не «сетевой диск».

Block storage (блочное) выглядит для ОС как диск/том. Поверх него вы создаете файловую систему (ext4/xfs) или отдаете устройство напрямую базе данных. Приложение работает через системные вызовы чтения/записи блоков, а не через API-объекты.

Самая частая ошибка выбора: пытаться использовать S3 как «сетевой диск», а блочный том — как «архив навсегда». У них разные сильные стороны и разные провалы по latency/consistency.

Latency: где задержки будут заметны

Latency — время реакции на операцию. Для админа важно разделять задержку одного маленького I/O (условные 4–64 КБ) и время передачи большого объекта (сотни МБ/ГБ).

Почему у S3 обычно выше latency на мелких операциях

S3 — это API поверх сети: TLS, HTTP, маршрутизация, балансировка, авторизация, обработка метаданных. Операция GET/PUT — это не «прочитал блок с диска», а полноценный сетевой запрос. Поэтому много мелких обращений (тысячи небольших файлов, частые дозаписи, random I/O) быстро упираются в latency.

Практический вывод: если приложение активно работает с маленькими кусками данных и ожидает миллисекунды (или ниже) на операцию, S3 будет ощущаться «тормозным» даже при высоком суммарном throughput.

Почему block storage выигрывает для интерактивных систем

У блочного хранилища путь обычно короче: ОС → драйвер → сеть/хранилище → подтверждение. Даже если это тоже «сетевой диск» в облаке, протокол и модель доступа заточены под частые операции чтения/записи и очереди запросов. Поэтому для баз данных, очередей, индексов и любых систем со случайным доступом block storage почти всегда предпочтительнее.

Но для больших объектов S3 часто «быстрее по ощущениям»

Когда вы передаете один большой файл (например, архив бэкапа на десятки гигабайт), latency одного запроса не так важна, как стабильный поток. В таких сценариях объектное хранилище часто показывает хорошую эффективность благодаря параллельным частям, умным ретраям и отсутствию зависимости от вашей файловой системы.

Если у вас приложения крутятся на VDS, обычно проще всего разделять данные по типу: «диск под state» и отдельное объектное хранилище под бэкапы/артефакты.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Throughput: пропускная способность и параллелизм

Throughput — сколько данных в секунду вы реально читаете/пишете. Важно: throughput почти всегда зависит от параллелизма. Один поток может быть медленным из‑за RTT, но несколько потоков обычно «раскачивают» канал.

S3: throughput через multipart и параллельные запросы

Для объектного хранилища «правильный» режим — параллельная загрузка/скачивание (multipart). Большие объекты режутся на части, части передаются независимо. Это помогает:

• эффективнее использовать полосу;
• переживать сетевые просадки без перезакачки всего файла;
• масштабировать скорость почти линейно до пределов сети/квот.

Практический нюанс: throughput S3 часто ограничивают не диски, а сеть, лимиты запросов и стоимость операций. Поэтому в оценке TCO обязательно учитывайте цену запросов (LIST/GET/PUT) и исходящего трафика.

Block storage: throughput зависит от типа нагрузки

У блочного хранилища throughput обычно лучше прогнозируется для последовательного чтения/записи, но при случайном доступе упирается в IOPS и глубину очереди. Для БД важнее не «гигабайты в секунду», а IOPS + стабильная latency под нагрузкой.

Consistency: почему «прочитал не то» бывает не багом

Consistency — причина странных инцидентов уровня «я только что залил файл, а сервис его не видит» или «список объектов показывает старую версию». В объектных хранилищах это одно из ключевых отличий от диска/FS.

Что важно знать про consistency в S3-подобных системах

У объектных хранилищ модели согласованности могут различаться для чтения, перезаписи и листинга. Даже когда чтение «свежее», операция LIST может отражать изменения с задержкой — и это критично, если вы строите индекс по листингу бакета.

Чтобы избежать сюрпризов, безопасная стратегия для приложений и бэкапов обычно такая:

• считать объект опубликованным только после успешного завершения multipart (complete);
• для «атомарности» использовать новые ключи (версии) вместо перезаписи одного и того же имени;
• не строить логику на предположении о мгновенной консистентности листинга;
• использовать хеши/ETag/контрольные суммы как часть проверки целостности.

Если у вас уже был опыт «выложили, а не видится», собрал типовые паттерны и анти‑паттерны в отдельном разборе: паттерны записи и листинга в S3 без гонок и фантомов.

Block storage: консистентность на уровне FS и приложения

Блочный том дает привычную модель: записали — прочитали (с оговорками про кэширование, барьеры, writeback). Консистентность здесь больше зависит от приложения и файловой системы: используете ли вы fsync, корректно ли настроены барьеры записи, как снимаются снапшоты, не замораживаете ли FS перед ними.

Durability и надежность: что именно вы «покупаете»

Durability — вероятность не потерять данные. Не путайте с availability: доступность «прямо сейчас» может просесть, но данные при этом не потеряются.

Object storage: сильная сторона — долговечность объектов

У S3‑совместимых хранилищ обычно сильная durability за счет репликаций/кодирования и распределения. Это делает объектное хранилище удобным вторым контуром для резервных копий, архивов, артефактов сборки, медиа и логов, которые можно перечитать позже.

Но durability не отменяет ошибки человека. Поэтому версионирование, политики удержания и защита от случайного удаления часто важнее, чем «цифра durability в буклете».

Block storage: надежность зависит от схемы и бэкапов

Блочный диск может быть очень надежным, но часто это «надежность одного тома» и его снапшотов в рамках платформы. Для реальной защиты нужна стратегия: регулярные снапшоты, вынос копий в независимое хранилище, тестовые восстановления.

TCO: как сравнивать стоимость владения без самообмана

TCO — это сумма не только «цена за гигабайт», но и:

• стоимость запросов (особенно для S3: LIST/GET/PUT);
• стоимость исходящего трафика (egress) и межзонных переносов;
• цена производительности: сколько ресурсов уйдет на кэширование, прокси и локальные диски;
• операционные риски: цена простоя, время на расследования, сложность восстановления;
• стоимость хранения нескольких копий (версии, ретеншн, репликация).

Практическое правило TCO

Если вы храните мало данных, но делаете очень много мелких операций — объектное хранилище может оказаться неожиданно дорогим. Если вы храните много данных и доступ редкий/пакетный — object storage обычно выигрывает.

Типовые кейсы: backups storage

Для бэкапов объектное хранилище часто оказывается «по умолчанию правильным», но есть нюансы по формату и восстановлению.

Когда S3 для бэкапов подходит идеально

• Ночные/часовые бэкапы большими файлами или чанками.
• Offsite-копия: логически отдельно от боевого сервера.
• Долгое хранение: ретеншн и lifecycle-политики.
• Иммутабельность (если поддерживается): защита от шифровальщиков и «случайно rm -rf».

Из практики: даже если бэкап формально «один архив», часто выгоднее использовать инструмент/формат с чанками и дедупликацией. Это снижает время, трафик и количество перезаливок при сбоях.

Если вы делаете выгрузку на S3 через rclone, полезно не забывать про проверку целостности (ETag/хеши) и стратегию повторной синхронизации: настройка rclone sync и verify для копирования в S3.

Когда block storage лучше для бэкапов

• Когда нужен очень быстрый restore локально и вы готовы платить за диск.
• Когда делаете снапшоты на уровне FS/тома и вам важен минимальный RPO в рамках одной площадки.
• Когда бэкап — часть «горячего» контура (например, staging, который часто поднимают).

Если ваши сайты и сервисы живут на виртуальном хостинге, обычно проще держать «рабочие» данные на диске аккаунта, а резервные копии — отдельно (в объектном хранилище или другом независимом контуре), чтобы восстановление не зависело от одного места.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Типовые кейсы: static files storage

Под static files storage обычно понимают ассеты фронтенда, медиа, публичные загрузки (или выдачу по подписанным ссылкам), а иногда — артефакты деплоя.

Почему S3 часто выбирают для статики

• Хранение отделено от веб‑серверов: проще масштабировать фронтенды.
• Можно хранить «сколько угодно» объектов без расширения дисков на нодах.
• Удобно версионировать и делать cache-busting через новые ключи.

Но если приложение генерирует тысячи маленьких файлов и постоянно их перечитывает, без кэша и корректной политики HTTP‑кэширования вы упретесь в latency и стоимость запросов. На практике часто добавляют локальный кэш на фронтендах или отдельный слой кэширования.

Когда block storage для статики оправдан

• Когда статика тесно связана с приложением и нужна очень низкая latency на файловых операциях.
• Когда важна POSIX‑семантика (rename, блокировки, частичные записи).
• Когда это не «статика», а рабочий каталог (например, временные файлы конвертации).

Базы данных и stateful-сервисы: почти всегда block storage

Если коротко: базы данных любят блочные диски, предсказуемую latency и корректный fsync. Переносить рабочие файлы БД в object storage как «основной диск» почти всегда плохая идея. S3 здесь уместен как место для бэкапов, WAL‑архива, снапшотов и дампов.

Чеклист выбора: что спросить у себя перед решением

1. Паттерн доступа: много мелких random I/O или редкие большие объекты?
2. Требования по latency: что будет, если операции станут в 5–20 раз медленнее?
3. Consistency: зависит ли логика от мгновенного листинга/перезаписи?
4. Durability: нужна ли защита от ошибок человека (версии, удержание, неизменяемость)?
5. Throughput: сможете ли вы распараллелить загрузку/скачивание?
6. TCO: сколько будет запросов в сутки и какой egress?
7. Операции: кто это сопровождает и как вы тестируете restore?

Комбинированные архитектуры: чаще всего выигрывают

В реальных проектах редко бывает «или S3, или block storage». Обычно лучше работает связка:

• Block storage для stateful: БД, очереди, индексы, рабочие каталоги.
• S3/object storage для «холодных» и переносимых данных: бэкапы, архивы, медиа, статика, артефакты.

Так вы получаете предсказуемую latency там, где это критично, и высокую durability/удобство там, где важнее надежное хранение и экономия на масштабе. Если вы поднимаете приложения на VDS, эта схема обычно самая простая в сопровождении: «диск под state» плюс отдельное объектное хранилище под бэкапы и раздачу.

Итог: простая таблица решений

• S3 / object storage: бэкапы, архивы, медиа, раздача статики, артефакты, логи; когда важны durability и экономичный рост объема, а latency одной операции не критична.
• Block storage: базы данных, очереди, диски VM, рабочие директории и low‑latency сценарии; когда важны IOPS и предсказуемая задержка под нагрузкой.

Если сомневаетесь — измеряйте. Для честного сравнения достаточно воспроизвести ваш реальный паттерн доступа: размер объектов, параллелизм, количество операций, «горячие» и «холодные» данные. Это и дает ответ в споре «s3 vs block storage», а не абстрактные цифры в спецификации.