4 ms·

>Relational databases are very rigid so you need to really make sure you understand your data upfront. Is NOT true: CREATE TABLE/VIEW ... ALTER TABLE

by mamcx 6y ago

>Relational databases are very rigid so you need to really make sure you understand your data upfront. Is NOT true: CREATE TABLE/VIEW ... ALTER TABLE ... SELECT (whatever) ... Changing a rdbms at runtime is fully supported, in MUCH better ways than almost all "nosql" databases. > Changing the database is a big effort Is much less effort than nosql. With more guaranties than the change is CORRECT, and not left you half documents in one version and the other in other version. > These databases are hard to distribute and scale so you tend to end up with single instances that are very large and require replication for backup. The cloud providers have relational databases today that are supposed to scale, but I have no experience with them. Is very easy to be "web scale" if you don't care about data integrity. Very few nosql are half good about this. Scaling a rdbms is very similar to have a less brittle nosql product (like mongo), is about how you model the data. I was in a team behind one of the largest deployments on google cloud store. The amount of coding for cover for the store lack of integrity was a big part of the codebase. Despite the supposedly massive amount of data I don't see why have a rdbms in the back could have been worse (when anyway you must put in front redis and other caches for high ingestion). I think for the majority of the startup deployments, rarely a non-rdbms make much sense, specially if the team have not idea of what truly a good rdbms can do, or how code by hand a correct transaction code...

mrjn 6y ago
(author of Dgraph here) I'd argue relational DBs get way more credit than they're worth. And it is indeed tricky to make them work across different data models -- that's by now an established fact across big SV companies. Restricting direct access to rigid RDBMs and making data modeling easier via graphs is why Facebook Tao, Dropbox Edgestore, Airbnb Knowledge Graph and so on exist. See my post [1]. I'll give you a simple example. Consider, movies and directors. If you started with the fact that each movie has exactly one director, you'd design exactly one table, with a director column. Later, if you realize that each movie can have multiple directors, you can't just alter that table. You need two new tables -- one for directors, and another one to connect movies to directors. That's not simple, that's a big change which requires a bunch of work. Doing this in graphs is simple. Adding a bunch more outward relationships is simple. Data modeling, in general, is way simpler in graphs than in RDBMs. Mongo and such came out of the Bigtable era. Cockroach and Dgraph are coming out of the Spanner era -- where it's not only about horizontal scalability, but also about strong data integrity and distributed ACID transactions. [1]: https://dgraph.io/blog/post/how-dgraph-labs-raised-series-a/ https://dgraph.io/blog/post/how-dgraph-labs-raised-series-a/
- simonw 6y ago
  > That's not simple, that's a big change which requires a bunch of work. I feel like many of these criticisms of RDBMS come from a perspective of not working with a great database migrations system. I've made changes like this (one-to-many switched for many-to-many) using Django migrations many times over, and I find it easy. But that's because I've built up the experience with the tooling over time. Learning migration tooling in this way feels like a much smaller lift to me than entirely switching to a graph database. (I'm a big fan of Dgraph, but I've not yet found the right project to apply it. I'm not interested in it as a replacement for RDBMS, I want to use it to solve graph problems that are genuinely painful with a relational database. Easier schema changes aren't that for me.)
  - mrjn 6y ago
    Hey Simon, Totally see your perspective. You're already familiar with data migration, but not familiar with graph DBs. The former is just easier to do than to invest in the learning curve involved with the latter. Valid point. My take is more root-cause and principle based. If we were to think of a different way to build a DB, then avoiding a data migration altogether is a better approach. Avoiding the downtime, extra work, extra code and so on is just better for the user. Moreover, simpler data models, avoiding data duplication and such become very convincing features. It's also not so interesting to me when graph DBs are only applied to specific graph problems, like Page Rank and such. We didn't build Dgraph just to solve Page Rank. The reason we built Dgraph was because we saw the complex data modeling problem Google Knowledge Graph threw at us. Graph system allowed that problem to be solved in a really clean and simple way. And it's the same problem we see other companies dealing with as well.
- default-kramer 6y ago
  In your movie+director example, changing a relational database is relatively easy. Yes, you create two new tables but that is not hard. And you relocate the director data from the movie table into the new director table, also not hard. The hard part is updating all the application code that was written assuming that a movie has one director. I'm not super familiar with graph DBs, but I don't see how they could possibly help with that.
deleted 6y ago
[deleted]

by mamcx 6y ago

mrjn 6y ago

(author of Dgraph here) I'd argue relational DBs get way more credit than they're worth. And it is indeed tricky to make them work across different data models -- that's by now an established fact across big SV companies. Restricting direct access to rigid RDBMs and making data modeling easier via graphs is why Facebook Tao, Dropbox Edgestore, Airbnb Knowledge Graph and so on exist. See my post [1]. I'll give you a simple example. Consider, movies and directors. If you started with the fact that each movie has exactly one director, you'd design exactly one table, with a director column. Later, if you realize that each movie can have multiple directors, you can't just alter that table. You need two new tables -- one for directors, and another one to connect movies to directors. That's not simple, that's a big change which requires a bunch of work. Doing this in graphs is simple. Adding a bunch more outward relationships is simple. Data modeling, in general, is way simpler in graphs than in RDBMs. Mongo and such came out of the Bigtable era. Cockroach and Dgraph are coming out of the Spanner era -- where it's not only about horizontal scalability, but also about strong data integrity and distributed ACID transactions. [1]: https://dgraph.io/blog/post/how-dgraph-labs-raised-series-a/ https://dgraph.io/blog/post/how-dgraph-labs-raised-series-a/

simonw 6y ago
> That's not simple, that's a big change which requires a bunch of work. I feel like many of these criticisms of RDBMS come from a perspective of not working with a great database migrations system. I've made changes like this (one-to-many switched for many-to-many) using Django migrations many times over, and I find it easy. But that's because I've built up the experience with the tooling over time. Learning migration tooling in this way feels like a much smaller lift to me than entirely switching to a graph database. (I'm a big fan of Dgraph, but I've not yet found the right project to apply it. I'm not interested in it as a replacement for RDBMS, I want to use it to solve graph problems that are genuinely painful with a relational database. Easier schema changes aren't that for me.)
- mrjn 6y ago
  Hey Simon, Totally see your perspective. You're already familiar with data migration, but not familiar with graph DBs. The former is just easier to do than to invest in the learning curve involved with the latter. Valid point. My take is more root-cause and principle based. If we were to think of a different way to build a DB, then avoiding a data migration altogether is a better approach. Avoiding the downtime, extra work, extra code and so on is just better for the user. Moreover, simpler data models, avoiding data duplication and such become very convincing features. It's also not so interesting to me when graph DBs are only applied to specific graph problems, like Page Rank and such. We didn't build Dgraph just to solve Page Rank. The reason we built Dgraph was because we saw the complex data modeling problem Google Knowledge Graph threw at us. Graph system allowed that problem to be solved in a really clean and simple way. And it's the same problem we see other companies dealing with as well.
default-kramer 6y ago
In your movie+director example, changing a relational database is relatively easy. Yes, you create two new tables but that is not hard. And you relocate the director data from the movie table into the new director table, also not hard. The hard part is updating all the application code that was written assuming that a movie has one director. I'm not super familiar with graph DBs, but I don't see how they could possibly help with that.

deleted 6y ago

[deleted]