A binary large object (blob) storage, or blobstore, is the folder or network location for where Nexus Repository will store everthing uploaded to or proxied from a repository, including basic metadata for the object. Contents added to the blobstore are obfuscated internally by Nexus Repository to avoid naming collitions and file system constraints and are not meant to be modified externally. The blobstore location should be configured with as low latency as possible to avoid impacting performance. Every repository is configured against a single blobstore or blobstore group with one or many repositores using a given blobstore.
Generally, blobstore configuration should be limited to the either the storage disks available, cloud object storage, or a few potential business requirements where this is recommended. Having a large number of blobstores will impact performance since querying, cleanup, and indexing tasks are specific to a giving blobstore. Learn about different options in the blob store layouts section of Storage Planning.
By default, Nexus Repository creates a file blob store named
default in the
$data-dir directory during installation. You can configure new blob stores by navigating to Administration → Repository → Blob Stores in Nexus Repository. You will need nx-all or nx-blobstore privileges to access this section of Nexus Repository.
Find more information in the Configuring Blob Stores topic.
- Binary large object (Blob) - An object containing data (e.g., component binaries and metadata files) within a blob store.
- Blob Store - An internal storage mechanism for the binary parts of components and their assets.
- Fill Policy PRO - For a group blob store, the fill policy determines to which blob store a blob is written.
- Group Blob Store PRO - A blob store that delegates operations to one of the other blob stores on its list.
- Hard Delete - When a soft-deleted blob is permanently removed from the blob store (usually via the Admin - Compact blob store task).
- Promote to Group PRO - A process by which a concrete blob store becomes a group blob store that can access the original concrete blob store's blobs.
- Soft Delete - When a blob is marked for deletion from a blob store but still exists within the blob store. This exists to protect against accidental deletion.
- Soft Quota - A feature that monitors a blob store and raises an alert when a specified metric exceeds a constraint. If a monitoring check fails, then the blob store is considered unhealthy. Writes still proceed, but a warning is logged. Types of soft quotas are as follows:
- Space Limit - A limit (i.e., Constraint Limit (in MB)) compared against specific blob store metrics by a soft quota.
- Space Used Quota - This type of quota is violated when the total size of the blob store exceeds the space limit.
- Space Remaining Quota - This type of quota is violated when the available space of a blob store falls below the space limit.