No SQL

1. Amazon DynamoDB(Lienced)
Pros
1)Scalable:There is no limit for the data.
2)Distributed:Amazon DynamoDB scales Horizontally and seamlessly scales a single
table over hundreds of services
3)Flexible:It doesn t have fixied schema.Instead each data item may have
different no of attributes.
4)Easy administration :Hosted by Amazon and receives fully managed services from
Amazon.
5)Cost Effective
6)Automatic Data Replication
7)Low learning curve.
Cons
1)64KB limit on row size.
2)1MB limit on querying.
3)Deployable Only on AWS.
4)Cost Effective(Consistancy,Additional Storage).
5)Doesn't supported on Foregin keys,server side scripts and triggers.
Big Table(Google to Store Big Data )
Pros
1)It is a distributed storage system and very large data which can be used in
Goofle earth,Google Finance ...etc.
2)There is no limit for row length.
3)Unlimited number of connections can be kept for each record.
4)With this approach, disk access is reduced.
5)Cost is low in contrast to RDBMS.
6)Offers high availability.
Cons
1)Data loss can occur.
1)Lack of advanced features for data security.
2)Possibility of multiple copies of same data.
3)Secondary index is not supported.
CONCLUSION
Richer than simple key-value pairs, support
HBase(Apache)
Pros
1)Master-Slave Architecture
HBase build on top HDFS, HDFS is mater-slave architecture, HBase follows this
style. It will improve the interoperability between HBase and HDFS.
This style do good for load balance, the HMaster takes over the load balance
job, assign regions to region servers and auto failover dead RegionServers.
2) Real-time , random big data access
3) Column-Oriented data model for big sparse table
4) LSM-trees vs. B+ tree
5) Row-level Atomic
6) High Scalability & Reliability
8) Auto Failover
9) Data auto sharding
10) Simple Client Interface
Cons
1) Single Point of Failure (SPOF)
2) No transaction
3) No Join, if you want, use MapReduce
4) Index only on key, sorted by key, but RDBMS can be indexed on arbitrary
column
5) Security Problem

2. MongoDB
-------
1)Schema-Less:If you have a flexible schema, this is ideal for a document store
like MongoDB. This is difficult to implement in a performant manner in RDBMS
2)Ease of scale-out:Scale reads by using replica sets. Scale writes by using
sharding (auto balancing). Just fire up another machine and away you go. Adding
more machines = adding more RAM over which to distribute your working set.
3)Cost: Depends on which RDBMS of course, but MongoDB is free and can run on
Linux, ideal for running on cheaper commodity kit.
4)you can choose what level of consistency you want depending on the value of
the data (e.g. faster performance = fire and forget inserts to MongoDB, slower
performance = wait til insert has been replicated to multiple nodes before
returning).
1)MongoDB desigined for big data storage and query, and Social Network
applications like Facebook and twitter.
1)MongoDB is a document-oriented(key value query) database that natively
supports JSON format.so that it increase the performance.
3)MongoDB supports auto sharding and auto failover.When the data on one node
exceed threshold, MongoDB automatically rearrange the data to evenly distribute
the data.
2)DB administrator doesn t require
3)Actually, there is no schema in MongoDB, the document can have any number of
fields, the fields can be add to existing document at anytime, dynamically. No
ALTER TABLE, no rebuild indexing.
Cons
1)Data size in MongoDB is typically higher due to e.g. each document has field
names stored it
2)Less flexibity with querying (e.g. no JOINs)
3)No support for transactions - certain atomic operations are supported, at a
single document level
4)at the moment Map/Reduce (e.g. to do aggregations/data analysis) is OK, but
not blisteringly fast. So if that's required, something like Hadoop may need to
be added into the mix
less up to date information available/fast evolving product
REDIS(It means REmote DIctionary Server)
----------------------------------------
1)Redis is a data structure server. There is no query language (only commands)
and no support for a relational algebra. You cannot submit ad-hoc queries (like
you can using SQL on a RDBMS). All data accesses should be anticipated by the
developer, and proper data access paths must be designed. A lot of flexibility
is lost.
2)Redis offers 2 options for persistency: regular snapshotting and append-only
files. None of them is as secure as a real transactional server providing
redo/undo logging, block checksuming, point-in-time recovery, flashback
capabilities, etc ...
3)Generally Redis's used for high level operations and features.