Ravendb (www.ravendb.net) is a solid competitor.
[deleted]
Failing with MongoDB
51–60 of 128 posts
Re: Failing with MongoDB
#52Ravendb (www.ravendb.net) is a solid competitor.
"Raven is an Open Source (with a commercial option) document database for the .NET/Windows platform."
I'm not sure it's a competitor at all. RavenDB is a CouchDB clone for .Net that requires a commercial license for proprietary software.
Re: Failing with MongoDB
#53Earlier quoted context omitted.
Well here's a fuck you back from a dev: my time is finite and everyone wants a piece of it; If I can save an hour a day by never having to think about my database? If I can shave a week or two of labor off a project? It's really easy to work with. This is why people keep using it.
What about all the time you'll waste debugging your app because you can't make good assumptions about the structure of your data?
Isn't that the same argument some use against dynamic typing in programming languages?
Re: Failing with MongoDB
#54Earlier quoted context omitted.
Sorry, this is a pretty poorly written blog post. We're definitely using sharding+replica sets. Replication of any kind won't help you with a high write load as secondaries have to apply the same number of writes as primaries.
They seem to be very aware of the problem and focused on solving it as soon as possible. I guess it's just a matter of time. Compared to how long it took MySQL to mature into a stable platform I've been pretty impressed at their responsiveness and quick improvements so far :).
seems from the comments in the post that 10gen went out of it's way to be helpful in resolving the issues ???
Re: Failing with MongoDB
#55Earlier quoted context omitted.
Migration tools are great once you stop changing the schema very often like it happens when a project starts. This of course depends on the project... if you can have a full design from the start, it's probably going to work too. If you don't know the exact requirements or way to get there - not so much.
If you don't know the requirements to the point that you can't even design a data structure for your project... A schemaless database is NOT going to save you.
Ever hear the term "exploratory programming"?
Re: Failing with MongoDB
#56Why is a database that fails so easily and most of the time even loses data so popular? Is it really all just a huge marketing budget?
So what's the preferred alternative noSQL wise?
MongoDB is flaky. CouchDB is a maintainability nightmare, so I hear.
Riak? Cassandra? Or does everything else have some other equally huge down-side?
Re: Failing with MongoDB
#57Earlier quoted context omitted.
Why do I get the feeling that you're an op and look down on development people? If that's really true, try to start developing some project and see how you like frequent schema changes, trying to synchronise schemas with peers, resolving relation issues when merging features, etc. On the other hand if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care…
I've been dev since I graduated. I had been everything else during my intern (dev, qa, test-automation developer, tools dev, build engineer, integration engineer, etc). Are you saying that Rails schema migration can only solve 10% of your migration needs? That kinda suck bro.
Are you saying that Rails schema migration can only solve 10% of your migration needs?
Rails is a bad example here as their primitive migration-system still forces the developer to write those stupid migrations by hand.
Django/South just auto-generates them which removes a huge chore from the daily development workflow.
Re: Failing with MongoDB
#58Maybe there's a niche for "PostgreNoSQL", a layer atop Postgres that you start using like a NoSQL solution. (Perhaps, it's string keys and JSON blob values.) It's not very efficient, except for simple keyed lookups, but it works enough for a quick start.
Then, as you use it, the system optimizes itself (or makes suggestions) based on actual access patterns. A subset of objects could be a formal, indexed table? Have it happen automatically or offer the SQL as a suggestion.
Re: Failing with MongoDB
#59Why is a database that fails so easily and most of the time even loses data so popular? Is it really all just a huge marketing budget?
So what's the preferred alternative noSQL wise? MongoDB is flaky. CouchDB is a maintainability nightmare, so I hear. Riak? Cassandra? Or does everything else have some other equally huge down-side?
They all have their warts. For every story like this, there are petabyte deployments of your favorite datastore that work fine.
For every X sucks article, ther is Y is awesome.
In the nosql world the only way to choose is around the problems they solve... They are each specializing and optimizing for certain nitches. mongo is the most mysql-esque, but dosnt do things that redis, couch or cassandra do that you may need.
There is no clear winner (fortunately or unfortunately dependng on what you were hoping for)
Re: Failing with MongoDB
#60Earlier quoted context omitted.
The the data model contributes to it's popularity. A document store with indexes on document fields is very convenient for several types of applications.
It's interesting that couchdb gets little love (as evidenced by google trends), but it has document storage by index, easy enough to install, copy on write so has no global lock, sharding with bigcouch, and all client access is entirely REST... it may be couch is a little hard to grok, I dunno.
It isnt packaged and marketed as cleanly. It takes hunting and learning on your own to get good with couch, and map reduce is no where as easy to get started with as mongo queries (although the addition of unql may improve things next year).
Also there is no single, central steward and authority on couch. All of this stymies traction and confidence even though the tech is great.