Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bye Bye Mongo, Hello Postgres

theguardian.com

Post reply on HN
Print view View original

171–180 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#171

Post by Something1234 »

threeseed wrote: post #146
csytan wrote: post #68

Earlier quoted context omitted.

I think you're asking the wrong question. The question should be: How did MongoDB become so successful? IMO, the reason is that newer developers faced the choice of learning SQL or learning to use something with a Javascript API. MongoDB was the natural choice because they excelled at being accessible to devs who were already familiar with Javascript and JSON. Not only that, their marketing/outreach efforts were also…

None of this makes sense. ORMs have existed for decades so developers can use a SQL database just fine without knowing the language. So it's definitely not this. It's more likely because Mongo is (a) is extremely fast, (b) the easiest database to manage and (c) has a flexible schema which aligns better with dynamic languages which are more popular amongst younger developers.

To use an ORM and not get crap performance you still need to understand sql, and what is happening under the hood.

Re: Bye Bye Mongo, Hello Postgres

#172

Post by adrianpike »

femto113 wrote: post #142

> Dynamo didn’t support encryption at rest. This requirement made some sense in a world where a rogue employee might yank your database server out of a rack and walk off with it, but I don't understand why this is still considered relevant in an AWS context. First of all your data is never really "at rest", a huge point of Dynamo is that the data is always available (at least 99.999% of "always" anyway). Second "at r…

At least for those of us in the healthcare space, HIPAA compliance demands it.

The regulations and the attack risk aren't always in alignment unfortunately.

Re: Bye Bye Mongo, Hello Postgres

#173

Post by orblivion »

acjohnson55 wrote: post #129
orblivion wrote: post #107

Earlier quoted context omitted.

I found it a little funny that NoSQL started becoming popular during at least some of the same years that static typing starting becoming popular (again).

I don't see it that way -- I feel like NoSQL's rise was more or less coincident with the adoption of Rails, Django, and Node over Java. The surge in interest in new static languages has mirrored the resurgence of Postgres, right around version 9.4 (and JSONB).

Could be. I haven't thought too deeply about what happened when.

Re: Bye Bye Mongo, Hello Postgres

#174

Post by kstrauser »

indigodaddy wrote: post #164

Why would you delete the MongoDB's so soon after the migration? What if things look great for a few hours/days, but then things go horribly wrong? I suppose they still had Mongo backups too? Just unsure why you wouldn't leave those around for awhile.

Guessing:

- They'd been running the two systems in parallel and comparing their outputs for months. By the time the pulled the plug, they were confident that PostgreSQL was working fine.

- They had written systems to copy data from the MonogoDB-backed service to the one running on PostgreSQL. Once they started treating PostgreSQL as the official store of record, they'd be faced with either writing another system to mirror PostgreSQL back to MongoDB or committing to lots of double entry. Either of those sound painful.

Re: Bye Bye Mongo, Hello Postgres

#175

Post by qaq »

KaiserPro wrote: post #169
pjmlp wrote: post #42

Earlier quoted context omitted.

Fashion driven development and not understanding how to actually make use of SQL.

At "large financial news company" we had a "designed for the CV" tag that applied to stupid architectural decisions (of which there were many) One of the biggest and most expensive was using Cassandra to store membership details. Something like 4 years of work, by a team of 40, wasted by stupid decisions. They included: o Using Cassandra to store 6 million rows of highly structured, mostly readonly data o hosting it…

well Elixir might have being a good decisions :)

Re: Bye Bye Mongo, Hello Postgres

#176

Post by kstrauser »

astine wrote: post #167
InGodsName wrote: post #86

While we are here. I know HN hates mongo. But lemme ask this question, what are the things in which mongo is better than postgres?

For a serious note, there are occasionally situations where I have to take in a lot of data that I know nothing about. Sooner of the time this data is either in json or readily convertible to json so losing it into a mongodb database and poking around in it is a reasonable preliminary step to whatever the more permanent solution should be.

Would PostgreSQL + JSONB work for you there?

Re: Bye Bye Mongo, Hello Postgres

#177

Post by revel »

jack6e wrote: post #35

Specific technology choices aside, this was an incredible write-up of their migration process: thorough, organized, readable prose about a technical topic. It is helpful to read how other teams handle these types of processes in real production systems. Perhaps most refreshing is the description of choices made for the various infrastructure pieces, because it is reasonable and real-world. Blog posts so often describ…

Totally agreed. This is pretty much the definitive guide on how to perform a high stakes migration where downtime is absolutely unacceptable. It's extremely tempting, particularly for startups, to simply have a big-bang migration where an old system gets replaced by something else in one shot. I have never, ever seen that approach work out well. The Guardian approach is certainly conservative but it's hard to read that article and conclude anything other than that they did the right thing at every step along the way.

Well done and congratulations to everyone on the team.

Re: Bye Bye Mongo, Hello Postgres

#179

Post by tschellenbach »

mrsuprawsm wrote: post #80

>“But postgres isn’t a document store!” I hear you cry. Well, no, it isn’t, but it does have a JSONB column type, with support for indexes on fields within the JSON blob. > approximately 2.3m content items. I had a previous project where we did a similar thing (except with HSTORE instead of JSONB) and it exploded rather dramatically (very simple queries took multiple minutes or timed out entirely) after around 30m ro…

Yeah a well configured postgres instance will usually only start to have issue with more than a billion rows.

Re: Bye Bye Mongo, Hello Postgres

#180

Post by bunderbunder »

da_chicken wrote: post #168
untog wrote: post #62

Earlier quoted context omitted.

IMO there is still a place for schema-less document databases. It's just that Postgres's JSON columns mean you can get the best of both worlds, which makes Mongo look weak by comparison.

I would rather say, "Postgres's JSONB provides a hybrid compromise that may meet the needs of many users." JSONB feels like it's closer to creating more complex data types that are less primitive than those that SQL currently allows. The real driver of the NoSQL movement, I believe, was that everybody wanted to be the next big social network or content aggregation site. Everybody wanted to be the next Facebook, Insta…

> The question is, "If my data store isn't sure about the answer it has, what should it do?" RDBMS says, "Error." NoSQL says, "Meh, just return what you have."

Even that's too simplistic. For most RDBMSes, the answer depends on how you have it configured, and usually isn't "Error". If you're using a serializable transaction isolation level, it usually means, "you might have to wait an extra few milliseconds for your answer, but we'll make sure we get you a good one." Other isolation levels allow varying levels of dirty reads and race conditions, but typically won't flat out fail the query. This is probably the situation most people are working under, since, in the name of performance, very few RDBMSes' default configurations give you full ACID guarantees.

To the "DB in NY knows something different from DB in LA" example, there are RDBMSes such as the nicer versions of MSSQL that allow you to have a geographically distributed database with eventual consistency among nodes. They're admittedly quite expensive, but, given some of the stories I've heard about trying to use many NoSQL offerings at that kind of scale, I wouldn't be surprised if they're still cheaper if you're looking at TCO instead of sticker price.

Post reply on HN