De ce am ales in-language memory in loc de Redis si alternative?

[HKS 27D]

 

 

Alegerea solutiei perfecte

Conceptul de "solutie perfecta" nu exista in realitate atat de des atunci cand vorbim despre backend si software development. Mai degraba, exista solutii care se potrivesc pentru diverse use case-uri. Acestea acopera nevoi specifice, dar nu se pot numi "perfecte" nici pe departe. Asadar, totul se reduce la nevoile specifice pentru software-ul pe care il dezvolti, corect? Cazul meu: Am avut nevoie de o solutie de stocare a datelor extrem de rapida pentru un software micut. Aplicatia ruleaza in medii unde conteaza partea de concurrency, iar solutiile basic nu sunt suficiente. Am dorit backup-uri pentru a acoperi hardware failures, dar am cautat de asemenea sa mentin un setup minimal. Optiuni gasite la momentul respectiv? O gramada.

 

Stop research: RAM

M-am oprit pentru o secunda. Stop research! De ce sa nu stochez datele in RAM, cu compatibilitate SQLite si MySQL? As putea sa acoper in mod automat hardware failures, SQLite/MySQL driver errors, database corruption, backups, data import, data export si tot ce a ramas de adaugat. Un moment intrigant, as putea spune. O secunda am fost nelinistit. As putea construi software-ul cu tipuri de date potrivite, reducand in acelasi timp cerintele de CPU, RAM si Network? As putea evita Redis si alte alternative, in timp ce mentin in continuare un setup minimal, obtinand de asemenea unele dintre cele mai bune rezultate posibile in materie de performanta software? Am incercat si a meritat.

 

Implementare SQL

Am facut matching perfect pentru tabelele SQL in RAM. Am realizat o implementare custom la tipurile de date concurente pentru a evita problemele comune (performance bottlenecks, poor scalability) regasite in librariile comune din limbajul de programare ales. Am implementat atomicity si mutual exclusion cu sharding. Care au fost rezultatele? Concurrency peste asteptari comparativ cu orice alta solutie pe care am verificat-o anterior, totul cu 0 alocari de memorie aditionale.

 

Fiecare intrare urmeaza tiparul de mai jos:

• int64 key: 8 bytes
• UserData value: ~16 bytes (due to padding)

 

Rezultate implementare

Daca limbajul de programare isi face treaba bine, in mod normal am avea mai putin de 16 bytes pentru UserData type intrucat am ordonat corespunzator lucrurile la initializare.

Sa facem totusi calculul cu max padding.

100.000 entries: (8 + 16) bytes * 100000 users = 2400000 bytes = ~2.29 MB

 

Care sunt rezultatele implementarii? Stocarea datelor in RAM (in-language memory) pentru 100.000 utilizatori ar consuma in jur de 2.29 MB. Uimitor! Partea de overhead conteaza de asemenea, insa ne-am intrecut asteptarile cu implementarea custom pentru tipurile de date concurente, totul in timp ce exista 0 alocari de memorie aditionale. Diferenta data de overhead este neglijabila. Scalarea software-ului la milioane de intrari cu resurse hardware reduse si setup minimal e realizata cu usurinta.