Cloud Web-Service Architecture
NoSQL Database Solutions via MongoDB
Every identity management system has to have a well thought out backend database solution. It is well known that for scaling beyond 1 million the NoSQL class of solutions offer increasingly more powerful scaling laws. Depicted in the accompanying figure is the database solution within our FaceR Cloud via the NoSQL class of solutions focusing on our choice of MongoDB. Our NoSQL solution provides data replication providing immunity from hardware failures and data sharing providing scaling. Typically, within the US, nodes the replica set can be situated in the Eastern geographical zone and/or in the Western region. Each Replica Set typically operates with 3 to 7 nodes (or computers). Additional replica sets can be seamlessly added to horizontally scale data storage automatically. Growing the database in this way is referred to as Sharding and the data represented by each replica set is called a Shard. Our selection of MongoDB provides the following features including (i) Data Redundancy - Replica sets providing an automated method for storing multiple copies of the data and (ii) Automated Failover a correctly configured replica set basically provides a "hot backup". Recovering from backups is typically very time consuming and can result in data loss. Having an active replica set is generally much faster than working with backups.
Depicted in the Figure below is our MongoDB Database Architecture.
Our Replica set solution incorporates (i) maintenance as it allows for us to perform tasks such as upgrades, backups and compaction, as is typically required to remove a node from service, and (ii) Replica sets allow for these maintenance tasks to be performed while operating a production system. As long as the production system can withstand the removal of a single node, then it's possible to perform a "rolling" upgrade on such things.
Disaster recovery includes (i) replica sets allowing for a "delayed secondary" node, as well as a node which can provide a window for recovering from disastrous events such as bad deployment and dropped tables and collections.
Every identity management system has to have a well thought out backend database solution. It is well known that for scaling beyond 1 million the NoSQL class of solutions offer increasingly more powerful scaling laws. Depicted in the accompanying figure is the database solution within our FaceR Cloud via the NoSQL class of solutions focusing on our choice of MongoDB. Our NoSQL solution provides data replication providing immunity from hardware failures and data sharing providing scaling. Typically, within the US, nodes the replica set can be situated in the Eastern geographical zone and/or in the Western region. Each Replica Set typically operates with 3 to 7 nodes (or computers). Additional replica sets can be seamlessly added to horizontally scale data storage automatically. Growing the database in this way is referred to as Sharding and the data represented by each replica set is called a Shard. Our selection of MongoDB provides the following features including (i) Data Redundancy - Replica sets providing an automated method for storing multiple copies of the data and (ii) Automated Failover a correctly configured replica set basically provides a "hot backup". Recovering from backups is typically very time consuming and can result in data loss. Having an active replica set is generally much faster than working with backups.
Our Replica set solution incorporates (i) maintenance as it allows for us to perform tasks such as upgrades, backups and compaction, as is typically required to remove a node from service, and (ii) Replica sets allow for these maintenance tasks to be performed while operating a production system. As long as the production system can withstand the removal of a single node, then it's possible to perform a "rolling" upgrade on such things.
Disaster recovery includes (i) replica sets allowing for a "delayed secondary" node, as well as a node which can provide a window for recovering from disastrous events such as bad deployment and dropped tables and collections.