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

421–427 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#421

Post by theshrike79 »

Noumenon72 wrote: post #309
KaiserPro wrote: post #169

Earlier quoted context omitted.

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…

"real tin"?

Actual physical hardware, bought by the company and installed in a rack somewhere.

Not ephemeral Cloud Stuff rented from some company.

Re: Bye Bye Mongo, Hello Postgres

#422

Post by zorga »

int_19h wrote: post #420
zorga wrote: post #419

Earlier quoted context omitted.

> Have you ever implemented an ORM? I did. Several actually, which is why I know what I'm talking about; I've explored this area extensively. When Fowler first released PEAA I dug and went nuts and spent years coding up and exploring all the possible approaches and figuring out which ones I liked and why and which ones I didn't and why. > Same thing with high-level database abstractions - they're all either leaky in…

Any language with named tuples has a type system that is sufficiently expressive to handle joins without any sort of impedance mismatch. So, the only reason to avoid them is exactly the one that I cited earlier - the underlying implementation difference between databases.

> Any language with named tuples has a type system that is sufficiently expressive to handle joins without any sort of impedance mismatch

Incorrect. Named tuples will give you nothing back but a result set; the impedance mismatch refers to the mismatch between result sets and a domain model; getting tuples back doesn't remotely address this problem. I'd suggest you don't understand what the objection relational impedance mismatch problem actually is.

It's not a type system problem, it's fundamental mismatch between the relational paradigm and the object oriented paradigm. If a domain model has customers and addresses, and you do a relational query that joins the customer table and address table to return only the customer name and address city, the resulting set (name, city) doesn't map to the domain objects and isn't enough data for the domain model to load either of those objects which may contain various business rules. This is what the impedance mismatch refers to, relational projections of new result sets simply do not map to the OO way of doing things. Joins that create new projections are a relational concept that have no place in the object oriented world view: objects don't do joins, and object queries don't return differently shaped objects.

Hacks like partial loading of domain objects are attempts to mitigate the impedance mistmatch, but they do not solve it; they cannot solve what is a fundamental difference between two different ways of seeing data. Data is primary in the relational model and its shape can change on a per query basis, this is incompatible with the object oriented view of the world in which whole objects are primary and data is encapsulated and thus hidden.

The object relational impedance mismatch does not refer to a language problem, it refers to a difference in paradigm between OO and relational. It exists in all language regardless of the languages abilities and it's not a problem that can be solved, only mitigated, if you want to use both paradigms. You can solve the problem by avoiding using two paradigms, by either bringing the relational model into the application and not using OO or by using an object database.

Re: Bye Bye Mongo, Hello Postgres

#423

Post by Too »

zorga wrote: post #402
mmsimanga wrote: post #92

Earlier quoted context omitted.

I don't have any links to prove my point but I suspect we need to thank Mongo for pushing the traditional SQL databases to support JSON.

Why? Seriously, JSON is lame, it's an idiotic trend, a fashion from the UI that's infected the back end for no gain whatsoever for anyone not using JavaScript. XML is better and we've just watch JSON slowly reinvent everything XML already had.

I think he meant json as a data model, ie nested objects, arrays and PODs, rather than json as a textual representation..

Re: Bye Bye Mongo, Hello Postgres

#424

Post by ownagefool »

wwweston wrote: post #59
_gi12 wrote: post #39

Document DBs are like blockchain projects - overhyped and worse than existing solutions for nearly every use case. Why do ostensibly smart engineers keep falling for this stuff?

For one thing, a good chunk of what happens in the industry isn't particularly well described by the term "engineering," which in my mind describes someone who is well-trained and experience-versed in relevant scientific models for the application domain and the dynamics of relevant "materials" and their interaction that can be composed into a solution. It might be the term "craft" better describes a lot of software…

It's also largely a fact that we're paid better for following hypes, at least in the UK. Thus a smart "engineer" who also cares about their bank balance pretty much has to use everything new to stay relevant.

Further, most of the use cases are fairly shallow, so it doesn't actually matter that much, and you'll be paid more to paper over the cracks.

We need to change the market, but it doesn't like the strong and stable engineers are getting lead roles to pay more strong and stable engineers to build boring tech, despite that actually being better for most businesses.

Re: Bye Bye Mongo, Hello Postgres

#425

Post by k_bx »

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…

> The question should be: How did MongoDB become so successful?

Ability to store Algebraic Data Types and values with lists without a hassle of creating a ton of tables and JOINs. Postgres added JSON support since, plus there are now things like TimescaleDB, which didn't exist previously.

Re: Bye Bye Mongo, Hello Postgres

#426

Post by kstrauser »

int_19h wrote: post #420
zorga wrote: post #419

Earlier quoted context omitted.

> Have you ever implemented an ORM? I did. Several actually, which is why I know what I'm talking about; I've explored this area extensively. When Fowler first released PEAA I dug and went nuts and spent years coding up and exploring all the possible approaches and figuring out which ones I liked and why and which ones I didn't and why. > Same thing with high-level database abstractions - they're all either leaky in…

Any language with named tuples has a type system that is sufficiently expressive to handle joins without any sort of impedance mismatch. So, the only reason to avoid them is exactly the one that I cited earlier - the underlying implementation difference between databases.

I don't think there's a point in arguing this further. The other poster seems unwilling to understand that there are differences it databases within a category, let alone that there are multiple categories of databases with entirely different characteristics.

Re: Bye Bye Mongo, Hello Postgres

#427

Post by idbentley »

wftglf wrote: post #250
idbentley wrote: post #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…

Fair criticisms! It's true if we'd used Mongo Atlas or something similar it would likely have been a different story - often the MongoDB support spent half the time on the phone trying to work out what version of mongo, opsmanager etc. we were running. Re criticism of OpsManager - I think this is fair, given the sheer number of hoops we had to jump through to get a functioning OpsManager system running in AWS - no pr…

Support at this scale is a hard game. I know some of the guys who work over there, and they make a valiant effort.

Training is exceptionally hard. Databases are hard to manage, and it takes years to learn to diagnose their function on unknown hardware / software.

This all being said, "no provided cloudformation, AMIs etc." is no bueno - not a good experience for the user.

If you haven't used Mongo with WiredTiger, you really haven't used it at it's best.

Post reply on HN