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

111–120 of 176 posts

Re: Comparing Database Types

#111

Post by mumblemumble »

gbear0 wrote: post #70
mumblemumble wrote: post #26

Earlier quoted context omitted.

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's interesting, but kinda makes sense since it would be optimizing specific access patterns by translating it to relational models rather than using the normal graph walking algs to find relations. As an anecdote for one project, while trying to speed up some neo4j queries myself, I decided to model a binary tree structure in the nodes (child/parent relations) and then compared the query times for using the simpl…

It's been a while since I read the paper in detail, but, IIRC, it _is_ using normal graph walking algorithms. They're just implemented in SQL.

That it's implemented on top of a relational database seems like a red herring to me. The relational model just defines operations on sets of tuples. A graph is just a particular kind of thing you can construct with sets and tuples.

From there, the query planner and execution engine take over, and an incumbent RDBMS's query planner and execution engine are supported by decades and decades worth of accumulated dark knowledge on how to optimize execution plans and efficiently traverse large datasets in the presence of a hierarchical memory model.

By contrast, Neo4j (to take an example) has a steeper hill to climb. Both in terms of not having had to spend decades trying to compete with Oracle, and in terms of being implemented in a less-than-ideal language for chasing raw performance.

Re: Comparing Database Types

#112

Post by einpoklum »

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

Re: Comparing Database Types

#113

Post by talaketu »

woolcap wrote: post #74
tlarkworthy wrote: post #61

Earlier quoted context omitted.

What is the relation? The table? (I.e. the tuples describing the rows). Or is it the joins? (In which case the article is correct). The columns?

One way to think about it is with a mathematical relation, like 'X > Y'. A relational database relation representing this relation would consist of a header tuple, , and a set of tuples whose values satisfy the relation, such as , , . In more common terms, the rows of this table would contain pairs of numbers in which the value of the X attribute is greater than the value of the Y attribute. This table describes the…

This points to the dual view of a relation - intensional vs extensional. The beauty of the relational model of data is the morphism: by evaluating relational operations on the extensional model (data) we gain can answer questions corresponding to intensional model (concept).

For example given the extensional data ALBUM(TITLE, ARTIST) corresponding to the intention "the albums, each with a title and artist", we can compute "the eponymous albums, each with a title" via EPONYMOUS_ALBUM = ALBUM where (TITLE = ARTIST)

We started with some data for a relation corresponding with a concept, and were able to operate on the data to produce a new relation - data corresponding to a new concept.

Re: Comparing Database Types

#114

Post by AtlasBarfed »

_Understated_ wrote: post #3

I'm curious... what did the author mean by this: > Legacy database types represent milestones on the path to modern databases. These may still find a foothold in certain specialized environments, but have mostly been replaced by more robust alternatives for production environments. I didn't notice anything that went into any detail about legacy database types. Any idea what the author means by a "Legacy Database"?

Mainframe days

Re: Comparing Database Types

#116

Post by zawerf »

asah wrote: post #28
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…

I am trying this out and I am still on the edge of whether I like it or not.

Create a table with a json column:

  CREATE TABLE Doc (
    id UUID PRIMARY KEY,
    val JSONB NOT NULL
  );
Then later it turns out all documents have user_ids so you add a check constraint and an index:

  ALTER TABLE Doc ADD CONSTRAINT check_doc_val CHECK (
    jsonb_typeof(val)='object' AND
    val ? 'user_id' AND
    jsonb_typeof(val->'user_id')='string'
  );
  CREATE INDEX doc_user_id ON Doc ((val->>'user_id'));
I think the postgres syntax for this is pretty ugly. And if you also want foreign key constraints you still have to move that part of the json out as a real column (or duplicate it as a column on Doc). I am not sure it's even worth it to have postgres check these constraints (vs just checking them in code).

I am also a little worried about performance (maybe prematurely). If that document is large, you will be rewriting the entire json blob each time you modify anything in it. A properly normalized schema can get away with a lot less rewriting?

Re: Comparing Database Types

#117

Post by SPascareli13 »

616c wrote: post #104
AlphaWeaver wrote: post #2

