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

131–140 of 211 posts

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

#131

Post by adrianpike »

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…

> I don’t understand the “call to get a quote” sales cycle.

It's about maximizing revenue from enterprise clients - when the customer LTV is huge but the volume is low, it's smart to focus your resources on those dollar amounts. When the volume is high but the dollar amounts are low, it's smart to focus on optimizing the volume funnel.

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

#132

Post by d4l3k »

ben509 wrote: post #118
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. NoSQL caught on because of what it doesn't do: attempt to implement the relational model. A lot of people were using MySQL in infamous LAMP stacks to set up websites with virtually no business logic. So you had: 1. An application that didn't need the relational model 2. A DBMS that had a very poor implement…

MongoDB certainly was missing a lot of things when they first launched and were very hyped, but now pretty much everything you could want in a database is now in MongoDB.

Multi-document transactions + strong consistency: https://docs.mongodb.com/manual/core/write-operations-atomic...

Passes Jepsen test: https://www.mongodb.com/mongodb-3.4-passes-jepsen-test

Schema: https://docs.mongodb.com/manual/core/schema-validation/

Query Optimizer: https://docs.mongodb.com/manual/core/query-plans/

Backups: https://docs.mongodb.com/manual/core/backups/

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

#133

Post by stickfigure »

qaq wrote: post #125
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…

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.

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

#134

Post by zzzcpan »

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.

Exactly. Eventual consistency was never hard, people should stop taking Google's research so seriously. They mix it with marketing too much.

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

#135

Post by AtlasBarfed »

rickn wrote: post #2

My name is Rick Negrin. I run the Product Management team at MemSQL, a scalable relational database. I recently wrote a blog on my thoughts regarding NoSQL vs. Relational Databases and I'd love to hear the community’s thoughts on this.

I notice not a single mention of the CAP theorem. I have a hard time taking any "scalable" RDBMS solution seriously without a discussion on how you scale well-known problems with deletes and updates, maintaining b+tree indexes, distributed joins, distributed data, node loss/partitions, and distributed transactions/updates.

If you are a new distributed system and don't have Jepsen tests or a similar level of discussion on how your database handles partition events, then that tends to be harbingers of snake oil in distributed systems.

Granted I only did a quick search on CAP on your article, but the initial paragraph of your article didn't exactly invite further investigation or time investment.

If your "NoSQL" is just a single node MongoDB, then you should state that rather than your blanket statement. As is your categorization of "NoSQL" is unspecified and unqualified, leading me to believe this is a management-level article with little regard for the real issues in large-scale distributed databases, and why would I think your software also considers such problems?

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

#137

Post by [deleted] »

matwood wrote: post #85
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.

> This sounds like an old-wives tail at this point. Except it's not. I've seen it in person, over and over. I've gone into systems where people were complaining about the 'database is slow', but there were no indexes. I've seen systems pull back 100s of thousands of records and then sort on app server and take the first 50. I've seen what would have been a simple join with exists clause turned into many round trips t…

[deleted]

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

#138

Post by hinkley »

pluma wrote: post #47

I'm surprised how many people still conflate NoSQL with "document database" and only think of MongoDB or CouchDB. I'd love to hear how MemSQL addresses graph data, for example.

Because when the fox has been in the henhouse this long, it’s a fox house, not a henhouse.

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

#139

Post by qaq »

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.

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

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

#140

Post by stickfigure »

qaq wrote: post #139
stickfigure wrote: post #133

Earlier quoted context omitted.

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.

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?
Post reply on HN