Table of Contents
There are various limitations and "gotchas" that one should be aware of when using Titan. Some of these limitations are necessary design choices and others are issues that will be rectified as Titan development continues. Finally, the last section provides solutions to common issues.
These limitations reflect long-term tradeoffs design tradeoffs which are either difficult or impractical to change. These limitations are unlikely to be removed in the near future.
Titan can store up to a quintillion edges (2^60) and half as many vertices. That limitation is imposed by Titan’s id scheme.
When declaring the data type of a property key using
dataType(Class) Titan will enforce that all properties for that key have the declared type, unless that type is
Object.class. This is an equality type check, meaning that sub-classes will not be allowed. For instance, one cannot declare the data type to be
Number.class and use
Long. For efficiency reasons, the type needs to match exactly. Hence, use
Object.class as the data type for type flexibility. In all other cases, declare the actual data type to benefit from increased performance and type safety.
Retrieving an edge by id, e.g
tx.getEdge(edge.getId()), is not a constant time operation because it requires an index call on one of its adjacent vertices. Hence, the cost of retrieving an individual edge by its id is
k is the number of incident edges on the adjacent vertex. Titan will attempt to pick the adjacent vertex with the smaller degree.
This also applies to index retrievals for edges via a standard or external index.
These are limitations in Titan’s current implementation. These limitations could reasonably be removed in upcoming versions of Titan.
Mixed indexes only support a subset of the data types that Titan supports. See Mixed Index Data Types for a current listing. Also, mixed indexes do not currently support property keys with SET or LIST cardinality.
Titan provides a batch loading mode that can be enabled through the graph configuration. However, this batch mode only facilitates faster loading into the storage backend, it does not use storage backend specific batch loading techniques that prepare the data in memory for disk storage. As such, batch loading in Titan is currently slower than batch loading modes provided by single machine databases. Chapter 28, Bulk Loading contains information on speeding up batch loading in Titan.
Another limitation related to batch loading is the failure to load millions of edges into a single vertex at once or in a short time of period. Such supernode loading can fail for some storage backends. This limitation also applies to dense index entries. For more information, please refer to Issue #11.