15/03/2017 SOATBlogBasededonnesetarchitecturedistribue

ArchitectureAvanc(http://blog.soat.fr/levels/avance/)09/02/2015

Basededonnesetarchitecturedistribue

(http://blog.soat.fr/wpcontent/uploads/2014/09/accroche_ala_02.jpg)Dansunarticleprcdent,nousavonsabord

unaspectparticulierdesplateformeshautesdisponibilitsditesHA(http://blog.soat.fr/2014/09/leloadbalancing/).Ilsagissaitdelarpartitiondechargecouplela
redondancedesquipementscommemoyenderenforcementdecettehautedisponibilit.Ladisponibilitdesdonnesainsiquelarapiditdelaccs
linformationestunautreaspectquicaractrisecesplateformesHA.Laqualitdustockageainsiquelesstratgiesadoptespourceteffetsontlespiliersmmes
decettedisponibilit.Cettedisponibilitdoittrelafoisimmdiateetdurable.

Pourrpondrelimpratifdelarapiditdaccs,lestockageenmmoire,autrementditlecache,estlechoixnumroun.Lesarchitecturesactuelles
nhsitentplusmettreenplacediffrentsniveauxdecachepourrendrefluidecetaccslinformation.
Pourrpondrelautreimpratifquiestdegarantirladurabilitdelinformation,autrementditsapersistance,selonlescas,lesbasesdedonnesetoules
systmesdefichierssavrentincontournables.

Sansprtentionparticulireettoujoursdanslecadredelahautedisponibilit,nousallonsaborderquelquesarchitecturesadoptesparlemarch,parmilesplus
performantesentermesdefficacitdestockageetderestitutiondelinformation.

SQLORNoSQL
LesbasesdedonnesNoSQLconnaissentunessorcroissantenraisondeleurmiseenplaceetdeleurextensibilit(scalability),thoriquementfacilesetillimites.
Lesarchitecturesassociespermettentdedfinirunensembledebasesdedonnesrpliquespermettantlafois:

Unemonteenchargetransparentevisvisduclient
Unehautedisponibilitdelinformation(tolranceauxpannes)
Unegestionefficacedegrosvolumesdedonnes[terabyte,petabyte]
Unfortdbitetdoncdesperformancestrsconfortables.

Lesbasesdedonnesrelationnellesrgnaientjusquercemmentsanscontesteetpermettaientdestocker/restitueruneinformationtypeetstructure.Maisface
auxmontesdechargesetauxbesoinstoujourscroissantsentermedevolumedinformationetderapiditdaccs,ellesontcommencmontrerleurslimites.
Lapparitiondarchitecturesbasessurleclusteringet/oulepartitionnementdesdonnesapermisdatteindreunecertaineextensibilit,maiscesarchitectures
restent compliques en terme de mise en uvre et dexploitation (ou exploitabilit). Certaines tudes comparatives opposent SQL et NoSQL et finissent par
conclure que lextensibilit des bases de donnes relationnelles est non seulement limite mais aussi trs coteuse en temps et en moyens. Certes les deux
systmesSQLetNoSQLpermettentdestocker/restituerdelinformation,maisilsneserventpaslesmmesobjectifscequirendtoutecomparaisonsubjectivevoir
nonjustifie.Eneffet,lepremiersystmeestbtisurlerespectdespropritsACID,lesecondsurlahautedisponibilitetlatolranceauxpannes.Lethorme
CAP(Consistency,AvailabilityandPartitiontolerance)indiquequunsystmedistribunepeutpasrunirsimultanmentlestroiscritressuivants:

Cohrence,
Disponibilit
Tolranceauxpannes.

Sinousdevionsclasserlesdeuxtypesdebasesdedonnes,relationnelleetNoSQL,lespremiresseraientdetypeCA(Cohrenceetdisponibilit),lessecondes
seraientdetypesAPouCP(disponibilitetTolranceauxpannes|CohrenceetTolranceauxpannes).Lextensibilit(scalability)desbasesNoSQLest
essentiellementfaciliteparladnormalisationdesdonnesetlaffranchissementdescontraintesACID.Entermesdecot,cestassezrelatifcaronnesebasera
passurlemmetypedemachinepourinstallerlunoulautre.Leursmisesenplacefinirontdetoutefaonparcotercher,carpouravoirunerplicationqui
supporterellementlarpartitiondechargeetlatolranceauxpannes,ilfautdisposerdinstancesdiffrentes,installessurdesmachinesdiffrentes.Donc,
contrairementauxidesreues,lamiseenplacedesdeuxtechnologies(basessurduSQLousurduNoSQL)finissentparcotercher.Cescotspeuventtre
encoreplusimportantslorsquelesserveurs/machinesutilisssontdehautegamme.Danslesecteurdudata,lahautedisponibilitestsouventobtenuepar
rplication,parfoisgalementparpartitionnement,voirencombinantlesdeux.Sansallerplusloindanslacomparaisondesdeuxtechnologies,carcecimriteun
articlepartentire,nousallonsdanscequisuitbrosserquelquesarchitecturesgarantissantunehautedisponibilitdelinformation.Nousaborderonsen
particulier,lecasdecertainesbasesdedonnesconnues(Cassandra,MongoDBetOracle)etleursrecettespourgarantirlahautedisponibilit.

NoSQLCASSANDRA
CassandraestnesousledrapeaudeFacebook,enassociantlemeilleurdeGoogleBigTable(modlededonnesorientcolonnes+mcanismedepersistance
performant)etdAmazonDynamoDB(architecturedistribueotouslesnudssontquivalents).GreactuellementparlafondationApache,sonarchitecturea
tpensepourneprsenteraucunpointdedfaillanceSPOF(SinglePointOfFailure).

LarchitectureCassandraestbasesurunmodledistribuetdcentralisdetypepeertopeer.Tousleslmentsduneplateformesontsupposstre
identiques du moins dun point de vue client. Lensemble des lments ou nuds est maintenu dans un tat de service cohrent grce un protocole de
communicationinterneditgossip. Le but de larchitecture Cassandra est de garantir une haute disponibilit via une grande tolrance aux pannes double
duneextensibilit(scalabilit)facileetflexible,letoutavecunepromessedehautesperformancesaussibienlcriturequlalecture.Leschmacidessous
inspirdeladocumentationofficielledeDataStaxillustrelelienlinaireentrelescapacitsduneplateformeCassandraetlenombredenudsassocis.

http://blog.soat.fr/2015/02/basededonneesetarchitecturedistribuee/ 1/7
15/03/2017 SOATBlogBasededonnesetarchitecturedistribue

(http://blog.soat.fr/wp

content/uploads/2014/11/BD_HauteDispo_011e1415705738478.jpg)

LascalabilitdelaplateformeCassandraesttellequilsuffitdaugmenterprogressivementlatailledelafermedeserveurspourpouvoirabsorberplusdecharge,
ceci avec lavantage de ne rien modifier larchitecture applicative en place. Pour remplir ce cahier des charges, Cassandra utilise diffrentes techniques assez
sophistiques,parmilesquellesnouspouvonsciter:

Lacommunicationinternuds
LesfiltresBloom
Leread/repairetlacompaction
Lepartitionnementetlarplication

Lesdeuxdernirestechniquesrentrentdanslecadredelahautedisponibilit.Nouslesdtailleronscidessous.

Partitionnement
Cassandraatpensepourtredployesurdiffrentesmachines.Chacunedellesreprsenteunnudduclusteravecunecertainecapacitdhbergementet
detraitement.Pourdesraisonsdehauteperformance,lesdonnessontautomatiquementdistribuessurlensembledesnuds.Loprationdepartitionnement
est base sur un systme de hashage qui gnre automatiquement des cls uniques de stockage. Les littratures parlent de autosharding et/ou de key
basedsharding.Lagnrationautomatiquedecl(fonctiondehash)atpensepouravoirlafoisunebonnegestiondelarpartitiondesdonnesetun
supportperformantlorsdesoprationsdelecture(scansparbloc).Leprotocoledecommunicationinternegossipparticipegalementcettegestionefficace.Il
permetunnuddesavoirrapidementoestsitueunedonnedanslecluster.

Troislogiquesdepartitionnementexistentetpeuventtreinterchangesparconfiguration.LesderniresversionsdeCassandraprconisentetutilisentpardfaut
un nouveau rpartiteur plus performant dont les cls de stockage (64bits) permettent une plus grande capacit dhbergement. Dans les faits, chaque nud est
associ,parconfiguration,unRangeToken,dfinissantunintervalledeclsdestockage.LesderniresversionsdeCassandrapermettentdassocierunou
plusieurs num_Token ou range_Token en fonction des capacits dun nud (CPU, RAM, DISQUE). Cest cet intervalle qui permet au rpartiteur de savoir
exactementsurquelnudunedonneserastocke.

Rplication
Le partitionnement permet de rpartir linformation et son traitement sur diffrents nuds, mais ne garantit pas sa disponibilit tout moment. Pour rsoudre ce
problme, Cassandra renforce son systme par de la rplication. Cette dernire est pilote par deux piliers : Le facteur de rplication (replication factor) et la
stratgiederplication.Lepremierdterminelenombredecopiesconserverpourunedonnelesecondlamaniredontserarpliquelinformationentreles
nuds du cluster. Un facteur de rplication RF = 1 est dconseill car implique quune seule copie existera dans le systme. Il constitue, donc, une rupture au
principedelatolranceauxpannes.Autrementdit,encasdindisponibilitdunnud,toutelinformationquilhbergenepourraplustrerestitue.Pardfaut,le
facteur de rplication est fix 3 et doit tre adapt, avec intelligence, la taille de la ferme de serveurs. En effet, une valeur trop leve peut pnaliser les
performancescarlesystmeconsacrerabeaucoupdesesressources(CPU,RAM)larplicationetlasynchronisationdesdonnesentrenuds.

Malgrunevitessedcrituretrssuprieurecelledelalecture,lemcanismedelarplicationinduitunecertaineincohrencetransitoireetcycliquelorsquune
donneestrpliqueoumisejour.Ceciestdessentiellementaufaitquelarplicationestunmcanismeasynchroneetdpendantdelavitessedepropagation,
doncdelalatencerseau.Cettelatencepeutmmedevenirgnantesilarplicationinternudsestraliseentredatacenterloigns.

Pour rsoudre ce problme, Cassandra forte dun mcanisme de synchronisation appel readrepair , permet dagir sur le niveau de consistance (ou
cohrence)dunedonne.Ellemetdispositionduclientdiffrentsniveauxdeconsistance(Zro,One,ALL,Any,Quorum)quipeuventtreajustsaussibienen
criturequenlecture.LeniveauZroetAnysontlesniveauxdeconsistancelesplusfaiblesleniveauAllestleplusstrictetdoncleplusimpactantdepoint
devueperformance.Cesniveauxsontdoncutiliseravecprudence.Cenestquunefoislasynchronisationacheve,quelacohrencedusystmeestatteinte.
CettecohrencenedoitdoncpastreconfondueaveclacohrencegarantieparlesrglesACID(conceptpropreauxbasesrelationnelles).

Clustering
Dans lcosystme Cassandra, le cluster est un groupement logique de plusieurs nuds. Il est dot dun nom pour assurer le cloisonnement dun ensemble de
nudsdansunenvironnementmulticluster.Unclusterestliunkeyspace(quivalentduschmadebasededonnesrelationnelle)etsataillepeutvarier
dunmomentlautre.Ellepeut:

Baisserencasdemisehorscircuitdecertainesinstances(maintenance,pannes),
Augmenterencasdajoutdenouvellesinstances(augmentationdelachargesupporter).

Un cluster peut tre local un data center ou rparti sur plusieurs. La communication inter nuds y est possible grce au protocole gossip . Ce dernier
permetentreautresladtectiondesdfaillances.Eneffet,lensembledesnudssenregistreauprsdunmanager(Gossiper)responsabledelagestiondeleurs
tats de service. Un ensemble de nuds lis par configuration constitue une unit appele racks . Dans une topologie rpartie, un rack est en gnral
synchronisavecunautrerackjumeausitudansundatacenterdistant.

Dunpointdevueclient,touslesnudsdunclustersontquivalentsmmesilyaunecertainediffrenceentrelesnudsseed(plusstables,plusrobustes)et
les autres. Concrtement, lors de la rception dune requte client, un nud donn traitera lopration. Potentiellement, il peut ne pas disposer de linformation
demande.Danscecasdefigure,ilagiracommeunproxydecoordinationentreleclientetlenudfinal.

NoSQLMongoDB
MongoDBestunebasededonnesorientedocument. Les donnes, au format JSON, sont stockes en interne sous un format binaire plus compact appel
BSON, et groupes en collections (lquivalent des tables SQL). Les documents sont identifis grce une cl unique et peuvent tre indexs pour garantir de
meilleuresperformances.

http://blog.soat.fr/2015/02/basededonneesetarchitecturedistribuee/ 2/7
15/03/2017 SOATBlogBasededonnesetarchitecturedistribue
NousavonschoisiMongoDBcommesecondexemplecaraummetitrequeCassandra,ellejouitdunetrsbonnerputationetatadopteetprouveparde
grands groupes. Nous lavons choisi aussi pour illustrer un exemple de plateforme type CP (au sens du thorme CAP (Consistency, Availability and Partition
tolerance)).SonarchitectureestdiffrentedecelledeCassandra(detypeAP),maistoutaussiperformante.Labasededonnespeuttreconstitue:

Duneseuleinstance:unseulprocessus(mongod)estalorsdmarr.Onparledemodeserveur.
Deuxinstances:Ilsagitduneconfigurationdetypemaitreesclave.
DeNinstances:OnparledeReplicatSetregroupantNinstancessynchronises.

Lesdeuxpremiersmodessonttrspratiquespourlesdveloppementsetlestests(POCetautres).Ilspermettentnotammentdesimulerdesproblmatiqueslies
aurseauetlabsencederobustesse.Lederniermodeestgnralementutilisenproductionenraisondunemeilleuretolranceauxpannes.

Partitionnement
Larchitecture MongoDB utilise aussi le partitionnement pour amliorer les performances du systme et la disponibilit de linformation. Pour cela, elle utilise la
techniqueappelesharding.Aveccettetechnique,labasededonnesdevientuneunitlogiquerpartiesurNinstancesouserveursphysiques.Ellepermet
donc davoir une extensibilithorizontale adaptable la charge du systme. Limplmentation MongoDB de cette technique (automatiquesharding) rend la
rpartitiontotalementtransparentepourleclient.Ellepermetaussidajuster,ausenstuning,leniveaudeperformanceenrajoutantdesrpartiteursderequtes
(QueryRouter).Unshardpeuttredfinicommeuneunitlogiqueconstituedunserveurunique(dconseill)oudunreplicatset.Lesdonnessontalors
rpartiessurunensembledenudsensebasantsuruneshardkey.

Rplication
Larchitecture MongoDB ddie le nud matre lcriture et permet de rpartir les oprations de lecture sur lensemble des nuds. Les donnes sont donc
cohrentes tout moment au niveau du nud matre. De l, elles sont rpliques sur lensemble des nuds de faon asynchrone, pour garantir partout la
cohrence des donnes. En effet, les oprations dcriture sont toutes traces (oplog) pour tre rpercutes sur lensemble du cluster lexception du nud
arbitre. La hirarchie nuds primaire/secondaire(s) ainsi que les oprations de synchronisations entre nuds ont bien videment un cot. Nous lavons vu pour
Cassandra, cest galement vrai pour MongoDB. Pour rduire limpact de ce fonctionnement, diffrentes options dcriture (secondary, secondaryPreferred,
nearest)onttprvuesetsontsupportesparleDriverMongoDB.

Clustering
AladiffrencedelarchitectureCassandraotouslesnudssontsupposstrequivalents,larchitectureMongoDBestbasesurunehirarchienudprimaire/
secondaire(s). Cette hirarchie est maintenue par un processus natif dlection qui dtermine en cas de panne du nud matre le nud secondaire qui lui
succdera(automatedfailover).Unensembledenudsconstitueunreplicatsetetnepeutavoirquunseulnudprimaire.Lorsdelextensiondecedernier,
une priorit est associe chaque nud et dtermine sa position dans la hirarchie globale. La priorit est directement prise en compte lors du processus
dlection.Eneffet,elleestsouventdtermineenfonctiondelacapacitdelinstance.Lesreplicatsetsonttendusparajoutdenud.Chaquenudpossde
uneprioritquilesituedanslahirarchieglobaleducluster.Cettedernireestutilisedansleprocessusnatifdlection.Elleest,engnral,dfinieenfonctiondes

capacits de linstance ajoute. (http://blog.soat.fr/wp

content/uploads/2014/11/BD_HauteDispo_0311e1415723234589.jpg)

Figure4.1:ShardingSchmatirdeladocumentationMongoDB.

LeschmacidessustirdeladocumentationdeMongoDB,montrecertainscomposantsessentielsduclusterdontleslmentsclssont:

Lunitdestockagediteshardquicorrespondaureplicatset
Lerpartiteurderequtesquigrelenvoidesrequtesversunshard,ouassureleursdistributionssurlensembledessharddisponibles.Pourremplir
cettetche,ilutiliselesinformationscontenuesdanslunitdeconfiguration.Ilsagitdunensembledemtadonnesutilisesparlerpartiteurderequtes
pourgrerlarpartitionsurlesdiffrentsshard.
Larplicationsefaitdefaonasynchroneentrelenudprimaireetlesnudssecondairesassocis.

MongoDButilisemassivementlaRAMpourassurerdetrshautesperformances.Nouspouvons,donc,imaginersansdifficultslescapacitsquepeutoffrirune
telleplateforme.Cependant,ilfautrestervigilantcartouteslesdonnesnontpasvocationtremontesenmmoire.Untravailderationalisation(indexationet
decatgorisation)est,etdemeurerancessairemalgrtout.

Notons simplement que, compar au modle distribu adopt par Cassandra, le modle MongoDB est parfois dcrit comme tant moins tolrant aux pannes.
Concrtement, lorsquun nud du cluster Cassandra tombe, linformation reste disponible. Elle est restitue par un nud dtenant linformation rplique
moinsdavoir:

Opt,pouruneraisonobscure,pourunRF=1,
Unerpartitionnonrflchiedesnudssurlensembledesdatacenter.

Ce niveau de tolrance aux pannes nest pas garanti par larchitecture MongoDB. En effet, si un nud primaire ou un shard (cf. figure 4.1) venait tomber,
linformationquiyestdtenuepourraitnepastreimmdiatementdisponibleenlecture/criture.Lacontinuitduservicedpendrade:

Larapiditduprocessusdlectionquibasculeraunnudsecondaireenprimaire(dequelquesmillisecondesunevingtainedesecondes),
Larpartitiondesnudsentredatacenter.Unebonnepratiqueestderepartirlesnudsdunmmeshardsurdesdatacenterdiffrentscomme
lemontreleschmacidessoustirdeladocumentationofficielle.Ainsi,aupire,quelquesrequtesdinsertionserontnonhonoresmaistoutelinformation

http://blog.soat.fr/2015/02/basededonneesetarchitecturedistribuee/ 3/7
15/03/2017 SOATBlogBasededonnesetarchitecturedistribue
resteradisponibleenlecture.CequiestplusquacceptablemmeparlesSLAlesplusstrictes.

(http://blog.soat.fr/wpcontent/uploads/2014/11/BD_HauteDispo_0421e1415721635590.jpg)

Figure4.2:ShardingFailover.

Un peu plus haut dans cet article nous avons vu que, selon le thorme CAP, Cassandra est de type AP (Availibilty & PartitionTolerance). La disponibilit de
linformationtoutmomentestdonccapitale.Elleprimesurlaconsistancedesdonnes,quinestobtenuequaprssynchronisation.Nouslavonscompris,cette
hautedisponibilitestgarantieparunmodledistriburenforcparlarplicationdesdonnes.OrMongoDBestdetypeCP(Consistency&PartitionTolerance),
la disponibilit de toute linformation tout moment est moins capitale. Elle est un peu sacrifie au profit de la consistance des donnes (contrairement
Cassandra),consistancequiestgarantieparunecriturerserveau(x)nud(s)primaire(s).Nousnironspasplusloindanslacomparaisondesdeuxplateformes.
Cecisortducadredecetarticle,etsurtoutncessiteraunarticleddipourabordercorrectementlesujet.

BASESDEDONNESTRADITIONNELLES
Un trs grand nombre darchitectures continuent tre bases sur une base de donnes relationnelle centrale. Linformation y est type, structure et
maintenuecohrentetoutmoment.

Facesauxproblmatiquesdelamontedechargeetdeladgradationdesperformances,leplussouvent,cesarchitecturesprocdentdesamliorationsentrois
tapes:

Lapremireestengnral,unephasedoptimisationquitouchedunepartlabasedonneellemme(ajoutdindexes,utilisationdetablespacediffrents,
activation de la compression sur les tables, PCTFREE) et dautre part les requtes SQL. Ces dernires sont passes la loupe et amliores (paralllisation,
update bas sur des vues dynamiques, combinaison curseur et bulk collect). Lajout dindexes et le partitionnement, pour ne citer que ceuxl, sont parmi les
techniqueslesplusutilises.

Lasecondetapeestenclenchelorsqueleseffetsdelapremirenesontpasassezconcluants.Ellepasseengnralparlajoutdemmoire,laugmentation
descapacitsCPUetlutilisationdedisquesplusrapides.Onparlealors,dextensibilitverticale.Cetteextensibilitestefficacepourunebonnemajoritdes
plateformesmaismontretrsviteseslimitespourdesplateformesdevantrpondredesbesoinscroissantsentermesdecharge.

Latroisimephasepasseparlinstallation dune seconde base (rarement plus) rplique qui peut fonctionner soit en mode actif/actif ou en mode actif/passif.
Danslemodeactif/actif,lesdeuxbases,installessurdeuxmachinesdiffrentes,sontsynchronises(rplicationsynchroneouasynchrone)etserpartissentla
chargeglobale.Larpartitionestsoitassureparundriverddi(ex:squoia)ouviaunrpartiteurdecharge(ex:HaProxy).Enmodeactif/passif,lasecondebase
agitcommebasedesecours.Elleprendlerelaispourassurerlacontinuitduserviceencasdepannedelabasematre.Dautresconfigurationssontpossibles,et
on parle souvent de bases en mode matre/esclave(s). Le nombre de bases esclaves varie selon les plateformes et la technique de rplication. Les schmas ci

dessous montrent quelques possibilits de mise en place en cluster.

(http://blog.soat.fr/wpcontent/uploads/2014/11/BD_HauteDispo_041.jpg)

Figure5.1:basededonnesenmodeactif/actif

http://blog.soat.fr/2015/02/basededonneesetarchitecturedistribuee/ 4/7
15/03/2017 SOATBlogBasededonnesetarchitecturedistribue

(http://blog.soat.fr/wpcontent/uploads/2014/11/BD_HauteDispo_051.jpg)

Figure5.2:basededonnesenmodeactif/actif(HaProxy/Sequoia)

Des contrleurs comme Sequoia ainsi que des rpartiteurs comme HAProxy sont capables dassurer non seulement un rle de rpartition mais galement une
gestiondelatolrancelapanne.Siundesserveursnerpondplus,ilestretirdelalistederpartition.

Conclusion
Nousavonsvudanscetarticle,viadesarchitecturesdiffrentes,quelquesmoyensutilisspourassurerunehautedisponibilitdelinformation.Lammerecetteest
mise en uvre via des techniques diffrentes (Sharding, simple synchronisation ou ReadRepear). Les matres mots sont rplication, partitionnement et
indexation.Nousavonsgalementvu,querendreunebasededonnesextensibleest:

Possiblemaispeuttreplusoumoinscomplexe(SQL,NoSQL),
Seheurteencorecertaineslimites,etquececinevapassansuncertainimpactsurlesperformances.

Actuellement,cetimpactestleprixpayerdsquelesystmeestsoumisunecertainerigueuroucertainescontraintes(niveaudecohrence,concurrence,
aspecttransactionnel).

Articlessurlemmesujet
LepartitionnementavecRedis(http://blog.soat.fr/2017/02/lepartitionnementavecredis/)(Fv1,2017)
DEVOXX,lerendezvousincontournabledesDveloppeursJAVA,cestdemainetnousyserons!(http://blog.soat.fr/2014/04/devoxxlerendezvous
incontournabledesdeveloppeursjavacestdemainetnousyserons/)(Avr15,2014)
SpringData,uneautrefaondaccderauxdonnes(http://blog.soat.fr/2014/02/springdatauneautrefacondaccederauxdonnees/)(Fv6,2014)
ElasticSearch(http://blog.soat.fr/2013/07/elasticsearch/)(Juil23,2013)
WindowsAzureTableStorage2.0:Questcequiachang?(http://blog.soat.fr/2013/03/windowsazuretablestorage20questcequiachange/)(Mar18,
2013)

39 Total
Shares
0
(https://www.facebook.com/sharer/sharer.php?u=http://blog.soat.fr/2015/02/base-de-donnees-et-architecture-distribuee/)

0
(https://twitter.com/intent/tweet?
text=Base%20de%20donn%C3%A9es%20et%20architecture%20distribu%C3%A9e&url=http%3A%2F%2Fblog.soat.fr%2F2015%2F02%2Fbase-de-donnees-et-
architecture-distribuee%2F&via=SoatGroup)

37
(http://www.linkedin.com/shareArticle?
mini=true&title=Base%20de%20donn%C3%A9es%20et%20architecture%20distribu%C3%A9e&url=http://blog.soat.fr/2015/02/base-de-donnees-et-
architecture-distribuee/&summary=Dans un article prcdent, nous avons abord un aspect particulier des plateformes hautes disponi...)

2
(https://plus.google.com/share?url=http://blog.soat.fr/2015/02/base-de-donnees-et-architecture-distribuee/)
Nombredevue:1102

(http://blog.soat.fr/author/abdelmajidlali/)

AbdelmajidLALI(http://blog.soat.fr/author/abdelmajidlali/)
AbdelmajidLALI,architecteJavaEEPassionndetechnologies,jaiacquismonexprienceentravaillantsurdesprojetspourdegrandscomptesdansledomainede
lindustrie,lassurance,labanqueetlestlcoms.

http://blog.soat.fr/2015/02/basededonneesetarchitecturedistribuee/ 5/7
15/03/2017 SOATBlogBasededonnesetarchitecturedistribue

COMMENTAIRES4commentaires
1. PaulCLEMENTdit:
11/02/201512:26(http://blog.soat.fr/2015/02/basededonneesetarchitecturedistribuee/#comment338829)
Mercipourcetarticletrsinteressantettrsbiencrit.

2. EricPlat(http://www.chdexpert.fr/)dit:
19/11/201512:27(http://blog.soat.fr/2015/02/basededonneesetarchitecturedistribuee/#comment398361)
Mercipourlarticle,cavamaiderexploiterunebasededonneshotelquejedoisdcortiquer.

3. AbdelmajidLALIdit:
19/11/20152:24(http://blog.soat.fr/2015/02/basededonneesetarchitecturedistribuee/#comment398375)
Mercipourvosencouragements:adonneenviedcrireplus.

4. Sylvaindit:
06/05/20164:51(http://blog.soat.fr/2015/02/basededonneesetarchitecturedistribuee/#comment402906)
Superarticle!Bravo!

AJOUTERUNCOMMENTAIRE
Nom(required)

Mail(willnotbepublished)(required)

Siteweb

SubmitComment

(http://www.google.com/url?q=http%3A%2F%2Fblog.soat.fr%2F2016%2F03%2Fsoatdansletop10duclassementgreatplaceto
work%2F&sa=D&sntz=1&usg=AFQjCNEGpQerQG558SjbhqsyS8Z7R3Cmeg)

Nosprochainesconfrences
Le25avril:SOATAgileDay2017"Lacultureproduit:impactstechniquesetorganisationnels"(http://agileday.soat.fr/edition2017/)

Le13mars:TechLabs:Atelier"EventStormingDDD#2"(https://www.meetup.com/frFR/TechLabsbySOAT/events/237783326/)

Le23mars:TechLabs:"AndroidDataBinding:simplifiezlagestiondevosvues(https://www.meetup.com/frFR/TechLabsbySOAT/events/238023615/)

LivreBlanc

http://blog.soat.fr/2015/02/basededonneesetarchitecturedistribuee/ 6/7
15/03/2017 SOATBlogBasededonnesetarchitecturedistribue

(http://www.soat.fr/publications/java8migrationetenjeuxstrategiquesenentreprise/)
Java8:Migrationetenjeuxstratgiquesenentreprise

GuidedesurvieencentreAgile

(http://www.soat.fr/publications/guidedesurviecentreagile/)

Commentcrer,greretanimeruncentred'excellenceauquotidien

ActualitTwitter
RT@mydigitalweek(https://twitter.com/mydigitalweek):Commentoprerlatransformationdigitale?https://t.co/onmztP0jEB
(https://t.co/onmztP0jEB)via@mydigitalweek(https://twitter.com/mydigitalweek)by@SoatGroup(https://twitter.com/SoatGroup)
https://t.co/NeOQIy(https://t.co/NeOQIy)
2monthsago(http://twitter.com/SoatAgile/status/818406440041848832)

RT@mydigitalweek(https://twitter.com/mydigitalweek):Commentoprerlatransformationdigitale?https://t.co/onmztP0jEB
(https://t.co/onmztP0jEB)via@mydigitalweek(https://twitter.com/mydigitalweek)by@SoatGroup(https://twitter.com/SoatGroup)
https://t.co/NeOQIy(https://t.co/NeOQIy)
2monthsago(http://twitter.com/SoatGroup/status/817404171368415232)

RT@SoatGroup(https://twitter.com/SoatGroup):@M1cr0(https://twitter.com/M1cr0)vousexpliquecommentgarderlecontrledevostestsA/B
avec@kameleoonrocks(https://twitter.com/kameleoonrocks)https://t.co/oZoqaOXnAl(https://t.co/oZoqaOXnAl)
2monthsago(http://twitter.com/SoatAgile/status/816995999944245248)

REJOINSNOUS(http://www.soat.fr/postuler/?context=77)

Suiveznous
(https://www.facebook.com/SoatGroup) (https://twitter.com/SoatGroup) (https://plus.google.com/+SoatFr)

(https://www.youtube.com/user/soatit) (https://www.linkedin.com/company/soat)

NewsletterSOAT(http://www.soat.fr/soat/newsletter/)
Contact(http://www.soat.fr/contact/)
Mentionslgales(/mentionslegales/)
Copyright2017SOATBlog

http://blog.soat.fr/2015/02/basededonneesetarchitecturedistribuee/ 7/7