KeyDB yn lle [posibl] i Redis

Ni chafwyd unrhyw adolygiadau o “ddewis amgen cyflymach yn lle Redis” ar Habré - BysellDB. Ar ôl cael profiad gweddol ddiweddar o’i ddefnyddio, hoffwn lenwi’r bwlch hwn.

Mae'r cefndir yn eithaf banal: un diwrnod, gyda mewnlifiad mawr o draffig, cofnodwyd dirywiad sylweddol ym mherfformiad y cais (sef, amser ymateb). Bryd hynny, yn anffodus, nid oedd yn bosibl gwneud diagnosis arferol o’r hyn a oedd yn digwydd, felly cynlluniwyd cyfres o brofion llwyth wedi hynny. Ar ôl eu cynnal, roeddem yn gallu darganfod tagfa, sef y storfa gronfa ddata yn Redis. Fel sy'n digwydd yn aml, ni allai'r broblem gael ei datrys ar unwaith ac yn y ffordd gywir - gan y datblygwyr (trwy newid rhesymeg y gwaith). Felly, trodd chwilfrydedd ac awydd i oresgyn y sefyllfa mewn ffordd gylchfan ymlaen. Dyma sut yr ymddangosodd yr erthygl hon.

Materion

Am Redis yn gyffredinol

Fel y mae llawer o bobl yn gwybod, mae Redis yn gronfa ddata un edau. I fod yn fwy manwl gywir, mae fel hyn yng nghyd-destun gweithio gyda data defnyddwyr. Wedi'r cyfan, ers y pedwerydd fersiwn, gwasanaeth, gweithrediadau mewnol Redis wedi'i gyfieithu ar gyfer gweithredu cyfochrog. Fodd bynnag, dim ond rhan fach o'r llwyth gwaith yr effeithiodd y newid hwn arno, gan fod y rhan fwyaf o'r gwaith yn cael ei wneud ar ddata defnyddwyr.

Mae copïau di-rif wedi'u torri ar y pwnc hwn, ond mae datblygwyr Redis yn ystyfnig yn gwrthod gweithredu paraleliaeth lawn, gan sôn am faint y bydd yn cymhlethu'r cais ac yn cynyddu costau cyffredinol, yn ogystal ag ychwanegu mwy o fygiau. Eu safbwynt yw hyn: os ydych chi'n wynebu problem un craidd, mae gennych chi broblemau gyda phensaernïaeth y cymhwysiad ac mae angen newid rhywbeth ynddo. Ymhlith defnyddwyr, fodd bynnag, mae “gwersyll arall” hefyd – y rhai sy’n sownd ar un craidd ac yn honni bod Redis yn creu tagfa iddo’i hun. Yn achos llwythi mawr iawn - yn hwyr neu'n hwyrach - mae'n anochel dod ar draws y broblem hon, sy'n gosod cyfyngiadau sylweddol ar y bensaernïaeth a / neu gymhlethdodau gorfodol ynddi.

Ni fyddaf yn gwerthuso hyn na'r farn honno. Yn lle hynny, byddaf yn rhannu ein hachos penodol a sut y gwnaethom ei ddatrys.

Ein hachos ni

Yn un o'r prosiectau, daethom ar draws y ffaith bod y tîm datblygu wedi ffurfweddu celcio data hynod ymosodol o'r gronfa ddata (PostgreSQL) trwy Redis. Dyma'r unig ffordd, yn ystod mewnlifiadau sydyn o draffig, arbed PostgreSQL ei hun ac, o ganlyniad, y cais rhag marwolaeth.

Ar ôl cyfres o brofion llwyth, dadansoddwyd y sefyllfa gennym a chanfod bod Redis wedi'i gyfyngu i un craidd (yr hyn a elwir yn "silff"), ac yna diraddio'r cais yn weddol gyflym. Roedd y “tagu” yn esbonyddol: cyn gynted ag y cyrhaeddwyd terfyn perfformiad Redis, stopiodd popeth weithio.

Roedd yn edrych rhywbeth fel hyn:

Nododd New Relic y broblem yn glir:

Dyma'r ystadegau ar gyfer y llawdriniaeth: get yn Redis:

Ar ôl i'r broblem gael ei hadrodd yn fanwl i'r tîm datblygu, daeth i'r amlwg “na ellir datrys y broblem ar hyn o bryd.” Felly dechreuwyd chwilio am ateb ar yr ochr weithrediadau, a'r KeyDB a grybwyllwyd eisoes oedd yr ateb.

Fodd bynnag, cyn i ni ddechrau ein hadolygiad, mae'n werth nodi bod y prosiect yn defnyddio Redis annibynnol, gan fod yr ateb clwstwr yn seiliedig ar Sentinel yn llawer israddol o ran hwyrni. Un ateb amlwg oedd creu sawl atgynhyrchiad o'r storfa: a gadael i'r cais fynd i bobman gyda chydbwyso! Fodd bynnag, ar ôl ymgynghori â'r datblygwyr, fe'n gorfodwyd i ddileu'r opsiwn hwn oherwydd mecanwaith annilysu cache gweithredol a chymhleth y cais. Roedd yr un broblem yn ymestyn i ddarnio storfa.

