Limitation and Best Practices

Object Stores

Limitations

The following rules apply to the naming of Object Stores in cegedim.cloud Object Storage Service:

  • Must be between one and 255 characters in length

  • Can include hyphen (-) and alphanumeric characters ([a-zA-Z0-9])

  • Avoid the use of underscores (_)

  • Avoid the use of UPPERCASE letters

  • Cannot start with a dot (.)

  • Cannot contain a double dot (..)

  • Cannot end with a dot (.)

  • Cannot contain spaces

  • Must not be formatted as IPv4 address

  • Object Store names must be unique in cegedim.cloud Object Storage Service

Best Practices

  • Create Object Store per Business Unit or per application

  • Geo Replication can't be enable or disable once the Object Store created

  • For best performance, recommended to have less than 1000 buckets in a single Object Store

  • Object Stores should be DNS compatible

Buckets

Limitations

The following rules apply to the naming of S3 buckets in cegedim.cloud Object Storage Service:

  • Must be between 3 and 255 characters in length.

  • Can include dot (.), hyphen (-), and underscore (_) characters and alphanumeric characters ([a-zA-Z0-9])

  • Avoid the use of UPPERCASE letters

  • Can start with a hyphen (-) or alphanumeric character

  • Cannot start with a dot (.)

  • Cannot contain a double dot (..)

  • Cannot end with a dot (.)

  • Cannot contain spaces

  • Must not be formatted as IPv4 address

  • Bucket names must be unique within an Object Store

Best Practices

  • Use buckets for specific environment, workflow, or uses. For instance: dev, test, finance, operations, etc

  • In an Object Store with the Geo Replication enabled, create buckets using the closest (EB4 or ET1) endpoint to the application accessing and updating the objects

There is overhead involved with checking the latest copy if the ownership of object is at a remote endpoint

  • For best performance, recommended to have less than 1000 buckets in a single Object Store

  • Bucket names should be DNS compatible

Objects

Limitations

The following rules apply to the naming of Objects in cegedim.cloud Storage Service:

  • Cannot be null or an empty string

  • Length range must be between 1 and 255 (Unicode char)

  • Avoid using space

  • No validation on characters

Best Practices

  • Object names should be DNS compatible

Small Objects vs Large Objects

This section provides useful tips when handling small and large objects within your application. It also provides some information on cegedim.cloud Object Storage Service versioning and compression details and options.

Small Objects

A small object is considered to be an object that is less than 100 KB.

cegedim.cloud Object Storage Service has a special internal mechanism which helps performance for data writes of small objects. It aggregates multiple small data objects queued in memory and then

write them in a single disk operation, up to 2MB of data. This improves performance by reducing the number of round-trips to process individual writes to storage.

Although cegedim.cloud Object Storage Service has optimizations for small writes, if there is an option in your application to define a size

then choose a larger size (e.g. 1 MB rather than 64 KB) or a value that aligns to the cegedim.cloud Object Storage Service internal buffer size of 2 MB for performance.

Large Objects

One of the issues with reading and writing large objects is performance.

cegedim.cloud Object Storage Service provides certain API features to reduce the impact on performance for large objects, such as, multipart uploads. Some tips to alleviate some of the issues for large object access include:

When working with large objects (> 100 MB), utilize the multipart upload feature. This allows pause and resume uploads for large objects.

cegedim.cloud Object Storage Service internal buffer size is 2 MB. For size inferior to 1 GB, use multiple of 2 MB (e.g. 8 MB).

cegedim.cloud Object Storage Service chunk size is 128MB. For size superior to 1 GB, use 128 MB part size.

Performance throughput can be improved by parallelizing uploads within your application.

Use APIs that allows for easy upload and download, for instance:

  • In Java, use the TransferManager

  • In .NET, use TransferUtility

Last updated