Unicorn: a simple and flexible abstraction of BigTable-like databases

How would I use this if I have graph data that's described in terms of its edges, not its nodes?

The N-Triples and DOT formats would be examples of graph data that's structured like this: you just list the edges as the pairs of nodes that they connect. The nodes don't necessarily have any properties, they're just implicitly created by edges. I could describe

    a -- b
    b -- c
    b -- d

and nodes "a", "b", "c", and "d" would implicitly exist.

I ask this because the documentation involves programmatically creating nodes, storing them in local variables, and referring to them when building edges:

    gods.addEdge(jupiter, "father", saturn)
    gods.addEdge(jupiter, "lives", sky, json"""{"reason": "loves fresh breezes"}""")

If "jupiter", "saturn", and "sky" weren't previously declared and stored in local variables, how would you do this?

The documentation on the GitHub page is reasonably extensive, but it doesn't even say how to get an existing node without creating it, and certainly doesn't say how to create an edge in an efficient way that is independent of whether its nodes have already been created.

I've also run into a similar problem trying out the new version of OrientDB. They have a fast importer called ETL, but all the documentation for it assumes that you're mostly concerned with importing nodes and you're only using edges to represent SQL-esque relational data. I'm not trying to shove relational data into NoSQL for the sake of NoSQL, I actually have a large graph. Importing serialized graphs into a graph database seems to be a pretty neglected use case.

In most graph database, you find a vertex by filtering its properties, e.g. Gremlin graph query language. In Unicorn, you can do the similar with document vertices (it is, a vertex corresponding to a document in another table/collection). This is probably very nature in a business application. However, it is not very useful in your case as your vertices are abstract without any properties.

I guess what you want is some large scale graph analytics, which I suggest Spark GrpahX or other distributed graph computing engine.

Unicorn is designed for property directed multi-graphs.

Not to be a stickler about name collisions, but Facebook wrote a research paper about a graph database called Unicorn back in 2013:

https://people.csail.mit.edu/matei/courses/2015/6.S897/readi...

This appears to be unrelated, which is somewhat unfortunate.

It is true. Unfortunately, the project was started several years ago and had nothing to do with the startup world. I would like to complain that VCs destroy another nice name with their hypes :(

Search engines will just need to take context into account, I remember a lot of confusion between searches for Cisco IOS versus Apple IOS back when IOS first took on the name, but with a few keywords to provide context, now it's pretty easy to get relevant results.