Build your next app with a graph database • Hacker News Board

Re: Build your next app with a graph database

#51

Post by LukeEF » Fri, Jul 10, 2020, 9:01 AM UTC

hitpointdrew wrote: post #29

freehunter wrote: post #10

I have never used a graph database but I can say there is one truth in the article: I find I have to stop and structure my app around the tables I need, and have had to stop and reorganize my code and data to fit a proper table structure when I realize my existing table structure doesn't make sense or hits the database too hard. I have no idea if graph databases are the answer to that problem, but I do get tired of b…

You probably just want any NO-SQL database then, not necessarily a Graph DB. MongoDB or Elasticsearch should fit your needs. The thing that is great about relational databases is data integrity, the thing that sucks about relational databases is data integrity. NO-SQL is fantastic, but if you want you data to adhere to ACID then there is simply no substitute for a relational database.

Some graph databases, like TerminusDB and others, give strong ACID guarantees and enforce data integrity - you can have the best of all worlds

Re: Build your next app with a graph database

#52

Post by LukeEF » Fri, Jul 10, 2020, 12:15 PM UTC

the_duke wrote: post #25

I'm currently on my first project involving a graph database . Dgraph coincidentally, and I somewhat like the product. But this is a horrible article that would immediately leave a bad taste in my mouth if I were researching the product. It boils down to a shallow dismissal of relational databases that does not have much more substance than "Relational dbs are old and bad! Graphs are awesome because relations and que…

It the section where you criticize graph is unfair. 1. All databases can be immature. 2. There is a whole world of graph DBs where strong schema support is the cornerstone of the system (TerminusDB, Stardog etc.). 3. Some relational Dbs have little tooling - Neo4j, as the oldest and most successful graph, has way more tooling than johnny newcomer RDBMS 4. performance characteristics are hard. That is not a necessary feature of graph. 5. Query languages - so you are saying only SQL will do? Lots of graph DBs use datalog or a variant (Datomic, TerminusDB, Opencrux). It is a well understood, powerful and composable approach to query. Yes, some query languages have flaws, but we should be open to doing better on query. SQL fundamentalism is wrong.

Re: Build your next app with a graph database

#53

Post by thelazydogsback » Fri, Jul 10, 2020, 3:03 PM UTC

The OP also misses the point that rather than modeling the 1:n relationship as he describes ("backwards" from the Comment to the Card) one could have a separate [Card.Comments] table that maps comments to and from cards (in either direction if so indexed) -- in other words, you could model the relationship directly and implements a graphDB w/your RDBMS. This allows one to add/remove relationships while leaving the data, to reference/reify the relationship, etc. Easy enough to create your own client-side query pre-processor or stored-procs to make queries easier of this graph if you desire.

Re: Build your next app with a graph database

#54

Post by freehunter » Sat, Jul 11, 2020, 11:07 PM UTC

nawgszy wrote: post #50

freehunter wrote: post #48

Earlier quoted context omitted.

When I say "hit the database too hard" what I actually mean is making too many calls to the database. If I have to make three or four calls just to get all the data I need, performance is going to take a hit. And databases are often the worst-performing part of the tech stack, so you have to craft your queries around the performance bottleneck of the database. So you have to balance your table structure around gettin…

Well, this was maybe a bit entry level description. Q: "databases are often the worst-performing part of the tech stack" - compared to what? nginx throughput? I find this to be a bit of a strange view, surely business logic is always the slowest part of the tech stack Q: "What happens if that int should actually be a float?" - how often do you actually need to run migrations versus just extending the data? From my en…

>I'm yet to encounter a real-world case where a migration wasn't just bad planning

That's basically the root of the issue. Poor planning in your code means you re-write some code. Poor planning in your database means you have to start restructuring data, and if it's already running in production you have to hope you don't accidentally corrupt production data. It's a lot harder to restore corrupted data in production than it is to roll back a code deployment. And the answer to the problem is obviously just spending more time thinking about the proper data structure, which is the entirety of my complaint: I want my data to fit my application, I don't want to have to write my application to fit my data. I don't want to have to think "does this field belong in the Users table or the Accounts table or the [insert table here]".

I'm not sure what you mean by "just extending the data"... if I'm writing a Rails app and I need to change an int to a float, the way I do that is by writing and executing a migration.

