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

371–380 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#371

Post by pas »

michelpp wrote: post #76
zzzcpan wrote: post #63

Earlier quoted context omitted.

They are not overhyped, definitely not as much as old school RDBMS stuff. It's just most engineers can't make good database choices no matter what database they choose. Or more generally they can't make good infrastructure choices, as those are out of their competence and are mostly about things like operations and distributed systems, that take a long time and a lot of experience to get to a level of good decisions.

You cannot be old-school and hype. That's the reason why it is old school. And the people who can't make good database design choices are exactly the kind of people who should be using SQL. Postgres knows how to optimize and plan queries efficiently based on the actual distributions of values in your dataset. These poor choosers should be doing that... by hand? https://www.postgresql.org/docs/11/planner-optimizer.htm…

hipsters are allegedly the cool old-schoolers.

the whole promise of mongo is/was distributed (HA+LB), which was all the rage back then, when AWS AZs dropped like flies every few weeks and scaling was seen as the problem. go fast, break things was the mantra.

and it's still not trivial to do pgsql maintenance without downtime, whereas in a clustered/distributed "solution", you can enjoy certain additional freedoms. this includes the freedom to shoot yourself in the foot (data inconsistency, but you had to fight a bit for that state by promoting a non latest slave to master).

Re: Bye Bye Mongo, Hello Postgres

#372

Post by deadbunny »

DRW_ wrote: post #147
jdietrich wrote: post #136

Earlier quoted context omitted.

The BBC's Online and R&D departments have very interesting blogs, if you like this sort of thing. http://www.bbc.co.uk/blogs/internet https://www.bbc.co.uk/rd

Also: https://medium.com/bbc-design-engineering

Has world class platform for delivering articles. Uses Medium.

I don't even.

Re: Bye Bye Mongo, Hello Postgres

#373

Post by user5994461 »

KaiserPro wrote: post #369
user5994461 wrote: post #219

Earlier quoted context omitted.

What were the issues? You're the first person I hear complain about cassandra for this. Agreed that any database can do that type of data at that volume.

its a 50/50 split between terrible design and horrible support. I've seen cassandra shine when it comes for write optimised loads. Pipe a bucket load of data into gremlin and magic happens. But thats a specific workload, which is pretty rare, and certainly not suited 999:1 read to write ratio. Thats not cassandra's fault, thats the fault of the idiot that chose it, and the boatload of idiots who carried on and added…

Is this all about their enterprise tools? I can't say I've used any of these.

For backups, we found a tool on github to snapshot to S3. Worked fine as far as I know. It's the guys in the office next to me that were handling this, not me, never heard of any major issue.

Re: Bye Bye Mongo, Hello Postgres

#374

Post by bonesss »

orblivion wrote: post #107
nemild wrote: 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…

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 think they're both responses to the same challenges: distributed web enabled applications.

On the server front that means ever increasing complexity with decoupled microservices and latency issues that play nicely with the classic approaches to those domains (static typing, functional programming).

On the data front sites like HN, Reddit, or Facebook need scability more than consistency, and have oodles of 'uninteresting' data that jives nicely with a schemaless document store.

Re: Bye Bye Mongo, Hello Postgres

#375

Post by cmrdporcupine »

csytan wrote: post #68
nemild wrote: 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…

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…

From my POV the rise of 'NoSQL' some years back was tied into a number of things:

- Misunderstanding by most developers of the relational model (I heard a lot of blathering about 'tabular data', which is missing the point entirely).

- The awkwardness and mismatchiness of object-relational mappers -- and the insistence of most web frameworks on object-oriented modeling.

- The fact that Amazon & Google etc. make/made heavy use of distributed key-value stores with relatively unstructured data in order to scale -- and everyone seemed to think they needed to scale at that level. (Worth pointing out that since then Google & Amazon have been able to roll out data stores that scale but use something closer to the relational model). This despite the fact that many of the hip NoSQL solutions didn't even have a reasonable distribution story.

- Simple trending. NoSQL was cool. Mongo had a 'cool' sheen by nature of the demographic that was working there, the marketing of the company itself.

I remember going to a Mongo meet-up in NYC back in 2010 or so, because some people in the company I was at at the time (ad-tech) were interested in it. We walked away skeptical and convinced it was more cargo-cult than solution.

