Database Reference
In-Depth Information
search, executing geospatial queries, and numeric range queries. Elasticsearch allows
us to query over nonindexed properties, as well.
Edge Compression
With edge compression, Titan can store compressed metadata and keep memory usage
low. It also can store all edge labels and properties within the same data block for faster
retrieval.
Graph Partitioning
This is where the underlying database matters the most. In Cassandra, we know that
data for one particular row would be stored on one Cassandra node. Titan understands
that with keys sorted by vertex ID, it can effectively partition and distribute graph data
across Cassandra nodes. The vertex ID is a 64-bit unique value.
By default Titan adopts a random partitioning strategy to randomly assign vertices
to nodes. Random partitions are efficient and keep the cluster balanced, but in the case
of multiple backend storage options adopted for storing graphs, it would lead to per-
formance issues and require cross-database communication across the instances. With
Titan we can also configure explicit partitioning. With explicit partitioning we can con-
trol and store traversed subgraphs on same node.
We can enable an explicit partition in Titan as follows:
cluster.partition = true
cluster.max-partitions = 16
ids.flush = false
Here
max-partitions
is the maximum number of partitions per cluster. Also
we need to disable flushing IDs as well.
When using Cassandra as the storage backend option, it must be configured with
the
ByteOrderedPartitioner
.
Titan stores vertices and adjoining edges and properties as a collection. This mech-
anism is called
adjacency list format.
With this mechanism, edges connecting to a
vertex and its properties would be stored together in a collocated way. Each row will
contain a vertex ID as a key and adjoining edges and properties as cells. Data repres-
entation in this format is common across all supported databases.