As for the speed... a database typically stores its data on disk and is often not hosted on the same physical machine as the web server. Meanwhile the app and web server store a lot of things in-memory on the local server and even when it has to read from disk, it's a local disk attached to that machine. Check these numbers for how long it takes to read from memory (or even local disk) versus reading a remote disk over the network: https://gist.github.com/jboner/2841832

Re: Build your next app with a graph database

#55

Post by freehunter » Sat, Jul 11, 2020, 11:13 PM UTC

balfirevic wrote: post #49

freehunter wrote: post #48

Earlier quoted context omitted.

When I say "hit the database too hard" what I actually mean is making too many calls to the database. If I have to make three or four calls just to get all the data I need, performance is going to take a hit. And databases are often the worst-performing part of the tech stack, so you have to craft your queries around the performance bottleneck of the database. So you have to balance your table structure around gettin…

> but make it hard to make changes to the data structure later. What happens if that int should actually be a float? Now you have to write a migration that makes fundamental changes to the structure of the data and hope there are no negative side effects. This is often stated, but it's not true. RDBMS make it easier to make changes to the data structure precisely because you only have to write migration and after tha…

I strongly disagree that this pattern makes it easier to make changes. It makes it easier to use the data (because you know this data will always be this type), but changing the data is harder than if it did not enforce a type.

I'm not arguing that un-typed data in a DB is easy to use or a good idea, just that it's harder to change the structure of RDBMS if you didn't plan properly from the beginning.

Basically: I think data is hard and I wish there were better tools for interacting with it.

Re: Build your next app with a graph database

#56

Post by jexp » Sun, Jul 12, 2020, 10:23 AM UTC

Not sure why, but the blog post in question (same URL), has been sneakily replaced with one replacing "graph database" with "GraphQL" in the title.

And changing the tagline on relational database from "Relational databases: a software engineering fail" to "Relational databases: engineering success is not always the best software engineering fit"

https://dgraph.io/blog/post/graphdb-for-your-next-app/

Fortunately internet archive still has the previous version, that the comments here were discussing. https://web.archive.org/web/20200709192510/https://dgraph.io...

Re: Build your next app with a graph database

#57

Post by nawgszy » Mon, Jul 13, 2020, 2:00 AM UTC

freehunter wrote: post #54

nawgszy wrote: post #50

Earlier quoted context omitted.

Well, this was maybe a bit entry level description. Q: "databases are often the worst-performing part of the tech stack" - compared to what? nginx throughput? I find this to be a bit of a strange view, surely business logic is always the slowest part of the tech stack Q: "What happens if that int should actually be a float?" - how often do you actually need to run migrations versus just extending the data? From my en…

>I'm yet to encounter a real-world case where a migration wasn't just bad planning That's basically the root of the issue. Poor planning in your code means you re-write some code. Poor planning in your database means you have to start restructuring data, and if it's already running in production you have to hope you don't accidentally corrupt production data. It's a lot harder to restore corrupted data in production…

> >If it's already running in production you have to hope you don't accidentally corrupt production data

Or you write use a read replica to transform your data into a non-live DB and validate it before you put it into production, with backups of your final old schema available? Plus I really don't think a migration is that hard. Much harder than having a litany of shitty backends you have to glue together in your front-end app, trust me as someone who's done both.

I mean, I hear you, persisting data is hard, but that's not the database's fault, it's because you pick two of three on data: performance, persistence, and flexibility

> a database typically

But that's not the "worst performing" part of the stack, that's the highest latency part of the stack. Is there some specific reason you can not have co-located web & db servers? Also, is there a reason you still reference 2012 disk numbers when SSDs clearly have reduced all "disk" operations by an order of magnitude?

> just extending the data

What I mean by this is if you start with a minimal amount of columns in your database, and someone is like "we need new property x", it's easy to add X outside a migration - adding new columns or new tables does not require migrations if you don't modify existing columns

So this is my approach. Use as few bits as possible to persist your data, and then you can generally add new features migration-free

Re: Build your next app with a graph database

#58

Post by OrderlyTiamat » Sat, Jul 18, 2020, 10:27 PM UTC

I'm sorry, how many different ways are there of saying "you likely think relational databases are good, but they are not" without any substance? I'm up to 6, and no longer interested in the article.