TITAN

I've created a graph model for a social network and needed some concrete advice regarding the design in regards to scaling. Pardon the n00bness of these questions but I'm not finding very many clear examples out there... NOTE: the status updates and activity nodes /relationships are linked lists - with the newest entries constantly being placed at the top of the list. Linked lists allow for news feed generation, but there could be hundreds of records per user - I presume the limit clause isn't sufficient even though the data is in descending order by date. Do I have to have a separate linked

I was trying to make a comparison between these two technologies when approaching this and I was wondering if any of you already have some experience dealing with any or both of them? I am mainly interested in performance numbers when dealing with similar use cases. Agreeing with everything Marko said, one could take it further and argue that in the graph database world local indexes can (and even should) substitute global ones. In my opinion, the single greatest advantage of a graph data model is that it lets you encode your data model into the graph topology, gaining qualitative advantages

I'm having my first steps as a TitanDB user. That being, I'd like to know how to make an upsert / conditionally insert a vertex inside a TitanTransaction (in the style of "get or create"). I have a unique index on the vertex/property I want to create/lookup. Here's a one-liner "getOrCreate" for Titan 1.0 and TinkerPop 3: getOrCreate = { id -> g.V().has('userId', id).tryNext().orElseGet{ g.addV('userId', id).next() } } As taken from the new TinkerPop "Getting Started" Tutorial . Here is the same code translated to java: public Vertex getOrCreate(Object id) { return g.V().has('userId', id)

I've noticed that relationships cannot be properly stored in C* due to its 100MB partition limit, denormalization doesn't help in this case and the fact that C* can have 2B cells per partition neither as those 2B cells of just Longs have 16GB ?!?!? Doesn't that cross 100MB partition size limit ? Which is what I don't understand in general, C* proclaims it can have 2B cells but a partition sizes should not cross 100MB ??? What is the idiomatic way to do this? People say that this an ideal use case for TitanDB or JanusDB that scale well with billions of nodes and edges. How do these databases

Is there anyway to query on date in titan/gremlin? e.g. find all results in the last X days Any help would be much appreciated. The best approach is to simply store the date as a Long value and to possibly index upon such a field in an edge such that you could take advantage of limit() , interval , etc. See this Titan wiki page on the topic: https://github.com/thinkaurelius/titan/wiki/Vertex-Centric-Indices It maps to your specific request with a Twitter example where it indexes on time . You could find results based on time by simply calculating milliseconds for "X days" back and then finding

I'm using a framework that generates objects Node and they already have assigned a id. Now they need to be converted to Titan vertices with the same ID controlled in the framework (accessed with node.id ) public long addNode(Node node) { TitanVertex vertex = (TitanVertex) g.addVertex(null); g.commit(); vertex.setProperty(ID, node.id); vertex.setProperty(TYPE, node.type); vertex.setProperty(VERSION, node.version); vertex.setProperty(TIME, node.time); vertex.setProperty(DATA, node.data); ... Error: java.lang.IllegalArgumentException: Name is reserved: id But it seems to not allow it. Should I

In the O'Reilly book "Graph Databases" in chapter 6, which is about how Neo4j stores a graph database it says: To understand why native graph processing is so much more efficient than graphs based on heavy indexing, consider the following. Depending on the implementation, index lookups could be O(log n) in algorithmic complexity versus O(1) for looking up immediate relationships. To traverse a network of m steps, the cost of the indexed approach, at O(m log n), dwarfs the cost of O(m) for an implementation that uses index-free adjacency. It is then explained that Neo4j achieves this constant