Live data from Hacker News

Bye Bye Mongo, Hello Postgres

theguardian.com

161–170 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#161
I really don't get this as an indictment of MongoDB, or their OpsManager product really.

They used the version of OpsManager that doesn't manage the deployment - is specifically not a deployment manager. Mongo does offer a managed version of this software, which the author mentions - with a justification for why they couldn't use that offering. However, I think this was the main mistake that The Guardian made. As the author notes: "Database management is important and hard – and we’d rather not be doing it ourselves." They underestimated the complexity of managing database infrastructure. If they had been attempting to set up and manage a large scale redundant PostgreSQL system, they would have spent an enormous engineering effort to do so as well. Using a fully managed solution - like PostgreSQL on RDS from the beginning would have saved them time. Comparing such a fully managed solution to an unmanaged one is an inappropriate comparison.

Full disclosure - I used to work at MongoDB. I have my biases and feelings w.r.t the product & company. In this case I felt that this article didn't actually represent the problem or it's source very accurately.

Re: Bye Bye Mongo, Hello Postgres

#162
>Since migrating to AWS we’ve had two significant outages due to database problems, each preventing publication on theguardian.com for at least an hour.

This happened to us numerous times before and after we migrated to their Atlas platform. We are a major streaming company with more than 120M registered user. Disclosure, we are moving away from MongoDB as well.

Re: Bye Bye Mongo, Hello Postgres

#163

Earlier quoted context omitted.

This was what was particularly interesting to me - that they went to the effort of writing a purely technical article on the particulars of how parts of their environment operate, and to publish it on their platform even when that's not the sort of content they're known for.

It's not their main platform though: > Digital Blog > A blog by the Guardian's internal Digital team. We build the Guardian website, mobile apps, Editorial tools, revenue products, support our infrastructure and manage all things tech around the Guardian

Ish. From what I can tell, the “Digital Blog” seems to be set up as just another column on the platform.

Re: Bye Bye Mongo, Hello Postgres

#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.

Re: Bye Bye Mongo, Hello Postgres

#165
post #78
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…

I think you'll enjoy the series then, I spent several months investigating and made the same point about JSON and the Javascript-like CLI (plus great Node support, plus savvy marketing). For example: > 10gen's key contributions to databases — and to our industry — was their laser focus on four critical things: onboarding, usability, libraries and support. For startup teams, these were important factors in choosing Mo…

Halfway into part two, this is very good so far. Thank you for the effort you put in (it really does show throughout).

Re: Bye Bye Mongo, Hello Postgres

#166

> 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…

GDPR and Cyber Essentials

Re: Bye Bye Mongo, Hello Postgres

#167

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.

Re: Bye Bye Mongo, Hello Postgres

#168
post #62
post #42

Earlier quoted context omitted.

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

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, Instagram, Twitter, etc. and that's what people were trying to build. Ginormous sites like these are are one of the applications that strongly favors availability/eventual consistency over guaranteed consistency, whereas most other applications are quite the opposite.

Nobody really cares if your Instagram post shows up 10 minutes later in New York than it does in LA, and certainly not if the comments appear in similarly inconsistent order. It's one step above best-effort delivery. However, your bank, hospital, etc. often care quite a bit that their systems always represent reality as of right now and not as of half an hour ago because there's a network problem in Wichita.

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."

Re: Bye Bye Mongo, Hello Postgres

#169
post #42
post #30

The Guardian example was heavily used by MongoDB as a case study to pitch their database to others in 2011: https://www.mongodb.com/customers/guardian https://www.mongodb.com/presentations/mongodb-guardian https://www.slideshare.net/tackers/why-we-chose-mongodb-for-... And reupping my previous, three-part series on MongoDB: On MongoDB NoSQL databases were the future. MongoDB was the database for "modern" web engineer…

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 on real tin, expensive tin, in multiple continents (looking at >million quid in costs)

  o writing the stack in java, getting bored, re-writing it as a micro service, before actually finishing the original system

  o getting bored of writing micro services in java, switching to scala, which only 2/15 devs knew.

  o writing mission critical services in elixir, of which only 1 dev knew. 

  o refusing to use other teams tools

  o refusing to use the company wiki, opting for thier own confluence instance, which barred access to anyone else, including the teams they supported

Re: Bye Bye Mongo, Hello Postgres

#170

My takeaways: 1. Stop. Trying. To. Build. Your. Own. Cloud. A pizza shop doesn't build their own cars to deliver pizzas. 2. There's no such thing as hassle-free anything, unless you are paying someone else to deal with the hassle. Sales teams lie. 3. Justifying an untested idea with "but it's modern technology" is going to backfire. Follow established patterns with good track records. 4. Writing your own in-house beh…

Point 5. I'm not a software/application person... can you expound on how else you would interact with a DB if not directly?
Post reply on HN