12:30 what they are good at 14:39 Neo4j use cases 15:13 real time recommendation 18:33 master data management 18:53 concept: MDM is the process of binding an 19:00 ambiguous copy or the structure of a record in an organization 24:06 graph based search 26:54 Identity and Access Management 27:57 UBS
Structuring your data as a graph has the advantage of the ability to apply weights to the edges (dynamic), as well as values to the nodes (static), to permit designing a rich stochastic model. It's simply another way of viewing the data. It does not invalidate using relational databases. Different tools for different jobs. I like this.
We certainly agree that there is still value for relational databases for tabular data. For data with a lot of relationships, storing it in a native graph database allows you to query those relationships much faster-- traversing across relationships is done via pointer arithmetic VS doing index lookups as you'd do on JOINs in SQL databases. The difference in performance is very large when doing many JOINs in the same query vs doing it in a graph.
4:38 why What is graph database 7:25 graph database 7:30 good for: dynamic systems where data topology is difficult to predict 8:35 graph properties 9:21 label
Hello Just a suggestion: The 'Typical Complex SQL Join' is a sad example for getting hierarchical data from RDBMS. I work with Oracle and SQL Server and I do have to write hierarchical queries. And honestly speaking, it is not really that hard to write SQL queries for these kinds of requirements given that both of them support their own extensions for handling hierarchical kind of data. But I do agree that Cypher is more elegant when it comes to expressing what you are trying to get. Anyway, thanks for the explanation, even though it seems to me more targeted for the non technical people. It worries me sometimes that marketing makes people in the management think that they know more than the 'ordinary programming folks' and make our slightly more harder. Anyway, you guys have a great product and I am going through all the free ebooks provided by you to learn Neo4j for my next microservices project!
Thanks for challenging Neo4j for hierarchical data. The reason why graph database is better than Oracle/SQL server at hierarchical, network, self referencing data is due to the simplicity with which you can extract it. We had run a test of same data in oracle vs neo4j for 1 M records spread across tables. Oracle query was 1 page long (written by a well known programmer) and neo4j query was 3 lines (if you can call that). Additionally, Oracle took 3.25 sec and neo4j took 0.274 sec for the same data and to top it, it also showed the data in a visual format.
How can i use neo4j for word2vec and solr/elasticsearch, that would be so nice if you can give me a hint or something like this. Thx for the presantation it is very great.
Visualization UIs are very important when dealing with graph databases. Can anyone recommend some UI solution for embedded neo4j? Could I use somehow the same ui that we would use with the non-embedded version? If not this, any other that can "talk" to my server and display/manipulate the graph? Thanks in advance!
The example at 34:40 is bizarre. The code in Cipher has "magic" numbers like "3" which are not mentioned in problem statement. And your SQL code looks immature. As a result, the comparison appears unfair and manipulative. Also, for deep hierarchies of management your cipher code probably would produce results grouped by all levels of management rather than just the first level.
Thanks for your comment. The actual SQL query was provided by a customer and goes on for another page. Agreed that one could produce a more optimized SQL query, but queries like you see there are actually being used by real companies today. The numbers you mentioned indicate the number of degrees to go down the organizational hierarchy - which are represented in the SQL query by the number of UNION statements present--- one union for each "degree."
Thank you. OK. But surely it is just a sign that the person is not familiar with SQL? For example, PostgreSQL is perhaps not the brightest implementation but as you can see on www.postgresql.org/docs/8.4/static/queries-with.html it supports recursive queries and in fact the page feature queries for graph-like structures. And it is not a new feature. PostgreSQL 8.4 was released back in 2009. But a more interesting aspect is why does the query in Cipher mentions magic numbers. Frankly, that looks like a bug.
Re recursive queries, it's a fair point-- though I'm not familiar with when this query was written by the customer, so it may have not been an option at the time. On the 'magic numbers' in the Cypher query, they represent the number of degrees that you want to perform the query. The query could have used '*' alone to go infinite levels deep, but then it wouldn't have been an analogous query to the SQL query, which restricted the depth of the traversal based on the number of UNION statements.
It's a good video but the the the euh the the the speaker has a rather annoying rather rather rather rather rather anoying habbit of repeating short words in the euh the the the the the the middel of a sentence which makes it very a very a very a very difficult , a very very a very very hard, to follow.
The dude quickly just resorts to rambling about big companies that use the product without going into any detail at all as to how they use the features of this product or why a property graph allows them to get results more efficiently than a relational database.
thanks for the feedback. let us know if there are particular topics you'd like to understand better and happy to guide you to content you may find more meaningful.
12:30 what they are good at
14:39 Neo4j use cases
15:13 real time recommendation
18:33 master data management
18:53 concept: MDM is the process of binding an 19:00 ambiguous copy or the structure of a record in an organization
24:06 graph based search
26:54 Identity and Access Management
27:57 UBS
thanks!
xie xie!
Wish I saw this before I watched the vid!
thank you for your time
Structuring your data as a graph has the advantage of the ability to apply weights to the edges (dynamic), as well as values to the nodes (static), to permit designing a rich stochastic model. It's simply another way of viewing the data. It does not invalidate using relational databases. Different tools for different jobs.
I like this.
We certainly agree that there is still value for relational databases for tabular data.
For data with a lot of relationships, storing it in a native graph database allows you to query those relationships much faster-- traversing across relationships is done via pointer arithmetic VS doing index lookups as you'd do on JOINs in SQL databases. The difference in performance is very large when doing many JOINs in the same query vs doing it in a graph.
4:38 why
What is graph database
7:25 graph database
7:30 good for: dynamic systems where data topology is difficult to predict
8:35 graph properties
9:21 label
The use case section of this presentation is very helpful.
Hello
Just a suggestion: The 'Typical Complex SQL Join' is a sad example for getting hierarchical data from RDBMS. I work with Oracle and SQL Server and I do have to write hierarchical queries. And honestly speaking, it is not really that hard to write SQL queries for these kinds of requirements given that both of them support their own extensions for handling hierarchical kind of data. But I do agree that Cypher is more elegant when it comes to expressing what you are trying to get.
Anyway, thanks for the explanation, even though it seems to me more targeted for the non technical people. It worries me sometimes that marketing makes people in the management think that they know more than the 'ordinary programming folks' and make our slightly more harder.
Anyway, you guys have a great product and I am going through all the free ebooks provided by you to learn Neo4j for my next microservices project!
Thanks for challenging Neo4j for hierarchical data. The reason why graph database is better than Oracle/SQL server at hierarchical, network, self referencing data is due to the simplicity with which you can extract it. We had run a test of same data in oracle vs neo4j for 1 M records spread across tables. Oracle query was 1 page long (written by a well known programmer) and neo4j query was 3 lines (if you can call that). Additionally, Oracle took 3.25 sec and neo4j took 0.274 sec for the same data and to top it, it also showed the data in a visual format.
Did you implement ?
How can i use neo4j for word2vec and solr/elasticsearch, that would be so nice if you can give me a hint or something like this. Thx for the presantation it is very great.
Great stuff on Neo4j. I enjoyed the session.
Visualization UIs are very important when dealing with graph databases. Can anyone recommend some UI solution for embedded neo4j? Could I use somehow the same ui that we would use with the non-embedded version? If not this, any other that can "talk" to my server and display/manipulate the graph? Thanks in advance!
The example at 34:40 is bizarre. The code in Cipher has "magic" numbers like "3" which are not mentioned in problem statement. And your SQL code looks immature. As a result, the comparison appears unfair and manipulative. Also, for deep hierarchies of management your cipher code probably would produce results grouped by all levels of management rather than just the first level.
Thanks for your comment.
The actual SQL query was provided by a customer and goes on for another page. Agreed that one could produce a more optimized SQL query, but queries like you see there are actually being used by real companies today.
The numbers you mentioned indicate the number of degrees to go down the organizational hierarchy - which are represented in the SQL query by the number of UNION statements present--- one union for each "degree."
Thank you.
OK. But surely it is just a sign that the person is not familiar with SQL?
For example, PostgreSQL is perhaps not the brightest implementation but as you can see on www.postgresql.org/docs/8.4/static/queries-with.html it supports recursive queries and in fact the page feature queries for graph-like structures. And it is not a new feature. PostgreSQL 8.4 was released back in 2009.
But a more interesting aspect is why does the query in Cipher mentions magic numbers. Frankly, that looks like a bug.
Re recursive queries, it's a fair point-- though I'm not familiar with when this query was written by the customer, so it may have not been an option at the time.
On the 'magic numbers' in the Cypher query, they represent the number of degrees that you want to perform the query. The query could have used '*' alone to go infinite levels deep, but then it wouldn't have been an analogous query to the SQL query, which restricted the depth of the traversal based on the number of UNION statements.
I see. Then it makes sense.
Thank you very much.
rtvdenys surely. thanks for your feedback
Hi! How neo4j can be leveraged to visualize the relationships in data governance? including the classifications like data retention cycle and privacy
where can we find the presentation?
Just wondering if Neo4j suits well for workflow kind of systems? Is this a use case that Neo4j suit well?
Did you implement neo4j ?
8:40 concepts
14:38 use cases
Neo4j applications in terms of real life usage?
Great video for fresh. Thanks
It's a good video but the the the euh the the the speaker has a rather annoying rather rather rather rather rather anoying habbit of repeating short words in the euh the the the the the the middel of a sentence which makes it very a very a very a very difficult , a very very a very very hard, to follow.
All the recommendations I get from website are really bad, makes no sense at all!
Presentation would be half as long without the stammering and the "uh uh uh"s
"Trillions, Quadrillions" right at the end there, you guys should just cut that out, it's embarrassing.
The dude quickly just resorts to rambling about big companies that use the product without going into any detail at all as to how they use the features of this product or why a property graph allows them to get results more efficiently than a relational database.
soporific
So many words, so little meaning 😒
thanks for the feedback. let us know if there are particular topics you'd like to understand better and happy to guide you to content you may find more meaningful.