Patent Description:
<CIT> pertains to a method of efficiently managing storage in a distributed network having a plurality of connected nodes comprising the steps of: determining when a certain file storage parameter exceeds a pruning threshold; and performing a pruning cycle including: (a) identifying the content components associated with the storage; (b) selectively pruning the content components based at least in part on usage statistics so that the file storage parameter is reduced to below the pruning threshold; and (c) updating meta data associated with the content components to reflect the updated storage system parameters and further comprising (d) presenting the contents of the updated storage network as a virtual file system so that all the files appear locally accessible to any node. "The Zebra Striped Network File System" by JOHN HENRY HARTMAN discusses a distributed file system using, in some cases, replication to protect against failures and to increase performance of reading.

A distributed computer system for delivering data to at least one client-side application is provided. The computer system is distributed as such that data required by the client-side application is stored on a database that is located distant to the client-side application(s) and is connected to these applications over a computer network. The client-side applications are for example flight booking applications querying airport lists or the like. Those applications might run their back-ends on particular application servers. The distributed computer system may provide fast, reliable and scalable to data that may be the same for thousands of servers and does not change too often, i.e. it remains constant for at least for thousands of read requests. In this sense the distributed computer system comprises a read oriented distributed filesystem.

The distributed computer system comprises a database to store immutable data blocks. The data blocks may contain, for example, portions of the data demanded by the client-side application, such as portions of an airport lists or arrival time/departure time schedules for an airline. The data blocks are immutable in the sense that the only way of changing the data contained by the data block(s) is to replace the entire data block(s).

The distributed computer system further comprises a data distribution entity to split source-data into the immutable data blocks and metadata. The data distribution entity might include a distribox for splitting up data of a file into data blocks above, the copies of immutable data blocks are redundantly stored on a plurality of different storage nodes. The parallel requests are directed to these different storage nodes.

A characteristic of immutable blocks is that they are redundant, as no immutable block can ever differ from a different immutable block of the same file version. As they are redundant, a quorum read will give the exact same result for each of the parallel queries of the quorum read, so that a selection based on the fastest response is possible.

To provide an example, if the file has <NUM> bytes and the block are <NUM> bytes long, there will be <NUM> blocks. And when the application interface of the client-side application will ask to read data from offset <NUM> to <NUM>, the fuse daemon will perform a quorum read two times, once for block <NUM>-<NUM> and once for block <NUM>-<NUM>. The other blocks will not be fetched. If later on, the application interface request bytes <NUM>-<NUM> it will be served from a cache in which the immutable data blocks are stored, e.g. a page cache. If, however, the bytes <NUM>-<NUM> are requested, another quorum read will be issued by the fuse daemon.

The fuse-daemon is configured to fetch the data blocks delivered by the database in the fastest response and is configured to discard results delivered subsequently to the fastest response. For some reasons, for example, latency or workload, one of the storage nodes might be able to response more quickly than others. Nonetheless, all storage nodes to which a request is directed will process the requests of the quorum read and deliver results. However, only the fastest results (= immutable data blocks requested) will be fetched by the fuse daemon and delivered, for example, to a data repository of the data fetching and delivering entity located close to the client application(s). Upon receiving the fastest response, the fuse daemon orders the storage nodes of the database to cancel processing of the not yet served requests.

The fuse-daemon is configured to generate a virtual file comprising the corresponding range of data from the fetched data blocks. The virtual file is, for example, a file that is located close to the client-application to enable fast retrieval of data stored in said virtual file to the client-side application. The virtual file might store only the data contained in the immutable data blocks that corresponds to the requested range and might discard the rest. The request for a range of data of a file will then be answered by the data fetching and delivering entity by means of the data stored in the virtual that corresponds to the requested range of data. The file is referred to as a virtual file as the client application cannot distinguish the data delivered from the virtual file from a data delivered by a remote database. As such the structure and access patterns to the file from which the range of file is requested are free and in the responsibility of the client application(s) instead of the access patterns being managed by the database.

The data fetching and delivering entity comprises an operating system having an operating system page cache, wherein the operating system page cache is configured to store at least the parts of the fetched data blocks corresponding to the range of data of a file requested by the client-side application.