I'm _very_ glad the pendulum is swinging back and that Postgres (which I've pretty much always been an advocate of in my 15-20 year career) is now seeing something of a surge of use.

Re: Bye Bye Mongo, Hello Postgres

#377

Post by AlexCoventry »

untog wrote: post #351
AlexCoventry wrote: post #317

Earlier quoted context omitted.

> the choice between "run an entire data centre ourselves, store everything there" If those were the only two choices, you might be right. But the resources needed for the actual CMS functionality sound modest enough to run independently of the main website. > the client computer that connects to the CMS is just as, or more likely to be compromised That's faulty reasoning.

> That's faulty reasoning. Why? It's an obvious potential point of compromise.

Sorry, I misunderstood. I read it as saying "We're going to get hacked via this other vector, anyway, so why bother?" I see your point, now.

Re: Bye Bye Mongo, Hello Postgres

#378

Post by vincnetas »

int_19h wrote: post #364
dsirola wrote: post #331

Earlier quoted context omitted.

Why wouldn't you be able to take advantage of those systems? I think it's quite the opposite where you can take the advantages without even knowing about it / affecting other parts of the system.

Because of how different they are, taking advantage of them requires using them in specific ways that are also very different. If you have an abstraction layer that hides those differences, it's practically a given that it does so with the lowest common denominator approach, where you get all the flaws of both and none of their unique benefits. (Alternatively, people find ways to use the abstraction layer such that i…

I'm pretty sure you can have one interface for YeSQL an NoSQL.

* getUsers() * saveUser() * listUsers() * deleteUser()

and implementation can implement it in specific way to take advantage of chosen technology. If you have some esoteric use cases they could be handled in special way separate from business code.

Re: Bye Bye Mongo, Hello Postgres

#379

Post by Thaxll »

philliphaydon wrote: post #287
snacktaster wrote: post #245

Earlier quoted context omitted.

I'm sure mongodb is fine and powers a lot of high-profile sites and services. But I've never had a good experience running it or administering it. But I'm also one of the the people that still prefers to run MySQL over PostreSQL just because the tooling is still far superior

Can you give an example of superior tooling or tooling that isn’t good in PostgreSQL compared to MySQL. Serious question. I’m curious cos I mostly use PostgreSQL.

All the Percona tool are for MySQL and there is nothing comparable for PG afaik.

https://www.percona.com/doc/percona-monitoring-and-managemen...

https://www.percona.com/software/database-tools/percona-tool...

Re: Bye Bye Mongo, Hello Postgres

#380

Post by SonnyWortzik »

vonseel wrote: post #212
SonnyWortzik wrote: post #24

I never got around to using Mongo as my main doc db because it was incredibly hard to find a management tool. I now use json supported functions in SQL Server and do not have the need for a different type of database. SQL Server handles my small 'documents db' implementation with the infrastructure of a RDMS. Win win for me. To me Mongo just got popular by mistake way too early. It's like having a celebrity retweet y…

I have seen so many critical articles of Mongodb. Even if I did have a use-case particularly well-suited for it, I would never consider using Mongo. As an aside, I did consider using SQL Server until I looked at the licensing fees. Why would someone choose SQL Server when options like Postgres or MySQL/MariaDB exist? Is there a specific SQL feature (MSSQL or Oracle SQL) provides which is not available elsewhere and w…

Integration. It is all about the integration. M$ platform is so tightly coupled that many companies see the value in spending on this tight integration than spending it on 25 different Engineers to manage their 40 vendors that may be needed to run some of these applications and platforms.

Dealing with one vendor, M$, is better than dealing with 20. You pay for one support package and get all the benefits that come with one platform.

As much as I love open source, I do see the benefit of working with one vendor on all of your stack needs.

M$ reporting systems of SSRS SSIS and other is probably their bread and butter when it comes to DB space. Very few want to spend 60-70 hours a week building complex command line reports where with SSRS and SSIS most of these tools come with a nice GUI that helps you build these reports. Sure there are others that do the same but most required a third party vendor to add to the functionality. For example Apache. With Java and Apache I've had to deal with literally 15 to 20 different vendors just to do the same thing I can do with one vendor. Jenkins, Zookeeper, Camel, Cassandra, Tomcat all under the banner of Apache, but in reality governed by their own set of standards. I mean take a look for your self: https://www.apache.org/index.html#projects-list

Post reply on HN