ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 141
Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 116
Abonament PDF

Soluții cloud – Change Data Control și DynamoDB

Cătălin Dragoș Sinca
Software Development Manager @ Accenture



PROGRAMARE


În ziua de azi, din ce în ce mai multe proiecte software aleg să se folosească de platforme publice de cloud. Fie că vorbim de Azure, AWS sau Google Cloud, impactul serviciilor oferite de aceste platforme poate schimba fundamental modul în care sistemele software sunt concepute și folosite. În ceea ce urmează, vom exemplifica acest aspect plecând de la un scenariu întâlnit într-unul dintre proiectele noastre.

Odată cu migrarea în AWS a unui produs existent, bazat pe o arhitectură de micro servicii clasică, găzduit și operat într-un centru de date local, am avut și cerința suplimentară de a stoca și agrega cererile utilizatorilor de căutare a unor puncte de interes, localizate pe hartă - restaurante, hoteluri, benzinării sau alte astfel de obiective. Aceste date urmau să fie folosite ulterior la construirea unui istoric personalizat și prioritizat în funcție de numărul cereri pentru anumite locații sau tipuri de obiective de interes pentru fiecare utilizator în parte.

Destul de frecvent, în proiecte care se bazează pe REST APIs, implementate prin micro servicii, întâlnim situații în care datele stocate recurent în baze de date RDBMS necesită o prelucrare ulterioară înainte de a fi returnate către front-end. Acesta era și cazul nostru, însă această abordare tradițională poate implica și anumite dezavantaje, precum:

Așa că, deși implementarea unei astfel de soluții nu presupune un grad de complexitate prea mare, operarea aplicației productive vine cu oarecare dificultăți și costuri adiționale.

Cu această migrare ne-am propus de asemenea să ne folosim de tehnologiile oferite de platforma cloud pentru a simplifica operarea produsului. Pentru noi, AWS DynamoDB și funcțiile lambda s-au dovedit a fi o abordare mai eficientă.

Mecanismul de Change Data Control (CDC) oferit de DynamoDB creează automat evenimente care capturează schimbările survenite pe fiecare înregistrare din tabela DynamoDB asociată, fie că este vorba de introducerea unei înregistrări noi, modificarea sau ștergerea unei înregistrări existente. Aceste evenimente pot fi publicate automat pe un DynamoDB stream, sau pe un Kinesis stream; chiar mai mult, evenimentele pot fi publicate pe ambele streamuri în paralel.

Așa că pentru a stoca interacțiunile utilizatorilor ne-am folosit de o tabelă DynamoDB definită astfel:

Partition key: customer_id

Sort key: last_interaction_time

Fiecare acțiune a unui utilizator, odată stocată în această tabelă, va genera un eveniment în DynamoDB stream, unde un subscriber configurat în prealabil va invoca o funcție lambda ce implementează mecanismul de agregare și stochează datele finale agregate într-o altă tabelă DynamoDB.

Partition key: customer_id

Sort key: action_string_hash

Această soluție de tip serverless a simplificat considerabil gestionarea aplicației în producție. Spre deosebire de RDBMS-urile tradiționale, AWS DynamoDB este un produs 'fully managed' de către AWS, iar din punct de vedere al performanței, prin eliminarea nevoii de interogări complexe datorită implementării logicii de agregare într-o funcție lambda, extragerea datelor din tabela finală a devenit extrem de rapidă.

DynamoDB și funcțiile lambda vor scala automat în momentul creșterii semnificative a traficului, fără să trebuiască să gestionăm explicit nimic legat de load balancing sau autoscaling. Totuși, există o limitare (throttling) din motive de cost, aceasta este dată de capacitatea de scriere sau citire rezervată - Read Capacity Units și Write Capacity Units definite pentru conexiunea aplicației la instanța de DynamoDB. În momentul depășirii acestei limitări, apelurile suplimentare vor fi respinse, rezultând în final în erori HTTP 429 (Too many requests) către aplicație.

Fiecare tabelă DynamoDB poate avea configurat, de asemenea, un TTL ('time to live') pentru înregistrările stocate; prin urmare, acestea vor fi șterse automat la expirarea acestui time to live, fără costuri adiționale și fără să fie necesară implementarea explicită a unui mecanism de ștergere a datelor.

Dar un potențial dezavantaj al acestei soluții este faptul că posibile nevoi de analiză ale datelor ulterioare nu vor putea fi satisfăcute; o soluție de stocare key-value store precum DynamoDB nefiind prea flexibilă în ceea ce privește construirea de rapoarte și analize ale datelor. Totuși, această limitare este compensată de posibilitatea de a exporta datele în S3 sau chiar de a activa în paralel transmiterea evenimentelor de Change Data Control pe un Kinesis stream, de unde pot fi analizate cu Amazon Athena sau propagate într-o bază de date specializată pentru nevoi de analiză a datelor, cum ar fi Amazon Redshift.

AWS DynamoDB și evenimentele de Change Data Control nu reprezintă în niciun caz o soluție universală pentru orice tip de problemă de genul celei întâlnite de noi, însă cu siguranță această abordare merită luată în considerare, din moment ce poate aduce avantaje importante care se pot dovedi decisive în alegerea soluției potrivite.

NUMĂRUL 140 - Generative AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO