Chapter 14. Technical Limitations

titan-head

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.

14.1. Design Limitations

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.

14.1.1. Size Limitation

Titan can store up to a quintillion edges (2^60) and half as many vertices. That limitation is imposed by Titan’s id scheme.

14.1.2. DataType Definitions

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 Integer or 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.

14.1.3. Edge Retrievals are O(log(k))

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 O(log(k)) where 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.

14.1.4. Type Definitions cannot be changed

The definition of an edge label, property key, or vertex label cannot be changed once it has been committed to the graph. However, a type can be renamed and new types can be created at runtime to accommodate an evolving schema.

14.2. Temporary Limitations

These are limitations in Titan’s current implementation. These limitations could reasonably be removed in upcoming versions of Titan.

14.2.1. Limited Mixed Index Support

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.

14.2.2. Batch Loading Speed

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 29, 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.