Aerospike VS. Redis, juhtumianalüüsid

Aerospike Vs Redis Case Studies



Aerospike VS. Redis, juhtumianalüüsid
pilt
Redise küps kogukond Hiinas ja enamik neist kasutab enam-vähem Redist, kuid usun, et leiame, et Redisel on palju soovida, kui KV andmebaas on olemas, võib see anda teile kiirema lugemis- ja kirjutamiskiiruse ning usaldusväärsema turvalisuse ja madalama kogukulud, miks mitte vaadata Aerospike iti?

Täna tahan teiega jagada juhtumit meie klientide reisipublikust!



„Reisipublik“ on digitaalse reklaami platvorm, mis tähendab, et jätkame kogu maailmas suurt reklaami investeerimist. Selles artiklis tahaksin arutada mõningaid väljakutseid, mis meie sektori hankega silmitsi seisavad.



Meie, pakkujad, osalesime oksjonil, reaalajas keskkond lehekuulutustes. Pakkumise taotluse kohta on 60–70 000 sekundit. Iga taotluse töötlemise aeg peaks olema alla 75 ms. Süsteemi suure koormusega toimetulekuks oleme taustal mälus värskendanud andmeid Postgres ja Redises reaalajas andmeid. (Andmebaaside tehnoloogiaettevõtted, mida tavaliselt kasutatakse, hõlmavad RDBMS-i, näiteks Postgres, MySQL ja vahemälu.)



Iga SSP (Supply Side Platform) päring toob kaasa mitu vahemällu salvestatud päringut. Läbilaskevõime (tehingud sekundis) ja latentsus (reageerimisaeg) on ​​oluline näitaja, see vahemälu peab vastama RTB-rakenduste vajadustele.

Aja jooksul on kasutajate arvu suurendamise kampaaniate arv suurendanud ka meie reklaamieelarvet. Sellepärast peame oma süsteemi laiendamiseks olema paindlikud, sõltuvalt koormusest.

väljakutse



Meie Redis Redise puhvrikiht, mis koosneb mitme andmebaasi (5-6) käitamisest erinevates portides, igal andmebaasil on põhisõlm ja alamsõlmed umbes 10. Algusest peale märkasime Redise kasutamisel üha suuremat probleemi. Need on mõned probleemid, millega silmitsi seisame:

· Põhiseade, mitu seadet - kirjuta, et piirata põhisõlme juhitava serveri läbilaskevõimet.

· Redis on üheahelaline, mis tähendab, et meil pole protsessori vertikaalset mastaapsust.

Reaalajas ülema ja orja vahelised sünkroonimisprobleemid - peamise sõlme suure hulga kirjutamisoperatsioonide tulemusena tuleb kõik muudatused sõlmega sünkroonida. Kuna suurt hulka andmeid ei ole võimalik sünkroonida, tuleb need samaaegselt sünkroonida võrguühenduseta sõlmest tuleneva rakendusprogrammi RTB lugemispäringuga.

• Samas andmebaasis pole mugavat viisi paljude eri tüüpi andmete salvestamiseks - meil on erinevates Redise eksemplarides (eksemplaris) salvestatud erinevad üksused, seega peame hakkama saama mitme pordi mitme ühendusega.

lahendus

Püüan leida lahenduse, mis vastab kõigile meie vajadustele, säilitades samas paindlikkuse ja kasutusmugavuse.

Pärast põhjalikke uuringuid saan sügavalt aru, et Aerospike suudab tõesti meie vajadusi rahuldada. Mul on juba eelmises töökohas Aerospike'iga kogemusi. Niisiis hakkasime selles projektis kasutama Aerospike'i.

Lennunduse hüvede hulka kuuluvad:

· Partitsioon - vaikimisi on partitsioon 4096 jaotatud klastri kõigi sõlmede vahel. Selle eesmärk on meie kirjutamine, et läbilaskevõime on nii palju paranenud.

· Aerospike on mitmekeermeline - saab meie ressursse kõige tõhusamalt kasutada.

