I am thinking about using couchdb or mongodb for my next project. I know mongodb supports both sharding and replication but I can't find any documentation where it says couchdb supports partitioning. So, do you know if couchdb supports partitioning?
CouchDB does not support partitioning, but BigCouch (http://bigcouch.cloudant.com/use) does. BigCouch's partitioning features, among others, will be incorporated into CouchDB over the next few releases, but BigCouch works today.
CouchBase also support sharding. Some of it is rewritten in C for the efficiency and SDK are available for various languages. CouchDB supports only REST and client libraries have to use it. Although, I am not convinced to CouchBase philosophy and I place hope to BigCouch.
Note that CouchBase has its own amin app and does not use futon. It is expected, as the engine supports additional services (sharding) -- the feature set is bigger. But futon is useful for developing views (Couch queries). BigCouch and CouchBase are mostly compatible with CouchDB and you should be able do develop using the former. When the time will come to deploy your app and BigCouch patches are not yet in CouchDB, then you can switch to one of the fork :) Mind the minor differences between them: BigCouch vs. CouchDB and CouchBase vs. CouchDB.
Related
I am currently working in a project which includes migrating a content recommender from MySQL to a NoSQL database for performarce reasons. Our team has been evaluating some alternatives like MongoDB, CouchDB, HBase and Cassandra. The idea is to choose a database that is capable of running in a single server or in a cluster.
So far we have discarded the use of Hbase due to its dependency on a distributed environment. Even having the idea of scaling horizontally, we need to run the DB in a single server for a little while in production. MongoDB was also discarded because it does not support map/reduce features.
We have still 2 alternatives and we have no solid background to decide. Any guidance or help is appreciated
NOTE: I do not pretend to create a religion-like discussion with non-founded arguments. It is a strictly technical question to be discussed in the problem's context
Graph databases are usually considered as best suited for recommendation engines, since a lot of the recommendation algorithms are actually graph based. I recommend looking into Neo4J - it can handle billions of nodes/edges on a single machine and it supports a so-called high availability mode which is a master-slave setup with automatic master selection.
Membase is great for social game due to it's low latency.
As I understand CouchDB is a MVCC system using b+ tree, with a focus on append only design.
(http://guide.couchdb.org/draft/btree.html)
One of the most important scenario of Membase is social game.
Social game has a lot of write operations (50+%).
And a good portion of them are in-place updates.
So why is CouchDB a suitable persistent layer for Membase?
I'd also add that CouchDB's append-only log format really doesn't have much relation to whether application writes are new items or updates. The append-only format gives us much better reliability and performance than an in-place system (like sqlite...which is still quite reliable). It's also much easier to take backups of.
Does Membase NEED an append-only log format? maybe not...does it NEED CouchDB?...YES!
The benefits of map-reduce and indexing as well as eventually consistent replication that CouchDB brings are nothing less than huge for Membase...and the benefits of low-latency, clustering and UI that Membase brings to CouchDB are arguably just as important.
(Disclosure: I work for Couchbase)
Perry Krug
CouchDB has great file formats, great ability to recover from crashes, sophisticated authentication and authorization tools, and a universal, standard, interface: HTTP. CouchDB is poor at low-latency queries, optimized memory utilization, and heavy update speeds (a million per second).
Membase currently has only a simple SQLite file format for persistence, less sophisticated authentication and authorization, using a more obscure protocol. Membase is amazing for low-latency queries, ideal memory utilization, and heavy update speeds.
I think the two complement each other very well. Since the merging effort is coming from core developers in both projects, collaborating together, I expect to see the strengths of both and the weaknesses of neither. Yes, CouchDB is a good persistence layer for Membase.
Money speaks and if there ever was a vote of confidence then here it is, not only from a new lead investor but also from the existing ones as well.
http://www.couchbase.com/press-releases/couchbase-series-C
Besides, don't you think that Membase itself is more than well enough qualified to make an evaluation for such a merger decision?
I started looking into Cassandra and I am really impressed with what it provides, but at the same time I read about how Reddit had a fire drill after migrating to Cassandra, and about twitter deciding to not using it for tweets. Although those were about a year ago or so, I am wondering if the latest version is ready for prime time yet?
Netflix has talked extensively about how they are moving from Oracle and SimpleDB entirely to Cassandra.
Twitter was also at the Cassandra Summit a few weeks ago talking about how they use Cassandra for multiple projects; Reddit had some early problems with being under-capacity, but later said, "Our traffic more than tripled [in 2010], and the transparent scalability afforded to us by Apache Cassandra is in large part what allowed us to do it on our limited resources."
There are many other companies using Cassandra (and DataStax customers are the tip of the iceberg).
In short, Cassandra is solving real problems for real companies. Just don't go into it expecting MySQL and you'll be fine. The DataStax documentation is a good starting point.
(Chris is mistaken about API stability: we were clear that after 0.7 we would be strict about maintaining backwards compatibility, and we have, even for "maintenance" operations like schema updates and mixed-version cluster operation for downtime-free upgrades. I would also note that unlike many "NoSQL" databases, Cassandra has always taken data durability seriously.)
Cassandra is still under very heavy development. The API is still changing, and in that respect, no the product isn't stable. There are still occasional glitches, and a number of kinks to be worked out. It is still a very young product with a long way to reach before actual maturity.
Having said that, Cassandra is quite capable, provided that you are capable of structuring your data in a manner suited to Cassandra's strong points. In other words, if you play to Cassandra's strengths I think you'll find that it's "mature enough" at this point. There are already a number of large sites that use cassandra, and in this regard it's certainly ready for "prime time" (whatever that really means).
It will be years (if ever) before it has the same reputation and stability as a traditional DBMS like MySQL.
What are the major differences between MongoDB and CouchDB, and are there any other major NO-SQL database-servers out there worth mentioning?
I know that CERN uses CouchDB somewhere in their LHC back-end; huge stamp of approval. What are MongoDB - and any other major servers' - references?
Update
One of the major selling points of CouchDB, to me, is the REST-based API and seamless JavaScript integration using JSON as a data-wrapper. Is this possible with any of the other NO-SQL databases mentioned?
There are many more differences, but some quick points:
CouchDB has MVCC (Multi Version Concurrency Control) - each time a document is updated, a NEW version of it is created. Whereas MongoDB is update-in-place.
CouchDB has support for multi-master, so you can write to any server. MongoDB only has 1 server active for write (master-slave) - However: I this this may have changed in the latest release (1.6) so MongoDB may now support multiple servers for writes
To see who's using MongoDB see here (e.g. foursquare, bit.ly, sourceforge....)
To see who's using CouchDB see here.
The most notable other NoSQL database is Cassandra (facebook, twitter)
Then you have HBase, HyperTable, RavenDB, SimpleDB, and more still...
Welcome to some new ground #AdaTheDev covered most of the major ones. There's also Project Voldemort, Tokyo Cabinet/Tyrant, and a whole bunch of wrappers around all of these things. So people are also building MemcacheDB (memcache with a persistence layer).
MongoDB has several hooks to support "REST" APIs (check out "Sleepy Mongoose" and Node.js support). MongoDB and CouchDB have different ways of handling map-reduces (though they are somewhat similar). MongoDB does not have MVCC, but the two systems really have different ways of storing data each with their own set of trade-offs.
MongoDB uses language-specific drivers where CouchDB uses REST (performance trade-off).
For more detailed comparison look here.
MongoDB is probably a little easier for a relational developer to grasp since it uses drivers and has better support for ad hoc queries. CouchDB has very little in common with the old relational ways of doing things.
Both deal with sharding and replication differently.
Having said that, I believe both are conceptually similar enough that it often boils down to personal preference. They are all fun to code with. In fact, we evaluated both for an internal project and went back and forth with our decision.
From MongoDB's webpage I understand that they are not supporting transactions fully, if any.
I wonder if they are ever going to support it in the future so that I can store financial information in them, instead of using a RDBMS for it.
And how is it with CouchDB, do they support transactions?
Neither of these supports transactions in the sense of the more traditional RDMS - and it's unlikely they will - it's a tradeoff, supporting transactions in a distributed system is non-trivial and expensive.
MongoDB does not have ACID properties, and likely never will. CouchDB does give you ACID (I'm not sure if it does by default).
Both allows you to perform simple atomic operations on data, such as simple add/subtract on values though.
See also
Can I do transactions and locks in CouchDB?
MongoDB transactions?
On that note, this podcast with one of the MongoDB guys should give you an brief overview of the problems many NoSQL systems tries to solve, and the tradeoff they make.
Yes, MongoDB does't support transaction out of the box, but you can implement optimistic transactions on your own. I wrote an example and some explanation on a GitHub page. I hope you'll find it useful.
Major development: starting the next version, multi-document ACID transactions with snapshot isolation and all-or-nothing guarantees are supported by MongoDB.
See more in the announcement made by Eliot Horowitz, MongoDB's CTO and co-founder.