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

151–160 of 176 posts

Re: Comparing Database Types

#151

Post by nailer »

takeda wrote: post #142
nailer wrote: post #38

> Relational vs. Document Tabular vs Document. Having relations is orthogonal to the shape of your data. There are document databases with relations - RethinkDB was pretty popular. Mongo sadly doesn't have them but will probably eventually get them too.

The adjective relational in a relational database comes from mathematical relations, tuples i.e. data in tables. It's common misconception that it is from foreign keys.

That's interesting - it seems to both be backed by and conflict with a lot of https://en.wikipedia.org/wiki/Relational_model but maybe that's wrong.

I'd still avoid the word 'relational' though - obvious many people will assume 'relational' is related to DB relations rather than tuples (assuming you're right about 'relations' meaning tuples, a lot of the wikipedia contributors are included).

Re: Comparing Database Types

#152

Post by nicoburns »

kthejoker2 wrote: post #127
einpoklum wrote: post #112

The document completely overlooks Columnar databases, which are focused on analytics and are much faster than (most, not all) general-purpose DBMSes. See: https://en.wikipedia.org/wiki/Column-oriented_DBMS and https://www.slideshare.net/arangodb/introduction-to-column-o... or get: http://www.nowpublishers.com/article/Details/DBS-024 Examples: * MonetDB * SAP Hana * Actian Vector (formerly Vectorwise) * Oracle In-Memo…

Also Druid, HBase, Vertipaq (engine behind PowerBI), Redshift, Azure SQL DW, etc Columnar compression is a really interesting engineering problem

Also notable is the Postgres column store extension.

Not as fancy / performant as the dedicated columns store databases, but it allows you mix and match row-tables with column-tables which is pretty nice.

Re: Comparing Database Types

#153

Post by AndrewBowman »

mumblemumble wrote: post #26
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?

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...

That compares against Neo4j 1.9.4, released in 2013. All technologies in question have improved much since then, especially graph db technology, efficiency, and speed, so I don't think that paper has as much relevance anymore. Would love to see a more updated comparison.

Re: Comparing Database Types

#154

Post by takeda »

pas wrote: post #148
zawerf wrote: post #145

Earlier quoted context omitted.

(We're getting way off topic) but I think the problem with auto increment is that it can't be sharded easily since multiple shards can increment to the same value. If you then try to go back to random ids you're now stuck with 8 bytes which will conflict once every billion items or so. I guess it's pretty extreme premature optimization but I think UUID is nicer for future-proofing at the cost of some performance. (I…

In MySQL/MariaDB/Percona InnoDB Galera every writeable replica has an auto increment offset.

Same in postgres[1], and I'm willing to guess every relational database has a way to do it.

[1] https://www.postgresql.org/docs/current/sql-createsequence.h...

Re: Comparing Database Types

#155

Post by takeda »

zawerf wrote: post #145
takeda wrote: post #141

Earlier quoted context omitted.

Just a note about using uuid as a primary key. Typically you will use a b-tree index, which likes to keep things sorted. So something like a serial number works best, because it is already sorted and will be appended at the end. Otherwise inserting a new column will cause traversal the b-tree all over the place which will hurt performance it you do a lot of inserts. If you really want to use uuid and care about perfo…

(We're getting way off topic) but I think the problem with auto increment is that it can't be sharded easily since multiple shards can increment to the same value. If you then try to go back to random ids you're now stuck with 8 bytes which will conflict once every billion items or so. I guess it's pretty extreme premature optimization but I think UUID is nicer for future-proofing at the cost of some performance. (I…

> I would love to see benchmarks to know exactly how much performance I am giving up though

https://www.youtube.com/watch?v=xrMbzHdPLKM

It ends up being a pitch for Aurora at the end (as with any presentation from AWS folks), but it has tons of useful information for standard Postgres.

Re: Comparing Database Types

#156

Post by ithkuil »

pas wrote: post #146
Pheebau wrote: post #69

Earlier quoted context omitted.

A join in an intersection in relational algebra

Isn't a full outer join a Descartes product? And thus any other join is just a special case where rows get selected/projected/filtered out?

The Cross join is a Cartesian product. Good read: https://en.m.wikipedia.org/wiki/Join_(SQL)

Re: Comparing Database Types

#157

Post by gibsonf1 »

planck01 wrote: post #83
gibsonf1 wrote: post #27

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…

Do you know of any successfully semantic RDF graph databases, I guess with OWL support? Because I personally don't. If not, it probably is rightfully too much an academic niche to be discussed in the article.

We are using Blazegraph and Neptune in production as well as Allegrograph. With Neptune, we tested scale by putting the entire dbpedia on one 4 core machine with 16G of ram. It handled 2.7 billion statements without any issues (we ran out of time with the test - sure it can handle more)

Re: Comparing Database Types

#158

Post by cptnapalm »

einpoklum wrote: post #112

The document completely overlooks Columnar databases, which are focused on analytics and are much faster than (most, not all) general-purpose DBMSes. See: https://en.wikipedia.org/wiki/Column-oriented_DBMS and https://www.slideshare.net/arangodb/introduction-to-column-o... or get: http://www.nowpublishers.com/article/Details/DBS-024 Examples: * MonetDB * SAP Hana * Actian Vector (formerly Vectorwise) * Oracle In-Memo…

I know very, very little about any of this, but would this be akin to entity component systems in video games? Forgive me if I'm way off.

Re: Comparing Database Types

#159

Post by einpoklum »

cptnapalm wrote: post #158
einpoklum wrote: post #112

The document completely overlooks Columnar databases, which are focused on analytics and are much faster than (most, not all) general-purpose DBMSes. See: https://en.wikipedia.org/wiki/Column-oriented_DBMS and https://www.slideshare.net/arangodb/introduction-to-column-o... or get: http://www.nowpublishers.com/article/Details/DBS-024 Examples: * MonetDB * SAP Hana * Actian Vector (formerly Vectorwise) * Oracle In-Memo…

I know very, very little about any of this, but would this be akin to entity component systems in video games? Forgive me if I'm way off.

Sorry, I don't know what "entity component systems" are. If you mean saving the same component for all entities, rather than saving a bag of components for each of the entities, then sort of.

Re: Comparing Database Types

#160

Post by einpoklum »

kthejoker2 wrote: post #127
einpoklum wrote: post #112

The document completely overlooks Columnar databases, which are focused on analytics and are much faster than (most, not all) general-purpose DBMSes. See: https://en.wikipedia.org/wiki/Column-oriented_DBMS and https://www.slideshare.net/arangodb/introduction-to-column-o... or get: http://www.nowpublishers.com/article/Details/DBS-024 Examples: * MonetDB * SAP Hana * Actian Vector (formerly Vectorwise) * Oracle In-Memo…

Also Druid, HBase, Vertipaq (engine behind PowerBI), Redshift, Azure SQL DW, etc Columnar compression is a really interesting engineering problem

Yes it is, and I've written academically about this. For example: https://is.gd/9wwjjf
Post reply on HN