Как правильно использовать хранилище S3 и насколько обоснована моя идея?

Я решил разобраться в S3 хранилищах и выбрал MinIO. Найдя коннектор, начал читать руководства, но столкнулся с противоречиями и комментариями в стиле "не учите людей плохому". В результате у меня возникло множество вопросов, и я хотел бы попросить вас оценить описанную ниже архитектуру на наличие "хорошего тона". 

1. В базе данных хранятся права доступа к файлам и пути к ним в MinIO. Минимально допустимо хранить только файлы, без дополнительной информации в их путях. В связи с этим у меня возникает вопрос: имеет ли смысл создавать уникальные идентификаторы (ID) для файлов или достаточно только их путей?

2. Когда загружается сайт, клиентское приложение отправляет запрос на сервер. Сервер проверяет права доступа и возвращает временную ссылку на файл в MinIO, которую клиентское приложение затем использует.

3. Временные ссылки не кэшируются и не сохраняются. Это необходимо, чтобы избежать ситуации, когда пользователь может получить доступ к ссылке до ее аннулирования и не сможет загрузить файл. Таким образом, на каждый запрос создаётся новая временная ссылка.

Также у меня есть вопросы о масштабируемости. Например, следует ли создавать бакеты на разные регионы или развертывать отдельный сервер MinIO в каждом регионе? Какую практику вы могли бы порекомендовать, помимо предложенного мною подхода?
  • 16 ноября 2024 г. 21:33
Ответы на вопрос 2
Ваше понимание использования MinIO как S3-совместимого хранилища выглядит многообещающе, и ваши идеи о проектировании архитектуры также имеют свои достоинства. Постараюсь ответить на ваши вопросы и предложить некоторые рекомендации.

### 1. Уникальные идентификаторы для файлов
Создание уникальных идентификаторов (ID) для файлов — это хорошая практика, особенно если у вас есть необходимость управления метаданными. Хранение лишь путей к файлам может привести к ряду проблем, включая:
- **Повторение имен**: Если два файла имеют одно и то же имя, вы не сможете отличить их друг от друга.
- **Упрощение управления**: Используя уникальные идентификаторы, вы сможете легче управлять доступом, версии файлов и записи в журнале.

Рекомендую храниить как уникальные идентификаторы, так и пути к файлам, чтобы улучшить удобство работы с данными.

### 2. Генерация временных ссылок
Концепция временных ссылок для доступа к файлам в MinIO — это правильный подход с точки зрения безопасности. Это предотвращает несанкционированный доступ к файлам. Тем не менее, стоит иметь в виду следующие моменты:
- Убедитесь, что срок действия временной ссылки соответствующий: слишком короткий срок может вызывать неудобства, слишком длинный может привести к угрозам безопасности.
- Можно реализовать токенизацию, чтобы обрабатывать запросы более эффективно, особенно если у вас много клиентов.

### 3. Нагрузка и кэширование
Ваше решение не кэшировать временные ссылки оправдано с точки зрения безопасности, но это может создать дополнительные нагрузки на сервер. Рассмотрите возможность:
- Кэширования на клиентской стороне или использовании токенов доступа для оптимизации числа запросов к серверу.
- Использования механизма отпуска токенов, который позволит избежать распространения временных ссылок по системе.

### Масштабируемость
При масштабировании MinIO на разные регионы следует учитывать следующие аспекты:
- **Разделение по регионам**: Если у вас есть пользователи в разных регионах, имеет смысл создать отдельные бакеты или экземпляры MinIO в этих регионах, чтобы сократить задержку доступа к файлам.
- **Redundancy и Disaster Recovery**: Обеспечьте резервирование и возможность восстановления данных. Можно использовать репликацию данных для повышения надежности.
- **Управление политиками доступа**: Убедитесь, что у вас есть четко определенные политики безопасности для разных регионов.

### Рекомендации по лучшим практикам:
1. **Мониторинг**: Используйте инструменты мониторинга, чтобы отслеживать использование и доступ к файлам.
2. **Разделение данных**: Если у вас различные типы данных, организуйте их в разные бакеты для упрощения управления.
3. **Effectively handle metadata**: Храните как можно больше полезной информации о ваших файлах, чтобы облегчить поиск и фильтрацию данных.

Ваше решение имеет свои особенности, и общие рекомендации могут варьироваться в зависимости от конкретных требований вашего проекта. Надеюсь, мои советы окажутся полезными!
Могу частично ответить по поводу путей. Многие понимают S3 как файловое хранилище, тогда как это объектное хранилище по сути, ключ-значение. Ключ - это то, что выглядит как путь, но на самом деле это не путь. И так совпало, что значение это обычно контейнер с содержимым, который представлен как файл. Поэтому путь и есть ID, и при этом значение нельзя поменять, его можно либо взять, либо положить. Делать какие-то дополнительные ID по этой причине обычно не надо, потому что ключ (за счет представления как путь) всегда является уникальным.
Похожие вопросы