· Põhikoopia sünkroonimine pole seisakuid - saate konfigureerida kirjutamisreeglid (poliitika), kinnitatakse, et luua 'kirjutamise' taotlus loetakse koopia täielikuks.

· Nimeruum - kõiki erinevaid andmetüüpe saab ühte klastrisse salvestada erinevad nimeruumid, kas see on hierarhia: nimeruum> Määra> kirje.

· SSD või mälu - Aerospike'il on kaks režiimi: SSD ja mälu. Redis ainult mälus, mis tähendab, et suurem laienemine muutub väga kalliks, kuid Aerospike SSD-mäluseadmete abil, et tagada jõudlus konkurentsivõimeline.

Võrdlusuuringud

Testisin Redise ja Aerospike'i võrdlust. Esiteks on läbilaskevõime kõige olulisem parameeter, sest meil on pakkujatelt sajad tuhanded päringud sekundis.

Ma lõin virtuaalse masina, millel oli 16 vCPU ja 14,4 GB mälu (enamik reisipubliku infrastruktuure on hostitud Google Cloud Platformil), kus ta seadistas Redise ja Aerospike kasutasid GCE-s Debian 9.

Aerospike ja võrdlusnäitajad seadsin järgmiste linkide järgi:

Installi Debianisse
See õpetus hõlmab Aerospike'i installimist Debiani süsteemi.
https://www.aerospike.com/docs/operations/install/linux/debian/

Võrdlusuuringud
Kasutage Aerospike Go kliendi võrdlusvahendit Aerospike klastri koormuse loomiseks ja jõudlusmõõdikute arvutamiseks.
https://www.aerospike.com/docs/client/go/benchmarks.html

Laadisin alla ka Go võrdlusuuringud, sest kõik meie RTB-rakendused on kirjutatud Go-ga.

See on link Redise installimiseks:

Redise kiire algus - Redis
Soovitatav viis Redise installimiseks on selle koostamine allikatest, kuna Redisel pole muid sõltuvusi peale töötava…
https://redis.io/topics/quickstart

Siis käivitasin just redis-serveri ja saan kasutada redis-benchmark tööriista.

Otsustasin käivitada vastavalt viite 'kirjutamise' ja 'lugemise'. Võrdlusuuringu kirjutamine / lugemine 1 000 000 rida, 8 baiti kirjutusväärtus (Int64) ja 50 samaaegset kliendiühendust.

Kirjutamise võrdlusalus:

Redis :

redis-benchmark -t komplekt -n 1000000 -d 8 -c 50

====== SET ======

1000000 taotlust täideti 7,66 sekundiga

50 paralleelset klienti

8 baiti kasulik koormus

hoida elus: 1

99,92%<= 1 milliseconds

100,00%<= 2 milliseconds

100,00%<= 2 milliseconds

130497,20 taotlust sekundis

Aerospike:

./näitaja -w I -c 50

2018/01/17 14:05:33 Kasutatavate protsessorite arvu määramine: 16

2018/01/17 14:05:33 benchmark.go: 181: võõrustajad: 127.0.0.1

2018/01/17 14:05:33 benchmark.go: 182: port: 3000

2018/01/17 14:05:33 benchmark.go: 183: nimeruum: test

2018/01/17 14:05:33 benchmark.go: 184: set: testset

2018/01/17 14:05:33 benchmark.go: 185: võtmed / kirjed: 1000000

2018/01/17 14:05:33 benchmark.go: 186: objekti spetsifikatsioon: I, suurus: 0

2018/01/17 14:05:33 benchmark.go: 187: juhusliku prügikasti väärtused on valed

2018/01/17 14:05:33 benchmark.go: 188: töökoormus: lähtestage 100% dokumentidest

2018/01/17 14:05:33 benchmark.go: 189: samaaegsus: 50

2018/01/17 14:05:33 benchmark.go: 190: maksimaalne läbilaskevõime on piiramatu

2018/01/17 14:05:33 benchmark.go: 191: ajalõpp 0 ms

