SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Graphing Performance


Graphing Performance

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)

Group: Administrators
Points: 224284 Visits: 19634
Comments posted to this topic are about the item Graphing Performance

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Dave Poole
Dave Poole
SSC-Insane
SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)

Group: General Forum Members
Points: 24236 Visits: 3491
I saw recently a paper comparing the performance of Postgres, MySql, Oracle and SQL Server. As loads got more complex so the difference in performance between the proprietary and the open source became astounding. That shouldn't surprise us. The resources and time dedicated to the query engines of both Oracle & SQL Server are immense. The problems that RDBMS' have had to solve remain intractably complex.
That graph DBs, particularly distributed graphs like Titan/Aurelius are slower than expected should not surprise us for the same reason. Oracle's approach to Graph DBs appears to be to implement graph algorithms over the top of an Oracle DB.
Personally I have enjoyed playing with Neo4J. I particularly like the Cypher query language. It shares many syntax constructs with SQL while adding relatively straightforward graph extensions. SQL Server 2017 seems to have recognised Cypher and implemented something with a high degree of similarity.
I have no doubt that we could write SQL queries that produce the desired results that a graph database has been designed to produce. However such queries are non-trivial in SQL while straightforward in Cypher. A graph database may satisfy the performance criteria while offering a simpler and more easily understood implementation. RDBMS may offer performance far beyond the use case but require top notch SQL skills and associated cost to maintain and develop

LinkedIn Profile
www.simple-talk.com
Steve Jones
Steve Jones
SSC Guru
SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)

Group: Administrators
Points: 224284 Visits: 19634
Fair points, David. Certainly simpler coding might be a benefit that makes sense for the development side, even if performance were similar (or worse).

I thought SQL 2017 had Gremlin, not Cypherm, as the query language.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Dave Poole
Dave Poole
SSC-Insane
SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)

Group: General Forum Members
Points: 24236 Visits: 3491
There are similarities between Gremlin and Cypher. I'm not confident to say one way or the other but have noticed the pictorial style of the MATCH statement looks just like Cypher.
Gremlin is an Apache foundation language and I'm not sure what that would mean for licencing within a closed source product.
I really think SQL Server DBA's are going to love the graph syntax. It solves some really interesting problems

LinkedIn Profile
www.simple-talk.com
Bill Talada
Bill Talada
SSCarpal Tunnel
SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)

Group: General Forum Members
Points: 4644 Visits: 2224
The article referenced in Steve's writing is completely biased and unfair in my opinion. Graph databases are for graph data but the data used in the study was simple two level relational data. Graphs become exponentially more beneficial when finding routes of four or more hops.
Steve Jones
Steve Jones
SSC Guru
SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)

Group: Administrators
Points: 224284 Visits: 19634
Bill Talada - Monday, August 28, 2017 11:23 AM
The article referenced in Steve's writing is completely biased and unfair in my opinion. Graph databases are for graph data but the data used in the study was simple two level relational data. Graphs become exponentially more beneficial when finding routes of four or more hops.


They used the benchmark for graphing data. Perhaps that's not fair, but I think it's a fair tests of one aspect of the platforms.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Dave Poole
Dave Poole
SSC-Insane
SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)

Group: General Forum Members
Points: 24236 Visits: 3491
When I was experimenting with Neo4J I found that consistent performance was a strength. A 4 hop query seems to take the same amount of time regardless of data volumes

LinkedIn Profile
www.simple-talk.com
Eric M Russell
Eric M Russell
SSC-Forever
SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)

Group: General Forum Members
Points: 43413 Visits: 12036
It seems to me that NoSQL database engines rely more heavily on just-in-time record parsing and computation, spreading an order of magnitude more reads across multiple nodes rather than relying on indexes or predefined schema. That makes database design more flexible, not necessarily more performant. The thing about old-school relational B-tree indexes is that they are powerful things; they can pack a lot of structured information in a relatively small amount of space, and when a single covering index is optimized to facilitate a specific problem domain, it's hard to beat. Likewise, flat de-normalized ColumnStore tables can compress data by 90% and facilitate a broad range of queries very efficiently. Likewise again for OLAP databases like SQL Server Analysis Services; for specific types of analytical processing it can't be beat.


"The universe is complicated and for the most part beyond your control, but your life is only as complicated as you choose it to be."
Dave Poole
Dave Poole
SSC-Insane
SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)

Group: General Forum Members
Points: 24236 Visits: 3491
The thing with NOSQL is that it is not a single thing, it's a massive range of things. Each one is intended to solve a particular problem. The trick is to understand which problem they are designed to solve and then do an honest assessment of
a. Do you have the problem
b. Is the problem big enough to be worth solving
C. Will solving it cause much bigger problems elsewhere (most likely with integration)

In the analytics world ORC & Parquet formats are becoming more prevalent. These use column store techniques to achieve acceptable performance. Parquet allows nested structures in the same way that Postgres has an array data type.
The question I have is at what point do the facilities in SQL Server fall into the NOSQL camp? MDX? Full-Text search? XML? JSON?

LinkedIn Profile
www.simple-talk.com
Steve Jones
Steve Jones
SSC Guru
SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)

Group: Administrators
Points: 224284 Visits: 19634
Well, keep in mind that NoSQL has meant "Not-Only-SQL" for some, and "Not (relational) SQL" for others.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search