Kujtesa për çelës në Valkey bie 37.5% nga 7.2.14 në 9.1.1
Lucas Yang i Percona ka publikuar një benchmark që mat se sa memorie kursen çdo version i Valkey për çelësa të vegjël string, dhe rezultati kryesor është një rënie prej 37.5% në memorien për çelës midis Valkey 7.2.14 dhe 9.1.1. Valkey është një depo të dhënash open source në memorie që përdoret për caching, sesione, aplikacione në kohë reale, e-commerce, ad tech dhe gaming. E njëjta ngarkesë pune që mesatarisht përdorte 102.48 bajt për çelës në 7.2.14 tani përdor 64.02 bajt për çelës në 9.1.1, që do të thotë se i njëjti hardware mund të ruajë rreth 60% më shumë nga këta çelësa të vegjël pas përmirësimit. Reduktimi është më i dobishëm për mjedise me shumë stringje, të cilat janë të zakonshme në caching, sesione dhe autentikim, aplikacione në kohë reale, e-commerce, ad tech dhe martech, dhe gaming.
Për të izoluar efektin e versionit, Yang testoi pesë versione të ndërtuara nga kodi burimor: 7.2.14, 8.0.10, 8.1.9, 9.0.5 dhe 9.1.1. Çdo ekzekutim përdori jemalloc 5.3.0 si alokator memorie, sepse alokatorë të ndryshëm mund të ndryshojnë përdorimin e memories pavarësisht nga vetë Valkey. Instancat u ekzekutuan në mënyrë standalone dhe jo në modalitet cluster, me maxmemory të vendosur në 0 dhe persistence dhe eviction të çaktivizuar duke përdorur save "" dhe appendonly no. Ngarkesa e punës u gjenerua me valkey-benchmark -t set -n 1000000 -r 1000000 -d 16, e cila dërgon një milion komanda SET me vlera 16-bajtëshe. Meqenëse hapësira e çelësave është gjithashtu një milion, përplasjet e rastësishme të çelësave lënë rreth 63.2% të operacioneve si çelësa unikë, afërsisht 632,000 çelësa, që përputhet me metodologjinë zyrtare të benchmark-ut të Valkey. Memoria bazë e një instance të zbrazët u zbrit nga çdo matje në mënyrë që numrat të tregojnë bajtet e vërtetë margjinale për çelës.
Rezultatet tregojnë se kërcimi më i madh i vetëm erdhi në versionin 8.1. Në 7.2.14 ngarkesa e punës përdori 61.78 MB për 632,181 çelësa unikë, ose 102.48 bajt për çelës. Versioni 8.0.10 e reduktoi atë në 57.00 MB dhe 94.49 bajt për çelës, një rënie prej 7.8%. Versioni 8.1.9 më pas e uli memorien në 43.43 MB dhe 71.98 bajt për çelës, një reduktim i mëtejshëm prej 23.8% krahasuar me 8.0 dhe një kursim kumulativ prej 29.8% kundrejt 7.2.14. Versioni 9.0.5 ishte praktikisht i sheshtë në 43.36 MB dhe 71.99 bajt për çelës (një ndryshim 0.0% nga 8.1), ndërsa 9.1.1 ra në 38.58 MB dhe 64.02 bajt për çelës, një tjetër reduktim prej 11.1% dhe 37.5% më pak se baza 7.2.14. Për një deployment 1 TB në 7.2, të njëjtat të dhëna do të zinin afërsisht 800 GB në 8.0, 640 GB në 8.1 dhe 630 GB në 9.1.
Ndryshimi i parë strukturor u shfaq në Valkey 8.0. Në 7.2, një hyrje fjalori (dictEntry) ishte një strukturë 24-bajtëshe që mbante tre pointera: një për çelësin, një për vlerën dhe një për hyrjen tjetër në një zinxhir përplasjesh hash. Pointeri i çelësit referonte një blob SDS (simple dynamic string) të alokuar veçmas, kështu që çdo kërkim paguante për një alokim shtesë memorie dhe një hop shtesë memorie vetëm për të lexuar çelësin. Versioni 8.0 prezantoi embeddedDictEntry, i cili vendos bajtet e çelësit në mënyrë inline direkt pas strukturës. Paraqitja e re është 16 bajt plus gjatësia e çelësit, duke kombinuar çelësin dhe hyrjen në një alokim të vetëm. Efekti i matur është 8 bajt më pak për çelës, një hop memorie më pak në çdo kërkim, dhe ndryshimi është automatik pas përmirësimit pa nevojë për ndryshime konfigurimi.
Valkey 8.1 solli fitimin më të madh të vetëm. Në 8.0 fjalori ishte një tabelë hash klasike me zinxhirë, ku arritja te një vlerë nënkuptonte ndjekjen e një rruge nga bucket te hyrja te çelësi te vlera, katër hop-e memorie plus më shumë për përplasjet. Versioni 8.1 e rishkruajti këtë si një strukturë të re tabele hash në të cilën një bucket është saktësisht 64 bajt, madhësia e një cache line të CPU-së (blloku i vogël i memories që procesori e ngarkon menjëherë). Bucket-i ka një rajon metadata 8-bajtësh që paketon një bit has-child-bucket, shtatë bit të mbushur dhe shtatë bajt hash sekondar. Kjo lejon që shumica e kandidatëve që nuk përputhen të anashkalohen pa një akses shtesë në memorie. Çelësi dhe vlera janë të ngulitura në të njëjtin serverObject, duke shkurtuar kërkimin në afërsisht dy hop-e, bucket te serverObject, dhe një përplasje hash zakonisht qëndron brenda të njëjtës cache line. Struktura dictEntry zhduket plotësisht. Rezultati është afërsisht 20 bajt më pak për çift çelës-vlerë, dhe 30 bajt më pak për çelësat me TTL. Kjo shpjegon rënien e madhe nga 8.0 në 8.1.
Fitimi i fundit i matur ndodhi në 9.1. Në versionet e mëparshme të Valkey, stringjet e ngulitura (embstr) ende shpërdoronin një fushë pointeri 8-bajtëshe që thjesht referonte ngarkesën e vazhdueshme. Valkey 9.1 e ndryshoi këtë për stringjet e shkurtra: bajtet e stringut ruhen direkt në mënyrë inline në të njëjtat 8 bajt që normalisht përdoren për pointerin. Nuk nevojitet pointer, dhe nuk bëhet asnjë alokim i veçantë për vlerën. Rezultati është deri në 20% reduktim memorie për stringjet nën 128 bajt, dhe çiftet çelës plus vlerë 16-bajtëshe të benchmark-ut bien në atë interval. Të marra së bashku, tre ndryshimet strukturore tregojnë se efikasiteti i memories së Valkey erdhi nga ristrukturime të synuara të nivelit të ulët dhe jo nga një rishkrim i vetëm gjithëpërfshirës.
Përtej kursimeve nga versioni në version, Yang krahasoi gjithashtu dy mënyra të modelimit të të njëjtave të dhëna. Qasja A ruan çdo atribut përdoruesi si një çelës String të veçantë, për shembull SET user:1:name Alice, SET user:1:age 30, SET user:1:city Toronto, dhe SET user:1:score 100. Qasja B ruan një çelës Hash për përdorues me katër fusha, si HSET user:1 name Alice age 30 city Toronto score 100. Për një milion rekorde, Qasja A përdori 220 MB ndërsa Qasja B përdori 100 MB, një reduktim prej 54%. Hendeku ekziston sepse çdo çelës paguan një overhead fiks për çelës. Katër çelësa të veçantë e paguajnë atë overhead katër herë, ndërsa një çelës Hash e paguan një herë. Megjithatë, zgjedhja nuk është pa kosto. Çelësat String mbështesin në mënyrë natyrale EXPIRE për TTL për çelës, ndërsa Hash nuk mbështeste në mënyrë natyrale TTL në nivel fushe para Valkey 7.4. Hash fiton në operacione atomike me shumë fusha: një HSET ose HMGET i vetëm mund të lexojë ose shkruajë disa fusha njëherësh, ndërsa String ka nevojë për disa round trips. Hash gjithashtu i mban të gjitha fushat në një slot automatikisht për lokalitetin e cluster-it, ndërsa String kërkon një hashtag manual për të bashkëvendosur çelësat e lidhur. Nuk ka përgjigje universalisht të saktë; varet nëse efikasiteti i memories apo fleksibiliteti për fushë ka më shumë rëndësi për rastin e përdorimit.
Në përgjithësi, testet e Percona përcaktojnë sasinë se si gjurma e memories së Valkey për çelësat e vegjël string ka rënë nga 102.48 bajt në 64.02 bajt për çelës në pesë versione, me hapin më të madh në 8.1 dhe një optimizim përfundimtar të stringjeve inline në 9.1. Për ekipet që operojnë Valkey në shkallë të gjerë, një ofrues evropian i menaxhuar i cloud dhe infrastrukturës së të dhënave si AEU Data mund të ofrojë monitorimin, backup-et e automatizuara dhe disponueshmërinë e lartë që e bëjnë më të sigurt implementimin dhe verifikimin e këtyre reduktimeve të memories në prodhim.