2018/01/17 14:05:33 benchmark.go: 192: max proovib uuesti 2

2018/01/17 14:05:33 benchmark.go: 193: silumine: vale

2018/01/17 14:05:33 benchmark.go: 194: latentsus: 0: 0

2018/01/17 14:05:33 benchmark.go: 137: Leitud sõlmed: [BB90512440A0142]

2018/01/17 14:05:34 benchmark.go: 712: kirjutamine (tps = 436881 timeout = 0 viga = 0 totalCount = 436881)

2018/01/17 14:05:35 benchmark.go: 712: kirjutamine (tps = 442889 timeout = 0 viga = 0 kokkuCount = 879770)

2018/01/17 14:05:36 benchmark.go: 712: kirjutamine (tps = 120230 ajalõpp = 0 viga = 0 kokkuSumma = 1000000)

„Lugemise” kriteeriumid:

Redis:

redis-benchmark -t saada -n 1000000 -d 8 -c 50

====== Hangi ======

1000000 taotlust täideti 7,47 sekundiga

50 paralleelset klienti

8 baiti kasulik koormus

hoida elus: 1

99,90%<= 1 milliseconds

100,00%<= 1 milliseconds

133850,89 taotlust sekundis

· Aerospike:

· ./Näitaja -w RE: 100-c50

· 2018/01/17 14:03:55 Kasutatavate protsessorite arvu määramine: 16

· 2018/01/17 14:03:55 benchmark.go: 181: hostid: 127.0.0.1

· 2018/01/17 14:03:55 benchmark.go: 182: port: 3000

· 2018/01/17 14:03:55 benchmark.go: 183: nimeruum: test

· 2018/01/17 14:03:55 benchmark.go: 184: set: testset

· 2018/01/17 14:03:55 benchmark.go: 185: võtmed / kirjed: 1000000

· 2018/01/17 14:03:55 benchmark.go: 186: objekti spetsifikatsioon: I, suurus: 0

· 2018/01/17 14:03:55 benchmark.go: 187: juhusliku prügikasti väärtused on valed

· 2018/01/17 14:03:55 benchmark.go: 188: töökoormus: lugege 100%, kirjutage 0%

· 2018/01/17 14:03:55 benchmark.go: 189: samaaegsus: 50

· 2018/01/17 14:03:55 benchmark.go: 190: maksimaalne läbilaskevõime on piiramatu

· 2018/01/17 14:03:55 benchmark.go: 191: ajalõpp 0 ms

· 2018/01/17 14:03:55 benchmark.go: 192: max proovib uuesti 2

· 2018/01/17 14:03:55 benchmark.go: 193: silumine: vale

· 2018/01/17 14:03:55 benchmark.go: 194: latentsus: 0: 0

· 2018/01/17 14:03:55 benchmark.go: 137: Leitud sõlmed: [BB90512440A0142]

· 2018/01/17 14:03:57 benchmark.go: 717: kirjutamine (tps = 0 ajalõpp = 0 viga = 0) lugemine (tps = 446765 ajalõpp = 0 viga = 0) kokku (tps = 446765 ajalõpp = 0 viga = 0, arv = 446765)

· 2018/01/17 14:03:58 benchmark.go: 717: kirjutamine (tps = 0 ajalõpp = 0 viga = 0) lugemine (tps = 503307 ajalõpp = 0 viga = 0) kokku (tps = 503307 ajalõpp = 0 viga = 0, arv = 950072)

· 2018/01/17 14:03:59 benchmark.go: 717: kirjutamine (tps = 0 ajalõpp = 0 viga = 0) lugemine (tps = 487852 ajalõpp = 0 viga = 0) kokku (tps = 487852 ajalõpp = 0 viga = 0, arv = 1437924)

Võrdlusaluste lugemisest ja kirjutamisest näete, et Redis TPS (tehingud sekundis) ja Aerospike TPS vahel on märkimisväärne vahe:

Aerospike 430 000 kirjutustoimingut sekundis ja 130 000 kirjutamist sekundis Redis

koos

