SMILA/Project Concepts/Binary Storage
- 1 Overview
- 2 Description
- 3 Storage Mechanism Internal Structure.
- 3.1 A. File System
- 3.2 I. Local hard drive
- 3.3 II. Distributed file system (SFTP, FTP)
- 3.4 B. RDBMS
- 3.5 C. Object DataBase
- 4 Cluster configuration
- 5 Concurrent access
- 6 Technical aspects for designing the Binary Storage Service
- 7 UML Class Diagram
Design a service to easy store / access binary data documents.
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 (configurable tree)
- 3. Hierarchical structure (deterministically calculation)
- II. Distributed file system (SFTP, FTP)
- 1. Flat structure
- 2. Hierarchical structure
- I. Local hard drive
- B. RDBMS
- C. Object DataBase (ODBMS)
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 (configurable tree)
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
- total number of subfolders from the deepest level : 23 folders, Bn' = Bn - (Sn - t/r). (Bn=27; Sn=40; t/r=36)
- hierarchy level - n=4 (logarithmical function)
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)|
3. Hierarchical structure (deterministically calculation)
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.
Binary Storage Service shall also be able to store the records (blob) into RDBMS. Url connection-string shall be configured (driver, host, database name, port, user, password).
For performance considerations, database schema shall contain multiple tables (since large BLOBs will be stored). Binary Storage Service shall deterministically distribute records to database tables.
C. 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.
Open Source Database Engines :
- db4o - http://www.db4objects.com - GNU General Public License (GPL)
- NeoDatis ODB - http://www.neodatis.org/ - GNU General Public License (GPL)
- Perst - http://www.mcobject.com/perst/ - GNU General Public License (GPL)
- Neo4j - http://www.neo4j.org - GNU General Public License (GPL)
- JODB - http://www.java-objects-database.com - GNU General Public License (GPL)
- Oracle Berkeley DB
- Berkeley DB Java Edition
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.
Both options must be supported by the frameworks / RDBMS that Binary Storage Service will use.
Binary Storage Service shall allow multiple clients accessing (read/write) the storage. It is Binary Storage Service responsibilities to synchronize the operation in order to avoid deadlocks.
Technical aspects for designing the Binary Storage Service
- Binary data compressing and encryption shall be available via configuration
- Binary storage shall internally manage its persistence hierarchy.
- The binary service shall be designed as a single bundle / service.
- 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
- Resources synchronization shall be done at the lowest possible level
- Binary Storage shall manage its configuration internally (highly couple classes are difficult to maintain and hard to understand in isolation – they tend to introduce internal dependencies). Decouple binary storage configuration from blackboard service
- The Binary Storage Service API shall stay as simple as possible
void store(String id, InputStream stream); void store(String id, byte blob) byte fetchAsByte(String id) InputStream fetchAsStream(String id) void remove(String id) int fetchSize(String id)