Gotchas and Limitations
This section presents a list of outstanding issues and likely problems that users should be aware of. A design limitation denotes a limitation that is inherent to the foundation of Faunus and as such, is not something that will not be rectified in future release. On the contrary, temporary limitations are incurred by the current implementation and future versions should provide solutions.
Faunus is built atop Hadoop. Hadoop is not a real-time processing framework. All Hadoop jobs require a costly setup (even for small input data) that takes around 15 seconds to initiate.
There is no easy way to serialize a Groovy closure and thus, propagate to the Hadoop jobs running on different machines. As such, until a solution is found, a closure must be provided as a String. For example: filter('{it.degree > 10}') instead of filter{it.degree > 10}.
A single vertex must be able to fit within the -Xmx upper bound of memory. As such, this means that a graph with a vertex with 10s of millions of edges might not fit within a reasonable machine. In the future, “vertex splitting” or streaming is a potential solution to this problem.
The current implementation of the GraphSON InputFormat is excessively inefficient. As it stands the full String representation of vertex is held in memory, then its JSON Map representation, and finally its FaunusVertex representation. This can be fixed with a smarter, streaming parser in the future.
Titan and Rexster can only be the source of graph data, not the sink of graph data. A near future release will provide OutputFormats to support writing to Titan and Rexster.
The Gremlin implementation that is currently distributed with Faunus is not identical to Gremlin/Pipes. Besides not all steps being implemented, the general rule is that once “the graph is left” (e.g. traverse to data that is not vertices or edges), then the traversal ends. This ending is represented as a pipeline lock in the Gremlin/Faunus compiler.