S3 / MinIO: object storage¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: Amazon S3 API: 2026-11-02; MinIO OSS RELEASE.2025-04-22T22-12-26Z, не AIStor. Проверка источников: 2026-11-02.

1. Архитектура и модель данных¶

FACT. Bucket/key адресует immutable-in-place object version: обновление публикует новое полное содержимое объекта, а не произвольную SQL row mutation. S3 — managed API, MinIO — отдельная реализация S3-compatible API. Совместимость не делает их failure domains, lifecycle и durability policies одинаковыми.

flowchart LR
  Writer --> Data[Immutable data objects]
  Data --> Commit[Conditional manifest or catalog commit]
  Commit --> Reader[Snapshot-aware reader]
  Reader --> Data
  Data -. independent policy .-> Backup[Versioning replication or backup]

2. Физическое хранение и путь записи¶

S3 скрывает физические детали; внутренняя раскладка конкретного объекта UNKNOWN для пользователя. MinIO OSS использует erasure coding по наборам drives: data/parity shards позволяют пережить определённые failures при достаточном quorum. Конкретная topology задаёт read/write quorum и recovery; нельзя назначать универсальную переносимость потери дисков.

Текущие min.io docs перенаправляют на AIStor. Здесь OSS baseline закреплён Git tag; AIStor-only функции не считаются подтверждёнными для OSS.

Источники механизма: документация 1, документация 5.

3. Индексы и путь чтения¶

GET/HEAD по key и LIST prefix — object API, не B-tree/secondary index по содержимому. Range GET помогает читать Parquet footer/column ranges, но сеть и request cost остаются. Metadata catalog/table format добавляют pruning; один только directory convention не даёт transactional snapshot.

Источники механизма: документация 1.

4. Транзакции и consistency guarantees¶

Amazon S3 документирует strong consistency PUT/DELETE/GET/LIST в соответствующей scope. Atomic update отдельного key не равен multi-object transaction, POSIX append или rename. Conditional writes If-Match/If-None-Match помогают CAS на object; поддержка конкретной операции/API проверяется отдельно для MinIO baseline. ETag нельзя универсально считать MD5, особенно при multipart/encryption.

Источники механизма: документация 1, документация 2.

5. Репликация, partitioning и sharding¶

S3 replication между buckets/Regions — отдельный асинхронный процесс со своей конфигурацией; она не наследует single-key strong read guarantee как мгновенную global publication. MinIO erasure coding внутри deployment и site replication — разные механизмы. Prefixes не являются database shards с транзакционными границами.

Источники механизма: документация 1, документация 4.

6. Конкурентная запись и конфликты¶

Два writers одного key без condition могут перезаписать результат друг друга. Table formats используют metadata commit protocol/catalog, а не небезопасное «LIST files и overwrite manifest». Multipart upload не публикует готовый object до completion; orphan uploads нужно очищать. Публикация data files до manifest позволяет readers видеть только committed набор при корректном протоколе.

Источники механизма: документация 2.

7. Отказы и восстановление¶

Versioning сохраняет версии, но не защищает от всех действий привилегированного пользователя; Object Lock добавляет retention/legal hold в поддерживаемой конфигурации. Lifecycle delete, encryption-key loss и accidental overwrite требуют отдельных мер. MinIO healing восстанавливает shards при наличии достаточных данных, но не является backup от логической ошибки.

Источники механизма: документация 3, документация 5.

8. Масштабирование и ограничения¶

Большие sequential objects эффективнее миллионов маленьких для многих analytical scans. Parallel requests увеличивают bandwidth до service/network/client limits; retries/backoff обязательны. MinIO capacity зависит от drives, erasure sets, сети и headroom на healing; S3 capacity model не переносится на собственный кластер.

9. Performance trade-offs¶

Преимущества — дешёвый для многих workloads durable blob/archive и разделение compute/storage; цена — API requests, network/egress, отсутствие row locks и множество small-file operations. «Дешёвый storage» не доказывает дешёвый query или быстрый restore. Iceberg/Delta/Hudi добавляют table semantics, а не меняют объект в OLTP page.

10. Мониторинг и эксплуатация¶

S3 request errors/latency, replication status, inventory/lifecycle и incomplete multipart; MinIO drive/node health, quorum errors, healing backlog, free space и audit. Проверять IAM/policies, encryption-key recovery, immutable retention и restore permissions. Контрольные manifest/hash проверяют полноту независимо от успешного LIST.

11. Сценарии FinTech и iGaming¶

INFERENCE. Raw Kafka archive, historical betting events, backup ledger и evidence bundles. Object retention может поддерживать audit, но правовую достаточность определяют требования и процедуры; здесь юридическое соответствие не заявлено. Table format выбирается отдельно от S3 provider.

12. Когда не выбирать¶

Не выбирать raw objects для конкурентного balance UPDATE или per-request row lock. Не монтировать S3 как POSIX filesystem, ожидая тех же rename/fsync/locking guarantees. Не считать replication/erasure coding независимой резервной копией.

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

Strong LIST делает lake transactional? Нет, читатель всё ещё может увидеть только часть multi-object публикации без commit protocol.

ETag всегда checksum содержимого? Нет, зависит от upload/encryption API.

Erasure coding равно backup? Нет, защищает от части физических failures, не от авторизованного удаления.

14. Практические SQL/config примеры¶

{"Rules":[{"ID":"abort-incomplete","Status":"Enabled","Filter":{"Prefix":"raw/"},"AbortIncompleteMultipartUpload":{"DaysAfterInitiation":7}}]}

Пример S3 lifecycle JSON очищает незавершённые uploads, не committed data. Число дней — учебная policy. JSON проверен; AWS/MinIO API и quorum failure не выполнялись.

15. Дополнительные источники¶

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

Смешивать commit, видимость projection и backup; приписывать формату функции query engine; игнорировать версии и cleanup horizon. Product-specific ошибки и безопасные альтернативы разобраны в разделах 4–9.

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

Составьте журнал одной записи: какие файлы/metadata появляются до публикации, что увидит reader при сбое и какой cleanup безопасен. Затем предложите restore drill с проверкой итоговой полноты, включая поздние исправления.