The operating system is, for example, a POSIX supporting operating system, such as a UNIX operating system. The page cache of said operating system is, for example, a cache of a UNIX, e.g. LINUX, kernel. This page cache may be implemented on a Openshift node which is in communication with the client-side application(s) as point of deliveries (POD). The fuse daemon is configured to keep fetched data blocks in the page cache as long as possible, hence, until the file and with it - the data block - has changed. Whenever more up-to-date data blocks are available, the new data block may be fetched and pushed to the page cache by the fuse daemon. Either all the fetched immutable data blocks containing the requested range of a file are stored in the page cache or only a data content extracted from the data block that corresponds exactly to said requested range.

In some example, the data in the virtual file is retrievable by the at least one client-side application as response to the request for a range of data of a file and as response to any future request for the same range of data of a file. Hence, the requested data range is deliverable directly when the request for said data is repeated. This saves computational resources needed for a new (quorum read) query to the database if the data is already available in the client-side page cache.

In some examples, the database comprising the storage nodes is a NoSQL database. A NoSQL database is a database that cannot be served by SQL call commands and is, for example, not a relational database at all. Such a NoSQL database could be a database with an append-only mechanism, hence, a database for which it is impossible to insert an entry between two prior existing entries in a list, but new entries have to be added to that list, after the prior existing entries. The database might be a Redis cluster optimized for heavy read / low write operations with high data availability.

In some examples, wherein the values comprised by the metadata are referencing values referencing the immutable data blocks for a key-value database call, these referencing values being generated through hash values of each corresponding data block.

To provide an example, each immutable data block is hashed and the resulting hash value is used as a key for this immutable data block, and referenced in the metadata, which is, for example, a file metadata. As such, there may be records in the file metadata about the immutable data blocks comprised by the file for which the range is requested. These records may include information about which hash value, corresponding to said key value in the key/value data base call, stands for which immutable data block of the file. As mentioned above, each referenced immutable data block is replicated to at least three nodes. For example, those immutable data blocks containing data within the requested range of data are fetched, those not containing data within this range are not fetched.

However, in some examples, the database is configured to deliver data corresponding to the file including data of a data block outside of the requested range of the file. As such, for example, also the data blocks adjacent to or in a certain range around the data blocks containing data within the requested range are also fetched. Furthermore, simply all immutable data blocks of a file could be fetched.

In some examples, the virtual file comprises, along with the range of data requested, the metadata of data blocks corresponding to data outside of the requested range of the file. In general, for example, the metadata may be delivered by the database to the data fetching and delivering database upon the request for the range of data of a file or before a request for the range of data of a file.

Hence, in some examples, the fuse daemon is configured to generate the virtual file comprising the metadata. The metadata might be stored in the virtual file on the data fetching and delivering entity, where the metadata might be used in formulating a query for (i) the data structure of the file and/or (ii) certain immutable data blocks comprised in the file by the quorum read.

The fuse-daemon is configured to perform the query for the quorum read operation at least three times in parallel and wherein the same data blocks are stored at least three times on at least three different database storage nodes. In this case, the number of queries performed in the quorum read corresponds to the number of nodes on which copies of the immutable data blocks are stored. Each of the three queries will be then, for example, directed a different one of those three storage nodes. In this example, not more copies are stored than queries to be performed, limiting the used storage capacity to the minimum amount necessary to process each query in competition with each other.

In some examples, the fuse-daemon is configured to perform the query for the quorum read operation three times in parallel and wherein the same data blocks are stored five times on at least five different database storage nodes. In this example, the immutable data blocks are replicated on more storage nodes than actually needed for processing the three queries of the quorum read. This, however, increases data availability, as even if two storage nodes failed, there are still enough functional storage nodes to perform the quorum read operation successfully. Furthermore, the number of queries in a quorum read operation could be flexibly increased to five queries when storing five immutable data block copies on five different storage nodes. value, corresponding to said key value in the key/value data base call, stands for which immutable data block of the file. As mentioned above, each referenced immutable data block is replicated to at least three nodes. For example, those immutable data blocks containing data within the requested range of data are fetched, those not containing data within this range are not fetched.

In some examples, the fuse-daemon is configured to perform the query for the quorum read operation at least three times in parallel and wherein the same data blocks are stored at least three times on at least three different database storage nodes. In this case, the number of queries performed in the quorum read corresponds to the number of nodes on which copies of the immutable data blocks are stored. Each of the three queries will be then, for example, directed a different one of those three storage nodes. In this example, not more copies are stored than queries to be performed, limiting the used storage capacity to the minimum amount necessary to process each query in competition with each other.

