Servirea unei baze mari de utilizatori cu date fiabile, consistente și cu latență scăzută este o provocare foarte grea pentru orice echipă de backend. La Ledger, am făcut alegerea strategică de a găzdui propriile noastre servicii de date de bază blockchain. Ne bazându-ne pe terțe părți, putem gestiona singuri datele clienților noștri, asigurându-ne că procesele subiacente respectă ghidurile noastre de securitate și obiectivele de nivel de servicii (SLO) orientate spre performanță.
Dar această strategie aduce și propriul set de provocări.
Prima noastră provocare este să migrăm aceste servicii de bază de furnizare de date departe de instrumentele noSQL cool și strălucitoare. În acest articol, voi explora de ce am luat această decizie dificilă, complexitățile pe care le-am întâlnit și beneficiile pe care le-am cules.
Scopul acestui articol este de a arăta aspectele tehnice care ne-au determinat să alegem PostgreSQL ca nou strat de stocare de bază pentru datele blockchain.
Aprofundare în datele Blockchain
Datele blockchain au mai multe caracteristici cheie.
În primul rând, este în continuă creștere și nimic nu este niciodată șters din el. Cu toate acestea, în practică, deși cea mai mare parte a unui blockchain este imuabilă, cea mai tânără parte a blockchain-ului se poate schimba din cauza conflictelor care trebuie rezolvate. Într-adevăr, deoarece lanțul este o rețea peer to peer, mai multe blocuri legitime pot coexista temporar. De obicei, cel mai vechi este șters, rezultând ceea ce numim o reorganizare. Pe scurt, datele sunt împărțite între o coadă rece imuabilă și o stare de cap care se schimbă rar.
Problema pe care încercăm să o rezolvăm este că, deși blockchain-urile sunt grozave pentru a avea date bizantine tolerante la erori, sunt mai puțin eficiente pentru a le tăia și a le tăia în bucăți pe mai multe axe. Și anume, obținerea listei operațiunilor care au afectat un cont este foarte dificilă. Chiar și obținerea unui sold de cont pe un blockchain precum bitcoin este o provocare atunci când nu aveți deja lista tranzacțiilor.
Pentru a depăși aceste provocări, Ledger Explorer Services indexează întregul blockchain.. Este un serviciu mare, critic și sensibil la performanță, scris complet în Scala, folosind pisici-efect timp de rulare de înaltă performanță. Avem peste 10k rps pe bitcoin, menținând în același timp o latență p95 sub 100 ms. Facem și recrutări 😊.
Un pic de istorie
La începutul poveștii noastre, cu mult înainte de a mă alătura companiei, nivelul serviciului de date Ledger era gestionat de o bază de date Neo4j încorporată. Fiecare cutie de servire își indexa propriile date și le difuza local, ceea ce a cauzat o mulțime de probleme.
Consecvența datelor între instanțe nu a fost garantată, iar dimensiunea mare a stării care trebuia indexată, combinată cu utilizarea discului și a ramului neo4j, nu a fost scalabilă. Această problemă s-a agravat doar pe măsură ce compania a crescut, făcând din ce în ce mai dificilă generarea de noi instanțe.
Cassandra a fost apoi ales ca motor principal al acestei noi configurații: este o bază de date grupată, scalabilă orizontal, care se află pe partea AP a teoremei CAP. Rezolvă problemele legate de partajarea datelor și permite o separare clară între componenta de indexare, blockchain și serverele API fără cap.
Dar ce rost are să avem la dispoziție întreaga stare istorică dacă nu vom citi niciodată din ea?
În ceea ce privește cazul nostru de utilizare, datele istorice brute sunt rareori necesare, deoarece starea contului utilizatorului nostru poate fi agregată din acestea. Acest lucru ne-a determinat să provocăm soluția existentă de stocare a datelor care se bazează pe baza de date distribuită Cassandra.
Volumul de date pe care trebuie să îl stocăm pe blockchain, deși este în intervalul terabyte, nu este ceea ce se poate numi „date mari”. Mai mult, partea din dacă va fi folosită pentru a răspunde la majoritatea întrebărilor (alias Calea fierbinte) este și mai mică. În prezent, puteți găsi cu ușurință servere hardware de bază cu mai mult de 16 TB de stocare SSD NVMe. Scalare verticală este un instrument foarte puternic, precum și o bază de date relațională.
În cele din urmă, principala problemă pe care am avut-o cu configurația actuală Cassandra nu a fost nici modelul de stocare risipitor, nici cazul de utilizare a datelor prost adaptat, ci lipsa de prietenie pentru dezvoltatori. Dezvoltarea unei noi caracteristici bazate pe date pe Cassandra s-a dovedit că consumă inutil timp. Ne-am străduit să implementăm fiecare nouă axă pe care trebuie să furnizăm date.
Având în vedere expertiza echipei noastre în abilitățile de modelare a datelor și competența SQL, PostgreSQL a fost candidatul perfect. Această soluție este testată în luptă, robustă, ușor de extins, ceea ce o face o alegere ideală.
De ce am ales SQL în locul NoSQL:
- Citește/Scrie solduri: cazul de utilizare a datelor blockchain a fost puternic denaturat în privința citirilor, mai degrabă decât a scrierilor (blockchain scrie foarte puține date la o rată foarte rezonabilă, chiar și pentru un blockchain precum Polygon). Cassandra are capacitatea de a absorbi o cantitate foarte mare de scrieri - calea de citire este de fapt mai lung decât calea de scriere.
- Suport pentru indexare: Indicii sunt o componentă cheie a unui SGBD pentru a răspunde întrebărilor și noilor cazuri de afaceri sau oportunități. Cassandra are suport limitat pentru indexare. Indicii sunt eficienți numai dacă interogarea specifică deja o modalitate de a restrânge partiția pe care va rula interogarea. Noi plătim aici costul pentru a avea un distribuit arbitrar Bază de date. Suportul PostgreSQL pentru indici este eficient, extensibil și la margine.
- Suport de agregare: Același caz pentru agregare; întrucât Cassandra nu permite agregarea cu mai multe partiții și nu tolerează nicio clauză GROUP BY în limbajul său de interogare, suportul său este oarecum lipsit. PostgreSQL propune un suport extins de agregare, chiar și pe tipuri de date exotice precum intervale și blob-uri jsonb.
- Modelarea datelor: Cassandra este foarte, foarte limitatoare în modul în care este posibilă modelarea datelor. Trebuie creat un tabel pentru aproape fiecare cerere la care doriți să răspundeți, iar datele trebuie să fie denormalizate în rânduri mari (folosind complet magazin cu coloane late aspectul C* și, de asemenea, faptul că scriitorii sunt foarte ieftini). PostgreSQL ne permite să valorificăm aspectul relațional al blockchain-ului (apeluri, tranzacții, blocuri) și spațiu de rezervă pe disc, încurajând reutilizarea datelor.
- Interogări ad-hoc și auditare: Fiind capabil să utilizăm standardul complet al SQL și să facem interogări arbitrare înseamnă că putem explora și căuta potențiale cauze principale ale erorilor sau avem date exploratorii pentru cazurile de utilizare viitoare. Putem folosi cu adevărat baza de date ca un instrument interactiv și inteligent, mai degrabă decât un stocare prost. Făcând acest lucru pe Cassandra fără un cluster de calcul analitic extins și costisitor, cum ar fi Presto, Spark etc. (și deoarece rulăm pe servere bare metal, nu avem acces la instrumente de analiză a datelor distribuite ușor de generat, cum ar fi EMR).
- Utilizarea depozitului: Presupunerea Cassandra este că stocarea este foarte ieftină și că clusterul poate fi extins cu ușurință cu mașini noi. Asta inseamna ca toate limitările atât la indici cât și la agregare trebuie plătite cu stocare. Fără indici eficienți la nivel global și suport pentru unire înseamnă că trebuie să denormalizăm și să stocăm o copie a întregului tabel pentru fiecare axă pe care dorim să o interogăm. PostgreSQL ne scutește de terabyte de stocare.
- consecvență: Deoarece Cassandra este o bază de date distribuită, orientată către AP (comunicarea se face prin bârfă între noduri), consistența este doar eventuală în ceea ce privește scrierile. Puteți regla politica de consistență a fiecărei declarații atât pentru citire, cât și pentru scriere, dar scopul acestei baze de date nu a fost niciodată să aibă o consistență puternică. PostgreSQL are o poveste puternică de a fi folosit pentru misiuni critice și este foarte rezistent. A fi centralizat înseamnă, de asemenea, că nu există nicio rețea implicată în calea de scriere.
- Tranzacții și MVCC:
- Tranzacții: Cassandra sprijină doar tranzacții ușoare pe interogări DML. Se pot aplica unele loturi (medic) dar există numeroase avertismente, și anume că rândurile trebuie să fie pe același server (= partiție) pentru a nu avea performanțe groaznice.
- MVCC: Cassandra acceptă marcarea timpului rândurilor, dar MVCC complet nu este garantat. O compactare poate șterge datele învechite și nu există nicio modalitate de a-i spune lui C* că nu ar trebui (cum ar fi, de exemplu, o tranzacție în PG).
- PostgreSQL acceptă un model MVCC puternic care asigură o cale de citire consecventă pentru utilizatorii noștri.
- scule: PostgreSQL are mult mai multe instrumente care sunt utilizate pe scară largă pentru a opera cu ușurință baza de date. Mai mult, un instrument ca calea de zbor ne asigură că menținem o versiune puternică a schemei bazei de date. L-am integrat deja cu baza noastră de cod cu succes. Nu există un echivalent cu acest nivel de maturitate pentru Cassandra.
- Scalabilitate orizontală: Acesta este punctul cheie de vânzare al Cassandra. Doar adăugați mai multe mașini pe măsură ce datele dvs. se extind. Nu există un echivalent pentru PostgreSQL, deoarece sharding-ul și partiționarea trebuie făcute manual.
Cum plănuim să creștem
După cum am văzut, singurul dezavantaj al utilizării unei configurații Postgres este scalarea atât pe citiri, cât și pe stocare. Ce putem face pentru a depăși această limitare?
Primul instrument eficient pe care îl avem este să segregam fiecare protocol sau blockchain pe care îl sprijinim în propria sa bază de date, deoarece astfel poate fi scalat corespunzător, având în vedere volumul și traficul. Segmentarea pe domenii de activitate asigură un prim strat de scalare.
Luând acest concept mai departe, putem, de asemenea, să segmentăm datele istorice reci în partiție temporală. Cele mai recente versiuni de Postgres au îmbunătățit mult gradul de utilizare a tabelelor partiționate, ceea ce ar putea permite mutarea perfectă a datelor pe un cluster de mașini. De exemplu, am putea folosi mașini mai ieftine, cu o putere de calcul mai mică pentru a găzdui majoritatea datelor istorice, păstrând în același timp niște mașini stivuite în RAM pentru a găzdui tabele agregate și cele mai recente operațiuni ale utilizatorului.
Această abordare funcționează foarte bine în cazul nostru de utilizare, deoarece nu există chei externe cu partiții încrucișate în stocarea istorică (totul este în cele din urmă atașat blocului). Din perspectiva serverului principal, datele istorice ar putea fi chiar accesate transparent folosind partiționarea și extensia postgres_fdw.
Pentru a ajuta la punerea în aplicare a tuturor acestor lucruri, am analizat și extensia TimescaleDB. Această extensie adaugă o mulțime de funcționalități postgres de bază, iar cele mai multe dintre acestea se potrivesc perfect pentru cazurile noastre de utilizare:
- Partiționarea automată a tabelelor pe baza unei coloane de tip timp (în cazul nostru, o adaptăm luând înălțimea blockchain-ului ca referință).
- Comprimare automată, conștientă de tipul de date și bazată pe coloane a bucăților mai vechi. Acest lucru asigură un raport de compresie aproape perfect prin utilizarea algoritmilor de ultimă generație pe date foarte asemănătoare.
- Agregare eficientă bazată pe intervale de timp pentru a calcula cu ușurință soldurile istorice și graficele de date ale pieței.
Suntem abia la începutul experimentelor în ceea ce privește stocarea, iar acest lucru deblochează o mulțime de cazuri de utilizare. Dovada conceptelor folosind o cantitate mică de date (~10k blocuri pe rețeaua principală Ethereum, deci aproximativ 2 zile de date) a arătat o reducere a spațiului pe disc cu până la 40%.
După cum am văzut, volumul de date, cu condiția să folosim strategia corectă, nu este o problemă. Dar cum să scalam cu dimensiunea bazei noastre de utilizatori?
Avem deja un avantaj frumos aici: indexăm toate datele blockchain. Astfel, spațiul de stocare necesar nu va crește ca numărul de utilizatori, ci ca dimensiunea totală a blockchain-ului. Optimizările de stocare și citiri sunt total ortogonale în rezoluția lor.
Această configurație, combinată cu necesarul foarte scăzut de scriere proporțional cu volumul de citire care trebuie servit, este configurația de vis pentru un model de replica lider-follower de clasificare. Pentru a îmbunătăți performanța și debitul suplimentar, putem plasa, de asemenea, replicile de citire postgres pe aceleași mașini ca și serverele API și să profităm de socketurile de domeniu UNIX pentru a sări peste călătoriile dus-întors în rețea.
Iată un exemplu de strategie de replicare a datelor pe care l-am putea folosi pentru a ne scala citirile. Casetele gri deschis reprezintă servere individuale. Putem vedea aici că podurile API sunt amplasate direct cu replici ale celor mai bune date pentru a asigura un timp minim de transfer între stocare și utilizatori. Instanțele de arhivă descrise anterior nu sunt reprezentate pentru a nu complica prea mult schema.
Concluzii finale
În calitate de utilizator Cassandra pe termen lung, vreau să subliniez faptul că este o bază de date excelentă în design, care se potrivește unei game largi de aplicații. Din păcate, alegerea făcută la Ledger de a-l utiliza a fost făcută pe un caz de utilizare a datelor care nu s-a materializat niciodată.
Productivitatea echipei noastre a fost afectată și, așteptând cu nerăbdare provocările pe care le avem de rezolvat, am ales să mușcăm glonțul și să nu cădem în eroarea costurilor scufundate.
În multe cazuri, datele dvs. nu sunt date mari. Gestionarea distribuției datelor nu este o sarcină dificilă în majoritatea cazurilor, iar compromisurile unei baze de date distribuite cu drepturi depline trebuie să fie luate în considerare cu atenție. Considerentul cheie este experiența dezvoltatorului, deoarece eliberează timp prețios pentru a construi orice altceva. Acesta este cazul real de utilizare în care trebuie să investim mult.
- Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
- PlatoAiStream. Web3 Data Intelligence. Cunoștințe amplificate. Accesați Aici.
- Mintând viitorul cu Adryenn Ashley. Accesați Aici.
- Cumpărați și vindeți acțiuni în companii PRE-IPO cu PREIPO®. Accesați Aici.
- Sursa: https://www.ledger.com/blog/serving-web3-at-web2-scale
- :are
- :este
- :nu
- $UP
- 10
- 10 K
- 20
- a
- capacitate
- Capabil
- acces
- accesate
- Cont
- peste
- de fapt
- adapta
- adăuga
- Adaugă
- adera
- Avantaj
- agregare
- algoritmi
- TOATE
- permite
- permite
- deja
- de asemenea
- Cu toate ca
- sumă
- an
- analiză
- Google Analytics
- și
- răspunde
- Orice
- nimic
- api
- aplicatii
- aplicat
- abordare
- în mod corespunzător
- arhivă
- SUNT
- în jurul
- Artă
- articol
- AS
- aspect
- aspecte
- presupunere
- At
- disponibil
- conştient
- departe
- AXE
- Axă
- Backend
- Sold
- soldurile
- de bază
- bazat
- De bază
- BE
- deoarece
- fost
- înainte
- Început
- giganti
- fiind
- Beneficiile
- între
- Mare
- Datele mari
- Pic
- Bitcoin
- Bloca
- blockchain
- date blockchain
- blockchains
- Blocuri
- atât
- Cutie
- Dulapuri
- Aduce
- Bug
- construi
- afaceri
- dar
- by
- apel
- apeluri
- CAN
- candidat
- capac
- cu grijă
- caz
- cazuri
- Provoca
- cauzată
- centralizat
- lanţ
- contesta
- provocări
- provocare
- Schimbare
- schimbarea
- ieftin
- mai ieftin
- masini mai ieftine
- alegere
- Alege
- a ales
- ales
- clar
- Grup
- cod
- baza codului
- rece
- Coloană
- combinate
- produs
- Comunicare
- companie
- complexități
- component
- Calcula
- concept
- Concepte
- considerare
- luate în considerare
- consistent
- Rece
- Nucleu
- A costat
- ar putea
- a creat
- critic
- Curent
- de date
- analiza datelor
- schimbul de date
- stocare a datelor
- Baza de date
- Zi
- decizie
- descris
- Amenajări
- Dezvoltator
- în curs de dezvoltare
- dificil
- direct
- murdărie
- distribuite
- distribuire
- împărțit
- do
- face
- face
- domeniu
- Dont
- dezavantaj
- vis
- şofer
- două
- e
- fiecare
- cu ușurință
- uşor
- Margine
- Eficace
- eficient
- altfel
- încorporat
- scoate in evidenta
- permite
- Fii încurajator.
- spori
- asigura
- asigură
- asigurare
- Echivalent
- etc
- ethereum
- ETHEREUM MAINNET
- Chiar
- eventual
- EVER
- Fiecare
- tot
- exemplu
- existent
- Exotic
- se extinde
- experienţă
- expertiză
- explora
- explorator
- extinde
- extensie
- extensiv
- fapt
- Cădea
- Caracteristică
- DESCRIERE
- puțini
- Găsi
- First
- potrivi
- Pentru
- străin
- Înainte
- prietenie
- din
- Complet
- cu drepturi depline
- complet
- funcționalități
- mai mult
- viitor
- obtinerea
- dat
- La nivel global
- scop
- merge
- grafice
- gri
- mare
- grup
- Crește
- În creştere
- garantat
- orientări
- HAD
- Greu
- Piese metalice
- Avea
- având în
- cap
- puternic
- înălțime
- ajutor
- aici
- Înalt
- extrem de
- istoric
- orizontal
- gazdă
- FIERBINTE
- cea mai tare
- Cum
- Cum Pentru a
- Totuși
- HTML
- HTTPS
- i
- ideal
- if
- imuabil
- afectate
- Punere în aplicare a
- îmbunătățit
- in
- tot mai mult
- index
- Indici
- instanță
- integrate
- interactiv
- în
- Investi
- implicat
- problema
- probleme de
- IT
- ESTE
- alătura
- alăturat
- jpg
- doar
- păstrare
- Cheie
- chei
- Copil
- lipsă
- limbă
- mare
- Latență
- Ultimele
- strat
- Led
- carte mare
- legitim
- mai puțin
- Nivel
- Pârghie
- ușoară
- categorie ușoară
- ca
- limitare
- limitări
- Limitat
- Listă
- mic
- la nivel local
- Lung
- uitat
- cautati
- Lot
- Jos
- Masini
- făcut
- Principal
- retea principala
- menține
- Mentine
- Majoritate
- Efectuarea
- administra
- de conducere
- manual
- multe
- Piață
- Piata de date
- scadență
- max-width
- Mai..
- mijloace
- metal
- migra
- minim
- misiuni
- model
- mai mult
- În plus
- cele mai multe
- muta
- mult
- trebuie sa
- și anume
- aproape
- Nevoie
- necesar
- nevoilor
- Nici
- reţea
- nu
- Nou
- frumos
- Nu.
- noduri
- nimic
- număr
- numeroși
- Obiectivele
- of
- on
- ONE
- afară
- funcionar
- Operațiuni
- Oportunităţi
- or
- comandă
- al nostru
- ne
- peste
- Învinge
- propriu
- plătit
- parte
- petreceri
- cale
- Model
- Plătește
- egal
- peer to peer
- Perfect
- performanță
- perspectivă
- Loc
- plan
- Plato
- Informații despre date Platon
- PlatoData
- Punct
- Politica
- Poligon
- posibil
- postgresql
- potenţial
- putere
- puternic
- practică
- Problemă
- procese
- productivitate
- dovadă
- proporție
- propune
- protocol
- dovedit
- furniza
- prevăzut
- pune
- interogări
- RAM
- gamă
- rată
- mai degraba
- raport
- Crud
- Citeste
- real
- într-adevăr
- rezonabil
- reducere
- cu privire la
- legate de
- de încredere
- reorganizare
- răspunde
- replică
- reprezenta
- reprezentate
- solicita
- elastic
- Rezoluţie
- hotărât
- rezultând
- reutilizarea
- dreapta
- robust
- rădăcină
- rotund
- RÂND
- Alerga
- funcţionare
- acelaşi
- scalabil
- Scară
- scalare
- perfect
- Caută
- securitate
- vedea
- văzut
- segment
- segmentarea
- De vânzare
- punct de vanzare
- Servere
- serviciu
- Servicii
- servire
- set
- configurarea
- câteva
- sharding
- partajarea
- Pantaloni scurți
- Arăta
- parte
- asemănător
- întrucât
- singur
- Mărimea
- aptitudini
- mic
- mai mici
- inteligent
- So
- soluţie
- REZOLVAREA
- rezolvă
- unele
- Spaţiu
- Scânteie
- standard
- Stat
- Declarație
- depozitare
- stoca
- Poveste
- Strategic
- Strategie
- puternic
- tare
- Reușit
- a sustine
- Sprijină
- tabel
- Lua
- luare
- Sarcină
- echipă
- Tehnic
- spune
- termeni
- decât
- acea
- Blocul
- Statul
- lor
- apoi
- Acolo.
- Acestea
- ei
- Al treilea
- terțe părți
- acest
- debit
- timp
- la
- de asemenea
- instrument
- Unelte
- Total
- INTRU TOTUL
- trafic
- tranzacție
- Tranzacții
- transfer
- transparent
- tip
- Tipuri
- în cele din urmă
- în
- care stau la baza
- din pacate
- unix
- deblochează
- inutil
- us
- uzabilitate
- Folosire
- utilizare
- carcasa de utilizare
- utilizat
- Utilizator
- utilizatorii
- folosind
- obișnuit
- Valoros
- varietate
- vertical
- foarte
- volum
- vrea
- a fost
- Cale..
- we
- Web2
- Web3
- BINE
- Ce
- Ce este
- cand
- care
- în timp ce
- În timp ce
- întreg
- de ce
- larg
- pe larg
- voi
- cu
- fără
- fabrică
- scrie
- scris
- Tu
- Youngest
- Ta
- zephyrnet