LE
CACHE
Dans tous ses états
Mathilde Lemée
Java developper
Terracotta Engineer

DuchessFR Founder

Mobile dev – Aetys.fr

FluentLenium
MISS
TTI
TTL
Cache Aside

"Par ma foi ! Il y a plus
de quarante ans que je
dis de la prose sans
que j'en susse rien.
"
Molière ; Le Bou...
Tom veut un

cache

simple pour

améliorer l’accès aux
données.
CACHE ASIDE
Application

Cache
Put A
Get B
B

DAO
Read B

Databas
e
Tom aimerait garantir
que son cache
comporte toujours
les données les

plus récentes.
System of

Record
Cache as a s-o-r : Read through
Application

Persistence layer

Get A

Ehcache

Database
Cache as a s-o-r : Read through
Application

Persistence layer

Get A

Ehcache

Database
Cache as a s-o-r : Write through
Application

Persistence layer

Ehcache

Database
Tom travaille pour un site
de vente en ligne,
l’important est de
garantir les temps de
réponses et tant pis si la
donnée n...
Cache as a s-o-r : Write Behind
Application

Get A B C D
Ehcache

Write-behind
thread

Put A
B
D
C

Persistence layer

Wri...
Temps
de
Write Through – Temps de
réponses
Write Behind – Temps de
réponses
Base de
données
Write Through – Database load
Write Behind – Database load
Tom n’a pas
la main sur
les données
insérées/modifi
Paul travaille dans
une banque où à
heure fixe, de
gros volumes de
données sont
LED
REFRES
H
REFRES
H
AHEAD
0

TTR

TTL
CACHE ASIDE

VS
READ/WRITE
Refresh
Ahead/Schedul
ed Refresh

VS
Refresh Ahead

VS
Scheduled
Refresh Ahead
Write
Behind

VS
Write
CONNAI
T TES
CACHE
CACHE
capacité qu’a
l’architecture pour

évoluer en cas
de montée en
Wikipedia
charge si
d’une
application est
égale à la
scalabilité de
son composant

le moins
DISTRIB
UTION
Consistence
• Julie / 32 ans / 2 enfants / Paris
• Paul / 27 ans / 4 enfants / Marseille
• Thomas / 40 ans / 1 enfant / Pa...
ANY

ONE

EACH QUORUM

THREE
TWO

QUORUM
LOCAL QUORUM
CAP
• Consistency :
• Availability :
• Partionning
• Consistency + Available = RDBMS
• Consistency + Partionning = BigTable / Hbase /
MongoDB / Redis
• Available + Partionni...
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Cache
Upcoming SlideShare
Loading in …5
×

Cache