In some examples, the fuse-daemon is configured to perform the query for the quorum read operation three times in parallel and wherein the same data blocks are stored five times on at least five different database storage nodes. In this example, the immutable data blocks are replicated on more storage nodes than actually needed for processing the three queries of the quorum read. This, however, increases data availability, as even if two storage nodes failed, there are still enough functional storage nodes to perform the quorum read operation successfully. Furthermore, the number of queries in a quorum read operation could be flexibly increased to five queries when storing five immutable data block copies on five different storage nodes.

In some examples at least two client-side applications employ a common middleware client library to access the virtual file. Middleware could be defined, for example, as the software layer that lies between the operating system and applications on each side of a distributed computing system in a network. Providing a common middleware client library to access the virtual file saves resources in the communication between the virtual file and the client-side applications. This communication might take place over dedicated interfaces.

In some examples, the data fetching and delivering entity comprises a file interface being compatible to at least one portable operating system, the file interface being an interface to at least one client application back end and the file interface supporting sequential and random read access. This file interface might be used to carry out the communication over the common middleware client library. In some examples, the operating system of the data fetching and delivering entity is a UNIX based operating system.

In some examples, as mentioned above, the fuse daemon is configured to select and to fetch data blocks based on the range of the data of the file by selecting and fetching those immutable data blocks that contain the data within the requested range of data.

In some examples, before the quorum read request for at least one immutable data block is issued by the data fetching and delivering entity, a request from the client application to the fuse daemon comprising the name of the data file is issued when a request for opening the data file is issued by the client application. Hence, the client application is aware data of which file it wants to retrieve. It therefore, for example, issues an open-file request to the database via the fuse daemon, wherein the open-file request contains said file name of the requested data file.

In some examples, the fuse daemon is further configured to retrieve metadata of the file that comprises the list of blocks with their hash value, the size of the file and the block size, and is to store the metadata on the data fetching and delivering entity, wherein the metadata is retrieved also when a request for opening the data file performed by the client application is issued.

The metadata, stored, for example, in the virtual file on the data fetching and delivering entity will then comprise, for example, at least the following values: (i) the size of the file in bytes; (ii) the size of a single immutable data block in bytes; (iii) a list of blocks with their corresponding hash values. This information in the metadata is then used to calculate which immutable data blocks should be requested by the fuse daemon / the data fetching and delivering entity to cover the range of the file.

In some examples, the fuse daemon is to translate the request for a range of data of a file to the quorum read request using the information contained in the metadata, the translation comprising a calculation involving the size of the file, the block size and the requested range, using a calculation rule also obtained from the metadata of the file. The calculation rule is therefore, for example, also obtained when retrieving the metadata of the file.

For example, the block size of an immutable data block could vary depending of the global size of file. For a bigger/smaller global file size in bytes, immutable data blocks with a bigger/smaller size in bytes could be comprised by the file.

In the following, an example of how to determine which immutable data blocks are to be fetched to obtain the requested range of data of the file, using the calculation rule stored in the metadata is presented:.

If there is a read request with an intended offset in the file X and a requested data range of Length L, with the block size being known, then the fetching entity will compute the first immutable data block to be retrieved and the number of blocks to be retrieved by: <MAT> and <MAT> wherein the "/" operator indicates an integer division.

It will then retrieve the immutable block from <MAT> the last block being the last block containing data within the requested range and Filesize being the global size of the file, by retrieving the correct number item (hash value) in the list of immutable blocks and corresponding hash values/ key values.

The calculation of which blocks to be retrieved, is performed by the fuse daemon, for example, in the course of the application request to read the file or to fetch the immutable data blocks.

In some examples, at least two versions, preferably three versions of the data file split into the immutable data blocks are kept in a storage of the distributed computer system being able to deliver the version of the datafile to the data distribution entity.

The purpose of keeping at least two versions, preferably three versions of the file is a criterion to have some regular garbage collection that will remove the data that is not needed anymore. Another criterion for this may be, for example, to do not remove a file that is still used by someone. An option to ensure this is, for example, to ask the client to register itself as a user of the file for a certain time, being referred to further as a lease. Because of the possibility of a network crash or a partition crash, the lease may not be infinite because otherwise a dead node could prevent deletion of data forever.

For example, each time a client opens a file, it will beforehand put a lease on the file and should clean the lease or reissue the lease when needed. Then when the garbage collection daemon, for example, will scan the file to purge, it will check if there is a lease on the file or not. This is, for example, implemented by putting an item (filename: e.g. TTL) with the expiration time. If many clients open the file, they will write to the same item. If this item expires, it means nobody needs the file anymore and the item can be deleted.