Golwg Cyflym ar KeyDB

Wrth chwilio am ateb posibl i'r broblem, fe wnaethom ddarganfod cais o'r enw KeyDB. Mae hwn yn fforc Redis a ddatblygwyd gan cwmni o Ganada a'i ddosbarthu o dan y drwydded BSD am ddim. Mae'r prosiect yn ifanc iawn: mae wedi bodoli ers dechrau 2019. Ei hanes yw bod yr awduron hefyd unwaith hefyd wedi dod ar draws cyfyngiadau Redis ... a phenderfynu gwneud eu fforc eu hunain. Yn ogystal, fe wnaeth nid yn unig ddatrys problemau hysbys, ond derbyniodd hefyd nodweddion ychwanegol sydd ond ar gael yn y fersiwn enterpise o Redis.

I'r rhai sydd am ddod yn gyfarwydd â KeyDB yn fwy manwl, mae yna dda erthygl ragarweiniol ar Ganolig, sy'n cyflwyno'r DBMS a meincnodau cryno yn ei gymharu â'i “riant” - Redis.

Yn gyntaf oll, cawsom ein denu i KeyDB gan yr ateb posibl i'n problemau, ac ar yr un pryd roedd gennym ddiddordeb mewn rhai nodweddion ychwanegol. Fe wnaeth defnyddio KeyDB addo'r manteision canlynol:

• cael multithreading llawn;
• cydnawsedd llawn ac absoliwt â Redis (roedd hyn yn arbennig o bwysig i ni, gan nad oedd yn bosibl gwneud unrhyw addasiadau ar ochr y cais), a oedd hefyd yn addo mudo di-drafferth;
• mecanwaith wrth gefn adeiledig yn storfa S3;
• hawdd i'w gweithredu atgynhyrchu gweithredol;
• clystyru a darnio syml heb Sentinel a meddalwedd ategol arall.

Roedd mwy na 3 mil o sêr a llawer o gyfranwyr ar GitHub hefyd yn edrych yn galonogol. Mae'r cais yn cael ei ddatblygu a'i gefnogi'n eithaf gweithredol, sydd i'w weld yn glir yn yr ymrwymiad, cyfathrebu mewn materion, yn ogystal â chysylltiadau cyhoeddus caeedig (derbyniol). Mae ymateb y prif gynhaliwr ar bob ffrynt bob amser yn gyfeillgar ac yn brydlon. Yn gyffredinol, roedd digon o ddadleuon.

Mudo a chanlyniadau

Er bod y prosiect mudo yn dipyn o gambl (oherwydd newydd-deb KeyDB), nid oedd llawer i'w golli. Wedi'r cyfan, mae treiglo newidiadau yn ôl yn eithaf cyflym a hawdd - yn ffodus, mae'r seilwaith cyfan yn cael ei ddefnyddio yn Kubernetes, a'r mecanweithiau adeiledig Diweddariad Treigl Maent yn datrys problemau o'r fath yn dda iawn.

Yn gyffredinol, fe wnaethom baratoi templedi Helm, newid y cymhwysiad yn yr amgylchedd prawf i gronfa ddata newydd a'i gyflwyno i gyd, gan ei drosglwyddo i adran SA y cleient.

Dechreuodd y profion, a barhaodd tua wythnos ac ni wnaethom blymio i'r manylion. Ni wyddom ond bod y cwsmer wedi profi swyddogaethau safonol gweithio gyda Redis gan ddefnyddio gyrrwr PHP phpredis, a chynhaliodd hefyd brofion SA o'r rhyngwyneb defnyddiwr. Ar ôl hynny, cawsom y golau gwyrdd: ni chanfuwyd unrhyw sgîl-effeithiau wrth ddefnyddio'r meddalwedd newydd. Hynny yw O safbwynt y cais, nid oes dim wedi newid o gwbl.

Mae'n werth nodi na wnaethom newid unrhyw beth yn y ffurfwedd: yn llythrennol, yn syml, fe wnaethom ddisodli'r ddelwedd a ddefnyddiwyd. Mae'r un peth yn wir am fonitro ac allforio metrigau i Prometheus: y mwyaf cyffredin ohonynt yn gweithio'n berffaith gyda KeyDB a heb unrhyw addasiadau. Felly, gallwn ddweud yn ddiogel, o safbwynt gweithredol, mai symudiad delfrydol yn unig yw hwn.

Diolch i hyn i gyd, ar ôl newid y cais i DBMS newydd, ni allwch newid unrhyw beth, ond fel “mesur sefydlogi” gallwch ei adael yn y ffurflen hon i weithio yn y frwydr am beth amser. Fodd bynnag, os ydych am weld cynnydd mewn perfformiad (neu unrhyw newidiadau o gwbl), rhaid i chi beidio ag anghofio hynny yn ddiofyn Paramedr KeyDB sy'n gyfrifol am aml-edafu (server-threads), yn gyfartal i un, hyny yw Mae'r DBMS yn gweithio'n union yr un fath â Redis.

