-
Notifications
You must be signed in to change notification settings - Fork 7
Using CloudB
CloudB is composed of a server-side and a client-side, which will communicate through an open protocol (eg. TCP/IP, HTTP, etc.).
The architecture of the system provides a foundation library (cloudb.dll) which is used as a framework for managing connections, serialization, messaging, etc., creating a bridge between the two sides of an instance of CloudB. By design, CloudB hasn't any specific data-model (eg. SQL, BigTable, XML, ODB, etc.), but provides instruments for creating model specific libraries: it comes with a basic key/value (plus files) table data model library (CloudBase), which is the simplest approach to data storage; other models are under development and testing (SQL, ODB).
To know more about developing data-model specific libraries, please read this guide.
Since its open standard approach, CloudB hasn't any specific binding to network protocols, nor any predetermined message format for communications between client and server side: messages can be serialized and deserialized using various formats (eg. binary, XML, JSON, etc.) to let the clients to communicate in different environments and contexts.
Anyway, CloudB comes by default with a TCP/IP service (mode.exe), which exposes the machine where it's running to the CloudB network and that can be run as a standalone console application or be installed as a service (only Windows for the moment).
To know more about mnode.exe read this guide.
Every machine in a CloudB network can have one to three roles: Manager, Root and Block. For more details on machine roles, please read this guide.
Controlling the roles of a machine can be done by using the administration command line application provided by default (cadmin.exe), which will allow a complete organization of a CloudB network topology.
In an ideal network configuration, it is recommended to have 2 Managers (for replication and load balancing), 2 Roots and 4 Blocks.
There is not such a concept of database in CloudB: since it's a data-model agnostic kind of system, it's impossible to define the data topological elements managed as bases of organized data (hypothetically, one certain data model could consist of a single, sharded, infinite string, which doesn't respect any pre-ordinated model): because of this, we define such elements as paths.
Using the Cloud Administration console (cadmin.exe) the network administrator will be able to create a new path, having a given name and type, located at a certain root (see the section Creating Paths on the CAdmin guide).
Summing up, to setup a consumable path instance on the server side, the network administrator must follow the following steps:
- Launch mnode.exe (or other administration service) on all machines members of the network
- Use cadmin.exe (or other administration console) to set the roles of every machine in the network (at least 1 manager, 1 root and 1 block)
- Use cadmin.exe (or other administration console) to create a new path instance, given a name (arbitrary) and type (mandatory), which controls the data model of the path.