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

Goodbye MongoDB, Hello PostgreSQL (2015)

developer.olery.com

Post reply on HN
Print view View original

91–100 of 172 posts

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#91

Post by saturn_vk »

dheera wrote: post #33
bildung wrote: post #17

Earlier quoted context omitted.

In what scenarios does one work on data without any relations? Honest question - perhaps I'm too used to think in SQL but even with e.g. a completely flat bunch of documents one usually needs at least access control (i.e. document owners, which is a relation).

When you get piles of JSON data from somewhere else (e.g. an API response from a provider you subscribe to) and want to store all of it intact, query it, and that somewhere else may insert new fields at any time in the future without telling you. When you have multiple types of objects with differently populated fields that you want to store in a single collection and query across them in currently unknown ways, and…

That's what I'm using postgresql for, among other things. The only drawback I've ran into so far is that it sometimes doesn't pick the proper index for a specific query.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#92

Post by NicoJuicy »

bildung wrote: post #17
menzoic wrote: post #11

Earlier quoted context omitted.

What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?

In what scenarios does one work on data without any relations? Honest question - perhaps I'm too used to think in SQL but even with e.g. a completely flat bunch of documents one usually needs at least access control (i.e. document owners, which is a relation).

Microservices / DDD

"Relations" are stored as an object, not a separate table.

See: AggregateRoot

Eg.

Document: { metadata: {}, owner: {}, sharedWith:{}}

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#93

Post by HelloNurse »

threeseed wrote: post #66
bildung wrote: post #17

Earlier quoted context omitted.

In what scenarios does one work on data without any relations? Honest question - perhaps I'm too used to think in SQL but even with e.g. a completely flat bunch of documents one usually needs at least access control (i.e. document owners, which is a relation).

Most data in large enterprises e.g. telcos, banks, insurance etc are not stored in a single data warehouse with well-defined relationships. They are in multiple disparate silos of which their EDW is just one. It's why Data Lakes become so commonplace because it was an easy way to just get all of the data out of the silos into one place so that the business could attempt to join between them. And it's why MongoDB (and…

If an enterprise wants to "get all the data out of the silos", unstructured storage is only "friendly" to the temptation to be sloppy in such an export.

Not only missing or corrupted individual columns, but completely incoherent and arbitrary complex document structures. If "no-one knows the schemas and no-one knows how to join between them" the data lake project has already failed to provide value.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#94

Post by dijit »

threeseed wrote: post #63
soulchild37 wrote: post #4

MongoDB is like snapchat for database

Would've been funnier and timely about a decade ago.

Make a joke similar to this a decade ago (as I did) and developers would jump on you for being "old" or "not getting it".

So, not really.

But I agree that this joke is an old one and doesn't really have a place in a constructive discussion on hackernews.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#95

Post by HelloNurse »

amenod wrote: post #41
menzoic wrote: post #11

Earlier quoted context omitted.

What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?

I had a project where I just needed to be saving a constant flow of data (id + 100 bytes records) somewhere, no persistence needed, no sharding (single machine) - but lots of it. I first turned to Redis and it worked nicely, but since I had PostgreSQL running, I made a performance test with it too. To my surprise, once I optimized both (memory only, pg WAL disabled, persistent connections,...) there was almost no dif…

Your data-saving test was probably limited by how fast you could save to disk a roughly equal amount of data with the two databases; queries might work and perform more differently.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#96

Post by fhunt »

@dang, I found this in the guidelines: Please don't post shallow dismissals, especially of other people's work.

I see good critical comments here but also many shallow dismissals from people who just sneer at the work of all software engineers who created MongoDB. Why is such behavior tolerated in any Mongo thread and why do these people never face any consequences?

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#97

Post by tgv »

bildung wrote: post #17
menzoic wrote: post #11

Earlier quoted context omitted.

What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?

In what scenarios does one work on data without any relations? Honest question - perhaps I'm too used to think in SQL but even with e.g. a completely flat bunch of documents one usually needs at least access control (i.e. document owners, which is a relation).

I've got a project where one part of the application is just for editing a medium-sized, hierarchical object. So it's easiest to just get it from the database as a whole, and update it like that. It's also very easy to understand for the frontend programmers. The other part gets data from users and dumps it in its entirety in another table. Then the analysis part simply retrieves them all (at most a few thousand objects), and can build graphs, or whatever visualization with them. There's not a single JOIN involved, and updating is simple. If it goes beyond that, it's time to look at a relational database, either for performance reasons or because the API becomes cumbersome.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#98

Post by swebs »

fhunt wrote: post #96

@dang, I found this in the guidelines: Please don't post shallow dismissals, especially of other people's work. I see good critical comments here but also many shallow dismissals from people who just sneer at the work of all software engineers who created MongoDB. Why is such behavior tolerated in any Mongo thread and why do these people never face any consequences?

That doesn't work here. You have to send an email to hn@ycombinator.com

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#99

Post by dijit »

schoolornot wrote: post #61
anticristi wrote: post #5

I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.

Postgres doesn't have multi-master. That's the problem.

Pedantically; it does, but you pay for it: https://www.2ndquadrant.com/en/resources/postgres-bdr-2ndqua...

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#100

Post by collyw »

ZephyrBlu wrote: post #40
bushbaba wrote: post #32

Earlier quoted context omitted.

Latency at p99 is substantially better at scale with a key value lookup in nosql over postgresql. Thing is most people don’t have scale these days. You can get a single box with hundreds of logical cores and many hundreds of TiB of locally attached ssd. Until you exceed that you don’t necessarily have scale.

Distributed databases like cockroachDB are KV stores.

MySQL had a Berkley DB engine underneath, that's a KV store too. I wouldn't say that makes /made MySQL a key value store.
Post reply on HN