MongoDB queries don’t always return all matching documents

Re:MongoDB queries don’t always return all matching documents by tomphoolery on Tuesday June 07, 2016 @06:58PM (#11858686)

Postgres wasn't always a great document store...there was definitely a time period where if you wanted to take a document-oriented approach to data modeling, MongoDB was a good way to go. JSONB was only added in the last minor version of Postgres, and while the JSON and HSTORE types were available, it didn't give you quite the same speed. Now that JSONB is a thing, I think the two databases are more comparable as a document store.

[ Parent | on HN ]

Re:MongoDB queries don’t always return all matching documents by im_down_w_otp on Tuesday June 07, 2016 @07:06PM (#11858743)

Is that actually true? I mean the part about Postgres might be, I don't know. But was there a time when MongoDB was a good way to go?

Was there ever a time when it actually worked consistently well at something that was database shaped? Because I started dealing with it in ~2010 I think, and it wasn't a suitable database for anything other than toy projects or throw-away data back then, and while it's many versions newer, it still appears to be pretty fast and loose with its supposed system guarantees.

There was a point when they raised $100+ Million in funding that I thought they'd take that money and actually build a database. At least as recently as last Summer that wasn't a reality yet.

[ Parent | on HN ]

Re:MongoDB queries don’t always return all matching documents by Lazare on Tuesday June 07, 2016 @08:01PM (#11859038)

> But was there a time when MongoDB was a good way to go?

Not in any way, shape, or form. Keep in mind, as bad as it is now, it was vastly worse when it launched.

[ Parent | on HN ]

Re:MongoDB queries don’t always return all matching documents by themartorana on Tuesday June 07, 2016 @08:18PM (#11859125)

A text/blob field with a normalized key column or two were always vastly superior. We're talking about data loss at an incredible level. I mean, a new Jepsen test comes out and this community goes bonkers over how database X might suffer a split-brain problem for a few milliseconds under an extreme condition but Mongo on a single instance has never been safe, and people are making excuses for it.

[ Parent | on HN ]

Re:MongoDB queries don’t always return all matching documents by sciurus on Tuesday June 07, 2016 @09:52PM (#11859483)

Somewhat surprisingly, recently Aphyr came close to recommending MongoDB. From https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5 :

> I’ve hesitated to recommend RethinkDB in the past because prior to 2.1, an operator had to intervene to handle network or node failures. However, 2.1’s automatic failover converges reasonably quickly, and its claimed safety invariants appear to hold under partitions. I’m comfortable recommending it for users seeking a schema-less document store where inter-document consistency isn’t required. Users might also consider MongoDB, which recently introduced options for stronger read consistency similar to Rethink–the two also offer similar availability properties and data models.

[ Parent | on HN ]

Re:MongoDB queries don’t always return all matching documents by talvola on Tuesday June 07, 2016 @08:26PM (#11859158)

I've been using Postgres/jsonb for JSON document store. It works OK - the query capabilities are still a little rough (9.5 is better than 9.4), and some frameworks like Loopback don't support JSON in Postgres yet (not sure which ones do), but it's definitely capable and reliable...

[ Parent | on HN ]

Re:MongoDB queries don’t always return all matching documents by philliphaydon on Tuesday June 07, 2016 @09:54PM (#11859490)

The support in .net for Jsonb is awesome. Support by npgsql and a document database api written on top called Marten.

[ Parent | on HN ]