Hacker News Reader

Comment by markus_zhang | Hacker News Reader

Interesting. I wonder what does a NoSQL one look like?

I call it the "Build now, cry later" approach.

Second that, i’ve built multiple services with MongoDB just to port them now (and probably for some time) to postgres.

Just curious why? I have never worked with NoSQL but I always envy the people who does that because they are a bit further away from business than us data warehouse modellers. They are usually our upstream, paid more and less hassle from business.

That only makes sense if you wanted to store relational data in a NoSQL database (and that's not what Mongo is meant to do)

And if your business is okay with all of your data living in a single instance.

Because PostgreSQL is unacceptably poor at HA/replication compared to MongoDB.

Is that really true these days? Setting up Postgres read replicas with automatic fail over across multiple machines is pretty trivial in the cloud with services like RDS, spanner etc. And although doing it in your own datacenter is still a big job it's far from impossible.

Huh? Replicas are easy, and hot standby nodes aren’t that hard either. There are also various active-active solutions if you need that.

I'm genuinely curious what you mean when you say "relational data"? I've seen this phrase thrown around and I think it's something of a misconception.

The way you use the term implies that you're referring to the type of data, but the term generally refers to the method used for storing the data.

This distinction is important because it leads to a circular reasoning dynamic: many of us are accustomed to storing the data in tabular form using a relational data model. But choosing to use that particular model to represent objects or entities or ideas does not make those objects or entities or ideas fundamentally relational data.

Postgres and NoSQL are not exclusive, Postgres works pretty well as NoSQL (some would say better than Mongo).

This is an extremely misleading statement. You have to jump through hoops to do expressive queries, with a limited set of index primitives, a query optimizer that doesn't take advantage of anything that resembles nested JSONB, and syntax and storage overhead that will leave you thinking there's nothing good about storing data with rich JSONic structure begin with.. worst of all worlds

I used it for that and it is not like a hell you describe.

What kind of scale are we talking to out of curiosity?

Pretty small.

And yet almost all of the major websites you use today rely on NoSQL.

Also if you have non-traditional data structures e.g. document, star, graph, time series then storing them in a SQL database will cause you nothing but problems.

There are no black/white answers in tech. Always right tool for the right job.

> And yet almost all of the major websites you use today rely on NoSQL.

They may use NoSQL in specific use cases, but certainly not exclusively. Using the right tool for the job is crucial; otherwise, you’re doing yourself and your product a disservice.

In this case, NoSQL database architecture and internals provide little to no advantage over relational databases. I can’t imagine building a calendar implementation with NoSQL. Some flexible parts of the event model might be stored as NoSQL, but in general? No way.

Edit: looks like I wrote my comment as you were editing yours. We agree :-)

It's a weird argument because the article is wrong.

Google Calendar is not implemented on top of a traditional SQL database but rather on top of Spanner which is more akin to a NoSQL database with a SQL front end.

Up to chapter 6 the method is completely database-independent. In chapter 7, a classic relational table approach is explained.

You can choose a different approach if you want to use something like Cassandra, MongoDB or DynamoDB (or some other NoSQL solution). I am not an expert in all three, but I hope some day to write "alternative ending" for this tutorial and show how it can be applied in those environments.

Whatever database you choose, you still must do all the work of logical modeling (first six chapters) for your application. If you don't do that explicitly, you would have just to do that implicitly, intertwined with physical design and thus inherently more confusing.

I've been building something using a JSON-blob inside SQLite using the Schema.org/Event schema. It's turning out okay.

It looks like one you shouldn't implement.

May I ask why? Actually I never used a NoSQL one so curious.

Because events are related to users and they both are related to timezones and events can be related to each other. MongoDB is really good for storing big blobs of data you want to retrieve quickly, with some basic search and index, but it's awful at relations between data.

Ah I see what you mean. That makes sense!

The for most people somewhat counter-intuitive answer is that NoSql is very rigid. It is counter intuitive, because having no required schema up front appears to be more flexible, not less.

However, having your database not handle schema means your application must do it, there is no way around it. If you ask for an DayEvent and you get back something totally different, what do you do?

The rigidness in most NoSql (assuming some form of document store like MongoDB) comes from its inability to combine data in new ways in a performant manner (joins). This is what SQL excels at. That implies you need to design your data in exactly the way it is going to be consumed, because you can't easily recombine the pieces in different ways as you iterate your application. Generally you must know your data access patterns in advance to create a well behaved NoSql database. Changes are hard. This is rigid.

Thus, it actually makes more sense to go from sql to a nosql, as you gain experience and discover the data access patterns. The advantage of nosql is not flexibility, that is actually its disadvantage! The advantage is rather its horizontal scalability. However, a decent sql server with competently designed schema will go a very long way.

I think you have a very thoughtful take but believe it's a mistake to think of 'NoSQL' as a monolithic category..

There's a very wide spectrum from having an evolvable document oriented data model with evolvable strongly consistent secondary indexes, transactions, aggregations, and joins to simplistic key/value stores like DynamoDB and Cassandra that do force you into a very much waterfall posture that I think you are spot on in pointing out.

Reply on news.ycombinator.com