In some examples, the method being executable on the distributed computer system as described above, the method comprising:.

Furthermore, a computer program product comprising program code instructions stored on a computer readable medium to execute the method steps mentioned above, when said program is executed on a computer, is provided.

Examples of the invention are now described, also with reference to the accompanying drawings, wherein.

The drawings and the description of the drawings are of examples of the invention and are not of the invention itself. Like reference signs refer to like elements throughout the following description of examples.

An example of a distributed computer system <NUM> with a data distribution entity <NUM>, a database <NUM> and a data fetching and delivering entity <NUM> as well as client applications <NUM>, <NUM>' and a fuse daemon <NUM>, with immutable data blocks <NUM> being replicated and stored by the data distribution entity on the database <NUM> and queried via a quorum read <NUM> by the data fetching and delivering entity <NUM> is shown in <FIG>.

A data producer application <NUM> is configured to produce a data file <NUM>, for example, an airport list, exported from an airport dataset. The data producer application <NUM> is configured to send the generated data file <NUM> to the data a data distribution entity <NUM>. The data distribution entity <NUM> comprises a distribution box <NUM>' (also referred to as "distribox") and a distribox back end <NUM>" with the function of a persistent file storage for the data file <NUM>. The distribox <NUM>' is to import the file <NUM> from the distribox back end <NUM>". The data file <NUM> comprises data that is, for example, segmented into immutable data blocks <NUM>. The distribox <NUM>' is configured to replicate all or at least a significant part of the immutable data blocks <NUM> comprised by the data file <NUM> and store the replicated immutable data blocks <NUM> storage nodes <NUM> of a database <NUM>.

In the example illustrated by <FIG>, the immutable data blocks are replicated five times and are stored on five different storage nodes <NUM>. Hence, in total, twenty-five data blocks <NUM> are stored on the data base. When the data file <NUM> is segmented into five different immutable data blocks <NUM>, each storage node <NUM> may contain a copy of each different immutable data block <NUM>.

Client-side applications <NUM>, <NUM>' might run on respective application servers, indicated by the dashed boxes comprising the client-side applications <NUM>, <NUM>'. Those data consuming applications might are connected to a data fetching and delivering entity <NUM>, which is, for example, an Open shift node. The client-side applications <NUM>, <NUM>' might send a request for a range of data of a file <NUM> via a middleware that is common to both client-side applications <NUM>, <NUM>' and an application back-end interface <NUM>" to the data fetching and delivering entity <NUM>. From the data fetching and delivering entities side, this communication may take place via file interface <NUM>. The file interface <NUM> supports sequential and random read access.

If the request for a range of data of file <NUM> is triggered for the first time, no data corresponding to the requested range of data can be delivered directly from the virtual file <NUM>. Therefore, the data blocks <NUM> corresponding to said data range <NUM>, <NUM> (see <FIG> and <FIG>) have to be fetched from the data base <NUM>. For this purpose, the data fetching and delivering entity <NUM> employs a fuse daemon <NUM>. This fuse daemon is configured to translate the request for a range of data of the file <NUM> into a quorum-read request <NUM> for at least one immutable data block <NUM> to the database <NUM>. After performing this translation to a quorum read request <NUM> (see the example translation explained in the section before), the fuse daemon <NUM> issues this request towards the database <NUM>.

Herein, the quorum-read request <NUM> comprises three individual parallel requests <NUM> to different storage nodes <NUM> storing the same immutable data block <NUM>. The parallel requests <NUM> are identical with respect to the immutable data block <NUM> they are directed to. As such, all parallel requests <NUM> are, for example, directed to the first two immutable data blocks <NUM> of a file <NUM> comprising overall ten immutable data blocks <NUM>.

The quorum read request <NUM> is then processed by every storage node <NUM> to which one of the individual requests <NUM> is sent and send answers in the form of the requested data blocks <NUM> towards the data fetching and delivering entity <NUM>. However, the data fetching and delivering entity <NUM> may receive every response but discards every response except the fastest response <NUM>. Alternatively, the data fetching and delivering entity <NUM> may receive the fastest response <NUM> and cause the storage nodes <NUM> to stop processing those requests that have not been answered yet.

The fuse daemon <NUM> may receive the data block(s) <NUM> contained in the fastest response <NUM> and store these data blocks in a virtual file <NUM>. This virtual file <NUM> is stored in a page cache <NUM> of a operating system <NUM>, for example, a LINUX operating system. The fuse daemon <NUM> is configured to keep fetched data blocks <NUM> in the page cache <NUM> as long as possible, hence, until the data file <NUM> and with it - the data block - has changed. The originally requested range of data <NUM>, <NUM> may be cut out of the fetched immutable data blocks <NUM> resident in the page cache's <NUM> virtual file <NUM>.

