S3 Object Storage vs Database Storage¶

Сравнения · Раздел 02

Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.

Область: S3 / MinIO object API; Database engine. Численные latency/TPS/cost требуют измерений на сопоставимом workload с одинаковыми гарантиями.

Критерии выбора¶

Критерий	S3 / MinIO object API	Database engine
Workload	Large immutable objects, archive и analytical files	Key/row/document operations с engine-specific transactions
Consistency	S3 single-key strong consistency; multi-object transaction отсутствует	Конкретные isolation/commit/replication guarantees продукта
Latency	Object request/network/range-read cost; не page-local UPDATE	Indexes/buffers/locks/engine path; зависит от query
Throughput	Parallel object I/O и размер/batching files	WAL/locks/shards/compaction/query execution
Cost	Capacity, requests, replication, egress и catalog/engine compute	Storage/compute/replicas/indexes/licensing и operations
Scalability	API масштабирование отличается у managed S3 и self-hosted MinIO	Server/shard scaling зависит от конкретной базы
Operational complexity	Lifecycle/versioning/IAM/keys, small files, manifests и MinIO quorum	Indexes, vacuum/compaction, backups, PITR и failover

flowchart LR
  Workload --> Transaction[Concurrent row invariant]
  Transaction --> DB[Database transaction engine]
  Workload --> Blob[Immutable files and archive]
  Blob --> Objects[S3 or MinIO]
  Objects --> Format[Optional table format and query engine]

Конкретные сценарии¶

Ledger debit → transactional database. Raw Kafka archive и backup bundles → object storage. Analytical corrected table → objects + Iceberg/Delta/Hudi + catalog/engine; object layer и database semantics могут дополнять друг друга.

Ограничения и отказы¶

Object overwrite не row lock, prefix не SQL index, filesystem mount не POSIX contract. MinIO OSS release не AIStor current. Strong consistency отдельного object не делает atomic публикацию набора data/metadata files.

Как принять и проверить решение¶

Зафиксировать query mix, data distribution/skew, payload, working set, retention, concurrency, authoritative boundary и допустимую stale-read policy. Проверять steady state и maintenance, lost ACK, node loss, replay и restore. Сопоставлять total cost при одинаковых durability/replication requirements. Не объявлять универсального победителя по одному среднему времени запроса.

Типичные ошибки проектирования¶

Сравнивать default eventual/cache path с durable transactional commit; игнорировать operations/recovery; переносить benchmark другого dataset; выбирать продукт до определения access pattern.

Вопросы на собеседовании¶

Можно ли использовать варианты вместе? Да, если роли, data contracts и способы reconciliation определены. Дополнительная projection добавляет lag, replay и ownership, поэтому её польза должна покрывать эту сложность.

Практические упражнения¶

Для одного сценария выше составьте ADR: invariant, выбранный вариант, отклонённая альтернатива, failure outcomes и план измерений. Не задавайте придуманные TPS/SLA; перечислите входные данные, необходимые для sizing.