Aerospike luges 480 000 korda sekundis, 133 000 korda sekundis ja luges Redist.

Klastri seadistamine

Otsustasime Aerospike'i kasutamist jätkata ja seadsime GCE-sse kolmest sõlmpunktist koosneva klastri, replikatsioonitegur 2 oleme muutnud mõned kõige sagedamini kasutatavad reaalajas andmed Redisest Aerospike'iks.

Iga nimeruum on konfigureeritud nii, et sellel oleks jagamata SSD-ketas ja parameeter 'data-in-memory' (andmed mälus) on seatud 'true'. Seega, kui sõlm algab oluliselt, laadib see kohe kõik andmed mällu ja alustab seejärel päringu töötlemist. See korraldus võimaldab kiiremat stardisõlme ja annab andmeid (Aerospike Kuigi mehhanismil on oma mälus olev andmete vahemälu alles siis, kui salvestamisel esmalt leitakse, hangitakse salvestus SSD-lt ja jääb seejärel mällu järgmiseks kasutustaotluseks).

Klastri staatuse paremaks mõistmiseks kasutasime Prometheuse indikaatoreid ja Aerospike'i juhtimiskonsooli.

Kõiki sõlme riist- / tarkvarauuendusi saab hõlpsasti üksteise järel vahetada. See tähendab, et kui uuendate või kustutate / lisate sõlme, oodates lihtsalt andmete üleviimist, saab tasakaalu täita. Aerospike klaster, mis vastutab kogu muu töö eest.

Puudujääk

Lisaks Aerospike'i eelistele (võrreldes Redisega) pean mainima ka puudusi:

· Ridade arvu piiramine - ridade arv Community Edition iga sõlme kohta igas nimeruumis on piiratud 4 miljardi reaga, nüüd saame seda kasutada. Piirangute täieliku loetelu leiate siit:

Https://www.aerospike.com/docs/guide/limitations.html

· Ei toeta tehinguid - meie konkreetses olukorras võib see olla veelgi suurem kujundusprobleem: peame tegelema üksusega Google PubSubi sõnumijärjekorrast (sõnumijärjekord ei taga, et sõnumijärjestus oleks). Peame sõnumi töötlema ja selle Aerospike'i versioonis salvestama. Seetõttu oleme iga üksuse päästmiseks kirjutanud mitu korda ajakirjas Aerospike sisse. Üldiselt puudus ACID-tehingute toetamine, kasutades sellise suure jõudlusega andmebaasi Aerospike maksmise kulusid (nii kiiresti pole tehingute andmebaasi). Teisisõnu, põlvkonna aerospike on hea kompromiss. (Märkus: Aerospike toetab nüüd klastrite tugevat järjepidevust, järjepidevust ja tugevat tuge klastrite ühtlasele jaotumisele kasutaja osa erinevates osades, et näidata rohkem Aerospike'i kasutamist.)

· Minge ebastabiilsetesse kliendiraamatukogudesse - meie Aerospike Go klient toodab aeg-ajalt Go korda 2-3 korda ja need rutiinid jäävad seisma. See tähendab, et nad tarbivad rohkem mälu ja ei vabasta seda kunagi. (Märkus: ka Aerospike uus versioon lahendas probleemi)

Kokkuvõtteks

Aerospike muudab meie andmete haldamise lihtsamaks. Andmeid saame andmebaasi 5 salvestada Redis Aerospike'is kolme klastri sõlme.

Go taotlusprotsess on nüüd ainult Aerospike'i ühendus kõigi vajalike andmete pärimiseks.

Taotlege keskmist kestust 320 mikrosekundit, vastake täielikult RTB puhvri nõuetele (väga sarnane Redisega).

Meie infrastruktuuri laiendamine on lihtsam. Esiteks kasutame GCE-s uusi sõlme genereerivaid terraform-projekte. Seejärel kasutage Kubernetese saavutamiseks Helmi graafikuid. Nüüd lihtsalt käivitage Helm Charts sama lihtsalt kui uue klastri loomine ühe käsu abil.

Täname lugemast!