It's not really this at all; the point is - read the docs, research and understand the tools you are going to use. Choose the ones which fit best. Understand the trade-offs.
no the point is , while its "api" is great , you cant replace your RDBMS with a mongodb , while other solutions like redis or couchdb are "minimalist" they are better suited for what nosql db are for , high availability and scalling.
Unfortunately that's not true: it depends directly on what you are doing with your RDBMS - there are many work loads which are better suited to MongoDB. Obviously there are also many which are not.
Unless I'm out of date, Redis and High Availability don't go together in the same sentence; awesome as it is, it's still a single point of failure.
Comments
It's not really this at all; the point is - read the docs, research and understand the tools you are going to use. Choose the ones which fit best. Understand the trade-offs.
no the point is , while its "api" is great , you cant replace your RDBMS with a mongodb , while other solutions like redis or couchdb are "minimalist" they are better suited for what nosql db are for , high availability and scalling.
Unfortunately that's not true: it depends directly on what you are doing with your RDBMS - there are many work loads which are better suited to MongoDB. Obviously there are also many which are not.
Unless I'm out of date, Redis and High Availability don't go together in the same sentence; awesome as it is, it's still a single point of failure.
> Unless I'm out of date, Redis and High Availability don't go together in the same sentence; awesome as it is, it's still a single point of failure.
Clustering is a work in progress (http://redis.io/topics/cluster-spec , http://redis.io/presentation/Redis_Cluster.pdf), replication is available (http://redis.io/topics/replication).
> Obviously there are also many which are not. that's exactly what i am saying.