Ограничения S3 Cloud4Y

Бакет S3 принадлежит учетной записи Cloud4Y, которая её создала. Владение "бакетом" не может быть передано другому аккаунту.
При именовании сегмента выберите имя, которое имеет отношение к вам или вашему бизнесу.
Избегайте использования имен, похожих на другие имена
Использование одного или нескольких сегментов не сказывается на производительности.
Если "бакет" пустой, вы можете удалить его. В этом случае имя становится доступным для повторного использования. Однако после удаления сегмента вы не сможете повторно использовать это имя. Этому есть причины.
Например, когда вы удаляете бакет S3 и имя становится доступным для повторного использования, другая учетная запись Cloud4Y может создать "бакет" S3 с этим же именем. Кроме того, может пройти некоторое время, прежде чем вы сможете повторно использовать имя удалённого сегмента. Если вы хотите использовать то же имя сегмента, то рекомендуем вам не удалять сегмент.
Не существует максимального размера бакета S3 или ограничений на количество объектов, которые вы можете хранить в "бакете".
Вы можете хранить все свои объекты в одном bucket-е или распределить их по нескольким bucket-ам. Однако вы не можете создать сегмент внутри другого сегмента.
Проектирование высокой доступности Сloud4Y S3 сосредоточено на операциях получения, размещения, перечисления и удаления. Поскольку операции с сегментами работают с централизованным глобальным пространством ресурсов, нецелесообразно создавать, удалять или настраивать сегменты в пути кода высокой доступности вашего приложения. Лучше создавать, удалять или настраивать сегменты в отдельной процедуре инициализации или настройки, которую вы запускаете реже.
Если ваше приложение автоматически создаёт сегменты, выберите схему именования сегментов, которая не вызовет конфликты имен. Убедитесь, что логика работы вашего приложения выберёт другое имя бакета, если имя корзины уже занято.
Также в S3 присутствуют некие ограничения скорости
Предположим, что в вашем "бакете" (созданным администратором) есть четыре объекта со следующими ключами объектов:

Development/ Projects.xlsx
Finance/statement1.pdf
Private/tax document.pdf
s3-dg.pdf

Cloud4Y S3 автоматически масштабируется в ответ на устойчивую новую частоту запросов, динамически оптимизируя производительность. Пока Cloud4Y S3 выполняет внутреннюю оптимизацию для новой скорости запросов, вы будете получать ответы на запросы HTTP 503. Временно, пока не завершится оптимизация. Когда Cloud4Y S3 оптимизирует производительность для новой скорости запросов, все запросы обслуживаются без повторных попыток.
Например, ваше приложение может выполнять не менее 3500 запросов PUT/POST/DELETE и 5500 запросов GET в секунду на префикс в "бакете".
Количество префиксов в "бакете" не ограничено. Но так как каждый префикс может выполнять до 3500/5500 запросов в секунду, во многих случаях предполагается, что вам не нужно использовать несколько префиксов.
Префиксы считаются полным путем (до последнего символа «/») до объекта и берутся любого размера. Поэтому достаточно просто разделить данные между любыми двумя «папками», чтобы получить максимальные запросы x2 в секунду (если запросы делятся поровну между ними).
Для достижения более высокой производительности реализована схема со случайным хэшем/префиксом. Этого увеличения часто бывает достаточно для приложений, чтобы смягчить ошибки 503 SlowDown без необходимости рандомизировать префиксы.
Если новых ограничений недостаточно, необходимо использовать префиксы. Префикс не имеет фиксированного количества символов. Это любая строка между именем бакета и именем объекта, например:
bucket/folder1/sub1/file
bucket/folder1/sub2/file
bucket/1/file
bucket/2/file
Префиксы объекта «file» будут следующими: /folder1/sub1/, /folder1/sub2/, /1/, /2/
В этом примере, при равномерном распределении чтений по всем четырем префиксам, можно достичь 22 000 запросов в секунду.
Производительность масштабируется для каждого префикса, поэтому вы можете использовать столько префиксов, сколько вам нужно параллельно для достижения требуемой пропускной способности. Количество префиксов не ограничено.
Это означает, что теперь вы можете использовать логические или последовательные шаблоны именования при именовании объектов S3 без каких-либо последствий для производительности
Но это полуправда. На самом деле префиксы (в старом определении) всё ещё имеют значение.
Помните, что S3 — это не иерархическая файловая система, это всего лишь хранилище ключей и значений, хотя ключ часто используется как путь к файлу для организации данных, префикс + имя файла. Кроме того, данные должны быть разделены для масштабирования квадриллиона объектов.
Новый процесс создания имён ключей объектов является как бы «автоматическим», но не до конца. Это как если вы записываете данные в ведро с сумасшедшим параллелизмом в разные подкаталоги
До того, как S3 изучит новый шаблон доступа, вы можете столкнуться с регулированием S3, прежде чем он соответствующим образом перераспределит данные.
Изучение новых моделей доступа всегда требует времени, как и перераспределение данных.
Но это не будет касаться вашего случая, если у вас нет большого количества данных или шаблон доступа к данным не слишком параллелен.
S3 не фиксирует определённую длину префикса в имени ключа для использования распараллеливания по этим префиксам. Но всё равно учитывается длина префикса в 6-8 символов.
Не фиксированные по длине префиксы работают, но не сразу. Требуется время, чтобы приспособиться к новой нагрузке. Чтобы Cloud4Y S3 мог обрабатывать миллиарды запросов в секунду, им необходимо разделить данные, чтобы оптимизировать пропускную способность. Для этого они разбивают данные на разделы на основе первых 6–8 символов имени ключа объекта.
Когда нужно добиться менее 100 запросов в секунду, то это не станет проблемой. Но если у вас есть серьезные требования к скорости, придётся хорошо подумать об именовании ключей объектов.
Для получения максимальной параллельной пропускной способности вы должны придерживаться вашей модели использования данных, и использовать максимально разные символы в начале имени ваших ключей объектов. Или даже генерировать для этого 8 случайных символов для первых 8 символов имени ключа объекта.
Приведём несколько примеров. Будем считать, что что первые 6 символов определяют раздел:
Использовать files/user/bob в качестве имени ключа объекта было бы плохо, так как все объекты пользователей были бы в одном разделе files/.
2018-09-21/files/bob было бы так же плохо, как в предыдущем примере, если бы читались данные только из раздела 2018-0. Но это будет более лучший вариант, если объекты будут считываться за разные годы.
bob/users/files подходит, если разные пользователи могут одновременно использовать данные из раздела bob/us. Но будет не так хорошо, если bob читает чаще всех данные из своего «каталога» bob/us.

  • 0 Пользователи нашли это полезным
Помог ли вам данный ответ?

Связанные статьи

Как начать работу с S3 Cloud4y используя AWS Command Line Interface (CLI)

1) Устанавливем AWS CLI - На Windows, загружаем  AWSCLI-64  или  AWSCLI-32 разрядный установщик...

Доступ в S3 из панели управления облаком VCD

Благодаря наличию плагина VMware vCloud Director® Object Storage Extension™ пользователям Cloud4y...

Способы работы с объектным хранилищем через различное программное обеспечение

Подготовка идентификационных данных 1. Авторизуйтесь в объектном хранилище Cloud4Y:...

Как начать работу с объектным хранилищем

ОБЪЕКТНОЕ ХРАНИЛИЩЕ ОТ CLOUD4Y Наше объектное хранилище построено на платформе компании Cloudian...

Создание подобия файловой структуры в "бакете" S3

Хранилище S3 не обладает иерархической файловой системой, как в Unix. Файловая система в «бакете»...