Hacker News Reader

Comment by gjolund | Hacker News Reader

I have issues with his "Reasons to use NoSQL"

* Making the most of cloud computing and storage

There are plenty of "cloud" hosting options for SQL databases, enough that a simple google search should make my point for me.

* Rapid development

This is a really common reason that I have heard for wanting to use NoSQL databases. It is flat out wrong.

While NoSQL databases may not force you into a schema for your database, you will pay a toll for this mutability in your application layer.

I have worked on several NoSQL backed projects, and nearly without fail development speed drops like a rock once you make changes to the way your data is persisted.

SQL migrations may seem tedious, but the process of planning your data model and having rigid definitions for your data types saves you huge amounts of time in the long run.

Data is the foundation of most applications, and if you can't rely on your data then you are building your application on sand.

View on HN

Another point on rapid development: SQL databases have some amazing libraries and tooling. I've been working a lot with SQLAlchemy in Python lately and have been blown away by it.

> While NoSQL databases may not force you into a schema for your database, you will pay a toll for this mutability in your application layer.

A while ago I read a really good point on this: There's always a schema. NoSQL / "schemaless" databases don't get rid of the schema, they just move it out of the database layer. It's still there, whether in the application or the documentation or just in your head.

NoSQL databases have as many schemas as there have been changes to the model. Everytime you make a change, and are keeping old data, you have another schema. Your code then has to be aware of every schema that has ever existed. Over time this becomes more and more painful and error-prone.

In a relational database, you have one schema and you have to convert/update your data to match that schema whenever it changes.

I've done one big project many years ago that used NoSQL storage of heterogeneous "document" types -- a perfectly reasonable use-case for the technology -- and I wouldn't do it again. Although at the time it seemed crazy to create different tables to hold this data it would have made that code so much simpler now.

Imagine handling data like that with javascript.

Mutable data types, with mutable data, and inconsistent error handling.

Burned me out in a matter of months.

I also love the "Reasons to use SQL":

> If your business is not experiencing massive growth that would require more servers and you’re only working with data that’s consistent, then there may be no reason to use a system designed to support a variety of data types and high traffic volume.

This whole article seems heavily NoSQL biased. I don't know what qualifies as high traffic volume, but Postgres has been known to handle 500,000 transactions per second, and there is stuff in the pipeline that is only going to make that faster.

http://akorotkov.github.io/blog/2016/05/09/scalability-towar...

Yeah, the title should be "SQL vs NoSQL: I only partially understand one"

Adding to your very good points:

There are very good ORMs and frameworks that make working with SQL simpler. With baked in type checking and migrations, there is not a lot of need for NoSQL. Plus PostgreSQL and it's JSON data type basically made a lot of the popular NoSQL options obsolete.

Articles like this should have, in the opening paragraphs, a statement like, "This is for the general case, there are many outliers." For instance, not all non-relational databases are NoSQL. What about hierarchical databases (LDAP)?

The other thing this article totally fails to address: Why NoSQL was so problematic early on. How Mongo by default would let errors fail silent in Java and other drivers.

She doesn't address the huge limitation in many NoSQL solutions: consistency. She briefly mentions ACID, but neglects the primary use case for document based NoSQL: if your data doesn't need to be current on ever read. So a blog is a great example, or any type of social network really. It really doesn't matter if you're reading a version of the comment thread from 20 seconds ago or 5 seconds ago (as long as it's not like 2 minutes ago).

The author also classifies all NoSQL as document stores, when they're not. Mongo uses a document model/concept, but others may use a model that's more like a distributed memcache or key/value store. There are things like Apache Geode which uses a distributed object store with client based schema versioning. The data model space is pretty big and they're pretty different fundamentally.

The author mentions how a lot of solutions use both, but in other posts I've looked at and other companies I've worked for, I've found that you often have to require both. In a lot of implementations, people use both a NoSQL and a relational store; one more as a fast read cache and the other for long term persistence. Then you get into all the issues with insuring consistency between the two and it's a miss.

Overall, this is a pretty basic article and not one I'd recommend. It can lead to the wrong decision for a project.

>I have issues with his "Reasons to use NoSQL"

Looking at the author bio at the bottom, I believe it is "her".

SQL migrations may seem tedious, but the process of planning your data model and having rigid definitions for your data types saves you huge amounts of time in the long run.

Your reasoning seems too black and white, most the of the time, you can't know your data model ahead of time, that's why prototypes are so useful, so just using your language data structures or some less rigid datastore lets you get quicker to your data model.

Having rigid definitions for data types doesn't necessarily mean the datastore is rigid. It just means that you know what type of data goes in each column. Like it or not, if you change your schema that change has to be handled somewhere - either you update the old data to the new schema (do this), or you handle old versions of the schema in the application (fundamentally non-scalable IMO). It doesn't matter whether they're values in a JSON object or columns in a relational DB.

Flyway is a fantastic tool for making changes to relational schemas. Your code is versioned, and you can just keep the schema migration scripts right next to it. If you need to upgrade an old schema, it just walks through the migration scripts until it's up-to-date.

If there is some portion of your model that really, truly, honestly consists of unstructured data, you can just put that in a JSON column.

That is why I mentioned prototypes, they are a quick messy hack that is not meant to scale, its purpose its to validate your ideas and decisions, what is going to become your MVP, which IMO is far more important than getting the perfect stack/tooling from the start.

We obviously value very different things in regards to software development.

You really seem to favor initial velocity and rapid iteration. Fair, I can totally understand why.

I favor planning, stability, and limiting thrash due to bad/uninformed decision making.

In my experience the rush to market only pans out when you plan on having a large influx of funding to rebuild your stack. Otherwise you are stuck holding a mess of code and trying to scale ideas that never should have gone to production in the first place.

There is a whole other side to the industry that demands provably correct solutions, and will not tolerate the "hacker culture". Not because of any petty reasons like work hours or perks, but because some applications require a level of accuracy that your average growth hacker can't meet.

I also really like the sqitch project for migration management.

http://sqitch.org/

This sounds so logical, is repeated often, and is fundamentally incorrect. Just because you are defining a data model doesn't mean you can't change it. There's nothing easier. Undefined schemas are actually worse under change than defined ones.

Like I've argued before, you have a schema. Your app cares about the location and format of the data. You're only deciding whether or not you want to write down your schema and use it to catch mistakes.

Like I've argued before, with NoSQL you have many schemas -- one for every change (unless you delete all the data after every schema change). In SQL, you have one schema -- which is much easier to work with even when you're just doing early spec development.

Reply on news.ycombinator.com