Pse një korporatë si MegaFon ka nevojë për Tarantool në faturim? Nga jashtë duket se shitësi zakonisht vjen, sjell një lloj kuti të madhe, fut spinën në prizë - dhe kjo është faturimi! Kështu ishte dikur, por tani është arkaike, dhe dinosaurët e tillë tashmë janë zhdukur ose po zhduken. Fillimisht, faturimi është një sistem për lëshimin e faturave - një makinë numërimi ose kalkulator. Në telekomunikacionet moderne kjo është sistem automatizimi për të gjithë ciklin jetësor të ndërveprimit me një pajtimtar nga lidhja e një kontrate deri në përfundimin, duke përfshirë faturimin në kohë reale, pranimin e pagesave dhe shumë më tepër. Faturimi në kompanitë e telekomit është si një robot luftarak - i madh, i fuqishëm dhe i ngarkuar me armë.
Çfarë lidhje ka Tarantool me të? Ata do të flasin për të Oleg Ivlev и Andrey Knyazev. Oleg është arkitekti kryesor i kompanisë me përvojë të gjerë pune në kompani të huaja, Andrey është drejtor i sistemeve të biznesit. Nga transkripti i raportit të tyre në do të mësoni pse R&D nevojitet në korporata, çfarë është Tarantool, si ngërçi i shkallëzimit vertikal dhe globalizimit u bënë parakushtet për shfaqjen e kësaj baze të dhënash në kompani, rreth sfidave teknologjike, transformimit arkitektonik dhe se si technostack i MegaFon është i ngjashëm me Netflix , Google dhe Amazon.
Projekti "Faturimi i Unifikuar"
Projekti në fjalë quhet “Faturimi i Unifikuar”. Ishte këtu që Tarantool tregoi cilësitë e tij më të mira.
Rritja e produktivitetit të pajisjeve Hi-End nuk vazhdoi me rritjen e bazës së abonentëve dhe rritjen e numrit të shërbimeve; pritej rritje e mëtejshme e numrit të abonentëve dhe shërbimeve për shkak të karakteristikave të M2M, IoT dhe degës. në një përkeqësim të kohës për në treg. Kompania vendosi të krijojë një sistem të unifikuar biznesi me një arkitekturë modulare unike të klasit botëror, në vend të 8 sistemeve aktuale të faturimit.
MegaFon është tetë kompani në një. Në vitin 2009, riorganizimi përfundoi: degët në të gjithë Rusinë u bashkuan në një kompani të vetme, MegaFon OJSC (tani PJSC). Kështu, kompania ka 8 sisteme faturimi me zgjidhjet e tyre “doganore”, veçoritë e degëve dhe struktura të ndryshme organizative, IT dhe marketing.
Gjithçka ishte në rregull derisa na u desh të lëshonim një produkt të përbashkët federal. Këtu u shfaqën shumë vështirësi: për disa, tarifat rrumbullakosen lart, për të tjerët rrumbullakosura poshtë, dhe për të tjerët - bazuar në mesataren aritmetike. Ka mijëra momente të tilla.
Përkundër faktit se kishte vetëm një version të sistemit të faturimit, një furnizues, cilësimet ndryshuan aq shumë sa u desh një kohë e gjatë për t'u bashkuar. Ne u përpoqëm të zvogëlojmë numrin e tyre dhe hasëm në një problem të dytë që është i njohur për shumë korporata.
Shkallëzimi vertikal. Edhe pajisja më e lezetshme në atë kohë nuk i plotësonte nevojat. Ne përdorëm pajisje Hewlett-Packard nga linja Superdome Hi-End, por ato nuk plotësonin nevojat e as dy degëve. Doja shkallëzim horizontal pa kosto të mëdha operative dhe investime kapitale.
Pritshmëri për rritje të numrit të abonentëve dhe shërbimeve. Konsulentët kanë sjellë prej kohësh histori rreth IoT dhe M2M në botën e telekomit: do të vijë koha kur çdo telefon dhe hekur do të ketë një kartë SIM dhe dy në frigorifer. Sot kemi një numër abonentësh, por në të ardhmen e afërt do të ketë shumë të tjerë.
Sfidat teknologjike
Këto katër arsye na motivuan të bëjmë ndryshime serioze. Kishte një zgjedhje midis përmirësimit të sistemit dhe dizajnimit nga e para. Menduam për një kohë të gjatë, morëm vendime serioze, luajtëm tenderë. Si rezultat, ne vendosëm të dizajnonim që në fillim, dhe morëm sfida interesante - sfida teknologjike.
Shkallëzueshmëria
Nëse ishte më parë, le të themi, le të themi 8 faturime për 15 milionë abonentë, dhe tani duhet të kishte funksionuar 100 milionë abonentë dhe më shumë - ngarkesa është një renditje e madhësisë më e lartë.
Ne jemi bërë të krahasueshëm në shkallë me lojtarët e mëdhenj të internetit si Mail.ru ose Netflix.
Por lëvizja e mëtejshme për rritjen e ngarkesës dhe bazës së abonentëve na ka vendosur sfida serioze.
Gjeografia e vendit tonë të gjerë
Midis Kaliningradit dhe Vladivostok 7500 km dhe 10 zona kohore. Shpejtësia e dritës është e kufizuar dhe në distanca të tilla vonesat janë tashmë të konsiderueshme. 150 ms në kanalet optike më të bukura moderne janë shumë për faturimin në kohë reale, veçanërisht pasi është tani në telekom në Rusi. Përveç kësaj, ju duhet të përditësoni në një ditë pune, dhe me zona të ndryshme kohore ky është një problem.
Ne nuk ofrojmë shërbime vetëm për një tarifë abonimi, ne kemi tarifa komplekse, paketa dhe modifikues të ndryshëm. Ne duhet jo vetëm të lejojmë ose mohojmë pajtimtarin të flasë, por t'i japim atij një kuotë të caktuar - të llogarisim thirrjet dhe veprimet në kohë reale në mënyrë që ai të mos e vërejë.
toleranca ndaj gabimeve
Kjo është ana tjetër e centralizimit.
Nëse mbledhim të gjithë abonentët në një sistem, atëherë çdo ngjarje emergjente dhe fatkeqësi është katastrofike për biznesin. Prandaj, ne e projektojmë sistemin në mënyrë të tillë që të eliminojmë ndikimin e aksidenteve në të gjithë bazën e pajtimtarëve.
Kjo është përsëri pasojë e refuzimit për të shkallëzuar vertikalisht. Kur shkallëzuam horizontalisht, rritëm numrin e serverëve nga qindra në mijëra. Ato duhet të menaxhohen dhe të këmbyeshme, të kopjohen automatikisht infrastruktura e TI-së dhe të rivendoset sistemi i shpërndarë.
Ne u përballëm me sfida kaq interesante. Ne projektuam sistemin dhe në atë moment u përpoqëm të gjenim praktikat më të mira globale për të kontrolluar se sa në trend jemi, sa ndjekim teknologjitë e avancuara.
Përvoja botërore
Çuditërisht, ne nuk gjetëm një referencë të vetme në telekomin global.
Evropa ka rënë për sa i përket numrit të abonentëve dhe shkallës, SHBA - për sa i përket pabarazisë së tarifave të saj. Ne shikuam disa në Kinë dhe gjetëm disa në Indi dhe punësuam specialistë nga Vodafone India.
Për të analizuar arkitekturën, ne mblodhëm një Ekip Dream të udhëhequr nga IBM - arkitektë nga fusha të ndryshme. Këta njerëz mund të vlerësonin në mënyrë adekuate atë që po bënim dhe të sillnin njohuri të caktuara në arkitekturën tonë.
shkallë
Disa numra për ilustrim.
Ne projektojmë sistemin për 80 milionë abonentë me një rezervë prej një miliard. Kështu i heqim pragjet e ardhshme. Kjo nuk është për shkak se ne do të pushtojmë Kinën, por për shkak të sulmit të IoT dhe M2M.
300 milionë dokumente të përpunuara në kohë reale. Edhe pse kemi 80 milionë abonentë, ne punojmë si me klientët e mundshëm ashtu edhe me ata që na janë larguar nëse duhet të mbledhim të arkëtueshme. Prandaj, vëllimet aktuale janë dukshëm më të mëdha.
2 miliardë transaksione Bilanci ndryshon çdo ditë - këto janë pagesa, tarifa, thirrje dhe ngjarje të tjera. 200 TB të dhëna po ndryshojnë në mënyrë aktive, ndryshoni pak më ngadalë 8 PB e të dhënave, dhe ky nuk është një arkiv, por të dhëna të drejtpërdrejta në një faturim të vetëm. Shkallëzimi sipas qendrës së të dhënave - 5 mijë serverë në 14 sajte.
Rafte teknologjike
Kur planifikuam arkitekturën dhe filluam të montonim sistemin, importuam teknologjitë më interesante dhe më të avancuara. Rezultati është një grumbull teknologjie i njohur për çdo lojtar të internetit dhe korporata që prodhojnë sisteme me ngarkesë të lartë.
Rafti është i ngjashëm me grupet e lojtarëve të tjerë kryesorë: Netflix, Twitter, Viber. Ai përbëhet nga 6 komponentë, por ne duam ta shkurtojmë dhe unifikojmë.
Fleksibiliteti është i mirë, por në një korporatë të madhe nuk ka rrugë pa bashkim.
Ne nuk do të ndryshojmë të njëjtin Oracle në Tarantool. Në realitetet e kompanive të mëdha, kjo është një utopi, ose një kryqëzatë për 5-10 vjet me një rezultat të paqartë. Por Cassandra dhe Couchbase mund të zëvendësohen lehtësisht me Tarantool, dhe kjo është ajo për të cilën ne po përpiqemi.
Pse Tarantool?
Janë 4 kritere të thjeshta pse zgjodhëm këtë bazë të dhënash.
Shpejtësi. Kemi kryer teste të ngarkesës në sistemet industriale MegaFon. Tarantool fitoi - tregoi performancën më të mirë.
Kjo nuk do të thotë se sistemet e tjera nuk i plotësojnë nevojat e MegaFon. Zgjidhjet aktuale të memories janë aq produktive saqë rezervat e kompanisë janë më se të mjaftueshme. Por ne jemi të interesuar të kemi të bëjmë me një lider, dhe jo me dikë që mbetet prapa, përfshirë edhe testin e ngarkesës.
Tarantool mbulon nevojat e kompanisë edhe në planin afatgjatë.
Kostoja TCO. Mbështetja për Couchbase në vëllimet MegaFon kushton shuma astronomike parash, por me Tarantool situata është shumë më e këndshme dhe ato janë të ngjashme në funksionalitet.
Një veçori tjetër e këndshme që ndikoi pak në zgjedhjen tonë është se Tarantool funksionon më mirë me memorien sesa bazat e tjera të të dhënave. Ai tregon efikasitet maksimal.
Seriozitet. MegaFon investon në besueshmëri, ndoshta më shumë se kushdo tjetër. Pra, kur shikuam Tarantool, kuptuam se duhej ta bënim të plotësonte kërkesat tona.
Ne investuam kohën dhe financat tona dhe së bashku me Mail.ru krijuam një version të ndërmarrjes, i cili tani përdoret në disa kompani të tjera.
Tarantool-ndërmarrja na kënaqi plotësisht në aspektin e sigurisë, besueshmërisë dhe prerjeve.
Partneriteti
Gjëja më e rëndësishme për mua është kontakt të drejtpërdrejtë me zhvilluesin. Kjo është pikërisht ajo me të cilën kanë dhënë ryshfet djemtë nga Tarantool.
Nëse vini te një lojtar, veçanërisht ai që punon me një klient spirancë, dhe thoni se ju nevojitet baza e të dhënave për të qenë në gjendje ta bëni këtë, këtë dhe këtë, ai zakonisht përgjigjet:
- Mirë, vendos kërkesat në fund të atij grumbulli - një ditë, ndoshta do t'i arrijmë ato.
Shumë prej tyre kanë një udhërrëfyes për 2-3 vitet e ardhshme, dhe është pothuajse e pamundur të integrohen atje, por zhvilluesit e Tarantool magjepsin me hapjen e tyre, dhe jo vetëm nga MegaFon, dhe përshtatin sistemin e tyre me klientin. Është e bukur dhe na pëlqen shumë.
Ku kemi përdorur Tarantool
Ne përdorim Tarantool në disa elementë. E para është në pilot, të cilën e bëmë në sistemin e drejtorisë së adresave. Në një kohë doja që ai të ishte një sistem i ngjashëm me Yandex.Maps dhe Google Maps, por doli pak më ndryshe.
Për shembull, katalogu i adresave në ndërfaqen e shitjeve. Në Oracle, kërkimi i adresës së dëshiruar zgjat 12-13 sekonda. - numra të pakëndshëm. Kur kalojmë në Tarantool, zëvendësojmë Oracle me një bazë tjetër të dhënash në tastierë dhe kryejmë të njëjtin kërkim, marrim një shpejtësi 200x! Qyteti shfaqet pas shkronjës së tretë. Tani po përshtatim ndërfaqen në mënyrë që kjo të ndodhë pas të parës. Sidoqoftë, shpejtësia e përgjigjes është krejtësisht e ndryshme - milisekonda në vend të sekondave.
Aplikacioni i dytë është një temë në modë e quajtur IT me dy shpejtësi. Kjo sepse konsulentët nga çdo cep thonë se korporatat duhet të shkojnë atje.
Ekziston një shtresë infrastrukture, mbi të ka domene, për shembull, një sistem faturimi si telekomi, sistemet e korporatave, raportimi i korporatës. Ky është thelbi që nuk ka nevojë të preket. Kjo, natyrisht, është e mundur, por paranojakisht duke siguruar cilësi, sepse i sjell para korporatës.
Më pas vjen shtresa e mikroshërbimeve - ajo që e dallon operatorin ose lojtarin tjetër. Mikroshërbimet mund të krijohen shpejt bazuar në cache të caktuara, duke sjellë atje të dhëna nga fusha të ndryshme. Këtu fushë për eksperimente - nëse diçka nuk funksionoi, unë mbylla një mikroshërbim dhe hapa një tjetër. Kjo siguron një rritje të vërtetë të kohës për në treg dhe rrit besueshmërinë dhe shpejtësinë e kompanisë.
Mikroshërbimet janë ndoshta roli kryesor i Tarantool në MegaFon.
Ku planifikojmë të përdorim Tarantool
Nëse e krahasojmë projektin tonë të suksesshëm të faturimit me programet e transformimit në Deutsche Telekom, Svyazcom, Vodafone India, ai është çuditërisht dinamik dhe krijues. Në procesin e zbatimit të këtij projekti, jo vetëm MegaFon dhe struktura e tij u transformuan, por edhe Tarantool-ndërmarrja u shfaq në Mail.ru, dhe shitësi ynë Nexign (dikur Peter-Service) - BSS Box (një zgjidhje faturimi në kuti).
Ky është, në njëfarë kuptimi, një projekt historik për tregun rus. Mund të krahasohet me atë që përshkruhet në librin “The Mythical Man-Month” nga Frederick Brooks. Më pas, në vitet '60, IBM punësoi 360 njerëz për të zhvilluar sistemin e ri operativ OS/5 për mainframe. Kemi më pak - 000, por tanët janë me jelek, dhe duke marrë parasysh përdorimin e burimit të hapur dhe qasjet e reja, ne punojmë më produktivisht.
Më poshtë janë fushat e faturimit ose, më gjerësisht, sistemet e biznesit. Njerëzit nga ndërmarrjet e njohin shumë mirë CRM-në. Të gjithë duhet të kenë tashmë sisteme të tjera: Open API, API Gateway.
Hap API
Le të shohim përsëri numrat dhe se si funksionon aktualisht Open API. Ngarkesa e saj është 10 transaksione në sekondë. Meqenëse ne planifikojmë të zhvillojmë në mënyrë aktive shtresën e mikroshërbimeve dhe të ndërtojmë API publike MegaFon, presim rritje më të madhe në të ardhmen në këtë pjesë. Do të ketë patjetër 100 transaksione.
Nuk e di nëse mund të krahasohemi me Mail.ru në SSO - djemtë duket se kanë 1 transaksione në sekondë. Zgjidhja e tyre është jashtëzakonisht interesante për ne dhe ne planifikojmë të adoptojmë përvojën e tyre - për shembull, duke bërë një kopje rezervë funksionale SSO duke përdorur Tarantool. Tani zhvilluesit nga Mail.ru po e bëjnë këtë për ne.
CRM
CRM janë të njëjtët 80 milionë abonentë që duam t'i rrisim në një miliard, sepse tashmë ka 300 milionë dokumente që përfshijnë një histori trevjeçare. Me të vërtetë po presim me padurim shërbime të reja dhe këtu pika e rritjes është shërbimet e lidhura. Ky është një top që do të rritet, sepse do të ketë gjithnjë e më shumë shërbime. Prandaj, do të na duhet një histori; ne nuk duam të pengohemi në këtë.
Vetë faturimi përsa i përket lëshimit të faturave, punës me llogaritë e arkëtueshme të klientëve shndërruar në një domen të veçantë. Për të përmirësuar performancën, model arkitekturor i aplikuar i arkitekturës së domenit.
Sistemi është i ndarë në domene, ngarkesa shpërndahet dhe sigurohet toleranca ndaj gabimeve. Përveç kësaj, ne kemi punuar me arkitekturë të shpërndarë.
Çdo gjë tjetër është zgjidhje e nivelit të ndërmarrjes. Në hapësirën ruajtëse të thirrjeve - 2 miliardë në ditë, 60 miliardë në muaj. Ndonjëherë ju duhet t'i numëroni ato në një muaj, dhe është më mirë shpejt. Monitorimi financiar - janë pikërisht të njëjtat 300 milionë që rriten dhe rriten vazhdimisht: abonentët shpesh drejtohen midis operatorëve, duke rritur këtë pjesë.
Komponenti më i telekomunikacionit i komunikimeve celulare është faturimi online. Këto janë sistemet që ju lejojnë të telefononi ose të mos telefononi, të merrni vendime në kohë reale. Këtu ngarkesa është 30 transaksione në sekondë, por duke marrë parasysh rritjen e transferimit të të dhënave, ne planifikojmë 250 transaksione, dhe për këtë arsye ne jemi shumë të interesuar për Tarantool.
Fotografia e mëparshme është domenet ku do të përdorim Tarantool. Vetë CRM, natyrisht, është më i gjerë dhe ne do ta përdorim atë në thelb.
Shifra jonë e vlerësuar e TTX prej 100 milionë abonentësh më ngatërron mua si arkitekt - po sikur 101 milionë? A duhet të ribëni gjithçka përsëri? Për të parandaluar që kjo të ndodhë, ne përdorim cache, duke rritur në të njëjtën kohë aksesueshmërinë.
Në përgjithësi, ekzistojnë dy qasje për përdorimin e Tarantool. Së pari - ndërtoni të gjitha memoriet e fshehta në nivel mikroservice. Me sa kuptoj unë, VimpelCom po ndjek këtë rrugë, duke krijuar një cache klientësh.
Ne jemi më pak të varur nga shitësit, ne po ndryshojmë thelbin BSS, kështu që kemi një skedar të vetëm klient jashtë kutisë. Por ne duam ta zgjerojmë atë. Prandaj, ne kemi një qasje paksa të ndryshme - bëni memorie brenda sistemeve.
Në këtë mënyrë ka më pak sinkronizim - një sistem është përgjegjës si për cache-në ashtu edhe për burimin kryesor.
Metoda përshtatet mirë me qasjen Tarantool me një skelet transaksioni, kur përditësohen vetëm pjesët që lidhen me përditësimet, domethënë ndryshimet e të dhënave. Çdo gjë tjetër mund të ruhet diku tjetër. Nuk ka asnjë liqen të madh të të dhënave, memorie të pamenaxhuar globale. Memoriet e fshehta janë krijuar për sistemin, ose për produktet, ose për klientët, ose për ta bërë jetën më të lehtë për mirëmbajtjen. Kur një pajtimtar telefonon dhe është i mërzitur për cilësinë e shërbimit tuaj, ju dëshironi të ofroni shërbim cilësor.
RTO dhe RPO
Ka dy terma në IT - OTR и RPO.
Objektivi i kohës së rikuperimit është koha që duhet për të rivendosur shërbimin pas një dështimi. RTO = 0 do të thotë që edhe nëse diçka dështon, shërbimi vazhdon të funksionojë.
Objektivi i pikës së rikuperimit - kjo është koha e rikuperimit të të dhënave, sa të dhëna mund të humbasim gjatë një periudhe të caktuar kohore. RPO = 0 do të thotë se nuk po humbasim të dhëna.
Detyrë Tarantool
Le të përpiqemi të zgjidhim një problem për Tarantool.
E dhënë: një shportë aplikacionesh që të gjithë i kuptojnë, për shembull, në Amazon ose diku tjetër. i nevojshëm në mënyrë që karroca të funksionojë 24 orë 7 ditë në javë, ose 99,99% të rasteve. Porositë që na vijnë duhet të mbeten në rregull, sepse ne nuk mund ta aktivizojmë ose çaktivizojmë rastësisht lidhjen e pajtimtarit - gjithçka duhet të jetë rreptësisht e qëndrueshme. Abonimi i mëparshëm ndikon në atë të radhës, kështu që të dhënat janë të rëndësishme - asgjë nuk duhet të mungojë.
vendim. Mund të përpiqeni ta zgjidhni atë kokë më kokë dhe të pyesni zhvilluesit e bazës së të dhënave, por problemi nuk mund të zgjidhet matematikisht. Ju mund të mbani mend teoremat, ligjet e ruajtjes, fizikën kuantike, por pse - nuk mund të zgjidhet në nivelin DB.
Qasja e mirë e vjetër arkitekturore funksionon këtu - ju duhet të njihni mirë fushën e temës dhe ta përdorni atë për të zgjidhur këtë enigmë.
Zgjidhja jonë: krijimi i një regjistri të shpërndarë të aplikacioneve në Tarantool - një grup gjeo-shpërndarë. Në diagram, këto janë tre qendra të ndryshme të përpunimit të të dhënave - dy para Uraleve, një përtej Uraleve, dhe ne shpërndajmë të gjitha kërkesat midis këtyre qendrave.
Netflix, i cili tani konsiderohet si një nga liderët në IT, kishte vetëm një qendër të dhënash deri në vitin 2012. Në prag të Krishtlindjeve Katolike, më 24 dhjetor, kjo qendër e të dhënave u prish. Përdoruesit në Kanada dhe SHBA kanë mbetur pa filmat e tyre të preferuar, janë mërzitur shumë dhe kanë shkruar për këtë në rrjetet sociale. Netflix tani ka tre qendra të dhënash në bregun perëndimor-lindor dhe një në Evropën perëndimore.
Fillimisht po ndërtojmë një zgjidhje gjeo-shpërndarë - toleranca ndaj gabimeve është e rëndësishme për ne.
Pra, ne kemi një grup, por çfarë ndodh me RPO = 0 dhe RTO = 0? Zgjidhja është e thjeshtë, në varësi të temës.
Çfarë është e rëndësishme në aplikime? Dy pjesë: Hedhja e koshit tO marrjen e një vendimi blerjeje, dhe PAS. Pjesa DO në telekom zakonisht quhet kapja e porosisë ose negociata për urdhër. Në telekom, kjo mund të jetë shumë më e vështirë sesa në një dyqan online, sepse atje klientit duhet t'i shërbehet, t'i ofrohen 5 opsione dhe e gjithë kjo ndodh për ca kohë, por shporta është e mbushur. Në këtë moment, një dështim është i mundur, por nuk është i frikshëm, sepse ndodh në mënyrë interaktive nën mbikëqyrjen e njeriut.
Nëse qendra e të dhënave në Moskë dështon papritmas, atëherë duke kaluar automatikisht në një qendër tjetër të të dhënave, ne do të vazhdojmë të punojmë. Teorikisht, një produkt mund të humbasë në karrocë, por ju e shihni atë, shtoni përsëri në karrocë dhe vazhdoni të punoni. Në këtë rast RTO = 0.
Në të njëjtin moment, ekziston një opsion i dytë: kur klikuam "dorëzo", duam që të dhënat të mos humbasin. Nga ky moment, automatizimi fillon të funksionojë - kjo është RPO = 0. Duke përdorur këto dy modele të ndryshme, në një rast mund të jetë thjesht një grup gjeo-shpërndarë me një master të ndërrueshëm, në një rast tjetër një lloj rekord kuorumi. Modelet mund të ndryshojnë, por ne e zgjidhim problemin.
Më tej, duke pasur një regjistër të shpërndarë të aplikacioneve, ne gjithashtu mund t'i shkallëzojmë të gjitha - kemi shumë dispeçer dhe ekzekutues që hyjnë në këtë regjistër.
Cassandra dhe Tarantool së bashku
Ka një rast tjetër - "vitrinë e bilanceve". Këtu është një rast interesant i përdorimit të përbashkët të Cassandra dhe Tarantool.
Ne përdorim Cassandra sepse 2 miliardë telefonata në ditë nuk është kufiri, dhe do të ketë më shumë. Tregtarët duan të ngjyrosin trafikun sipas burimit; gjithnjë e më shumë detaje po shfaqen në rrjetet sociale, për shembull. Gjithçka i shtohet historisë.
Cassandra ju lejon të shkallëzoni horizontalisht në çdo madhësi.
Ne ndihemi rehat me Kasandrën, por ajo ka një problem - nuk është e mirë në lexim. Gjithçka është në rregull në regjistrim, 30 në sekondë nuk është problem - problemi i leximit.
Prandaj, u shfaq një temë me një cache, dhe në të njëjtën kohë zgjidhëm problemin e mëposhtëm: ekziston një rast i vjetër tradicional kur pajisjet nga një ndërprerës nga faturimi në internet hyjnë në skedarët që ngarkojmë në Cassandra. Ne luftuam me problemin e shkarkimit të besueshëm të këtyre skedarëve, madje duke përdorur këshillat e transferimit të skedarëve të menaxherit të IBM - ka zgjidhje që menaxhojnë transferimin e skedarëve në mënyrë efikase, duke përdorur protokollin UDP, për shembull, në vend të TCP. Kjo është mirë, por janë ende minuta, dhe ne nuk i kemi ngarkuar ende të gjitha, operatori në qendrën e thirrjeve nuk mund t'i përgjigjet klientit se çfarë ndodhi me bilancin e tij - duhet të presim.
Për të parandaluar që kjo të ndodhë, ne ne përdorim rezervë funksionale paralele. Kur dërgojmë një ngjarje përmes Kafkës në Tarantool, duke rillogaritur agregatët në kohë reale, për shembull, për sot, marrim gjendjet e parave të gatshme, i cili mund të transferojë bilancet me çdo shpejtësi, për shembull, 100 mijë transaksione në sekondë dhe po ato 2 sekonda.
Qëllimi është që pas kryerjes së një telefonate, brenda 2 sekondave në llogarinë tuaj personale të ketë jo vetëm bilancin e ndryshuar, por informacione se përse ka ndryshuar.
Përfundim
Këta ishin shembuj të përdorimit të Tarantool. Na pëlqeu shumë hapja e Mail.ru dhe gatishmëria e tyre për të shqyrtuar raste të ndryshme.
Është tashmë e vështirë për konsulentët nga BCG ose McKinsey, Accenture ose IBM të na befasojnë me diçka të re - shumë nga ato që ata ofrojnë, ne ose e bëjmë tashmë, kemi bërë ose po planifikojmë të bëjmë. Unë mendoj se Tarantool do të zërë vendin e tij të merituar në grupin tonë të teknologjisë dhe do të zëvendësojë shumë teknologji ekzistuese. Jemi në fazën aktive të zhvillimit të këtij projekti.
Raporti i Oleg dhe Andrey është një nga më të mirët në Konferencën Tarantool vitin e kaluar, dhe më 17 qershor Oleg Ivlev do të flasë në me një raport . Alexander Deulin do të bëjë gjithashtu një prezantim nga MegaFon . Le të zbulojmë se çfarë ka ndryshuar, çfarë planesh janë zbatuar. Bashkohuni - konferenca është falas, gjithçka që duhet të bëni është ... Të gjitha dhe programi i konferencës është formuar: raste të reja, përvojë e re në përdorimin e Tarantool, arkitekturë, ndërmarrje, tutoriale dhe mikroshërbime.
Burimi: www.habr.com