542 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
542
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Qu’estceque le cache ?Le but : faire en sortequ’unepartie des donnéessoient le plus rapidement accessible par l’application.
  • Hello, Thanks for coming.My name is Mathilde Lemee, I’m a java developper. I’m a QA Engineer for terracotta, a company specialized in in-memory caching and scaling. I’m also a Java User Group founder in France, one that focus women in Java and I do some mobile developpement on iPhone and Android - some kid apps to help children learning. Today we will talk about a fluent wrapper in top of the Java API, FluentLenium.
  • Principalement au niveau de la ram.
  • Description + Quandutiliser ? Casclassique, besoin de monter en charge, focus sur les lectures.2 APIs une pour le cache, une pour la DBAméliore les temps de lectureDécharge la base de données en lecturePeutintroduireune race condition en ecritureProblemed’invalidation (incoherence db/cache)
  • Réduit la latence des lectures / Décharge la BDD => comme cache asideUneseule APIDog-pile effect possible : siplusieurs threads demandent en meme temps la meme donnée qui n’est pas la, alorsilva y avoir n requetesvers la db.Recquiert un cache intelligent
  • Focus sur les écritures1 API pour le cacheLa transaction n’est pas complete tantque la donnéen’a pas etéécritedans la “bdd” => pas de races conditionsAugmentelegerement la latence des ecrituresInvalidation naturelle
  • Augmenteénormément le nombred’écriture par secondePossibilitéd’écrire par batch => unegrosserequete plus efficacequeplusieurs petiteConflationFenetredanslaquelleil y a des différences entre le cache et la db / incohérence.
  • Fournie par Coherence
  • Une lecture peutentraineruneecritureasynchroneDiminution latence read.Se base sur le fait quel’onest capable de prédirenosacces future ànosdonnées. Si celui ci estrespectéalors pas de surcharge de la DB. Par contre, sicelui ci n’est pas “respecté”alors beaucoup de donnéesvontétrerecalculées/récupérées pour rien => charge inutile de la base de données.
  • Batch size, job parralel count, bulkload, quartz job count …
  • Une lecture peut entrainer une ecriture asynchroneDiminution latence read.Se base sur le fait que l’on est capable de prédire nos acces future à nos données. Si celui ci est respecté alors pas de surcharge de la DB. Par contre, si celui ci n’est pas “respecté” alors beaucoup de données vont étre recalculées/récupérées pour rien => charge inutile de la base de données.
  • Une lecture peutentraineruneecritureasynchroneDiminution latence read.Se base sur le fait quel’onest capable de prédirenosacces future ànosdonnées. Si celui ci estrespectéalors pas de surcharge de la DB. Par contre, sicelui ci n’est pas “respecté”alors beaucoup de donnéesvontétrerecalculées/récupérées pour rien => charge inutile de la base de données.
  • Si plusieurs threads attaquent la meme données, chacun va faire les aller retour réseau dans le cas de cache aside.Alors qu’une seule action dans le cas de read/write through (lock sur la clé par exemple)
  • Refresh Ahead tres performant si un cache peut prédire quelles donnéees vont etre accessible dans le futur. Si cette connaissance est complete, alors des lectures beaucoup plus rapides et pas d’overhead sur la base. Mais plus il y a d’échec dans cette connaissance, plus il va y avoir un overhead important sur la base de données ( des données non utilisées sont mises à jour).
  • Refresh Ahead tres performant si un cache peut prédire quelles donnéees vont etre accessible dans le futur. Si cette connaissance est complete, alors des lectures beaucoup plus rapides et pas d’overhead sur la base. Mais plus il y a d’échec dans cette connaissance, plus il va y avoir un overhead important sur la base de données ( des données non utilisées sont mises à jour).
  • Si write Behind possible au point de vue métier (fenetre d’incohérence) alors il vaut mieux le choisir, diminue la latence, la charge de la dbb, permet de faire bcp plus de write a la secondes. Sinon write through.
  • Pourceux qui ont déjà travaillé avec de gros volumes de données, on a touscommencé avec une petite base de données, SQL ouNoSQL, un cache, un in memory data grid, petit et maitrisé, rapide.
  • Puiscesystème a grossit, au début sans trop de problème
  • Et puis,c’estvitedevenu plus compliqué. Notre petit système de stockageestdevenugros, on a un CPU qui surchauffe, des problèmes de taillesmémoires, d’encombrement …Cesoir, c’estce genre de problèmatiquequel’onvarésoudredanscette première partie : comment gérer la montée en charge de notresystème de stockage.
  • Et cac’estcequ’onappelle la scalabilité.Comment estceque je peuxscaler ?
  • La première est la scalabilitéverticale. Le concept estassez simple, on rajoute du hardware surnotreserveurs pour qu’ilspuissenttenir la charge encore et encore. On valuiajouter des CPUs, de l’espacedisque, de la RAM … Il y a plusieursavantagesàcechoix : celapeutdiminuter le cout de certaines licenses, moins de maintenances … Par exemplemaintenant, avec BigMemory, ilest tout a fait possible de faire tenir 2 to en RAM suruneseule machine.Il y a des inconvénients : les prix s’envolentassezviteniveau hardware des qu’on arrive au limite de cequ’offre le marché.Si on veutetrerésistant aux pannes, comment faire quand tout estcentralisé ?
  • La deuxiémeest la scalabilitéhorizontale.Ici on rajoute des resources, des machines et on les fait travailler ensemble.C’estmoinscher, beaucoupmoinscher. Beaucoup plus de maintenances, meme sicas’automatise de plus en plus.
  • Il y a plusieursfacons de gérersesmontées en charge. Ainsisi par exemplevotre base de donnéesouvotre cache ne peuvent pas euxaussiscalerhorizontalement, alorsvousserezobligé de scalerverticalementjusqu’àunelimite “physique” et technologique. Il esttrès important d’identifier en avance de phase les composants qui peuventetrebloquantdansnotre application, quecasoitune application web, du back-end, des batchs …
  • Au niveau des base de l’architecture de base dedonnées, on vadécoupercelle-ci en shard. http://en.wikipedia.org/wiki/Shard_(database_architecture)Un shard qu’estcequec’est ?Chaque shard estune base de donnéesindépendante et collectivemeent, celadonneuneseule base de données.Typiquement, sij’utiliseune base mongodb d’un téra et que je remarque par exempleque les lectures deviennentlentes au fur et àmesurequemontrafic/mon volume de donnéeaugmente. Et bien le shardingvatypiquementetreune des solutions àceproblème.
  • On voiticiquej’aimodifié ma collection qui fait un terra pour no plus qu’elletiennedans un unique shard maisdans 4 shard, de 256 GB chacun !Le shardingpermet de résoudre la problematique descaler en supportantd’une part des gros volumes de données et d’autres parts une forte demandesurces memes données.Le shardingpermet de réduireici le nombred’opérationsqu’effectuechaquenoeud. Lorsque le cluster grossit, chacun des shards fait beaucoup moinsd’opérations qui si on étaitdans la solution en faut, avec une unique base de données. Par exemple pour insésrerunedonnée, celle le shard responsible de cettedonnéevaeffectuer des opératons.
  • Il y a plusieursmoyens de distribué les donnéessurchacun des shards.Les systèmes les plus primitifsvontnécessitéune intervention manuelle, commec’est le cassur les anciennes versions de pas mal de bases NoSQL.
  • MongoDB : A chunk : A contiguous range of shard key values within a particular shard. Chunk ranges are inclusive of the lower boundary and exclusive of the upper boundary.Mais comment distribuer ?Range : 0-10 10-20 20-30 30-40Given a range based partitioning system, documents with “close” shard key values are likely to be in the same chunk, and therefore on the same shard.Hashing (crypto)With hash based partitioning, two documents with “close” shard key values are unlikely to be part of the same chunk. This ensures a more random distribution of a collection in the cluster.Dans les 2 cas, attention si on choisit un mauvaischamptlors du hachage : tous les objetsayant le meme hash vont se retrouversur le meme shard.
  • Avec Cassandra, on a un système de répartition par range un peudiffférentdans la mesureoù avec Cassadra, le volume total de donnéesgérées par le cluster estreprésenté en tantqu’anneau. L’anneauestdivisée en nombre de ségmentégal au nombre de noeud. Avant qu’unnoeudpuisserejoindrel’anneau, ilfaudralui attributer un token indiquantsa position et son segment de données. Chaquenoeudest responsible de la région entre lui meme inclut et son prédecesseur (exclut). Le dernier noeudestconsidérécomme le prédecesseur du premier, d’oùcettereprésentation en anneaux.Danscet example de 4 noeuds, toutes les cléssontmanagés par un cluster pour des valeurs de 0 à 100. Chaquenoeud a un token assigné, respectivement 0,25,50 et 75. Le premier noeud, avec le token 0, est responsible des données du segment de 0 à 25. On remarmarqueque le 4eme segment accepte des plus petites que le plus petit des tokens (0) et plus grandeque le plus grand des tokens (75).Le partionnement des donnéesestune des points sensibles. Dépendant des outils, celapeutetre le client qui effectuecepartionnage, oucelapeutetrecalculé. La plupart du temps baséssur des algorthmes des Hashage. Si on gardel’example de Cassandra, on retrouvealors un algorithmeRandomPartionnerbasésurune distribution par hashagemaisaussiORderPreservingPartionner qui garantitque les cléssontorganisées de manièrenaturelle. L’algorithmequel’onchoisit depend de cequel’onveutveut (lecture/ecriture/recherche …).
  • J’aimaintenantoublié ma grosse base essouflée d’un tera, j’aimaintenant 4 shards de 256 go sur 4 resources phsyiquesdifférentes. J’ai de bonsrésultats en lectures et en écritures. Maisqu’estce qui se passesi je veuxmonterà 2 to ? Etsi je veuxajouter un noeudà la volée ?
  • Ce concept de rajouter des resources à la volée, c’estl’élasticité de votre base de données. Pas mal ne le sont pas, c’estvraimentquelque chose àprendre en comptedès le début.
  • Qu’estce qui se passe avec cassandra, sij’ai 5 nodes et quej’enajoute un 6eme F. Le noeudvaetredetecté, ajouté au cluster et les donnéesvontetredéplacées, d’un noeudàl’autre (cen’est pas gratuit !).Il faut par example recalculer les token pour chacun des noeudssur le cluster. Chaque token désignantsa position surl’anneau et donc le segment de donnéesqu’ilestamenéà stocker
  • Et pour unedéco / reco du mode? Alorsimaginonsicique le noeud 5 a disparu. Puis un nouveau noeud 5 estrecrée. Alors, ilvarécuperer des shards primaires et des réplicas pour garantirune charge équivalente.
  • A chunk : A contiguous range of shard key values within a particular shard. Chunk ranges are inclusive of the lower boundary and exclusive of the upper boundary.Ontrouveaussi la possibilité avec mongoDB de couper un gros chunk (définir un chunck), qui icidépasseraitunelimite de 64mo en 2 chunk plus petit de 32 mo. De maniereautomatiqueoumanuelle. (on ne peut pas les recollerensuite).
  • On peutensuiteeffectuer de manièreautomatique des migrations des chunks de la collection d’un shard à un autre via le process de balancer.
  • An index is like a ‘database’ in a relational database. It has a mapping which defines multipletypes.Si on regarde du coté d’élastic search, chaque index (définir un index) a 5 shards primaires. On peut bien sur spécifier plus ou moins mais 5 est le défaut.On ne peut pas changer le nombre de shards primairesunefoisquel’index a étécrée.You cannot change the number of primary shards in an index, once the index is created
  • Si on regarde du coté de couchbase, on voitapparaitre le notion de virtual Nodes, ici virtual bucket. C’estune notion quel’onretrouvedésormais un peu partout (mongodb/cassandra) … Qu’enestil de couchbase ? Ici on a un cluster a 4 noeuds. Quand un client veutobtenir la value de la clérecherchée, un algorithme de hashagevapermettre de d’indiquersurquelvBucketchercher. Par exemple, sil’algoretourne pour keyA vB8, le noeudsassocié sera le serveur C.
  • Si on ajoute un serveur D,alorsl’algorithme de hashagevatoujoursindiquer le vBucket8. Mais la map qui contient les liens entre vBucket id et serveurvadésormaisindiquer le serveur D. Le lcient v alorsdirectementcommunqieur avec le server D pour obtenirl’information.
  • Donc on a maintenant un cluster quel’onsait faire évoluer en ajoutant (et retirant des noeuds). Mais plus j’ai de noeuds, plus j’ai de risques de recontrerunepanne.
  • On vadoncutiliser des réplicas pour garantirune résistance aux pannes. Un réplicaestuneréplication.
  • Si on reprendsnotre cluster cassandra en anneau, avec ses 4 noeudsrangés, avec des tokens 0,25,50,75.
  • On aura maintenantplusieursréplicas pour un shard primaire.Ici avec cassandra, il y a par défaut un unique réplica (elastic search en a aussi 1). Le nombre de réplicaspeutetre changer, et jamais un réplica ne sera lancésur le meme noeudque le shard primaire.
  • Quandunedonnéeestinséréedans le shard primaire, elleestrépliquée en générale de manièreasynchrone, versl’ensemble de sesréplicas.Les réplicas et le shard primaires’envoient des messages pour garantirqu’ilssontbientousfonctionnels.Qu’estcequ’il se passesi le shard primaireest en échec ?
  • Alors, un réplicaestélu en tantque primary shard. C’estversce shard queserontfaite en première les écritures.
  • L’un des avantages des vNodes, qui ne nécessite pas la création de nouveau token, c’estque les shards sont beaucoup plus petits.En effet, quand un shard estdéplacé,Within a cluster these can be randomly selected and be non-contiguous, giving us many smaller ranges that belong to each node.
  • Et simonréplicaprends la main alorsqueune information n’yavait pas étérépliquée ?Perte de données.
  • Les bases de données “traditionnelles” vonttoutesrépondre Paris. Tout le monde doitvoir la meme chose, quelquesoit le quecelaprends, quecesoit la nouvelle oul’ancienne value.Bases de donnéesNoSQL (non consistante) : Pour les grosses applications (on parleici de centaines de serveurs) on ne peut pas se permettred’attendresilongtemps et estcevraiment important ?
  • Level Description Usage ANY A write must be written to at least one node. If all replica nodes for the given row key are down, the write can still succeed after a hinted handoffhas been written. If all replica nodes are down at write time, an ANY write is not readable until thereplica nodes for that row have recovered. Provides low latency and a guarantee that a write never fails. Delivers the lowest consistency and highest availability compared to other levels. ONE A write must be written to the commit log and memory table of at least one replica node. Satisfies the needs of most users because consistency requirements are not stringent. Thereplica node closest to the coordinator node that received the request serves the request (unless the dynamic snitch determines that the node is performing poorly and routes it elsewhere). TWO A write must be written to the commit log and memory table of at least two replica nodes. Similar to ONE. THREE A write must be written to the commit log and memory table of at least three replica nodes. Similar to TWO. QUORUM A write must be written to the commit log and memory table on a quorum of replica nodes. Provides strong consistency if you can tolerate some level of failure. LOCAL_QUORUM A write must be written to the commit log and memory table on a quorum of replica nodes in the same data center as the coordinator node. Avoids latency of inter-data center communication. Used in multiple data center clusters with a rack-aware replica placement strategy ( NetworkTopologyStrategy) and a properly configured snitch. Fails when using SimpleStrategy. Use to maintain consistency at locally (within the single data center) . EACH_QUORUM A write must be written to the commit log and memory table on a quorum of replica nodes in alldata centers. Used in multiple data center clusters to strictly maintain consistency at the same level in each data center. For example, choose this level if you want a read to fail when a data center is down and the QUORUM cannot be reached on that data center. ALL A write must be written to the commit log and memory table on all replica nodes in the cluster for that row. Provides the highest consistency and the lowest availability of any other level. Even at consistency level ONE or LOCAL_QUORUM, the write is still sent to all replicas for the written key, even replicas in other data centers. The consistency level just determines how many replicas are required to respond that they received the write.About read conThe consistency level specifies how many replicas must respond to a read request before returning data to the client application.sistencyCassandra checks the specified number of replicas for the most recent data, based on the timestamp, to satisfy the read request.Read Consistency LevelsLevel Description Usage ONE Returns a response from the closest replica, as determined by the snitch. By default, a read repair runs in the background to make the otherreplicas consistent. Provides the highest availability of all the levels if you can tolerate a comparatively high probability of stale data being read. The replicas contacted for reads may not always have the most recent write. TWO Returns the most recent data from two of the closest replicas. Similar to ONE. THREE Returns the most recent data from three of the closest replicas. Similar to TWO. QUORUM Returns the record with the most recent timestamp after a quorum of replicas has responded. Ensures strong consistency if you can tolerate some level of failure. LOCAL_QUORUM Returns the record with the most recent timestamp once a quorum of replicas in the current data center as the coordinator node has reported. Avoids latency of inter-data center communication. Used in multiple data center clusters with a rack-aware replica placement strategy ( NetworkTopologyStrategy) and a properly configured snitch. Fails when using SimpleStrategy. EACH_QUORUM Returns the record with the most recent timestamp once a quorum of replicas in each data center of the cluster has responded. Same as LOCAL_QUORUM ALL Returns the record with the most recent timestamp after all replicas have responded. The read operation will fail if a replica does not respond. Provides the highest consistency of all levels and the lowest availability of all levels.
  • Consitency : Est-cequetoutes les applications voient les memes données ?Availabilty : Can I interact with the system in the presence of failures ?Partiionning : Si 2 sections du système ne peuvent pas se parler , estceque le systèmepeut continuer seul ?Si non, ilfautsacrifier la dispo.Si oui, ilfautsacrier la consistence – one ne peut pas tout avoirLes bases de donnéesconventionnellestendent le CA, les clusters sontconsidérescomme petit et local.Les bases de donnéesnoSQLsacrifient la plupart du temps la consistenceCindy HERLY
  • Les bases de donnéesconventionnellestendent le CA, les clusters sontconsidérescomme petit et local.Les bases de donnéesnoSQLsacrifient la plupart du temps la consistenceMongoDB : CP ?
  • Sources : http://computer.howstuffworks.com/computer-memory4.htmDocumentation : terracotta, cassandra, mongodb, couchdbSchema write behind : oracle coherence doc
  • Cache

    1. 1. LE CACHE Dans tous ses états
    2. 2. Mathilde Lemée Java developper Terracotta Engineer DuchessFR Founder Mobile dev – Aetys.fr FluentLenium
    3. 3. MISS
    4. 4. TTI TTL
    5. 5. Cache Aside "Par ma foi ! Il y a plus de quarante ans que je dis de la prose sans que j'en susse rien. " Molière ; Le Bourgeois gentilhomme
    6. 6. Tom veut un cache simple pour améliorer l’accès aux données.
    7. 7. CACHE ASIDE Application Cache Put A Get B B DAO Read B Databas e
    8. 8. Tom aimerait garantir que son cache comporte toujours les données les plus récentes.
    9. 9. System of Record
    10. 10. Cache as a s-o-r : Read through Application Persistence layer Get A Ehcache Database
    11. 11. Cache as a s-o-r : Read through Application Persistence layer Get A Ehcache Database
    12. 12. Cache as a s-o-r : Write through Application Persistence layer Ehcache Database
    13. 13. Tom travaille pour un site de vente en ligne, l’important est de garantir les temps de réponses et tant pis si la donnée n’est mise à jour
    14. 14. Cache as a s-o-r : Write Behind Application Get A B C D Ehcache Write-behind thread Put A B D C Persistence layer Write A B C D Database
    15. 15. Temps de
    16. 16. Write Through – Temps de réponses
    17. 17. Write Behind – Temps de réponses
    18. 18. Base de données
    19. 19. Write Through – Database load
    20. 20. Write Behind – Database load
    21. 21. Tom n’a pas la main sur les données insérées/modifi
    22. 22. Paul travaille dans une banque où à heure fixe, de gros volumes de données sont
    23. 23. LED REFRES H
    24. 24. REFRES H AHEAD
    25. 25. 0 TTR TTL
    26. 26. CACHE ASIDE VS READ/WRITE
    27. 27. Refresh Ahead/Schedul ed Refresh VS
    28. 28. Refresh Ahead VS Scheduled Refresh Ahead
    29. 29. Write Behind VS Write
    30. 30. CONNAI T TES
    31. 31. CACHE
    32. 32. CACHE
    33. 33. capacité qu’a l’architecture pour évoluer en cas de montée en Wikipedia charge si
    34. 34. d’une application est égale à la scalabilité de son composant le moins
    35. 35. DISTRIB UTION
    36. 36. Consistence • Julie / 32 ans / 2 enfants / Paris • Paul / 27 ans / 4 enfants / Marseille • Thomas / 40 ans / 1 enfant / Paris – Déménagement de Thomas sur Marseille Qui habite sur Paris ?
    37. 37. ANY ONE EACH QUORUM THREE TWO QUORUM LOCAL QUORUM
    38. 38. CAP • Consistency : • Availability : • Partionning
    39. 39. • Consistency + Available = RDBMS • Consistency + Partionning = BigTable / Hbase / MongoDB / Redis • Available + Partionning = Riak/Cassandra/CouchDB

    ×