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

251–260 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#251

Post by mopierotti »

quietbritishjim wrote: post #210
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…

> IMO, the reason is that newer developers faced the choice of learning SQL or learning to use something with a Javascript API. The thing I dislike about this type of comment – although I now notice yours doesn't explicitly say this – is the implication that devs don't like SQL because they're lazy or stupid. Well, sometimes that is probably true! But there are some tasks where you need to build the query dynamically…

To add to the pile of responses: in Scala, Slick is great library that lets you compose sql queries and fragments of queries quite effectively. (http://slick.lightbend.com/)

At my company we built a UI on top of Slick that lets users of our web app define complex triggers based on dynamic fields and conditions which are translated to type-safe SQL queries.

Re: Bye Bye Mongo, Hello Postgres

#252

Post by kureikain »

The article is very well written. Their team do leverage great tooling for thing such as Gor. I love Gor. I used it + Mongo OpsLog when migrate from AWS -> DigitalOcean and eventually have to migrate back to AWS because DigitalOcean cannot deliver good performance as AWS and they throtle CPU(lots of steal CPU).

OpsManager is great for team that don't have dedicated devops I think and have great dashboard/visualization.

However, run your own MongoDB is very easy. Not like Postgres(unless you used RDS). However, when using RDS, you still have downtime when upgrading db, it still have a small amount of time the standby in MultiAZ is promoted to master, DNS is updated, and during that yourcurrent primary is not writeable or even not available. MongoDB is way easier to operator. You add/delete/node on fly and client auto discover network topology. Plus https://docs.mongodb.com/manual/administration/production-no... this links give great info to tune it: thing like run on XFS, mount with notatime options...puts opslog on high iops volume etc...

Peformance isn't a factor to pick your database much nowsaday. They looks great on the benchmark. However, try for yourself before pick one on your workload. Postgres does has its own ward.

Pick a database based on how well your team confident with it, how does the database help you move fast enough or deliver business value. Don't follow the hype or silly benchmark.

Re: Bye Bye Mongo, Hello Postgres

#253

Post by dimgl »

Thaxll wrote: post #225

It's not a great article tbh, it's well written but it shows the clear lack of knowledge running a backend. The title should be "we didn't know what we were doing so we switched to a managed DB" I mean yeah who knew that blocking NTP therefore time drifting would break everything... For those criticizing MongoDB, Fortnite generates $3B/year and runs on MongoDB, you should tell them it's a mistake and that they should…

I thought the article was well written but I have to agree about the MongoDB use case by Epic. Mongo has its place and it is mature enough that it can handle itself in a production setting.

That being said they had a massive outage due to a MongoDB issue.

Re: Bye Bye Mongo, Hello Postgres

#254

Post by paulie_a »

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.

Postgres is faster at json than mongo. Also the pipeline query strategy of mongo is terrible to deal with. A schema should not be flexible. Now I have to write a bunch of code to handle things that should have been enforced by the database. Postgres is incredibly easy to manage with actual default security. I know the mongo tutorial says to not run the default configuration, then why is it the default configuration. It's so easy to manage anyone can take it over for ransom.

Mongo literally has no upside vs postgres.

Re: Bye Bye Mongo, Hello Postgres

#256

Post by luord »

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…

This is the first thing I noticed too. This was an excellent read.

Re: Bye Bye Mongo, Hello Postgres

#257

Post by konschubert »

revel wrote: post #177
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 th…

I agree, but it looked them a year if I am reading the article right.

In most early stage startups, that would be an unacceptable loss of time.

So I don't judge them for doing a one-shot migration even if it causes an hour of downtime.

It all depends on the business.

Re: Bye Bye Mongo, Hello Postgres

#258

Post by dguo »

StreamBright wrote: post #134
bdcravens wrote: post #37

Earlier quoted context omitted.

When was the last "Goodbye X, Hello Mongo" article?

Not sure, but there was Goodbye MySQL, Hello Postgres and Goodbye Postgres, Hello MySQL (same company did it actually) for sure. It is kind of weird why engineers are so obsessed with tools though.

I believe you're thinking of Uber: https://www.percona.com/live/plam16/sessions/relational-data...

Re: Bye Bye Mongo, Hello Postgres

#259

Post by wftglf »

z92 wrote: post #36

Wanted to read something about the cost impact, and performance impact after migration. But couldn't find that in the article.

Hi! I'm one of the authors. Good point, we should add something on that. Briefly our mongo db setup was running on 3 r4.xlarge instances which comes to around $5000/year with storage, plus the cost of opsmanager, which I think was around £40,000 including the support contract.

In Amazon it's harder to compare directly as the support contract is paid across all of our accounts, but we're spending around $13,000 for a highly available db.r4.xlarge postgres instance.

Performance wise, querying without an index is SLOW, basically not worth it - as we end up doing a scan of the entire database. Fortunately we don't need to do this as we can usually rely on the guardian content API for proper searching stuff. The average API (a Scalatra app) response time reaches 150ms at 'peak time'. This isn't a high-performance use case - around 1000 requests/minute at 'peak' time.

Post reply on HN