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

141–150 of 211 posts

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

#141

Post by manigandham »

nojvek wrote: post #126
stickfigure wrote: post #123

Everyone seems to want to compare against MongoDB, but when I think NoSQL I think about Google Cloud Datastore and Amazon DynamoDB. Databases which are fully hosted, infinitely scalable, zero-maintenance, transactional, reliable, and - at least with Google's offering - scales down to a free tier. They aren't perfect or applicable in every situation, but they're cheap and easy enough to allow a one- or two-programmer…

I don’t understand the “call to get a quote” sales cycle. I bet memsql has a sales time the size of their engineering team trying to get those fat Enterprise deals but in the grand scheme of things why should I care? It doesn’t have a free tier, I can’t use it easily and just seems like a lot of hype without any 3rd party to back up their claims. Its the kind of things mongodb used to say to gain mindshare. Most popu…

They're focusing on customers that can afford it, so it's not about you caring but you not being their primary customer.

You can download the developer edition and it does everything except cross-region replication if you want to test it.

It's a great product and the real deal, we used it before (as a startup too) and it did the job and is one of the most polished databases out there.

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

#142

Post by eftpotrm »

skohan wrote: post #107
charlesvdv wrote: post #83

Earlier quoted context omitted.

You can also add Neo4j (graph) as part of the NoSQL family, right?

Yeah in general it seems like NoSQL is used to proxy "MongoDB and other key-value stores." Graph databases arguably handle relational data better than SQL, and I'd argue they're much nicer to work with.

And MS SQL Server now supports graph databases; it doesn't have to be either-or.

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

#143

Post by ecnahc515 »

stickfigure wrote: post #133
qaq wrote: post #125

Earlier quoted context omitted.

Outside of very niche use cases pushing enforcing consistency to the app layer adds enough complexity to dev process that a one/two programmer team will not generally handle it well. That's why even Google ended up building Spanner.

Having built several large, complicated, high-traffic apps on the Google Datastore, I disagree. Eventual consistency was at worst a minor nuisance. Rather, I found the major pain points to be 1) no joins and 2) no aggregations.

Those major pain points are exactly what you're trading off off for when you pick eventual consistency.

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

#144

Post by qaq »

stickfigure wrote: post #140
qaq wrote: post #139

Earlier quoted context omitted.

so you have a distributed system that is handling eventual consistency at the app layer and it was a minor nuisance :)?

Yes. Genuinely, why is that hard to understand?

Because for avg. developer reasoning about eventual consistency and handling all the edge cases is fairly hard. If it's easy for you I guess you are far above avg. dev.

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

#145

Post by meowface »

lmm wrote: post #104
matwood wrote: post #80

Earlier quoted context omitted.

> Everybody uses an ORM with a SQL database. I'm ripping ORMs out of any backend code and using things like jOOQ. > I was just thinking to myself "I can write this in code in a few minutes instead of an hour or more".... > Joins are slow and complicated You know what's really slow? Creating joins in code. > This is not true at all. Programming languages are vastly superior at querying a database. Just go write a comp…

> You know what's really slow? Creating joins in code. It really isn't. In a good programming language expressing a join should be just as easy as in SQL. > It makes zero sense to pull a bunch of records back from the db using multiple network calls to join and then filter. Let the db do its job. Agreed that you need a way to do aggregate queries on the server, but plenty of NoSQL systems give you ways to do that. I'…

>It really isn't. In a good programming language expressing a join should be just as easy as in SQL.

I don't think they were saying it wasn't easy, just that it isn't as performant as letting the DB do the join. Which should be true in pretty much all cases.

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

#146

Post by spikej »

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…

Its been mentioned here before, but check out Rezoom.SQL https://github.com/rspeele/Rezoom.SQL

All the power with static typing

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

#147

Post by mmt »

jandrewrogers wrote: post #113
mmt wrote: post #81

Earlier quoted context omitted.

> It makes zero sense to pull a bunch of records back from the db using multiple network calls to join and then filter. Let the db do its job. But then it wouldn't be distributed processing! :) Seriously, though, consider it for a moment.. this pattern has similar features to something like Hadoop. The data comes from storage nodes (database server and, hopefully, their read replicas) and goes to processing nodes (ap…

Doing distributed joins correctly requires an architectural/technical capability that most distributed database engines don't have: decentralized parallel orchestration. If you have this, you can do joins even with very high data volumes efficiently given good parallel scheduling algorithms. Most databases are designed such that there is a single point of control that declaratively schedules all data flows required t…

Thanks for that detail. I knew there were more interesting, technical reasons than my oversimplification for why I had never seen it.

> People who design codes for supercomputers are often familiar with parallel orchestration idioms that work at extremely large scales but it hasn't crossed over into ordinary distributed database engines. (This is also a good litmus test for what makes a database "parallel" as distinct from "distributed".)

My understanding was that this is primarily (or also) due to the lack of low-latency (and high-bandwidth) interconnects in the ordinary distributed environments, as those enable that orchestration.

I admit to wanting that to be true, as it supports a mantra I like to say to managers with programming-only (no Ops/sysadmin or even DBA) backgrounds: not all problems can be solved with software.

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

#149

Post by richpimp »

Someone please help me understand. I use relational databases everyday for my projects (db, api, frontend). I'm well-versed in SQL and general best practices, and my projects scale well (admittedly I'm not in the petabytes level of scale). Does the desire to use NoSQL databases come from a disdain for having to think in terms of declarative programming instead of imperative? Is it desirable to have dynamically typed fields in a database? I've always thought that the biggest motivation to use NoSQL is simply due to high-level language programmers' unfamiliarity with relational database logic and SQL syntax. Once I grasped the concepts, the relational model has proven indispensable for me.

I will say, though, that it is important to get your schema correct at the beginning. I've also always worked full-stack, so I don't know what it's like not to have the ability to manipulate the database.

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

#150

Post by wild_preference »

richpimp wrote: post #149

Someone please help me understand. I use relational databases everyday for my projects (db, api, frontend). I'm well-versed in SQL and general best practices, and my projects scale well (admittedly I'm not in the petabytes level of scale). Does the desire to use NoSQL databases come from a disdain for having to think in terms of declarative programming instead of imperative? Is it desirable to have dynamically typed…

NoSQL is used by two camps. One wants a denormalized doc store for their technical needs, and the other because it has an easier quickstart on day 1 when you don’t know SQL. Here we are usually talking of the latter.

The beauty of something like Postgres is that you don’t need to get your schema right on day 1. How could you anyways unless tou already know all future data access pattern?

Post reply on HN