5 ms·

Does anybody here have a 'canonical' application or example in mind that shows me what neo4j can do that matches my intuitive understanding better than the 'reg

by fxfan 8y ago

Does anybody here have a 'canonical' application or example in mind that shows me what neo4j can do that matches my intuitive understanding better than the 'regular' RDBMS?

nisa 8y ago
I'm new into this "knowledge" space - but I've stumbled upon structr.com - It's open source - you can use this as an extremly flexible content management system for buisness processes and stuff like that - check out their website - however can't tell you much more it's on my todo list.
JJzD 8y ago
RDBMS are developed with joins in mind, but also die of the complexity involved resulting from these joins (both from developer perspective, as well resources.) Now imagine your join to become a primary perspective to look at your data. Then you'd see creditcard transactions (who buys what when?) or maps are better represented as a graph. I know for example TomTom uses neo4j to validate map edits in production.
joelschw 8y ago
Say you have transactions which follow a complex supply chain... Sure you can reconstruct the path taken using recursive SQL, but you're also joining lots and lots of things together at runtime. In a graph database, you've effectively taken your 'join' penalty at the point of ingestion and you have an expressive query syntax to describe the pattern you're trying to match.
stergios 8y ago
This may not be a canonical application of a data model, but expressing graph queries using "Cypher", the graph query language invented by Neo4j, is very intuitive to my mind. I find the use of ASCII art to help visualize the relationships welcome. For example, say we have a graph of movies, actors, reviewers, producers, etc. Here's Cypher query that returns the names of people who reviewed movies and the actors in these movies MATCH (r:Person)-[rev:REVIEWED]->(m:Movie)<-[:ACTED_IN]-(a:Person) RETURN DISTINCT r.name AS Reviewer, m.title AS Title, m.released AS Year, rev.rating AS Rating, collect(a.name) AS Actors Another example: You want to know what actors acted in movies in the decade starting with the year 1990 MATCH (p:Person)-[:ACTED_IN]->(m:Movie) WHERE 1990 <= m.released <= 1999 RETURN m.released, collect(m.title) as titles, collect(p.name) as actors ORDER BY m.released
lmeyerov 8y ago
That can be non-obvious, so fair. We (graphistry) get pulled into a lot of investigative scenarios -- account takeover (web logs), malware/phishing analysis (host/network logs & feeds), AML, claims fraud, etc. I found the problems being solved to be some combination of: awkward to express with SQL, too slow to run in a RDBMS, or hard to visually explore relationships/correlations. Examples: === Shortest Paths 1a. Referral: "Who on our team connected to which leadership at Apple?" (target:Company[name="Apple"])<-[_:Leadership]--(champion)--[]-->(us:Company[name="myCompany"]) 1b. Supply Chain, AML, entanglements...: "How are these companies related, even if 5 companies away, and across all sorts of relationship types?" (a:Company[name="a16z"])-[r:1..3]-(b:Company[name="juicero"]) === Neighborhood (incl. multi-hop): 2a: 360 context on a security/fraud/ops incident: (hacked:Computer[ip="10.10.0.0"])-[e:Alert]-(metadata:) + (hacked:Computer[ip="10.10.0.0"])-[Login]->(u:User)-[e:Alert]-(metadata:) 2b: fraud rings: (fraudster:clientIP)-[login:http]-(b:Fingerprint) + (fraudster:clientIP)-[x:http[method="POST"]]-(p:Page) 2c: Journeys (customer, patient, ...) (a:Patient[id=123]-[e:1..2]->(b:) === Whole system optimization / compute: Personalized pagerank, supplychain optimization, business process mining, ... === The above can be extended, such as by adding in compute (correlation, influence scores, ...). That feds into viz / recommendations / decision making. or: Not all uses of graph are end-to-end. We often get used with a graph db to improve understanding it (our viz scale 100-1000X over the tools here via GPUs)... but folks may instead plug their graphdb into a tabular frontend. Or use us with a tabular system like Splunk/Spark/Elastic. So the above can be hard to write in Splunk/SQL, or slow to run, or hard to visually understand.

by fxfan 8y ago

Does anybody here have a 'canonical' application or example in mind that shows me what neo4j can do that matches my intuitive understanding better than the 'regular' RDBMS?

nisa 8y ago

I'm new into this "knowledge" space - but I've stumbled upon structr.com - It's open source - you can use this as an extremly flexible content management system for buisness processes and stuff like that - check out their website - however can't tell you much more it's on my todo list.

JJzD 8y ago

RDBMS are developed with joins in mind, but also die of the complexity involved resulting from these joins (both from developer perspective, as well resources.) Now imagine your join to become a primary perspective to look at your data. Then you'd see creditcard transactions (who buys what when?) or maps are better represented as a graph. I know for example TomTom uses neo4j to validate map edits in production.

joelschw 8y ago

Say you have transactions which follow a complex supply chain... Sure you can reconstruct the path taken using recursive SQL, but you're also joining lots and lots of things together at runtime. In a graph database, you've effectively taken your 'join' penalty at the point of ingestion and you have an expressive query syntax to describe the pattern you're trying to match.

stergios 8y ago

This may not be a canonical application of a data model, but expressing graph queries using "Cypher", the graph query language invented by Neo4j, is very intuitive to my mind. I find the use of ASCII art to help visualize the relationships welcome. For example, say we have a graph of movies, actors, reviewers, producers, etc. Here's Cypher query that returns the names of people who reviewed movies and the actors in these movies MATCH (r:Person)-[rev:REVIEWED]->(m:Movie)<-[:ACTED_IN]-(a:Person) RETURN DISTINCT r.name AS Reviewer, m.title AS Title, m.released AS Year, rev.rating AS Rating, collect(a.name) AS Actors Another example: You want to know what actors acted in movies in the decade starting with the year 1990 MATCH (p:Person)-[:ACTED_IN]->(m:Movie) WHERE 1990 <= m.released <= 1999 RETURN m.released, collect(m.title) as titles, collect(p.name) as actors ORDER BY m.released

lmeyerov 8y ago

That can be non-obvious, so fair. We (graphistry) get pulled into a lot of investigative scenarios -- account takeover (web logs), malware/phishing analysis (host/network logs & feeds), AML, claims fraud, etc. I found the problems being solved to be some combination of: awkward to express with SQL, too slow to run in a RDBMS, or hard to visually explore relationships/correlations. Examples: === Shortest Paths 1a. Referral: "Who on our team connected to which leadership at Apple?" (target:Company[name="Apple"])<-[_:Leadership]--(champion)--[]-->(us:Company[name="myCompany"]) 1b. Supply Chain, AML, entanglements...: "How are these companies related, even if 5 companies away, and across all sorts of relationship types?" (a:Company[name="a16z"])-[r:1..3]-(b:Company[name="juicero"]) === Neighborhood (incl. multi-hop): 2a: 360 context on a security/fraud/ops incident: (hacked:Computer[ip="10.10.0.0"])-[e:Alert]-(metadata:) + (hacked:Computer[ip="10.10.0.0"])-[Login]->(u:User)-[e:Alert]-(metadata:) 2b: fraud rings: (fraudster:clientIP)-[login:http]-(b:Fingerprint) + (fraudster:clientIP)-[x:http[method="POST"]]-(p:Page) 2c: Journeys (customer, patient, ...) (a:Patient[id=123]-[e:1..2]->(b:) === Whole system optimization / compute: Personalized pagerank, supplychain optimization, business process mining, ... === The above can be extended, such as by adding in compute (correlation, influence scores, ...). That feds into viz / recommendations / decision making. or: Not all uses of graph are end-to-end. We often get used with a graph db to improve understanding it (our viz scale 100-1000X over the tools here via GPUs)... but folks may instead plug their graphdb into a tabular frontend. Or use us with a tabular system like Splunk/Spark/Elastic. So the above can be hard to write in Splunk/SQL, or slow to run, or hard to visually understand.