This article comes from the team at Prisma, who are doing some really cool work building "database schema management and design with code" tools. They're working on a new version of their library right now (Prisma 2) and are regularly giving updates to the community and providing test versions. Most everything they make is open source and really well designed. Would recommend checking it out!

I am curious about Prisma2 because I tried to build a server side API with v1 as a novice to graph systems and it became an unwieldy nightmare. Partially my fault for wanting to do it without the SaaS they provide but trying to build with something complicated and Apollo on the frontend with a skilled FE dev got me so confused I put it off.

I was looking into Prisma + Apollo, can you expand more on your problems with it? To be it seemed really magical at first, but I don't know how it really works in production.

Re: Comparing Database Types

#118

Post by jayd16 »

zawerf wrote: post #116
asah wrote: post #28

Earlier quoted context omitted.

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…

I am trying this out and I am still on the edge of whether I like it or not. Create a table with a json column: CREATE TABLE Doc ( id UUID PRIMARY KEY, val JSONB NOT NULL ); Then later it turns out all documents have user_ids so you add a check constraint and an index: ALTER TABLE Doc ADD CONSTRAINT check_doc_val CHECK ( jsonb_typeof(val)='object' AND val ? 'user_id' AND jsonb_typeof(val->'user_id')='string' ); CREAT…

At this point, I would just bite the bullet, break out a new user_id column and run a migration to populate the column.

Re: Comparing Database Types

#119

Post by greggyb »

Darkphibre wrote: post #110
Pheebau wrote: post #69

Earlier quoted context omitted.

A join in an intersection in relational algebra

Oh, wow . I've been in the industry for over 20 years. I even worked on SQL Server Analysis Services for 5 years (up to 256-dimensional 'cubes' in the early 2000s)... and I never thought of joins in this way. Granted, MDX was a beast in its own right. Cue discussion about self-taught vs college educations. I've got advantages being self-driven learner... but I've definitely missed out in some regards.

MDX isn't a relational language, though. It's a dimensional language.

The best short description I can give about MDX is that it's the language your pedantic uncle would come up with after falling in love with Ralph Kimball, when all he knew to base it on was SQL.

But the core operations in MDX operate upon hierarchical dimensions and facts that can be aggregated.

    SELECT ... FROM ... WHERE
has no inherent relational semantic. It is simply a syntax that has been standardized upon for interacting with relational database systems. It was also, coincidentally, chosen as the syntax for another language, MDX.

Funny enough, the successor to SSAS Multidimensional is SSAS Tabular, where the query language is DAX. DAX was designed with an explicit goal of looking like Excel's formula language, but it is in fact a relational language which is semantically very similar to SQL, despite looking nothing like it.

Re: Comparing Database Types

#120

Post by campoy »

mdaniel wrote: post #95
planck01 wrote: post #84

Earlier quoted context omitted.

I am surprised Dgraph isn't mentioned as an example. It is the most starred graph db on Github, and I think it is the best one in terms of performance and scalability.

Strange that they have to have such a non-standard license, when they go out of their way to mention Apache 2 several times: https://github.com/dgraph-io/dgraph/blob/master/LICENSE.md Contrast that with Orient, who also have an Enterprise version, and they just straight-up say "Apache 2, no drama" https://github.com/orientechnologies/orientdb/blob/develop/l... We had an absolutely miserable experience trying to get J…

Hi there,

Head of Product at Dgraph here. Our license is Apache v2 for most of our source code.

Only our enterprise features are licensed with the Dgraph Community License [DCL](https://github.com/dgraph-io/dgraph/blob/master/licenses/DCL...).

We decided to make all of our code available on GitHub regardless of the license (unlike OrientDB if I understand correctly) so anyone can see what the Enterprise Edition really does.

Let us know if this is confusing. If you don't want the proprietary code, you can always only use the open-source version of Dgraph with `make oss`.

I'm also really interested in seeing where GQL (gql.today) is going, adopting a community-wide standard would be a definite yes from us.

In any case, thanks for your feedback. I'd love to hear more on how we can make our product better, feel free to email me at francesc@dgraph.io.

Post reply on HN