Ar ôl newid, profi a pheth amser o fywyd ar y cymhwysiad newydd (gyda KeyDB), penderfynasom ailadrodd y profion llwyth gyda'r un paramedrau a ddefnyddiwyd ar gyfer Redis. Beth oedd ei ganlyniadau?..

Yn ôl y graff defnydd CPU, daeth dileu problemau gyda “nenfwd” un craidd yn amlwg ar unwaith: dechreuodd y broses ddefnyddio'r adnoddau sydd ar gael:

Ac yn ddiweddarach ceisiais “arteithio” y cais yn eithaf cryf a gwelais fwyta hyd at dri chraidd ...

Yn ôl New Relic, dechreuodd y cymhwysiad gwe yn ei gyfanrwydd, gyda'r un llwyth, ymddwyn yn amlwg yn fwy digonol. Gwelwyd rhywfaint o ddiraddio perfformiad o hyd, fodd bynnag, o gymharu â graff tebyg uchod, gallwch werthuso'r cynnydd sylweddol drosoch eich hun:

Gwaethygodd hwyrni'r gronfa ddata newydd (KeyDB) hefyd, ond arhosodd o fewn gwerthoedd derbyniol:

Mae'r graff canlynol yn dangos yn glir bod nifer y ceisiadau i KeyDB ei hun yn debyg:

I grynhoi'r profion synthetig hyn, gallwn ddweud bod Redis a KeyDB yn dangos dirywiad perfformiad sylweddol mewn hwyrni (40 ms+) gyda chynnydd sylweddol yn nifer y cysylltiadau cyfochrog (1000+). Yn ein hachos ni, roedd y rhaglen we yn gallu “gwastraffu” hwyrni Redis hyd yn oed gyda nifer is o gysylltiadau (400+), er ar gyfer KeyDB roedd llwyth o'r fath yn parhau i fod yn dderbyniol.

Canfyddiadau

Mae'r enghraifft hon yn dangos yn glir gryfder y gymuned Ffynhonnell Agored wrth ddatblygu prosiectau y mae ganddi ddiddordeb ynddynt. Deuthum ar draws datganiad rhagorol ar y Rhyngrwyd, yr oedd ei ystyr cyffredinol yn ymwneud â'r canlynol: “Mae rhai cwmni mawr yn creu cynnyrch diddorol, yn gwneud rhai o'i swyddogaethau'n agored, ond yn gadael y rhan bwysicaf yn cael ei thalu. Mae’r gymuned yn ei ddefnyddio ac yn ei ddefnyddio, ac yna mae rhywun yn rhoi’r gorau iddi ac yn gwneud fforc, gan weithredu’r un nodweddion taledig ynddo a’u hagor i bawb.” Yma mae KeyDB yr un achos.

Wrth siarad am y mudo ei hun, a oedd yn rhyfeddol o syml, ni chawsom felly cynnydd sylweddol mewn perfformiad, y gellir ei ddisgwyl trwy edrych ar graffiau awduron KeyDB... Fodd bynnag, dim ond ein hachos arbennig ni yw hwn, lle gall fod llawer o wyriadau, gan gynnwys pensaernïaeth ddrwg-enwog y cais (er enghraifft , nifer enfawr o orchmynion get yn Redis yn lle'r opsiwn mwy perfformiadol o ymholiadau cyfanredol mget...). Serch hynny, rydym wedi llwyddo i gyflawni canlyniadau cadarnhaol, ac ynghyd â hwy llawer o swyddogaethau defnyddiol y byddwn yn gweithredu yn y dyfodol agos.

Yn gyffredinol, mae KeyDB yn edrych yn addawol: wrth i ni ennill profiad ymarferol gyda'r DBMS hwn (ac mae'n rhaid i ni ei ennill o hyd!) a datblygu'r prosiect ei hun, byddwn yn ystyried y posibilrwydd o'i ddefnyddio mewn sefyllfaoedd eraill.

Fodd bynnag, ni ddylid ystyried yr erthygl hon fel canllaw (heb sôn am alwad) i weithredu ar gyfer rhoi'r gorau i Redis yn eang o blaid KeyDB. Er gwaethaf ein profiad cadarnhaol, mae’n amlwg nad bwled arian yw hon. Roedd yr achos yn benodol iawn: yn benodol ar gyfer datrys problem ennyd mewn sefyllfa lle'r oedd angen ei wneud yn gyflym ac am gost fach iawn, roedd cyfiawnhad dros yr ateb hwn. A fydd KeyDB yn ddefnyddiol yn eich achos chi? O leiaf nawr rydych chi'n gwybod bod y posibilrwydd posibl hwn yn bodoli.

PS

Darllenwch hefyd ar ein blog:

• «Cronfeydd data a Kubernetes (adroddiad adolygu a fideo)";
• «Mudo Cassandra i Kubernetes: nodweddion ac atebion";
• «Mudo di-dor o MongoDB i Kubernetes";
• «Mudo di-dor o RabbitMQ i Kubernetes'.

Ffynhonnell: hab.com