Introduction to Graph Databases
Why Stack Overflow recommends it
Stack Overflow users link it when answering questions about graph databases and NoSQL scaling, as a general introduction and for its chart comparing horizontal scalability across database types.
Recommended by 1 people across 1 different months, 2012 to 2013.
What it is
A roughly hour-long conference-style talk by Neo Technology CEO Emil Eifrem giving a fast-paced introduction to NoSQL, graph databases, and Neo4j. It covers the NoSQL landscape and how graph models differ from key-value, column and document stores.
What people said
Recommends Edmon · 2012-08 · Stack Overflow · on “Tutorial on Graph Theory”
My recommendations: Introductory - JMT Patrick: [LINK] Moderately difficult lectures - ADUni and Berkeley: [LINK] [LINK] Advanced stuff - MIT: [LINK] As a bonus, great presentation from Neo CEO: [this video]
Cites TizianoPiccardi · 2013-03 · Stack Overflow · on “Representation of Database as a Network”
If you are free to choose the database engine you want, graph databases are the best solution. You can find a quite complete list in Wikipedia here: [LINK] Take a look also at this video: [this video] I had good experience with Neo4J ( [LINK] ). It is written in Java but provides bindings for a lot of languages (in JMV languages can run in embedded mode). You can use it also via REST interface. The language to query the graph is Cypher ( [LINK] ) that is not so different from SQL. However one key point to consider in your evaluation is the size of your graph. The ability to model so complex data has as main drawback the difficulty to scale efficiently on multiple machines (partition a graph is an
Cites Sridhar Sarnobat · 2013-10 · Stack Overflow · on “Who do large key-value stores scale better horizontally than document databases?”
In this presentation there was a chart that showed the following horizontal scalability ceiling as data gets larger: key-value > column family > document database > graph database [this video] In other words, as data gets more connected (i.e. complex) the limit on which you can let the database grow gets lower. Why is data size not as scalable for document databases compared to key-value stores ? Have I answered my own question by saying "the more freedom in connecting data, the harder it is to partition data"? ( The "what I'm trying to do" part which everyone usually asks: I have a database with a schema that is MOSTLY tree-like but occasionally has nodes with 2 parents. I used Neo4j in my proto