Hacker News Reader

Comment by Daishiman | Hacker News Reader

The misplaced hype cycle is real.

10gen is not a company dedicated to databases, at least not if the initial code quality of MongoDB is a signal (and it should be, since if you know a thing or two about storage you wouldn't take the compromises it initially did)

Unfortunately, many fresh graduates with no experience in storage decided to evaluate the technology based on its very visible merits, without considering that scalability is not really a top priority even in companies that have to "scale", and that reliability trumps every other metric.

Mongo has failed spectacularly in being a reliable data store, and its scalability is mediocre, given that it's a lot more about query planning, analytics and optimization than having out-of-the-box sharding.

This is one of those areas having some seniority does wonders. Storage concepts are not easy to grasp, and evaluating a database's reliability takes much longer than most product cycles.

View on HN

Have you ever worked on a significant project using MongoDB?

I did. I wouldn't use it again. But reliability just wasn't an issue. There was a time when there were insane defaults that made this an issue, but that's a long time ago.

I am working on a significant project using MongoDB. Reliability absolutely is an issue even with significant engineering resources thrown at it.

Any idea about Memsql? We are evaluating it at our company and all the info is kind of fuzzy.

Feel free to reach out to me on our public Slack channel to clear up anything that is fuzzy! I'm an engineer at MemSQL and want to know (1) how I can help and (2) how we can provide non-fuzzy information to the rest of the community.

Channel: chat.memsql.com My UN: eklhad

MemSQL as in the distributed relational data warehouse product? If so, it's highly recommended, probably the best data warehouse solution you can run if you're not going with something managed (like redshift or bigquery).

For those actually needing scalable, resilient nosql, CouchBase ia worth evaluating.

Why wouldn't you always use something that is tried-and-true? MongoDB is relatively new compared to something like postgresql or even mysql.

Not only that but you can use PostgreSQL as a NoSQL and there are benchmarks showing that it outperforms MongoDB.

And if you do not want to commit to either SQL or NoSQL, the PostgreSQL has you covered. You can put a JSONB column in any of your tables to handle the part of your data that is schemaless, and you can still index the data in that JSONB column.

There are a very few applications that need distributed scalability beyond what Oracle or PostgreSQL can provide, and those ones need NoSQL. They also need highly skilled competent developers who are capable of reimplementing some needed functionality of RDBMSes at scale.

These PostgreSQL features are relatively recent. The jsonb column type dates back to 9.4, which was released in Dec 2014, less than three years ago. MongoDB had been around for well over five years by that point.

There are few applications that need distributed scalability beyond what PostgreSQL can provide, but I'd argue that it's not uncommon to have problems with Oracle scalability, if you don't have deep pockets for licensing.

> These PostgreSQL features are relatively recent. The jsonb column type dates back to 9.4, which was released in Dec 2014, less than three years ago. MongoDB had been around for well over five years by that point.

It's much much harder to design a reliable engine than a new datatype.

> There are few applications that need distributed scalability beyond what PostgreSQL can provide, but I'd argue that it's not uncommon to have problems with Oracle scalability, if you don't have deep pockets for licensing.

Yes they are, but chances are you don't have that need. You're not Google or Facebook.

You also picked up a really bad database to talk about scalability[1]

[1] https://www.datastax.com/wp-content/themes/datastax-2014-08/...

Postgres had hstore for a few years before that which solved similar use cases, but was only key value (no nested objects)

Plus, hstore can only handle strings, so it's actually pretty bad when weighed up against a json-store

Yep, you can't do stuff like update JSON in place until PG 9.5 (without resorting to a crazy regex, that is).

You also do have to think at least a little about your JSON structure given you can't really use an ORM to query JSONB, and the syntax for JSONB is a bit awkward at times.

My guess...

SQL is a lot for newcomers to grasp on top of learning the rest of their stack. The appeal of "no schema" is most likely what gets them as it seems easier than SQL. Simple things at first seem daunting like: constraints, joins, and indexes. What they fail to see is that doing these database level things in the application layer becomes the final level hell and you get to live it.

People also undervalue their data and it's integrity.

I personally do not like mongo and see zero reason for it except perhaps in some very niche use cases and even then, I'd still choose another document store over it.

Maybe I'm too old now... but SQL is relational algebra translated into some sort of code/language. I did a lot of SQL & relational algebra for my undergrad databases class [which was about 20 years ago now]. Has SQL/DBs been phased out of CS education? Just genuinely curious...

Doesn't really matter if it has or not given how many developers don't have a formal technical education.

Even 20 years ago the database class was optional for us. I didn't take it because networking was more interesting.

Nope, my college had at least 2 classes to cover databases. First one was to learn basics (although it had fun project to implement a DB engine and handle simple SQL), and second one was more about using it in real applications.

The classes were not mandatory so you could technically graduate with CS without knowing anything about databases.

I have an intern who's bout to graduate from a state university and has taken 0 classes on the implementation of compilers or databases. Java, Java. Java.

Sounds like me 10 - 15 years ago.

I'd say don't worry: I almost never use anything I learned in school.

The Java was to shallow as was lots of other stuff.

School is just there to convince your first few employers so you can het a chance to see how it is actually done.

Oh, and to give you the credentials to stop annoying sales guys that are about to convince your boss that "you need Active Directory because your network is slow". (Guys company had botched a certain server install and tried to solve it by selling even mire stuff. )

I graduated from an above average university in the UK in the last 5 years and we had multiple modules covering concepts of relational databases, data warehousing, hands-on MySQL and Oracle including full-stack application projects. There was a lot of Java and little more than a Hello World in C

I finished my BS in CS 7 years ago. I took an elective class on relational databases. We spent about the first 25% of the class on relational algebra & SQL, and then used SQL fairly consistently for the remainder of the class.

Late 1990s: 68k assembler, relational algebra taught via SQL, Prolog, C, and some Ada. And astard hard discrete maths, logic, and formal methods.

Red brick Russell Group British university, not prestigious.

I graduated 7-8 years ago and we did a lot of SQL so I'd surprised if that's not the case today. I think one or two SQL/relational database classes are almost a norm.

I think a web development class I took in college a few years ago spent maybe two or three class periods on SQL. Felt like enough to get by with, and learn more as you go.

A huge amount of people working as developers have no formal CS education whatsoever. In my company I even hear it touted as a perverse point of pride sometimes. (Kind of like, Oh you have a degree? I studied biology and I can still do the same job.)

I have a CS education, but have no real experience. So now, as a biomedical researcher, trying to rapidly prototype for medical devices and developing software is extremely daunting. I don't think these prideful people understand just how far a formal background can go to speed up the process when things get more complex.

The hope is that new technologies would provide some advantage, like prototyping speed. That was certainly true of Ruby on Rails, for example, back when it was the new kid on the block and the "tried and true" frameworks were stuff like Struts or Spring. Yes, that's not a database technology example.

If you think that every tried-and-true database is slower to develop against.

If you actually need certain features like a document store, then Postgres is less mature than MongoDB in that regard.

Have you actually studied the JSONB capabilities of PostgreSQL and related features such as partial indexes? These things can be used at scale and there is at least one company that has millions of partial indexes in production.

And you might want to look at how SalesForce has implemented a highly scalable architecture on top of Oracle RDBMS servers. That includes a document store as well as a dynamic denormalized schema layer that works real well for reporting.

Heck, I've implemented a persistent memcache server on top of SQLITE and it scaled pretty well because modern servers and network infrastructure just happen to do most of the work needed.

It is not easy to learn PostgreSQL well enough to evaluate it, but more and more people are doing so and finding that it is the ideal open source persistence solution for the vast majority of business uses.

Honestly you can say any of these things about MongoDB. Their marketing team sure does. Did you know MongoDB is web scale?

I'm not insulting Postgres (actually a big fan), but Postgres added JSON support after. By that metric, document store in Postgres is less tried-and-true than MongoDB. Does that mean it's the wrong choice? No. Age of product is not always a good qualifier.

I'll take "less mature" over "data loss" every day and twice on Sunday.

Whatever else you might say about Postgres, that community cares about the integrity of its users data, over pretty much every other consideration. I don't think the same can be said of Mongo, or any other "NoSQL" anything.

> I don't think the same can be said of Mongo, or any other "NoSQL" anything.

I feel pretty good about DynamoDB, but the development model WRT to indexes and throughput is what keeps me away.

That's exactly my point. Postgres JSON support is "relatively new" (quoting OP) compared to Postgres. So clearly MongoDB is better right?

Except it's not and age of the product is a bad qualifier.

The MongoDB hate hype train is even worse than the MongoDB hype train ever was.

You can reimplement 95% of the "document model" with a relational database just fine, and you'll actually come out ahead given all its advantages.

Unstructured documents are very rare. Querying arbitrarily against them even more so. For the fields that do need querying in a document, put them apart and add a few indexes and you're good. That's been my experience and I've been around a while.

The problem most developers who think they do really don't need a document store. They're just storing data and fields and relationships.

Reply on news.ycombinator.com