Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Database Types

prisma.io

Post reply on HN
Print view View original

21–30 of 176 posts

Re: Comparing Database Types

#21

Post by Nican »

I am really tired of articles that talk about the different types of databases. People can make a graph databases act like relational databases, and vice-versa. Computers, in the end, are just a Turing machine. Just pay attention that the query that you are executing is actually doing the optimal solution.

I wish more time would be spent talking about the underlying algorithms that the different query languages use to accomplish the tasks. It is important for developers to understand the execution complexity of queries, and how data is distributed across a cluster.

For example, I am usually surprised when people talk about "web-scale", but they do not understand the difference between a "merge-join" and a "hash-join". Or when people do not realize that a sort requires the whole result set to be materialized and sorted.

Re: Comparing Database Types

#22

Post by danenania »

namelosw wrote: post #15
danenania wrote: post #10

Earlier quoted context omitted.

“It should be emphasized that graph databases can do all other types of databases (relational, document, key/value, etc.)” Not to knock graph dbs, but isn’t the reverse also true?

Some databases design like extremely simple key-value databases cannot efficiently express joining relation unless load all the data in memory. The same could be said for column based databases etc. I guess that's quite a difference.

"key-value databases cannot efficiently express joining relation unless load all the data in memory"

With the right design can't you store the graph data across multiple keys and then load pieces of it selectively into memory? I get that a graph db specializes in this pattern and makes it more efficient, easier to query, etc., but that doesn't mean it's the only type of db that can model a graph.

Re: Comparing Database Types

#23

Post by tabtab »

I'd like to see "dynamic relational" implemented. It's conceptually very similar to existing RDBMS and can use SQL (with some minor variations for comparing more explicitly). You don't have to throw away your RDBMS experience and start over.

And you can incrementally "lock it down" so that you get RDBMS-like protections when projects mature. For example, you may add required-field constraints (non-blank) and type constraints (must be parsable as a number, for instance). Thus, it's good for prototyping and gradually migrating to production. It may not be as fast as an RDBMS for large datasets, though. But that's often the price for dynamicness. (A fancy version could allow migrating or integrating tables to/with a static system, but let's walk before we run.)

https://stackoverflow.com/questions/66385/dynamic-database-s...

Some smaller university out there can make a name for themselves by implementing it. I've been kicking around doing it myself, but I'd have to retire first.

Re: Comparing Database Types

#24

Post by bryanlarsen »

The description of flat-file database seems too restrictive. In my experience, flat files with fixed record lengths and no delimiters were far more common than variable-length delimited formats like CSV. File sizes were often much larger than computer memory size, so random read & write was necessary.

Re: Comparing Database Types

#25

Post by danenania »

lmkg wrote: post #19
danenania wrote: post #10

Earlier quoted context omitted.

“It should be emphasized that graph databases can do all other types of databases (relational, document, key/value, etc.)” Not to knock graph dbs, but isn’t the reverse also true?

One of the key features of graph databases is to select one node, and then recursively 'chase' edges until you find another node matching some criteria. Other database models can have trouble representing chasing an unbounded number of edges. E.g. in the relational model, following an edge to another node is usually represented as a Join operation, and SQL doesn't let you parameterize the number of iterated joins. Th…

It seem similar to the SQL vs. NoSQL dichotomy in that it's a question of general ad hoc queries vs. predetermined queries. SQL lets you query anything with or without an index, but you pay for this flexibility with limits on performance and scalability.

In the case of graphs, if you know the exact shape of your graph and its query patterns ahead of time, you can design the optimal structure in a KV/NoSQL store. But if you need/want the flexibility to do ad hoc queries of the graph in a reasonably performant way, that's where the graph db shines.

Re: Comparing Database Types

#26

Post by mumblemumble »

danenania wrote: post #10
marknadal wrote: post #8

What a lovely article! It should be emphasized that graph databases can do all other types of databases (relational, document, key/value, etc.) as you can see demonstrated in this article ( https://gun.eco/docs/Graph-Guide ). This makes graphs a superior data structure. If you think about the math, any document is a trie, and tables are a matrix. Both trees and matrices can be represented as graphs. But not all graph…

“It should be emphasized that graph databases can do all other types of databases (relational, document, key/value, etc.)” Not to knock graph dbs, but isn’t the reverse also true?

Yes. And it may even be the best way to do it. For example, here's a paper where the authors come up with a schema and transpiler for doing a Gremlin-queryable graph DB in PostgreSQL, and find that it outperforms Neo4j and Titan:

https://static.googleusercontent.com/media/research.google.c...

Re: Comparing Database Types

#27

Post by gibsonf1 »

The discussion of graph dbs completely misses the semantic rdf graph approach and how that differs greatly from the property graph (which is discussed). So important is not having to have a custom schema for each application that does not communicate with any other app as opposed to using standard ontologies with relationships and classes that are known and allow interoperability between systems (Linked Data Platform - Solid)

Re: Comparing Database Types

#28

Post by asah »

tabtab wrote: post #23

I'd like to see "dynamic relational" implemented. It's conceptually very similar to existing RDBMS and can use SQL (with some minor variations for comparing more explicitly). You don't have to throw away your RDBMS experience and start over. And you can incrementally "lock it down" so that you get RDBMS-like protections when projects mature. For example, you may add required-field constraints (non-blank) and type con…

I've done this (commercially!) with PostgreSQL - just start with a single table, with one JSON field, and as you want performance, integrity, etc, add expression indexes, break out frequently used expressions into columns etc. On large tables, obviously there's a cost for this reorganization but you can partition the data first, and only reorg the most recent data (e.g. range partitioning by time).

https://www.google.com/search?q=expression+index+postgres

https://www.postgresql.org/docs/10/ddl-partitioning.html

Re: Comparing Database Types

#29

Post by shostack »

Nican wrote: post #21

I am really tired of articles that talk about the different types of databases. People can make a graph databases act like relational databases, and vice-versa. Computers, in the end, are just a Turing machine. Just pay attention that the query that you are executing is actually doing the optimal solution. I wish more time would be spent talking about the underlying algorithms that the different query languages use t…

Do you have any articles you'd suggest that in your opinion cover the appropriate underlying guts of them?
Post reply on HN