Overview

Design a service to easy store / access binary data documents.

Description

Client components will access the Binary Storage Service for persisting binary data (attachments) into the binary storage. The binary data shall be simply identified by a unique key / identifier as a String data type. No directly client component access to the persistence storage shall be available; the persistence storage will be only accessible through the Binary Storage Service API which provides the needed CRUD operations.

Backend mechanism of Binary Storage shall be completely transparent to the client, thus user shall have the opportunity to setup basic configuration of the service. Binary Storage shall be able to determine and use default/optimistic configuration in case no one is specified by the user.

Storage Mechanism Internal Structure.

Binary Storage will depend on the amount of data it needs to persist/manage. Because of this the persistence storage of service shall be able to deal with fallowing persistence structures/techniques, depending on service configuration:

A. File System

I. Local hard drive

1. Flat structure

2. Hierarchical structure

II. Distributed file system (SFTP, FTP)

1. Flat structure

2. Hierarchical structure

B. Object DataBase

One of the persistence options will be used by the Binary Storage Service at the running time. Internally, the DAO & DAO Factory concept provides the appropriate/configured persistence option implementation to the Binary Storage Service independently. User can shall configure its appropriate persistence option that satisfies his/her needs.

A. File System

Binary Storage Service saves the binary data directly in the file system.

I. Local hard drive

The service saves data in the local drive using a predefined persistence storage location - binary.storage.root.path. Under this root path Binary Storage will create its files system structures flat or hierarchical, depending on the configuration.

1. Flat structure

The file system - flat structure configuration shall be used in case of small amount of data, since all the attachments will be saved in the same path location. For huge amount of data the systems becomes very slow, time responding increases significantly.

This option shall only be used for debugging purpose, since it offers an easy way for locating a specific persisted attachment.

In case of no initial configuration is provided by the user, the file system - flat structure option shall not be used as default.

2. Hierarchical structure

Through the hierarchical file system persistence, Binary Storage Service will manage by itself a configurable & hierarchically & internal structure under the configured persistence storage root path. This is to be considered the default configuration.
Following parameters are available for configuring the hierarchical structure:

q - Maximum number of subfolders per folder

r - Maximum number of persisted attachments per folder

The hierarchical (tree) structure is being created during the the storage of new data (the initial number of binary data which is going to be persisted is unknown for Binary Storage Service).

Hierarchical structure nomenclature. Test scenario

Fallowing picture outlines the hierarchic overview, file system nomenclature and binary data distribution (persistence) inside the tree structure. In the illustrated sample , our test scenario uses a total number of attachments to be stored 360. The configuration values are :

q = 3 (maximum 3 subfolders per folder in the hierarchy)
r = 10 (maximum 10 files stored in a folder inside of the hierarchic structure)
t = 360 (total number of attachments-files to be stored)

As it is outlined in the picture, the total number of subfolders from hierarchy structure represents a geometric progression (in mathematics also known as a geometric sequence), where each term (number of folders from the same level of the hierarchy) after the first is found by multiplying the previous one by a fixed non-zero number called the common ratio. The common ration identifies with maximum number of sub-folders per folder - q.

For a optimistic hierarchy, it is possible to determine fallowing parameters in order to configure the hierarchy as user expects:

total number of folders from structure (t/r) - 36

total number of subfolder at each level from the structure - Bn formula. (b1= 1 folder at the first level; b2=3 folders at the second level; b3=9 folders at the third level; b4=23 folders at the fourth level)

total number of subfolders from the hierarchy (in full mode) - Sn formula

Binary Storage Service has to map each attachment identifier to the path where the binary data is being stored. The mappings needs to be persisted so they can be reused if the system gets restarted.

An external manipulation of persistence storage structure (like deleting data form inside of it) will break the mappings. This is considered an exceptional case and it is not in the Binary Storage Service scope.

Fallowing table provides an overview of the hierarchical structure based on configured parameters:

t (number of attachments)

q (max number of subfolders in folder)

r (max number of att.in folder)

TF (number of folders)

n (hierarchical level)

Sn (full mode hierarchy)

M (missing subfolders in deepest level)

360

3

10

36

4

40

4

II. Distributed file system (SFTP, FTP)

The purpose of distributed file system option is to allow storing/accessing of binary data into network storage devices transparently through SFTP, FTP. User needs to provide configuration data related to distributed systems (host, user, password). It is considered that user has write access to the distributed system at the configured persistence location path.

1. Flat structure

It has the same characteristics like in the local flat configuration, but it is applied on the persistence location from the distributed system.

2. Hierarchical structure

It has the same characteristics like in the local hierarchic configuration, but it is applied on the persistence location from the distributed system.

B. Object DataBase

Binary Storage Service will use existing Open Source Object Database Engine to store the binary data. It is not Binary Storage Service responsibility to directly access the stored data; the service will store/fetch the data by using the exposed API.

Cluster configuration

Binary Storage Service must offer fallowing cluster configurations:

Client components clustering (like blackboard service) - where the client services run in cluster and all the cluster nodes needs to share the same data (which means, all the nodes have to share the same binary persistence storage). This will be only possible by configuring the Binary Storage Service to use the distributed file system option or object database option (where the Object Database Engine is capable to be remotely accessed - not an embedded designed database which does not allow directly remote connections);

Persistence storage clustering - where binary data will be stored in more than one nodes.

The two cluster options shall be available even configuring both at the same time, or only one, or non of them.

Technical aspects for designing the Binary Storage Service

Binary data compressing and encryption shall be available via configuration

Exception handling mechanism should treat all internal binary storage (logical and unexpected) errors and wrap the exceptions into a “binary storage exception” that makes sense for the Blackboard service