Storage Planning
Many attributes are immutable once a blob store is created. We recommend you carefully plan your blob store configuration before your initial deployment. While there are ways to change the configuration later, these methods come with a fair amount of rework, increased storage requirements, and potential downtime.
You will need to choose which types to use, how many blob stores to create, and how you allocate repositories to these blob stores. These decisions should be based on the following:
the size of your repositories
the storage space available
the rate at which you expect them to grow over time
the options you have available for adding storage space
Blob Store Types
Nexus Repository supports several types of blob stores. In general, file system blob stores have better performance, but object store blob stores offer unbounded storage and convenience. Cloud object stores should only be used when running Nexus Repository on the cloud provider in the same region.
File Blob Store
Stores files in a directory available to the system user running Nexus Repository. This may be local disk storage or a virtual reference to a location on the network such as a NFSv4-compatible mount. Low-Latency High IOPS storage is the highest-performance option for blob storage.
When deployed in Amazon's AWS, an EFS mount is acceptable as a limitless NFS version 4 server. The Path parameter is either the blob files' relative or absolute location.
See the Nexus Repository system requirements for supported file systems.
Object Blob Stores
A cloud object store service is a scalable, durable, and cost-efficient storage solution that allows users to store, retrieve, and manage unstructured data in the cloud. It organizes data into objects, which include the data itself, metadata, and a unique identifier, making it different from traditional file or block storage systems.
Nexus Repository supports storing uploaded files to blob stores configured to use cloud object stores managed by all the popular cloud providers. We recommend you carefully consider whether using an object store is the right storage solution for you.
A cloud blob store must be in the same region as the Nexus Repository installation. Using different regions results in unacceptably slow performance. Performance is highly dependent on the speed of the network between Nexus Repository and the object store. Nexus Repository sends multiple outbound HTTP requests to the object store; large blobs are split into chunks over multiple requests. Even when connected in the same region, object stores may perform up to three times slower than file-based blob stores.
The following are supported options for cloud base object blob stores:
AWS S3 Blob Store An S3 blob store saves blobs as objects within a bucket on AWS S3.
S3-Compatible Blob Store Any fully compatible on-prem S3 implementation that supports the AWS SDK version 1.12.658 can be used as a blob store, however, note that performance characteristics may differ from AWS S3. We recommend working with your vendor to ensure sufficient performance.
Azure Blob Store An Azure blob store saves blobs as objects within a storage account container on Microsoft Azure.
Google Cloud Blob Store A GCS blob store saves blobs as objects in Google Cloud Storage.
Blob Store Layouts
Once a repository is associated with a blob store, it can take significant time to run the tasks necessary to change this, and most of these tasks are only available in Nexus Repository Pro. Blob stores can be moved from one storage device to another using a process described in Configuring Blob Stores.
For these reasons, your approach to using blob stores should be chosen carefully.
Single Blob Store
The simplest approach is to create a single blob store per storage device and divide your repositories among them. This is suitable in the following cases:
If you exceed available storage, you will be able to move blob stores to larger storage devices.
Your repositories are growing slowly enough that you will not exceed your available storage within a year.
Multiple Blob Stores
When creating blob stores, focus on the utility gained versus the cost associated with managing multiple blob stores. Here are best practices and considerations:
Consider separating blob stores by format as they are often on different build pipelines or repository stages.
You might split out Docker repositories since they can grow very quickly.
Consider splitting out more critical components (hosted vs. proxy/replicated repositories).
Nexus Repository doesn't support partial backup restoration, so you may benefit from keeping more actively developed components on a separate blob store from archived components. You can also put priority components on faster disks while archived ones go on slower, cheaper storage.
Only split by teams or lines of business when the team will never overlap or share components and when there are a reasonably fixed number of teams.
Only use automation for initial blob store provisioning, not for mass blob store creation.
Don't partition blobs per repository. This will cause performance impacts at scale.
While Nexus Repository can handle many blob store configurations, performance issues can occur in some scenarios:
Repositories that are grouped or are part of a shared build pipeline (e.g., staging) benefit from being on a single blob store. If you use multiple blob stores in this scenario, components must be copied across multiple blob stores instead of just updating a database.
Because cleanup tasks are configured and serialized against each blob store, having many of them can cause them to run slowly.
The remaining disk space calculations can be inaccurate when multiple blob stores are located on the same disk.
Having many blob stores may negatively impact database search efficiency.
Group Blob Store
A group blob store combines blob stores so that they act as a single blob store for repositories. Repositories can only act singularly or as part of a group. A repository can either use a concrete blob store directly or as a member of a single group, but not both.
Group blob stores are a good choice if you meet the following criteria:
You need to add more storage space via multiple devices.
You need the ability to spread writes and reads across multiple blob stores.
You need to mix both disk and cloud storage.
See Group Blob Store
Estimating Blob Store Storage Requirements
Blob stores contain two files for each binary component stored in the Nexus Repository:
The binary component (stored as a .bytes file whose size is the same as the component).
A properties file that stores a small amount of metadata for disaster recovery purposes (<1KB).
The total blob store storage size is approximately the total size of all of your components plus an allowance for the properties files and the block size of your storage device.
On average, the allowance will be 1.5 * # of components * block size.