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

41–50 of 211 posts

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

#41

Post by mmt »

pavbelshippable wrote: post #11

Perfect! We at Shippable moved from NoSQL MongoDB to PostgreSQL for several reasons. Here is a small story, It started with small problems... Even though we had the ability to add features at a lightening pace, we started seeing occasional downtimes which always seemed to come down to MongoDB. For instance: > We were very happy to have 24x7 availability with primary and secondary instances of MongoDB. However, our pe…

Worth mentioning the two links toward the end of your story:

https://www.sisense.com/blog/postgres-vs-mongodb-for-storing...

https://www.enterprisedb.com/node/3441 (mongo-pg perf comparison)

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

#42

Post by 189723954 »

stephenr wrote: post #3

> NoSQL came into existence because the databases at the time couldn’t handle the scale required. Arguably the first "NoSQL" database was a DIT, generally accessed via the LDAP protocol. OpenLDAP is one of the better known open source instances, but Novell eDirectory was there in the early part of this century, as was MS AD. In the case of Directory Services, it's a completely different approach to both SQL and the c…

>lazy developers and too much Kool-aid consumption.

When your argument is based on personal attacks of the people using that thing, it sounds more like you have an emotional investment in the alternative rather than a rational argument.

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

#43

Post by uncle_d »

lyqwyd wrote: post #17
uncle_d wrote: post #10

My own experience chimes with this somewhat, having used MongoDB on my last project - quite often application data storage requirements are relatively trivial - and it is a boon to do away with the ORM layer and be able to vary any given object schema without touching the database (although in practice a .js data migration script may be involved, so this is moot). As a sidenote local cultural issue, the fact that we…

The fact that you could operate the mongo instance, but not the DB is definitely a cultural issue, or more likely a managerial issue. Definitely NOT a DB issue. I’ve worked at places where we could manage the DB ourselves, and other places where we couldn’t eve talk to the DBAs without beuraucracy. It’s all about the management in those scenarios. And the company results were as you would expect.

Sure - I’m not claiming that as a database issue at all. It’s just a side addendum to note that sometimes technical decisions can have a political aspect.

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

#44

Post by 189723954 »

logophobia wrote: post #6
stephenr wrote: post #3

> NoSQL came into existence because the databases at the time couldn’t handle the scale required. Arguably the first "NoSQL" database was a DIT, generally accessed via the LDAP protocol. OpenLDAP is one of the better known open source instances, but Novell eDirectory was there in the early part of this century, as was MS AD. In the case of Directory Services, it's a completely different approach to both SQL and the c…

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.

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

#45

Post by richmarr »

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…

> 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 convenient to work with.

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

#46

Post by zkomp »

igl wrote: post #26
icebraining wrote: post #15

Earlier quoted context omitted.

Postgres has had hstore for schema-less data since 2003.

This is a very blunt statement and overvalues hstore. Keys AND values in hstore are and can only be text strings.

Yes hstore is limited but since you can represent numbers and even hstore itself as text, all you really have to do is cast to and from text and then you have a nested structure with almost anything in it...

jsonb is much better obviously but hstore was really nice and kind of under appreciated.

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

#48

Post by pbz »

sidstling wrote: post #34
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…

Linq to SQL is still a thing, you may need to click it’s package when you install visual studio 2017+, but it’s still there and it’s still the best SQL interface they have build in my opinion. We rarely use anything else, but I can see the value of entity if you’re changing your DB a lot. We typically don’t do that though, and to be honest, working with changes with linq to sql, typically goes smoother than entity mi…

LINQ to SQL is a dead end. Look into LINQ to DB https://github.com/linq2db/linq2db which is way faster than LINQ to SQL ever was (faster than even Dapper). If you must you could give EF a try, but stay away from LINQ to SQL.

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

#49

Post by logophobia »

exclusiv wrote: post #12
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…

It wasn't just devs that didn't know how to properly optimize SQL. Programming w a NoSQL db was a better experience because there was no object impedance mismatch. ORMs fill the gap of course and SQL w JSON types are really nice. So I agree with your last paragraph but the rise was due to speed of db and speed for the developer. I cranked out a lot of apps under short deadlines w MongoDB way back in the day. And I mo…

I've seen some of those applications. It might be easier & faster to start with a schema-less json database, but I saw some serious maintenance issues with applications like that:

* Using the stored data outside the use cases imagined by the original developer is harder than it should be. (Oh you want a customer dashboard with this and this data correlated, ..)

* "Migrations" can be rather error-prone if developers don't pay attention. (It was stored as a string first, and now it's an integer, now how do we query that). Just because there's no database schema, doesn't mean there's no schema.

* It's hard to see what's actually in a json table/collection. You'd need to browse the code, see how it's used, and then browse through the available data.

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

#50

Post by 189723954 »

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…

You are just defining the limits of "something else" and then saying it doesn't do that. If your data looks completely differently to how the database outputs it, I don't think you can say it is just a trivial difference. Both the structure of a query and its output use different concepts to sql.

Using linq, a query will look like:

db.Products.Include(p => p.manufacturers).Include(p => p.parts).where(p => p.name == 'bike').ToList();

in sql, it is SELECT * from products, manufacturers, parts, JOIN ...... ON .........

The linq query syntax makes it seem like you are just plucking a Product out of a database that has manfufacturer and a list of parts as part of its object. It is an object, not a row and table based structure.

Then the output itself is also an object, in a completely different structure to what the database gave to you.

People can use an ORM and not really know how SQL works if they never bother to learn. It is presenting them with an object-based database.

In a NoSQL database like Mongo, you either have to literally store the Product with its parts and manufacturer, or you take them separately from the database and put them back together in code. This requires no abstraction. It is exactly what is happening.

Post reply on HN