Of course, like any technology MongoDB has its strengths and weaknesses. MongoDB is designed for OLTP workloads. It can do complex queries, but it’s not necessarily the best fit for reporting-style workloads. Or if you need complex transactions, it’s not going to be a good choice. However, MongoDB’s simplicity makes it a great place to start.

mongodb——非事务，支持复杂查询，但是不适合报表

This ease of scaling, coupled with exceptional write performance (“All you’re doing is appending to the end of a log file”) and predictable query performance, add up to a high-performance workhorse in Cassandra.

cassandra——分布式扩展好，写性能强，以及可以预料的查询

 

Cassandra does not support Range based row-scans which may be limiting in certain use-cases. Cassandra is well suited for supporting single-row queries, or selecting multiple rows based on a Column-Value index.Cassandra supports secondary indexes on column families where the column name is known. Aggregations in Cassandra are not supported by the Cassandra nodes - client must provide aggregations. When the aggregation requirement spans multiple rows, Random Partitioning makes aggregations very difficult for the client. Recommendation is to use Storm or Hadoop for aggregations.

 

摘自：http://www.infoworld.com/article/2848722/nosql/mongodb-cassandra-hbase-three-nosql-databases-to-watch.html

 

 

Comparison Of NoSQL Databases HBase, Cassandra & MongoDB:

HBase:

Key characteristics:

· Distributed and scalable big data store

· Strong consistency

· Built on top of Hadoop HDFS

· CP on CAP

Good for:

· Optimized for read

· Well suited for range based scan

· Strict consistency

· Fast read and write with scalability

Not good for:

· Classic transactional applications or even relational analytics

· Applications need full table scan

· Data to be aggregated, rolled up, analyzed cross rows

Usage Case: Facebook message

Cassandra:

Key characteristics:

· High availability

· Incremental scalability

· Eventually consistent

· Trade-offs between consistency and latency

· Minimal administration

· No SPF (Single point of failure) – all nodes are the same in Cassandra

· AP on CAP

Good for:

· Simple setup, maintenance code

· Fast random read/write

· Flexible parsing/wide column requirement

· No multiple secondary index needed

Not good for:

· Secondary index

· Relational data

· Transactional operations (Rollback, Commit)

· Primary & Financial record

· Stringent and authorization needed on data

· Dynamic queries/searching on column data

· Low latency

Usage Case: Twitter, Travel portal

MongoDB:

Key characteristics:

· Schemas to change as applications evolve (Schema-free)

· Full index support for high performance

· Replication and failover for high availability

· Auto Sharding for easy Scalability

· Rich document based queries for easy readability

· Master-slave model

· CP on CAP

Good for:

· RDBMS replacement for web applications

· Semi-structured content management

· Real-time analytics and high-speed logging, caching and high scalability

· Web 2.0, Media, SAAS, Gaming

Not good for:

· Highly transactional system

· Applications with traditional database requirements such as foreign key constraints

Usage Case: Craigslist, Foursquare

 

摘自：https://www.linkedin.com/pulse/real-comparison-nosql-databases-hbase-cassandra-mongodb-sahu

 

针对分析任务：

For analytics, MongoDB provides a custom map/reduce implementation; Cassandra provides native Hadoop support, including for  (a SQL data warehouse built on Hadoop map/reduce) and  (a Hadoop-specific analysis language that many think is a better fit for map/reduce workloads than SQL).

http://stackoverflow.com/questions/2892729/mongodb-vs-cassandra