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

How NoSQL forced the evolution of a scalable relational database

blog.memsql.com

Post reply on HN
Print view View original

51–60 of 211 posts

Re: How NoSQL forced the evolution of a scalable relational database

#51

Post by threeseed »

richmarr wrote: post #45
189723954 wrote: post #38

Earlier quoted context omitted.

>I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript. I chose Mongo for a project recently. I have many years experience with SQL databases, and I think SQL will become more of a niche in the future. Here are the reasons: Everybody uses an ORM with a SQL database. You can pretend they don't and everyone is writing raw sql, but they aren't. This is basically a b…

> This is basically a big, complicated, and slow piece of software that tries to make a SQL database into something else. Just to nitpick a little, but I think it's a worthwhile distinction, ORMs don't try to make a SQL database something else... either literally or philosophically. To use them in any more than a trivial way you still to understand RDBMSs. They just make the queries less verbose and the output more c…

> ORMs don't try to make a SQL database something else

This is simply not true.

Many ORMs are designed to abstract away SQL and RDBMS concepts entirely. They deal in objects and object graphs and output SQL which can be quite disjointed from the object model e.g. many-many relationships.

Re: How NoSQL forced the evolution of a scalable relational database

#52

Post by mpweiher »

keithnz wrote: post #22

I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript. While scaling is one of the advantages, I'd be super surprised if many people actually need scaling capabilities ( other than because their design is super inefficient ). Recently I've been inspired to play around with kicking out as many layers between a relational db and a REST Api, largely because I've bee…

> kicking out as many layers between a relational db and a REST Api

Cool, is there anything we can see? I pretty much stumbled upon something along those lines back in 2003, and developed it into what I now call "In-Process REST"[1][2] and "Polymorphic Identifiers"[3][4].

The idea being that you can stay within a "storage-oriented vocabulary" for as much as possible, and that can include seamlessly all the way from provided interface to various storage mechanisms.

What's neat is that it reduces friction a lot, greatly enhances composability and reusability and just makes things blatantly obvious.

[1] https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...

[2] https://github.com/mpw/SoftArchLon2016-In-Process-REST/blob/...

[3] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...

[4] http://objective.st/URIs/

Re: How NoSQL forced the evolution of a scalable relational database

#53

Post by threeseed »

mmt wrote: post #37
threeseed wrote: post #24

Earlier quoted context omitted.

So the developers at Google (BigTable), Facebook (Cassandra), Yahoo (HBase), Apple (FoundationDB), Redis etc are "lazy" and have drunk "too much Kool-aid". Because these technologies every day power the most demanding applications on the planet.

I think the accusation was against the developers who caused the rise in popularity (i.e. the users), not the developers who created the technologies (i.e. the authors). In that light, it might be best to exclude BigTable, since it's only available publically as a service.

Facebook, Yahoo, Google etc built these databases to use not as coding exercises. So are they lazy and drinking the kool aid for not relying on SQL databases instead of building their own ?

Or maybe SQL isn't perfect for every use case and other developers should stop arrogantly belittling those that choose to architect their own systems a particular way.

Re: How NoSQL forced the evolution of a scalable relational database

#55

Post by logophobia »

189723954 wrote: post #44
logophobia wrote: post #6

Earlier quoted context omitted.

I would say the the rise of nosql options is driven by the need for scalability by a few large companies that desperately need it, and cargo-culting by developers that don't actually need it, but want to be like google and don't want to take the time to properly learn and optimize sql. There's a genuine need for good scalable options, and with stuff like google spanner, those don't necessarily need to be "eventually…

>don't want to take the time to properly learn and optimize sql. This sounds like an old-wives tail at this point.

I've met developers like that.

Although honestly, sql is more than 40 years old and can be really nasty. Stored procedures, each database has a different dialect, nullability comparisons, CTEs. It's very different from any other programming language. It's not that hard to imagine people finding it hard to learn, especially front-end web developers who'd rather not touch the backend. If people don't know how indexes work, then it'll perform really badly as well, which would make databases like mongodb all the more attractive.

Not all developers are formally schooled, a lot of people don't know what a relational database model is.

I've seen people:

* Iterate over entire tables to get to a small number of records

* Not using joins, having the ORM "magically" handle everything (lazily getting non-joined values in separate queries, resulting in thousands of queries)

* Denormalize everything, and then wonder why things are inconsistent and hard to query

Re: How NoSQL forced the evolution of a scalable relational database

#56

Post by stephenr »

