CompareCloudNoSqlSolutionMingLeiManyNoSqlSolutionsoutthere:1.ConceptsofDistributedProgrammingArchitecture.2.ApplicationProgrammingModel.3.DetailedComparisonofafewNoSqlopen-sourceprojectsCassandraHbaseMongoDBMemCacheCommonArchitecturesHighlyCoupled(clustered):referstypicallytoaclusterofmachinesthatcloselyworktogether,runningasharedprocessinparallel.Thetaskissubdividedinpartsthataremadeindividuallybyeachoneandthenputbacktogethertomakethefinalresult.SpaceBased(virtualsingleaddressspace)referstoaninfrastructurethatcreatestheillusion(virtualization)ofonesingleaddress-space.Dataaretransparentlyreplicatedaccordingtoapplicationneeds.Decouplingintime,spaceandreferenceisachieved.CommonArchitecture(2)Peer-to-Peervs.Client-to-ServerNospecialmachineormachinesthatprovideaserviceormanagethenetworkresources.Insteadallresponsibilitiesareuniformlydividedamongallmachines,knownaspeers.vs.Machinesareassigneddifferenttasksandresponsibilitiesinacluster.Theydependoneachotherasclienttoserver.CommonArchitecture(3)Inter-processCo-ordinationvs.DatabaseCentricMethodofcommunicatingandcoordinatingworkamongconcurrentprocessesondifferentmachines.vs.Enabledistributedcomputingtobedonewithoutanyformofdirectinter-processcommunication,byutilizingashareddatabaseComparisonMetricsStorageTypeCAPACIDRead/WritePerformanceReplicationandShardingIndexedQueryandSecondaryIndexHighAvailability,FaultTolerance,FailoverScalabilityondataandrequestStorageTypesDocument:Jackrabbit,MongoDb,ArangoDb,CouchBase,CouchDbColumns:Hbase,CassandraKey-Values:Riak,MemCacheDbCAPTheoremConsistencydataisthesameacrossreplicationsAvailabilityabilitytoaccesstheclusterevenifanodeintheclustergoesdownPartitionToleranceclustercontinuestofunctionevenifthereisapartition(communicationsbreak)betweennodesCAPTheoremAdistributedsystemcannotsatisfyallthree.CAdataisconsistentbetweenallnodesbutmaybecomeoutofsyncifthereispartitionincluster.CPdataisconsistentbetweenallnodes,andmaintainspartitiontolerancebybecomingunavailablewhenanodegoesdown.APnodesremainonlineandunsyncedduringapartitionCAPandEventualConsistencyEventualConsistency––Datamaybetemporarilyoutofsyncondifferentnodesandwilleventuallybebroughttothesameversion.Canbeimplementedwithabackgroundprocessthatupdatesout-of-syncnodes.AdistributedsystemcanbeeCAP–ThisishowmanynoSqlstoresworks.Clustering:Sharding/ReplicationSharding–distributesasinglelogicaldatabasesystemacrossaclusterofmachines.Replication–replicatesdataamongagroupofmachineswithinaclustertoensureredundancy,backup,andautomaticfailover.Master-masterMaster-slaveACIDAtomic.Everythinginatransactionsucceedsortheentiretransactionisrolledback.Consistent.Atransactioncannotleavethedatabaseinaninconsistentstate.Isolated.Transactionscannotinterferewitheachother.Durable.Completedtransactionspersistintheeventofcrashesorserverfailure.TheScopeofACIDTraditionalSQL:ACIDforthewholedatabaseacrossalltables.CloudbasedLightweightSQL:LogicallypartitiondataandsupportACIDwithinalogicalpartition.E.g.,–WebsitehostingservicepartitiondatabydifferentwebsiteNoSql:partialACIDorACIDatrowlevel,(eg,HBase)MemCache“Free&opensource,high-performance,distributedmemoryobjectcachingsystem,genericinnature,butintendedforuseinspeedingupdynamicwebapplicationsbyalleviatingdatabaseload.Memcachedisanin-memorykey-valuestoreforsmallchunksofarbitrarydata(strings,objects)fromresultsofdatabasecalls,APIcalls,orpagerendering.“MemCache–ArchitectureShardinginclientcodetoselectserver.Peer-to-PeerServerinstances.Serverusesin-memstorage.Potentiallyexpandtopersistentstore.MemCache–UsageCharacteristicsObject-levelConsistency,IsolationandAtomicity.NopersistentstorageNoreplicationforload-balancingorfailoverConsistency+Partition-toleranceinCAPMongoDbDocument-oriented.ThinkofMySQLbutwithJSON-likeobjectscomprisingthedatamodel,ratherthanRDBMStables.Supportsneitherjoinsnortransactions.secondaryindexesatomicwritesonaper-documentlevel,andfully-consistentreads.master-slavereplicationwithautomatedfailoverandbuilt-inhorizontalscalingviaautomatedrange-basedpartitioning.MongoDb–DocumentModelCollection:collectionofdocumentofthesametype.Document:asetofname-valuepairs(properties)FlexibleanddynamicschemaofdocumentsSecondaryindexescanbebuiltondocumentproperties.Usage:mapobjects/relationaltablestoMongoDbdocuments.MongoDb–ACIDandCAPDocumentlevelAIDDataConsistency–tunablebetweenreadconsistencyandhighavailability/performanceReadscanbeconsistentoreventuallyconsistentToachievecompleteconsistency,writehastooccuronallreplicassynchronously.CAofCAPoreCAPMongoDb–ShardingShardbykeyofdocumentpropertieswithinacollection.Centralmappingfromkeyspacetoshards.Clientrequestsaredirectedtodifferentshardbyservicemongos.Dynamicbalancingofshards.MongoDb–ReplicationPrimaryNodeandSecondaryNodes.Synch/AsyncpropagationofwritesfromPrimarytoSecondaries.Re-electaprimaryamongsecondarieswhenprimarygoesdown.Roll-backofwriteswhenaformerprimaryrejoinsasasecondaryRoll-backwritesnotpropagated.Humaninterventionisneeded.MongoDb–Read/W