[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    [jira] [Created] (JAMES-3953) Provide a file based blobstore
From:       "Benoit Tellier (Jira)" <server-dev () james ! apache ! org>
Date:       2023-10-29 8:16:00
Message-ID: JIRA.13555935.1698567349000.187190.1698567360025 () Atlassian ! JIRA
[Download RAW message or body]

Benoit Tellier created JAMES-3953:
-------------------------------------

             Summary: Provide a file based blobstore
                 Key: JAMES-3953
                 URL: https://issues.apache.org/jira/browse/JAMES-3953
             Project: James Server
          Issue Type: New Feature
          Components: Blob
            Reporter: Benoit Tellier
             Fix For: 3.9.0


h3. Why?

While working on on-premise instalations, the S3 topic is often a blocker: clients \
are not equiped with this kind of technologies.

Aquiring S3 compatible object stores is not that of an easy /cheap task as it \
fundamentally redifines what storage is, and clashes hardly with the philosophy they \
applies.

So far I handled these projects by deploying MinIO (because it is easy to deploy). \
But on top of shared remote storage performance is mediocre (60 Append of ~500 KB in \
parallel). Technologies like MinIO are though with attached storage in mind and thus \
are not adapted to this kind of setup.

I can take concrete examples:

 - Medium size governement agencies in developing countries. They just have ISCI SAN \
                bay, and do not have founds to adopt other technologies.
 - Large size health organisation. Handling health data in France is subject to \
numerous security restrictions (HDS certification) thus they have constraints on the \
datacenter that prevent them from accessing more advanced features.

For these customers, I believe they would be better served with a file based \
implementation of the blob store.

h3. What?

Provide a file based implementation of the blob store. 

Buckets will be emulated via a folder.

Because of it's immutable nature, concurrent file access should not be an issue.

We let the su=ystem administrator the choice of how the file system is set up and \
distributed, backed up and which mount options are to be set up.

This will be a new *BlobStore* within `/server/blob/blob-file`.

Propose this blob Store as experimental first.

While a reactive implementation could be attempted with IO Uring (non portable to non \
Linux system) a first implementation could be as simple as using a *boundedElastic* \
thread for the reads.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]