Përse një korporate si MegaFon i nevojitet Tarantool në faturimin e tij? Nga jashtë duket se zakonisht vjen një shitës, sjell një kuti të madhe, e lidhi në prizë — dhe ja faturimi! Disa kohë më parë kështu ishte, por tani kjo është një arkaikë, dhe dinosaurët e tillë kanë vdekur ose janë duke vdekur. Fillimisht faturimi ishte një sistem për lëshimin e faturave — një numërues ose kalkulator. Në telekomunikacionin modern — kjo është një sistem automatizimi i gjithë ciklit të jetës së ndërveprimit me abonentin nga nënshkrimi i kontratës deri në anulimin e saj, duke përfshirë tarifimin në kohë reale, pranimin e pagesave dhe shumë të tjera. Faturimi në kompanitë telekomunikative është si një robot luftarak — i madh, i fuqishëm dhe i mbushur me armë.
A ka lidhje këtu Tarantool? Këtë do ta tregojnë Oleg Ivlev dhe Andrey Knyazev. Oleg është arkitekti kryesor i kompanisë me një përvojë të madhe pune në kompani të huaja, Andrey është drejtori për sistemet e biznesit. Nga dekripimi i raportit të tyre në do të mësoni se për çfarë nevojitet R&D në korporata, çfarë është Tarantool, si bllokimi i përmasimit vertikal dhe globalizimi ishin parakushte për shfaqjen e kësaj Baze të Dhënash në kompani, për sfidat teknologjike, transformimin e arkitekturës, dhe si është teknologjia e MegaFon-it e ngjashme me Netflix, Google dhe Amazon.
Projekti «Bilingu i Bashkuar»
Projekti për të cilin do të flasim quhet «Bilingu i Bashkuar». Pikërisht në të, Tarantool tregoi cilësitë e tij më të mira.
Rritja e performancës së pajisjeve Hi-End nuk po arrinte të përballonte rritjen e bazës së abonentëve dhe rritjen e numrit të shërbimeve, pritej një rritje e mëtejshme e numrit të abonentëve dhe shërbimeve përmes M2M, IoT, dhe veçoritë filiale çuan te përkeqësimi i kohës deri në treg. Kompania mori vendimin për të krijuar një sistem të vetëm biznesi me një arkitekturë modulare unike të nivelit botëror, në vend të 8 sistemeve të ndryshme aktuale të bilingu.
MegaFon është tetë kompani në një. Në vitin 2009 përfundoi reorganizimi: deget në të gjithë Rusinë u bashkuan në një kompani të vetme OAO «Megafon» (tani PAO). Kështu, në kompani u shfaqën 8 sisteme faturimi me zgjidhje të vetat «të personalizuara», veçori filiale dhe strukturë organizative të ndryshme, IT dhe marketing.
Gjërat shkonin mirë derisa nuk duhet të vinte në jetë një produkt të përbashkët federal. Këtu dolën shumë vështirësi: disa kishin tarifimin me rrethim në rritje, disa në rënie, e disa sipas mesatares aritmetike. Ka mijëra nga këto momente.
Pavarësisht se versioni i sistemit të faturimit është një, një furnizues, konfigurimet ishin aq të ndryshme sa që të bashkoheshin zgjaste shumë. Ne përpoqëm të reduktonim numrin e tyre, dhe u ndeshëm me një problem tjetër, që shumë korporata e njohin.
Shkallëzimi vertikal. Edhe hardueri më i avancuar në atë kohë nuk përmbushte nevojat. Në punë përdornim pajisje nga Hewlett-Packard, linjat Superdome Hi-End, por nuk arrinte të përmbushte nevojat as për dy degë. Dëshirohej shkallëzim horizontal pa shpenzime operative të mëdha dhe investime kapitale.
Pritja e rritjes së numrit të abonentëve dhe shërbimeve. Këshilltarët tashmë kanë sjellë në botën e telekomunikacionit tregime rreth IoT dhe M2M: do të vijnë koha kur në çdo telefon dhe hekurosje do të ketë nga një kartë SIM, ndërsa në frigoriferë nga dy. Sot kemi një numër abonentësh, ndërsa në të ardhmen e afërt do të ketë shumë herë më shumë.
Sfidat teknologjike
Këto katër arsye na kanë shtyrë në ndryshime të rëndësishme. Kishim një zgjedhje mes modernizimit të sistemit dhe projektimit nga e para. Menduam gjatë, morëm vendime të rëndësishme, organizuam tenderë. Në fund vendosëm të projektojmë nga fillimi dhe filluam me sfida interesante - sfida teknologjike.
Shkallëzueshmëria
Nëse më parë ishte, duke thënë kushtimisht, 8 billing për 15 milion abonentë, tani duhet të rezultonte 100 milion abonentë dhe më shumë — ngarkesa është shumë më e lartë.
Tani jemi të krahasueshëm në shkallë me lojtarët e mëdhenj të internetit, si Mail.ru ose Netflix.
Por lëvizja e mëtejshme drejt rritjes së ngarkesës dhe bazës së abonentëve na ka vendosur para detyrave të vështira.
Gjeografia e vendit tonë të gjerë
Mes Kaliningradit dhe Vladivostokut 7500 km dhe 10 zona kohore. Shpejtësia e dritës është e përfunduar dhe në distanca të tilla, vonesat janë tashmë të rëndësishme. 150 ms në kanalet optike më të avancuara është shumë për tarifimin në kohë reale, veçanërisht siç është tani në telekomunikacionin në Rusi. Për më tepër, duhet të përditësohemi brenda një dite pune, dhe me zona të ndryshme kohore, kjo është një problem.
Ne nuk ofrojmë thjesht shërbime për një tarifë mujorë; kemi tarifa komplekse, paketa, modifikatorë të ndryshëm. Na nevojitet jo vetëm të lejojmë ose të ndalojmë abonentët nga biseda, por të ofrojmë një kuotë të caktuar - të llogarisim thirrjet dhe veprimet në kohë reale në mënyrë që ata të mos e ndjejnë.
Qëndrueshmëria
Kjo është ana tjetër e centralizimit.
Nëse mbledhim të gjithë abonentët në një sistem, çdo katastrofë dhe ngjarje emergjente janë të dëmshme për biznesin. Prandaj, dizajnojmë sistemin në mënyrë që të përjashtojmë ndikimin e fatkeqësive në të gjithë bazën e abonentëve.
Kjo është përsëri pasojat e heqjes dorë nga shkallëzimi vertikal. Kur kaluam në shkallëzim horizontal, rritëm numrin e serverëve nga qindra në mijëra. Këta duhen menaxhuar dhe ndërtuar interoperabilitet, duke rezervuar automatikisht infrastrukturën IT dhe rikuperuar sistemin e shpërndarë.
Na ishin paraqyruar sfida interesante. Ne projektuam sistemin, dhe në atë moment përpiqeshim të gjejmë përvojën globale për të kontrolluar sa jemi në trend, sa ndjekim teknologjitë më të avancuara.
Përvoja globale
Çuditërisht, në telekomunikacionin global nuk gjetëm asnjë referencë.
Evropa ra për numrin e abonentëve dhe shkallën, SHBA për planin e tarifave të saj. Disa informata shihnim në Kinë, ndërsa disa gjetëm në Indi dhe morëm specialistë nga Vodafone India.
Për analizën e arkitekturës, mbledhëm ekipin ëndërrues të udhëhequr nga IBM - arkitektë nga fusha të ndryshme. Këta njerëz mund të vlerësonin saktësisht atë që po bënim dhe të sillnin njohuri të caktuara në arkitekturën tonë.
Shkallëzimi
Disa numra për ilustërim.
Ne po projektuam një sistem për 80 milion abonentë me një kapacitet deri në një miliard. Kështu ne hiqim pragjet e ardhshme. Nuk është se po planifikojmë të pushtojmë Kinën, por për shkak të fluksit të IoT dhe M2M.
300 milion dokumente përpunohen në kohë reale. Megjithëse kemi 80 milion abonentë, ne punojmë me klientë potencialë dhe me ata që kanë kaluar nga ne, nëse duhet të mbledhim borxhin. Prandaj, volumi real është ndjeshëm më i madh.
2 miliard transaksionesh ndryshojnë çdo ditë - këto janë pagesa, akruale, thirrje dhe ngjarje të tjera. 200 TB të dhënash ndryshojnë në mënyrë aktive, pak më ngadalë ndryshojnë 8 PB të dhënash, dhe ky nuk është arhiv, por të dhëna të gjalla në një faturim të vetëm. Shkalla në qendrat e të dhënave - 5000 serverë në 14 lokacione.
Stack teknologjik
Kur e kemi planifikuar arkitekturën dhe kemi filluar të ndërtomë sistemin, ne importuam teknologjitë më interesante dhe përparimtare. Kështu u krijua një stack teknologjik, i njohur për secilin lojtar të internetit dhe korporatat që ndërtuan sisteme me ngarkesë të lartë.
Stack-u është i ngjashëm me stack-et e lojtarëve të tjerë të mëdhenj: Netflix, Twitter, Viber. Ai përbëhet nga 6 komponentë, por ne dëshirojmë ta përshtat dhe ta unifikojmë.
Fleksibiliteti është i mirë, por në një korporatë të madhe, pa unifikim, asgjë nuk funksionon.
Ne nuk planifikojmë të ndryshojmë atë Oracle për Tarantool. Në realitetin e kompanive të mëdha, kjo është një utopi, ose një fushatë që zgjat 5-10 vjet me një rezultat të paqartë. Por Cassandra dhe Couchbase mund të zëvendësohen plotësisht me Tarantool-in, dhe ne e synojmë këtë.
Pse Tarantool?
Ka 4 kritere të thjeshta pse ne zgjodhëm këtë DB.
Shpejtësia. Ne realizuam teste ngarkese në sistemet industriale të MegaFon. Tarantool fitoi - ai tregoi performancën më të mirë.
Nuk mund të themi se sistemet e tjera nuk përmbushin nevojat e MegaFon. Zgjidhjet aktuale të memories janë aq efikase sa që kjo kapacitet mjafton për kompaninë. Por ne jemi të interesuar të punojmë me liderin, dhe jo me ata që qëndrojnë pas, përfshirë në testin e ngarkesës.
Tarantool përmbush nevojat e kompanisë edhe në perspektivën afatgjatë.
Kostoja e TCO. Mbështetja për Couchbase në volumet e MegaFon është tejet e kushtueshme, ndërsa situata me Tarantool është shumë më e këndshme, dhe funksionalitetet e tyre janë të ngjashme.
Një tjetër veçori e këndshme që ndikuar pak në zgjedhjen tonë është se Tarantool punon më mirë me memorjen se çdo bazë tjetër. Ai tregon efektivitetin maksimal.
Besueshmëria. MegaFon investon në besueshmëri, ndoshta si askush tjetër. Prandaj, kur e shikuam Tarantool, kuptuam se duhej të bënim që ai të përmbushte kërkesat tona.
Ne investuam kohën dhe financat tona, dhe së bashku me Mail.ru krijuam një version enterprise, i cili tani përdoret nga disa kompani të tjera.
Tarantool-enterprise na plotësoi plotësisht në aspektin e sigurisë, besueshmërisë dhe regjistrimit.
Partneritet
E rëndësishme për mua është kontakti direkt me zhvilluesin. Kjo është saktësisht ajo që na tërhoqi tek ekipi i Tarantool.
Nëse ju shkoni te një lojtar, sidomos atij që punon me klientë të rëndësishëm, dhe i thoni se ju nevojitet që baza e të dhënave të përmbushë këto e ato kërkesa, ai zakonisht përgjigjet:
— Mirë, vendosni kërkesat nën atë grumbull — ndonjëherë, ndoshta, do t'i arrijmë ato.
Shumë kompani kanë një plan për 2-3 vitet e ardhshme, dhe është praktikisht e pamundur të integrohesh aty, ndërsa zhvilluesit e Tarantool tërheqin me transparencën e tyre, jo vetëm me MegaFon, dhe e adaptojnë sistemin për klientët. Kjo është e shkëlqyer, dhe na pëlqen shumë.
Ku e kemi përdorur Tarantool
Ne përdorim Tarantool në disa elemente. E para është në pilotin, që e kemi zhvilluar në sistemin e katalogut të adresave. Në atë kohë, dëshironim që të ishte një sistem si Yandex.Maps dhe Google Maps, por rezultati doli ndryshe.
Për shembull, katalogu i adresave në ndërfaqen e shitjeve. Në Oracle, kërkimi i adresës së dëshiruar zë 12-13 sekonda — numra të pakëndshëm. Kur kalojmë në Tarantool, zëvendësojmë Oracle me një tjetër BD në konsolë dhe realizojmë të njëjtin kërkim, fitojmë një përshpejtim prej 200 herë! Qyteti del pas shkronjës së tretë. Tani po e adaptojmë ndërfaqen që të ndodhi pas shkronjës së parë. Megjithatë, shpejtësia e reagimit është krejt ndryshe — tani është milisekonda në vend të sekondave.
Përdoreshin gjithashtu në një temë të njohur, e cila quhet IT me dy shpejtësi. Kjo është për shkak se konsulentët nga të gjitha drejtimet thonë se korporatat duhet të shkojnë atje.
Këtu ka një shtresë infrastrukture, mbi të cilën janë domainet, për shembull, sistemi i faturimit, si në telekom, sistemet korporative, raportimi korporativ. Ky është thelbi që nuk duhet prekur. Pra, natyrisht, mund të bëhet, por me një qasje paranojake për të siguruar cilësinë, sepse kjo sjell të ardhura për korporatën.
Pas kësaj vjen shtresa e mikroshërbimeve - ajo që e diferencion operatorin ose lojtarët e tjerë. Mikroshërbimet mund të krijohen shpejt duke u bazuar në disa cache, duke tërhequr të dhënat nga domaine të ndryshme. Këtu ka hapësirë për eksperimente — nëse diçka nuk funksionon, mbyllet një mikroshërbim, hapet një tjetër. Kjo siguron me të vërtetë një rritje të shpejtësisë në treg dhe rrit besueshmërinë dhe shpejtësinë e kompanisë.
Mikroshërbimet janë, ndoshta, roli kryesor i Tarantool në MegaFon.
Ku planifikojmë të aplikojmë Tarantool
Nëse e krahasojmë projektin tonë të suksesshëm të faturimit me programet e transformimit në Deutsche Telekom, Svyaznoy, Vodafone India, ai është befasueshëm dinamik dhe krijues. Gjatë zbatimit të këtij projekti, jo vetëm që u transformua MegaFon dhe struktura e tij, por gjithashtu u shfaq Tarantool-enterprise te Mail.ru, dhe te furnizuesi ynë Nexign (më parë "Peterservice") – BSS Box (nje zgjidhje faturimi të paketuar).
Kjo, në njëfarë mënyre, është një projekt historik për tregun rus. Mund ta krahasojmë me atë që përshkruhet në librin e Frederick Brooks "Miti i Njeriut-Muaj". Atëherë, në vitet '60 për të zhvilluar një sistem të ri operativ OS/360 për mainframe të IBM, ishin angazhuar 5,000 njerëz. Ne kemi më pak – 1,800, por ata janë në rripa, dhe duke pasur parasysh përdorimin e burimeve të hapura dhe qasje të reja, ne punojmë më produktivisht.
Më poshtë janë treguar domenet e faturimit ose, nëse flasim më gjerë, – sistemet e biznesit. Njerëzit nga enterprise e dinë mirë CRM. Sistemas e tjera duhet të jenë tashmë te të gjithë: Open API, API Gateway.
Open API
Le ta shikojmë përsëri numrat dhe se si tani funksionon Open API. Ngarkesa e tij është – 10,000 transaksione në sekondë. Duke ne po planifikojmë të zhvillojmë aktivisht shtresën e mikroshërbjeve dhe të ndërtojmë një API publik për MegaFon, presim një rritje të konsiderueshme në të ardhmen pikërisht në këtë drejtim. Sigurisht se do të ketë 100,000 transaksione..
Nuk e di nëse do të jemi në gjendje të krahasohemi në SSO me Mail.ru - ata duket se kanë 1,000,000 transaksione në sekondë. Zgjidhja e tyre është jashtëzakonisht interesante për ne dhe planifikojmë të përfitojmë nga eksperienca e tyre - për shembull, të bëjmë një rezervë funksionale SSO me ndihmën e Tarantool. Tani zhvilluesit nga Mail.ru po merren me këtë për ne.
CRM
CRM janë ata 80 milion abonentë që dëshirojmë t'i çojmë në një miliard, sepse tashmë kemi 300 milion dokumente që përfshijnë historinë tri vjeçare. Ne vërtet presim shërbime të reja, dhe këtu prakhtimi i shërbimeve të lidhura është. Kjo është një sfere që do të rritet, sepse shërbimet do të jenë gjithnjë e më shumë. Prandaj, do të na nevojitet historia, nuk duam të hasim në këtë.
Faturimi në lidhje me lëshimin e faturave, punën me borxhet ndaj klientëve është transformuar në një domain të veçantë. Për të zgjeruar performancën, është aplikuar një model arkitekture domain..
Sistemi është i ndarë në domain, ngarkesa është e shpërndarë dhe është e garantuar qëndrueshmëria. Për më tepër, është bërë punë me arkitekturën e shpërndarë.
E gjithë e tjera — janë zgjidhje të nivelit enterprise. Në depozitat e thirrjeve — 2 miliard në ditë, 60 miliard në muaj. Ndonjëherë duhet t'i ribëjmë llogaritë për muajin, dhe është më mirë shpejt. Monitorimi financiar — janë ato 300 milion që vazhdimisht rriten: abonentët shpesh lëvizin nga një operator tek tjetri, duke rritur këtë pjesë.
Komponenti më telekomunikues nga lidhjet mobile — është tarifikimi online. Këto janë sistemet që ju lejojnë të telefononi ose të mos telefononi, duke marrë vendim në kohë reale. Këtu ngarkesa është 30,000 transaksione në sekondë, por për shkak të rritjes së transmetimit të të dhënave planifikojmë 250,000 transaksione, dhe prandaj jemi shumë të interesuar për Tarantool.
Imazhi i mëparshëm — janë ato domain ku planifikojmë të aplikojmë Tarantool. Vetë CRM, natyrisht, është më i gjerë dhe ne planifikojmë ta aplikojmë në thelbin e tij.
Numri ynë referues për TTH në 100 milion abonentë më shqetëson si arkitekt — çfarë, nëse 101 milion? Sërish do të duhet gjithçka të ri-përshtatet? Për të shmangur një situatë të tillë, ne përdorim cache, duke rritur gjithashtu disponueshmërinë.
Në përgjithësi ekzistojnë dy qasje për aplikimin e Tarantool. E para — ndërtimi i të gjithë caches në nivelin e mikroshërbimeve. Sa e kuptoj unë, ky është rruga që ndjek VimpelCom, duke krijuar cache për klientët.
Ne jemi më pak të varur nga ofruesit, po ndryshojmë thelbin e BSS, prandaj kemi një regjistër të vetëm klientësh që është gati nga kutia. Por ne dëshirojmë ta zgjerojmë. Prandaj aplikojmë një qasje pak më ndryshe — ndërtojmë caches brenda sistemeve.
Kështu kemi më pak asinkronizim — një sistem përgjigjet si për cache, ashtu edhe për burimin kryesor master.
Qas është i përshtatshëm për Tarantool me skeletin transaksional, kur përditësohen vetëm pjesët që lidhen me azhurnimet, dmth, ndryshimet e të dhënave. Gjithçka tjetër mund të ruhen diku tjetër. Nuk ka një liqen të madh të dhënash, asnjë cache global të pakontrolluar. Cache-t projektohen në përputhje me sistemin, ose për produktet, ose për klientët, ose për të lehtësuar jetën e mbështetjes. Kur një abonent i shqetësuar për cilësinë telefonon, dëshirojmë ta mbështesim atë siç duhet.
RTO dhe RPO
Në IT ekzistojnë dy termine - RTO dhe RPO.
Qëllimi i kohës së rikuperimit është koha e rikuperimit të shërbimit pas një dështimi. RTO = 0 do të thotë se, edhe nëse diçka dështoi, shërbimi vazhdon të funksionojë.
Qëllimi i pikës së rikuperimit është koha e rikuperimit të të dhënave, sa të dhëna mund të humbasim brenda një periudhe të caktuar. RPO = 0 do të thotë se nuk humbasim të dhëna.
Detyra për Tarantool
Le t'i zgjidhim një detyrë për Tarantool.
E dhënë: një shportë aplikacionesh e njohur për të gjithë, për shembull, në Amazon ose diku tjetër. Kërkohet për të siguruar që karroca të funksionojë 24 orë 7 ditë në javë, ose 99,99% të kohës. Porositë që na vijnë duhet të mbajnë rend, sepse nuk mund të aktivizojmë ose çaktivizojmë me rastësishmëri lidhjen e abonentëve - gjithçka duhet të jetë strikt e renditur. Abonimi i mëparshëm ndikon në atë të mëpasshëm, kështu që të dhënat janë të rëndësishme - asgjë nuk duhet të humbasë.
Zgjidhja. Mund të provoni ta zgjidhni drejtpërdrejt dhe të pyesni zhvilluesit e DB, por kjo detyrë matematikisht nuk zgjidhet. Mund të kujtoni teoremën, ligjet e ruajtjes, fizikën kuantike, por përse - nuk është e mundur ta zgjidhni në nivelin e DB.
Këtu funksionin një qasje arkitekturore e vjetër e mirë - duhet të njihni mirë lëmin dhe ta zgjidhni këtë enigmë nëpërmjet saj.
Zgjidhja jonë: krijojmë një regjistër të shpërndarë të aplikimeve në Tarantool - një klaster geo të shpërndarë. Në diagram, kjo janë tre qendra të ndryshme të përpunimit të të dhënave - dy para Uralit, një pas Uralit, dhe ne shpërndajmë të gjitha aplikimet në këto qendra.
Në Netflix, i cili tani konsiderohet si një nga liderët në IT, deri më 2012 kishte vetëm një Qendër të të Dhënave. Para Krishtlindjeve katolike më 24 dhjetor, ajo Qendër e të Dhënave dështoi. Përdoruesit në Kanada dhe SHBA mbetën pa filmat e tyre të preferuar, u shqetësuan shumë dhe shkruan për këtë në rrjetet sociale. Tani Netflix ka tre Qendra të të Dhënave në bregun perëndimor-lindor dhe një në Euroazinë Perëndimore.
Ne fillimisht ndërtuam një zgjidhje gjeo-repartizimi – na intereson qëndrueshmëria ndaj dështimeve.
Pra, kemi një grup, por si të bëjmë me RPO = 0 dhe RTO = 0? Zgjidhja është e thjeshtë, e cila varet nga subjekti.
Çfarë është e rëndësishme në kërkesa? Dy pjesë: përgatitja e shportës PËRPARA miratimit të vendimit për blerje, dhe PAS. Pjesa PËRPARA në telekom zakonisht quhet kapja e porosisë ose negocimi i porosisë.Në telekom, kjo mund të jetë shumë më e komplikuar se në një dyqan online, sepse duhet shërbyer klienti, të ofrohet 5 mundësi, dhe kjo ndodh për një kohë të caktuar, por shporta mbushet. Në këtë moment dështimi është i mundshëm, por nuk është frikshëm, sepse ndodh në mënyrë interaktive nën mbikëqyrjen e një personi.
Nëse Qendra të Dhënash e Moskës papritur ndalon së punuari, do të kalojmë automatikisht në një Qendër të Dhënash tjetër dhe do të vazhdojmë punën. Në mënyrë teorike, një produkt mund të humbasë në shportë, por ju e shihni këtë, e plotësoni sërish shportën dhe vazhdoni të punoni. Në këtë rast, RTO = 0.
Po njëkohësisht, ekziston një variant tjetër: kur ne e klikojmë "submit", do të duam që të dhënat të mos humbasin. Që nga ky moment, automatika fillon të funksionojë — kjo është RPO = 0. Përdorimi i këtyre dy modeleve të ndryshme në një rast mund të jetë një klasër gjeográfik me një master të përshkueshëm, në rastin tjetër një regjistrim kuorumi. Modelet mund të ndryshojnë, por ne e zgjidhim problemin.
Më pas, duke pasur një regjistër të shpalljeve të shpërndara, ne mund të zgjerim gjithçka — të kemi shumë menaxherë dhe ekzekutues që i qasen këtij regjistri.
Cassandra dhe Tarantool së bashku
Ekziston edhe një rast tjetër — "vitrina e ekuipazhit". Këtu ka një rast interesant të përdorimit të përbashkët të Cassandra dhe Tarantool.
Ne përdorim Cassandra, sepse 2 miliard thirrje në ditë nuk është kufi, dhe do të ketë më shumë. Marketerët e duan të analizojnë trafikun sipas burimeve, duke shfaqur më shumë detaje për rrjetet sociale, për shembull. Kjo e zgjeron historinë.
Cassandra lejon që të shkallëzohet horizontalisht për çdo volum.
Ne ndjehemi rehat me Cassandra, por ajo ka një problem - nuk është e mirë në lexim. Në regjistrim gjithçka është në rregull, 30,000 në sekondë nuk janë problem - problemi është në lexim.
Prandaj doli tema e caches, dhe ne gjithashtu zgjidhëm një problem tjetër: ka një rast të vjetër tradicional, kur pajisja nga switch-i nga tarifimi online vjen në skedarë, të cilat i ngarkohemi në Cassandra. Ne luftuam me problemin e ngarkimit të besueshëm të këtyre skedarëve, madje për të përdorur një këshillë nga menaxhuesi i IBM për transferimin e skedareve - ka zgjidhje të tilla që menaxhojnë transfertat e skedarëve në mënyrë efektive, duke përdorur protokollin UDP, për shembull, dhe jo TCP. Kjo është e mirë, por ende duhen minuta, dhe derisa të ngarkohet gjithçka, operatori në qendrën e thirrjeve nuk mund të përgjigjet klientit çfarë ka ndodhur me bilancin e tij - duhet pritur.
Që të mos ndodhë kjo, ne aplikojmë rezervën funksionale paralele. Kur ne dërgojmë një ngjarje përmes Kafka në Tarantool, duke rinisur agregatet në kohë reale, për shembull, për sot, atëherë marrim keshin e bilancit, i cili mund të japë bilancet me çdo shpejtësi, për shembull, 100 mijë transaksione në sekondë dhe të njëjtat 2 sekonda.
Qëllimi është që pas kryerjes së telefonatës, brenda 2 sekondave në kabinetin personal të ketë jo vetëm bilancin e ndodhur, por edhe informacionin se pse ai është ndryshuar.
Përfundimi
Ishin këto shembuj të përdorimit të Tarantool. Na pëlqeu shumë hapësira e Mail.ru, gatishmëria e tyre për të shqyrtuar raste të ndryshme.
Këshilltarëve nga BCG, McKinsey, Accenture ose IBM tani u është bëre e vështirë të na befasojnë me diçka të re - shumë nga ato që ata ofrojnë, ne ose i bëjmë tashmë, ose i kemi bërë, ose planifikojmë t'i bëjmë. Mendoj se Tarantool do të zërë një vend të merituar në stekën tonë teknologjike dhe do të zëvendësojë shumë teknologji ekzistuese. Ne jemi në fazën aktive të zhvillimit të këtij projekti.
Referati i Olegut dhe Andrey është një nga më të mirat në Konferencën Tarantool të vitit të kaluar, dhe më 17 qershor Oleg Ivlev do të flasë në me referatin . Në ngjarjen do të flasë Aleksandër Deulin nga Megafon . Do të mësojmë se çfarë ka ndryshuar, cilat plane janë realizuar. Bashkohuni - konferenca është falas, duhet vetëm të . Të gjitha dhe programi i konferencës është formuar: raste të reja, përvojë të re në përdorimin e Tarantool, arkitektura, ndërmarrjet, tutorialet dhe mikroshërbimet.
Burimi: habr.com