From the virtual file <NUM> in the page cache <NUM>, the requested range of data <NUM>, <NUM> is delivered in a response to the client-side application(s) <NUM>, <NUM>' in a response <NUM> to the initial request. As the fetched data blocks <NUM> are held in the virtual file <NUM>, these immutable data blocks <NUM> could be used for any future request for a range of data <NUM>, <NUM> comprised by the previously fetched data blocks. This significantly reduces the processing times for future requests for the same range of data or a range of data <NUM>, <NUM> also comprised by previously fetched immutable data blocks <NUM>.

An example of a No SQL database on which data blocks of a versioned file and metadata regarding that file are stored is shown in <FIG>.

Three versions of a data file, namely the latest three versions data file, namely data file <NUM>, data file <NUM>', and data file <NUM>" are kept in an external storage, such as the persistent file storage of a distribox back end <NUM>" shown in <FIG>. As these data files <NUM>, <NUM>', <NUM>" are external to the illustrated content of NoSQL database <NUM>', they are illustrated in <FIG> by dashed shapes. The NoSQL database <NUM>' is a possible implementation of the database <NUM>, shown in <FIG>.

The storage node <NUM> of NoSQL database <NUM>', illustrated in more detail in <FIG>, may store three different immutable data blocks <NUM>, <NUM>', <NUM>". These immutable data blocks <NUM>, <NUM>', <NUM>" are comprised by the latest version of the data file, namely data file <NUM> and are replicated, among others, to said storage node <NUM>. These immutable data blocks cover two ranges of data <NUM>, <NUM>. The first range of data <NUM> is comprised by the data block <NUM> and the data block <NUM>', whereas the second range of data <NUM> is comprised by the data block <NUM>' and the data block <NUM>". The first range of data <NUM> might be a range of data corresponding to an actual request for a range of data of a file <NUM>, while the second range of data <NUM> may correspond to the remaining data of a file <NUM>, outside of the requested range <NUM>.

The NoSQL database <NUM>' stores metadata <NUM> that is related to the immutable data blocks <NUM>, <NUM>', <NUM>" is stored. The metadata <NUM> comprises values <NUM> which are referencing the immutable data blocks <NUM>, <NUM>', <NUM>" for a key-value database call. In the example illustrated by <FIG>, these referencing values <NUM> are hash values <NUM>'. For example, each immutable data block <NUM>, <NUM>', <NUM>" is associated with a different unique hash value <NUM>'.

The metadata <NUM> of the data file <NUM> comprises a list of blocks with their hash value <NUM>', the size of the file <NUM> and the block size <NUM>. The metadata <NUM> of the data file <NUM> further comprises a calculation rule <NUM> being readily exposed for retrieval by the data fetching and delivering entity <NUM> (see <FIG>). The calculation rule <NUM> involves a rule for translating a request for a certain range of a file <NUM> with a certain offset, to a request for certain immutable data blocks <NUM>, <NUM>', <NUM>". This calculation rule <NUM> uses the size of the file <NUM> and the block size <NUM> stored in the list of blocks to put out the hash values for which the data fetching and delivering entity <NUM> has to query in order to obtain the immutable data blocks <NUM>, <NUM>' corresponding to those two data blocks <NUM>, <NUM>' that comprise the range of data of the file <NUM>. For an example of a such a calculation rule and the application of that rule in order to fetch particular immutable data blocks <NUM>, <NUM>', <NUM>" it is referred to the general description.

Besides the storage node <NUM>, the NoSQL database <NUM>' comprises further storage nodes, such as the storage node <NUM>', on which, for example, the data blocks <NUM>, <NUM>', <NUM>" are stored as well.

An example of a data fetching and delivering entity in communication with the database for retrieving the data blocks and the metadata to a virtual file stored on the data fetching and delivering entity is shown in <FIG>.

The data consuming application <NUM> issues a request for opening the data file <NUM>' to be read out to the fuse daemon <NUM>'. Concurrently with this request <NUM> or subsequent to this request, a request <NUM>' comprising the name of the data file is sent from the client application <NUM> to the fuse daemon <NUM>. The fuse daemon <NUM> issues requests <NUM>, <NUM> that correspond to the above-mentioned requests <NUM>', <NUM>' to the database. The requests <NUM>' and <NUM>' as well as the requests <NUM> and <NUM> can also be realized as a single request.

