CouchDB is simple and reliable. You can understand it from day one. I can't imagine why it isn't being used.
Agreed. Used it for many years, had servers crash, unplugged but never ended up with corrupt data.
MongoDB queries don’t always return all matching documents
141–150 of 419 posts
Re: MongoDB queries don’t always return all matching documents
#142If you were inserting changes in the status you'd have much better data and never incur in such issues.
Re: MongoDB queries don’t always return all matching documents
#143If you're currently using MongoDB in your stack and are finding yourselves outgrowing it or worried that an issue like this might pop up, you owe it to yourself to check out RethinkDB: https://rethinkdb.com/ It's quite possibly the best document store out right now. Many others in this thread have said good things about it, but give it a try and you'll see. Here's a technical comparison of RethinkDB and Mongo: https:…
How does it compare to Couchbase? That seems to be lighting the world on fire in that space lately.
RethinkDB's query language is infinitely better (among many things).
Re: MongoDB queries don’t always return all matching documents
#144I hear a lot about MongoDB's reliability issues. How do CouchDB or other document store database compare in terms of reliability and consistency?
CouchDB is rock solid. Used it for 5 years now. Never got corrupted data. Has master-to-master replications. Really shines in sometimes offline operation mode (with re-sync on reconnect).
I use that extensively to build custom replication cluster topoligies (overlapping rings, star, hierarchy) etc.
Has HTTP interface so easy to build clients for.
Transactions are per document only. So have to design your application to accomodate it. Raw single document write speed is not as fast as Mongo or Postgres. But I noticed in a concurrent environment, multiple connections writing it scaled pretty well.
Moreover, CouchDB 2.0 will have built-in clustering from code donated by Cloudant. And it will also have a similar query language like MongoDB (instead of having to use Javascript / Python / Other map-reduce functions).
Re: MongoDB queries don’t always return all matching documents
#145Earlier quoted context omitted.
As a guy who works on ACID database internals, I'm appalled that people use MongoDB. You want a document store? Use Postgres. Why on earth would you use a database that makes so little in the way of guarantees about what results you get from it? I think most people have really low load and concurrency, so things seem to work. When things get busier you're in for a world of pain. Look I get that's it's easy to use and…
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 d…
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...
Re: MongoDB queries don’t always return all matching documents
#146If you're currently using MongoDB in your stack and are finding yourselves outgrowing it or worried that an issue like this might pop up, you owe it to yourself to check out RethinkDB: https://rethinkdb.com/ It's quite possibly the best document store out right now. Many others in this thread have said good things about it, but give it a try and you'll see. Here's a technical comparison of RethinkDB and Mongo: https:…
How does it compare to Couchbase? That seems to be lighting the world on fire in that space lately.
I'm not sure if lack of overbearing marketing speak counts for something, but RethinkDB definitely has that going for it.
I'm not an expert on couchbase (and neither on RethinkDB, to be frank, though I am a huge fan), but here's what RethinkDB has going for it:
- Changefeeds - easily open a persistent connection to the server and get updates when the results of an almost arbitrary query changes.
- Joins
- Expressive query language that is pretty functionally minded, really shines in their clojure/haskell drivers
- Excellent client libraries, well maintained
- Geospatial queries/objects
- Amazing admin interface (it has been amazing for a long time, too, not a recent change)
- First class consideration of replication & sharding (it is not a bolt-on in any way shape or form)
- API-driven cluster configuration
- API driven permissions management (this is relatively new)
- Excellent, easy to follow documentation
There are more things, but this is just what I can think of off the top of my head.
The team at RethinkDB is also just great -- I've met them in person and gotten help from them and they're straight shooters.
They've also got this great project coming up called Horizon: https://www.youtube.com/watch?v=Sb1lH5mvYmU
Also they have a video up with a member of the team building a realtime game with React Native: https://www.youtube.com/watch?v=xRK0SYSgVF0
Maybe someone who is very familiar with couchbase can help make a list... I'll start it off:
- Custom query language
- First class consideration for scale -- replication and sharding
Re: MongoDB queries don’t always return all matching documents
#147Earlier quoted context omitted.
Like with any online community, Hacker News can be kind of an echo chamber where groupthink reigns and alternative points of view aren't encouraged. MongoDB hype has died down here, but there are still some people that are fans. There are some things MongoDB does fairly well: * MongoDB is really easy to use * Document databases can be great and flexible solutions for some kinds of projects * Documentation is fairly g…
About the only thing I agree with is how great their docs are. * Mongo is only easy to learn. Beyond simple demos, it gets harder and harder to use as projects evolve i.e. you have to do a lot of work yourself imo this is a common problem with nosql datastores that isn't exclusive to Mongo * "Document databases can be great and flexible solutions for some kinds of projects": Postgresql has been able to work directly…
But they do make great mugs. Who here doesn't have at least a couple of MongoDB mugs. I don't use MongoDB and still have a bunch from random conferences over the last 3-4 years.
Re: MongoDB queries don’t always return all matching documents
#148Said it before, will say it again... "MongoDB is the core piece of architectural rot in every single teetering and broken data platform I've worked with." The fundamental problem is that MongoDB provides almost no stable semantics to build something deterministic and reliable on top of it. That said. It is really, really easy to use.
As a guy who works on ACID database internals, I'm appalled that people use MongoDB. You want a document store? Use Postgres. Why on earth would you use a database that makes so little in the way of guarantees about what results you get from it? I think most people have really low load and concurrency, so things seem to work. When things get busier you're in for a world of pain. Look I get that's it's easy to use and…
But if you need to scale horizontally use Rethinkdb or Cassandra.
Re: MongoDB queries don’t always return all matching documents
#149Earlier quoted context omitted.
> Why on earth would you use a database that makes so little in the way of guarantees about what results you get from it? Because some people can't stand having to work with SQL,migrations,schema and constraints, it's as simple as that ( That's not my opinion,that's just the rational behind MongoDB). Even if you use Postgres with the Json column type, you still need to write SQL queries and schemas. In the context of…
> Because some people can't stand having to work with SQL,migrations,schema and constraints The thing is, if you actually try and write an app using MongoDB, you will rapidly find that you: 1) Have migrations (except they're going to be some scary ad hoc nodejs script that loop through your document store and modify fields on the fly). 2) Have schemas (except they'll be implicit and undocumented) 3) Constraints (exce…
This.
My company used mongo for years before we got our shit together.
Schmemas were always implicit (until we got our shit together and started defining and enforcing them with Python Schematics).
Migrations were crazy scripts you run in prod or hacks you stick into your code to "transition".
And yes, surprise constrains left and right causing awful anti-patterns. One-character key names to save disk. Hashed values for indexed keys to save memory. Awkward structuring to improve query performance.
The worst part is, we now have tons of important data in these databases and almost no one understands the legacy crazy app logic that makes them tick.
Re: MongoDB queries don’t always return all matching documents
#150Earlier quoted context omitted.
As a guy who works on ACID database internals, I'm appalled that people use MongoDB. You want a document store? Use Postgres. Why on earth would you use a database that makes so little in the way of guarantees about what results you get from it? I think most people have really low load and concurrency, so things seem to work. When things get busier you're in for a world of pain. Look I get that's it's easy to use and…
> Why on earth would you use a database that makes so little in the way of guarantees about what results you get from it? Because some people can't stand having to work with SQL,migrations,schema and constraints, it's as simple as that ( That's not my opinion,that's just the rational behind MongoDB). Even if you use Postgres with the Json column type, you still need to write SQL queries and schemas. In the context of…
Using a document oriented data store as a log aggregator?
Please lord, take him in his sleep.