OrientDB’s APIs: Document, Object, and Graph
Records (or documents/vertices)
attributes(or “fields” and “properties”)
In OrientDB each record has its own self-assigned unique ID within the database called Record ID or RID. It is composed of two parts:#<cluster-id>:<cluster-position>
cluster-id： is the id of the cluster. Each database can have a maximum of 32,767 clusters (2^15-1)
cluster-position： is the position of the record inside the cluster. Each cluster can handle up to 9,223,372,036,854,780,000 (2^63) records, namely 9,223,372 Trillion of records!
A RID (Record ID) is the physical position of the record inside the database.
OrientDB has the concept of records as an element of storage. There are different types of records, document is one type of records.
A document is composed of attributes(or “fields” and “properties”) and can belong to one class.
Classes are also used in OrientDB as a type of data model according to certain rules.
A cluster is a place where a group of records are stored. Perhaps the best equivalent in the relational world would be a Table.
By default, OrientDB will create one cluster per class. All the records of a class are stored in the same cluster which has the same name as the class. You can create up to 32,767 (2^15-1) clusters in a database.
The benefits of using different physical places to store records are:
faster queries against clusters because only a sub-set of all the class’s clusters must be searched
good partitioning allows you to reduce/remove the use of indexes
parallel queries if on multiple disks
sharding large data sets across multiple disks or server instances
There are two types of clusters:
Physical Cluster (known as local) which is persistent because it writes directly to the file system
Memory Cluster where everything is volatile and will be lost on termination of the process or server if the database is remote
The most important feature of a graph database is the management of relationships
With OrientDB, speed of traversal is not affected by the database size.It is always constant regardless if it has one record or 100 billion records. This is critical in the age of Big Data.
OrientDB comes with a generic Vertex persistent class called “V” (OGraphVertex in previous releases) and “E” (OGraphEdge in the past) for Edge.
lightweight edges: they don’t have own identities as record, but are physically stored as links inside vertices. OrientDB automatically uses Lightweight edges only when edges have no properties, otherwise regular edges are used.
This is to improve performance and reduce the space on disk. But as a consequence, since lightweight edges don’t exist as separate records in the database
Class –>table(classes can be schema-full, schema-less, or mixed.)
Property –> column
Record –> row
Cluster(store the data of a class in different physical locations)
Console命令
连接数据库：connect remote:172.19.163.83/jrdm orientdb orientdb
http://orientdb.com/docs/2.0/orientdb.wiki/Tutorial-Relationships.html
http://orientdb.com/spark-orientdb/