Subsequent to or concurrently to the request for opening the file <NUM>, <NUM>' the fuse daemon <NUM> is to retrieve metadata <NUM> of the data file <NUM> (see <FIG> and <FIG>). As described in conjunction with <FIG>, this metadata <NUM> comprises a list of blocks with their hash value, a size of the file and a block size, as well as a computational rule of how to translate the request for a range of data of the file to a request for certain blocks. The metadata <NUM> is stored at the data fetching and delivering entity <NUM>, for example, in the virtual file <NUM>.

When the calculation rule is received, the fuse daemon <NUM> performs a translation of the request for a range of data of a file <NUM> to said quorum read request <NUM>, which is sent to the database <NUM>.

A first such quorum read request <NUM> might be sent to retrieve a range of data <NUM> included in the immutable data blocks <NUM>, <NUM>'. These immutable data blocks <NUM>, <NUM>' are retrieved and stored in the virtual file <NUM>. The data of the immutable data blocks <NUM>, <NUM>' corresponding to the data range <NUM> may be isolated from these fetched immutable data blocks <NUM>, <NUM>' and the data of the range <NUM> is, for example, also stored in the virtual file <NUM>.

As such, the immutable data blocks <NUM>, <NUM>' may remain stored in addition to the range of data <NUM> originally requested by the client application <NUM> in the request <NUM> for a range of data. However, the immutable data blocks <NUM>, <NUM>' may also be deleted from the virtual file <NUM> after having isolated and stored the range of data <NUM> in the virtual file <NUM>.

In the same way, data from a data range <NUM>, corresponding to the remaining data of the file <NUM> may be retrieved. This data range <NUM> is data comprised by the immutable data blocks <NUM>', <NUM>" which are again retrieved by the fuse daemon and stored in the virtual data file <NUM> on the data fetching and delivering entity <NUM>. Also here, the range of data <NUM> may be isolated from the immutable data blocks <NUM>', <NUM>".

An example of a flow chart illustrating a method of delivering data from a database to at least one client-side application, in a distributed computer environment is shown in <FIG>.

In activity S1, source data in the form of a data file is split into immutable data blocks and metadata.

In activity S2, the data blocks are replicated and stored on at least two different storage node of a database, wherein the metadata created in activity S1 comprises values referencing the immutable data blocks in the at least two storage nodes for a key-value database call.

In activity S3, a request for a range of data of a file triggered by at least one client-side application is translated into a quorum-read request for at least one immutable data block to the database, wherein the quorum read request comprises a plurality of individual parallel requests to different storage nodes storing the same immutable data block.

In activity S4, the data blocks delivered by the database in the fastest response are fetched and those results delivered subsequently to the fastest result are discarded.

Claim 1:
A distributed computer system for delivering data to at least one client-side application, the distributed computer system comprising:
• a database configured to store immutable data blocks,
• a data distribution entity configured to split source-data in the form of a data file into immutable data blocks and metadata,
- wherein the data distribution entity is configured to replicate the immutable data blocks and to store the immutable data blocks on at least two different storage nodes of the database,
- wherein the metadata comprises values referencing the immutable data blocks in the at least two storage nodes for a key-value database call,
• a data fetching and delivering entity comprising:
- a fuse-daemon configured to translate a request for a range of data of a file triggered by at least one client-side application into a quorum-read request for at least one immutable data block to the database,
- wherein the quorum-read request comprises a plurality of individual parallel requests to different storage nodes storing the same immutable data block,
- wherein the fuse-daemon is configured to fetch the data blocks delivered by the database in the fastest response and is configured to discard results delivered subsequently to the fastest response, wherein upon receiving the fastest response, the fuse-daemon orders the storage nodes of the database to cancel processing of the not yet served requests,
- wherein the fuse-daemon is configured to generate a virtual file comprising the corresponding range of data from the fetched data blocks,
wherein the data fetching and delivering entity comprises an operating system having an operating system page cache, wherein the operating system page cache is configured to store at least the parts of the fetched data blocks corresponding to the range of data of a file requested by the client-side application, wherein the fuse daemon is configured to keep fetched data blocks in the page cache until the file and the respective data block has changed,
wherein the fuse-daemon is configured to perform the query for the quorum read operation at least three times in parallel and wherein the same data blocks are stored at least three times on at least three different database storage nodes.