In the previous episode we started to play with OrientDB; in this event will deepen the concepts that underlie the DBMS itself: RecordID and Cluster. For our experiment using the console view in the previous episode. To see all the records in a class is the class <class-name> browse command. For example:

> browse class OUser

In this case we are viewing all users of the database, further deepen OrientDB security system, but for now OUser is a class like any other. For each question the console always shows us the number of records in the resultset and Record ID.

The first is used as an identifier for a view of detail, to show the first record in detail is necessary to use the display command <#> where # is the number of records:

> display 0

Each record in OrientDB has its own self-assigned ID and unique within the database, composed of two parts <cluster-id>: <cluster-position>. What is a cluster ?

The cluster is nothing but a grouping of records. The equivalent of the relational world would be a table, but a cluster can also record heterogeneous group, so the same type. Each database can have a maximum of 32,767 clusters (2 15) and each cluster can handle up to record 9223372035000000000 (2 63). The maximum size of a database to record and then record of 2 78, ie 302231454903657000000 records. Probably not even come close to these numbers, so the only limit that we really remember is the number of clusters.

There are three types of clusters:

physical cluster (physical or local), which writes directly to the file system;
logical cluster, which is supported by the physical cluster, is slower, heavier, but has the advantage of not creating the files. In most cases this is not a problem, but in systems where there are restrictions on the number of logical file used in the cluster is to be preferred;
Cluster memory (memory): All information on this type of cluster are volatile, and therefore will be lost to the termination of the process or the server if the database is remote.

For the vast majority of cases the physical clusters are preferred because they are lighter and more efficient. When you want to store temporary information such as cache or application, the cluster "in memory" can be a good choice. The good news is that the default OrientDB always create physical clusters, so for now we can not worry too much.

To view all clusters from clusters console run the command:

> clusters

In object-oriented model of OrientDB all instances of a class are stored in a clustered ad hoc. By convention, the name of the cluster and the class match, but you can change the schema at any time and for this reason if we execute OUser browsing the cluster, which is used in a previous example, we would have the same results because the class is associated OUser OUser cluster.

> browse cluster OUser

To query the database, the vast majority of products NoSQL has a proprietary language more or less complex. OrientDB, however, between the various supports just a subset of SQL with new entrants to exploit the potential of the graph schema-less and not in the relational world. Although this choice may seem counterintuitive, it's actually been pondered, because it was considered that most people know today that uses a SQL DBMS, those who approach certainly has a background OrientDB relational and SQL is also much more readable and a concise script Map Reduce.

In the next episode we'll see how to manipulate the records in the database using only the console and SQL linguagggio. Meanwhile, write these lines in the console:

> select * from OUser

> select * from cluster:OUser

and see what happens.