threeseed wrote: post #53
mmt wrote: post #37

Earlier quoted context omitted.

I think the accusation was against the developers who caused the rise in popularity (i.e. the users), not the developers who created the technologies (i.e. the authors). In that light, it might be best to exclude BigTable, since it's only available publically as a service.

Facebook, Yahoo, Google etc built these databases to use not as coding exercises. So are they lazy and drinking the kool aid for not relying on SQL databases instead of building their own ? Or maybe SQL isn't perfect for every use case and other developers should stop arrogantly belittling those that choose to architect their own systems a particular way.

I'd say that 99.9% of organisations using any database technology, don't have the scaling problems of Google, Yahoo, Facebook or Apple.

They objectively can't be "drinking the koolaid" or cargoculting something, because they've specifically created their own solutions, to solve their own problems.

I specifically didn't say SQL is perfect - I said that they're very popular for the wrong reasons, and often are used in situations that a relational database would be a better solution.

Re: How NoSQL forced the evolution of a scalable relational database

#57

Post by [deleted] »

189723954 wrote: post #38
keithnz wrote: post #22

I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript. While scaling is one of the advantages, I'd be super surprised if many people actually need scaling capabilities ( other than because their design is super inefficient ). Recently I've been inspired to play around with kicking out as many layers between a relational db and a REST Api, largely because I've bee…

>I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript. I chose Mongo for a project recently. I have many years experience with SQL databases, and I think SQL will become more of a niche in the future. Here are the reasons: Everybody uses an ORM with a SQL database. You can pretend they don't and everyone is writing raw sql, but they aren't. This is basically a b…

[deleted]

Re: How NoSQL forced the evolution of a scalable relational database

#58

Post by sqlcook »

logophobia wrote: post #55
189723954 wrote: post #44

Earlier quoted context omitted.

>don't want to take the time to properly learn and optimize sql. This sounds like an old-wives tail at this point.

I've met developers like that. Although honestly, sql is more than 40 years old and can be really nasty. Stored procedures, each database has a different dialect, nullability comparisons, CTEs. It's very different from any other programming language. It's not that hard to imagine people finding it hard to learn, especially front-end web developers who'd rather not touch the backend. If people don't know how indexes w…

It actually IS quite hard to imagine solid engineers finding it hard to learn simple SQL. It's a lot harder to write "nasty" sql than "nasty" js, and if you're a front-end dev struggling with sql, then you probably should not be doing back end work. Yes not all databases are equal, thats why there are ORMs and ANSI standards.

From the list of bad practices you've "seen" people do in SQL, I would guess their comfort zone code is probably a hot mess as well.

Re: How NoSQL forced the evolution of a scalable relational database

#59

Post by ElectronShak »

keithnz wrote: post #22

I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript. While scaling is one of the advantages, I'd be super surprised if many people actually need scaling capabilities ( other than because their design is super inefficient ). Recently I've been inspired to play around with kicking out as many layers between a relational db and a REST Api, largely because I've bee…

> The REAL problem SQL wrappers need to solve is that most languages don't have a good interface with SQL. So most often SQL is handled in strings and manipulated with string manipulation and there is no type safe way transitioning data from the DB to a general purpose language.

For me this is (was) the main problem. When building Android apps and there was need to store some data locally, I always used Realm (https://realm.io/blog/realm-for-android/) because their API was way easier to use, other than the default SQLite database. Of course this made the apk significantly big, but at least i knew how to manage the data. SQLite on the other hand, wasn't easy to work with, and worse when it came to versioning / updating the local database schema / definition without messing things.

I say (was) because late last year, I started using Room (https://developer.android.com/topic/libraries/architecture/r...), and working with SQLite on Android has never been way easier. So yes, this has been a problem, but the solutions if built well, are great.

Re: How NoSQL forced the evolution of a scalable relational database

#60

Post by jexah »

siscia wrote: post #30
ddorian43 wrote: post #23

Earlier quoted context omitted.

The same answer applies to your product.

Honestly, I believe that for small workload you can definitely use RediSQL in production, it will happily contain your cache or it will be a great SQL database. However, I need a way to cut it between people just using the free product and people actually supporting the project, so provide as paying feature something that the big company will require it seemed to me the only way to go. Unfortunately, I don't have the…

I haven't followed any links posted in this thread, but some things I see often are: free for non-commercial use, timed commercial use usually in the region of 30 days, or rates based on reads and writes. The last one seems like a winner from what you've described as your situation.
Post reply on HN