PĂ«rse njĂ« korporate si MegaFon i nevojitet Tarantool nĂ« faturim? Nga jashtĂ« duket se zakonisht vjen njĂ« furnizues, sjell njĂ« kuti tĂ« madhe, e lidh nĂ« prizĂ« â ja edhe faturimi! NjĂ«herĂ« kĂ«shtu ishte, por tani kjo Ă«shtĂ« arkaike, dhe kĂ«to dinosaurĂ« tashmĂ« janĂ« zhdukur ose po zhduken. Fillimisht, faturimi Ă«shtĂ« njĂ« sistem pĂ«r lĂ«shimin e faturave â njĂ« shifĂ«rues apo kalkulator. NĂ« telekomunikacionin modern, kjo Ă«shtĂ« njĂ« sistem automatizimi i gjithĂ« ciklit tĂ« jetĂ«s sĂ« ndĂ«rveprimit me abonentin nga lidhja e kontratĂ«s deri nĂ« shkĂ«putje, duke pĂ«rfshirĂ« tarifimin nĂ« kohĂ« reale, pranimin e pagesave dhe shumĂ« tĂ« tjera. Faturimi nĂ« kompanitĂ« telekomunikacioni Ă«shtĂ« si njĂ« robot luftarak â i madh, i fuqishĂ«m dhe i mbushur me armĂ«.
Cila është lidhja këtu me Tarantool? Këtë do ta shpjegojnë Oleg Ivlev dhe Andrey Knyazev. Oleg është arkitekt kryesor i kompanisë me një përvojë të madhe pune në kompani të huaja, ndërsa Andrey është drejtor i sistemeve të biznesit. Nga përmbledhja e tryezës së tyre në  do të mësoni përse R&D është e nevojshme në korporata, çfarë është Tarantool, si impasi i shkallëzimit vertical dhe globalizimi u bënë parakusht për shfaqjen e kësaj BD në kompani, sfidat teknologjike, transformimin e arkitekturës, dhe si arkitektura e MegaFon i ngjan Netflix, Google dhe Amazon.
Projekti 'Faturimi i Posaçëm'
Projekti, për të cilin do të flasim, quhet 'Faturimi i Posaçëm'. Pikërisht në të, Tarantool e tregoi cilësinë e tij më të mirë.
Rritja e performancës së pajisjeve Hi-End nuk arriti të ndjekë rritjen e bazës së abonentëve dhe rritjen e numrit të shërbimeve, kërkohej një rritje e mëtejshme e numrit të abonentëve dhe shërbimeve përmes M2M, IoT, dhe veçoritë filiale çuan në përkeqësimin e kohës për të dalë në treg. Kompania mori vendim të krijojë një sistem të vetëm biznesi me një arkitekturë modulare unike në nivel botëror, në vend të 8 sistemeve të ndryshme të faturimit.
MegaFon Ă«shtĂ« tetĂ« kompani nĂ« njĂ«. NĂ« vitin 2009 pĂ«rfundoi reorganizimi: filialet nĂ« tĂ« gjithĂ« RusinĂ« u bashkuan nĂ« njĂ« kompani tĂ« vetme OAO 'MegaFon' (tani PAO). NĂ« kĂ«tĂ« mĂ«nyrĂ«, kompania fitoi 8 sisteme faturimi me zgjidhje âtĂ« personalizuaraâ, veçori filiale dhe njĂ« strukturĂ« organizative tĂ« ndryshme, IT dhe marketing.
Gjithçka ishte mirë deri sa erdhi koha për të lançuar një produkt të përbashkët federal. Këtu u shfaqën një sërë vështirësish: ndonjëherë tarifat ishin të rrumbullakosura lart, për disa lart, dhe për disa të tjera sipas mesatares aritmetike. Ka mijëra të tilla.
Megjithëse versioni i sistemit të faturimit është një, një ofrues, konfigurimet ishin aq të ndryshme sa u desh shumë kohë për t'i bashkuar. Ne u munduam t'i reduktojmë numrat dhe hasëm një problem tjetër, i njohur për shumë korporata.
Shkallëzimi vertikal. Edhe pajisjet më të avancuara të asaj kohe nuk përmbushnin nevojat. Përdorim pajisje nga Hewlett-Packard, të serive Superdome Hi-End, por ato nuk përballonin nevojat as të dy filialeve. Dëshironim shkallëzim horizontal pa shpenzime të mëdha operacionale dhe investime kapitali.
PræćŸ ćąéż pĂ«r numrin e abonentĂ«ve dhe shĂ«rbimeve. KonsulentĂ«t e kanĂ« sjellĂ« prej kohĂ«sh tregimet mbi IoT dhe M2M nĂ« botĂ«n e telekomit: do tĂ« vijĂ« njĂ« kohĂ« kur çdo telefon dhe hekur do tĂ« ketĂ« nga njĂ« SIM-kartelĂ«, ndĂ«rsa frigoriferĂ«t do tĂ« kenĂ« dy. Sot kemi njĂ« numĂ«r abonentĂ«sh, ndĂ«rsa nĂ« tĂ« ardhmen e afĂ«rt do tĂ« kemi shumĂ« mĂ« shumĂ«.
Sfidat teknologjike
Këto katër arsye na çuan në ndryshime të rëndësishme. Kishim zgjedhjen midis modernizimit të sistemit dhe ndërtimit nga fillimi. Menduam gjatë, morëm vendime të rëndësishme, zhvilluam tenderë. Në përfundim, vendosëm të projektuar nga e para dhe u angazhuam në sfida interesante - sfidat teknologjike.
Shkallëzueshmëria
NĂ«se mĂ« parĂ« ishim, le t'i themi, 8 sisteme faturimi me 15 milion abonentĂ«, tani duhej tĂ« arrihej 100 milion abonentĂ« e mĂ« shumĂ«Â â ngarkesa Ă«shtĂ« shumĂ« mĂ« e lartĂ«.
Ne filluam të ishim të krahasueshëm në shkallë me lojtarë të mëdhenj të internetit, si Mail.ru apo Netflix.
Por rritja e mëtejshme e ngarkesës dhe numrit të abonentëve na vuri përpara detyrave të rëndësishme.
Geografia 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 me këto distanca vonesat tashmë janë të rëndësishme. 150 ms në kanalet optike më të avancuara është shumë për tarifimin në kohë reale, sidomos tani në telekom në Rusi. Për më tepër, është e nevojshme që të përditësohemi brenda një dite pune, dhe me zona të ndryshme kohore - kjo është një problem.
Ne ofrojmë thjesht shërbime për abone, kemi plane komplekse, paketa dhe modifikatorë të ndryshëm. Nuk është vetëm çështje të lejojmë ose ndalojmë abonen të flasë, por duhet t'i japim një kuotë të caktuar - të numërojmë thirrjet dhe veprimet në kohë reale në mënyrë që ai të mos e vërë re.
Qëndrueshmëri
Kjo është ana e kundërt e centralizimit.
Nëse ne mbledhim të gjithë abonentët në një sistem, çdo ngjarje aksidentale dhe katastrofa do të kishin pasoja të rënda për biznesin. Prandaj, projektojmë sistemin në mënyrë që të përjashtojmë ndikimin e aksidenteve mbi të gjithë bazën e abonentëve.
Kjo është një pasojë e heqjes nga shkallëzimi vertikal. Kur u larguam në shkallëzim horizontal, rritëm numrin e serverëve nga qindra në mijëra. Duhet t'i menaxhojmë ata dhe të ndërtjmë ndërfaqe të ndërrueshme, duke rezervuar automatikisht infrastrukturën IT dhe rikuperuar sistemin e shpërndarë.
Këto ishin sfida interesante për ne. Ne projektuam sistemin, dhe në atë moment u përpoqëm të gjenim përvojën më të mirë në botë për të parë sa jemi në trend, sa ndjekim teknologjitë e avancuara.
PĂ«rvoja globale
ĂuditĂ«risht, por nĂ« telekomin global nuk gjetĂ«m asnjĂ« referencĂ«.
Evropa doli nga gara përsa i përket numrit të abonentëve dhe shkallës, SHBA - për shkak të sheshtëzimit të planeve të saj. Disa informacion morëm nga Kina, ndersa diçka gjetëm në Indi dhe morëm specialistë nga Vodafone India.
Për të analizuar arkitekturën, mblodhëm një ekip të ëndrrave të lideruar nga IBM - arkitektë nga fusha të ndryshme. Këta njerëz mund të vlerësonin siç duhet atë që po bënim dhe të sillnin njohuri të caktuara në arkitekturën tonë.
Shkalla
Disa numra për ilustrim.
Ne po projektojmë sistemin për 80 milion abonentë me një rezervë deri në një miliard. Kështu ne heqim kufizimet e së ardhmes. Kjo nuk është sepse planifikojmë të pushtojmë Kinën, por për shkak të rritjes së IoT dhe M2M.
300 milion dokumente procesohen në kohë reale. Megjithëse kemi 80 milion abonentë, ne po punojmë edhe me klientët potencialë dhe ata që na kanë lënë, nëse është e nevojshme të kërkojmë borxhin. Prandaj, vëllimet reale janë ndjeshëm më të mëdha.
2 miliard transaksionesh ndryshojnë bilancin çdo ditë - këto janë pagesa, akruale, thirrje dhe ngjarje të tjera. 200 Tb të dhënash janë në ndryshim aktiv, nd sedikit më ngadalë ndryshon 8 Pb të dhënash, dhe kjo nuk është një arkiv, por të dhëna të gjalla në një faturim të vetëm. Shkalla e Qendrave të Të Dhënave - 5 mijë serverë në 14 lokacione.
Stoku Teknologjik
Kur planifikuam arkitekturën dhe filluam të mbledhim sistemin, importuam teknologjitë më interesante dhe më përparimtare. Rezultati ishte një stok teknologjik, i njohur për çdo lojtar në internet dhe për korporatat që krijojnë sisteme me ngarkesë të lartë.
Stoku është i ngjashëm me stoqet e lojtarëve të mëdhenj: Netflix, Twitter, Viber. Ai përbëhet nga 6 komponente, por ne dëshirojmë ta shkurtomë dhe ta unifikohem.
Fleksibiliteti është e mirë, por në një kompani të madhe, unifikimi është i pashmangshëm.
Ne nuk kemi ndërmend të zëvendësojmë Oracle me Tarantool. Në realitetet e kompanive të mëdha, kjo është një utopi, ose një kryqëzatë që mund të zgjasë 5-10 vjet me një përfundim të pasigurt. Por Cassandra dhe Couchbase së bashku me Tarantool mund të zëvendësohen, dhe ne e synojmë këtë.
Pse Tarantool?
Ka 4 kritere të thjeshta, pse ne zgjodhëm këtë DB.
Shpejtësia. Ne zhvilluam testime ngarkese në sistemet industriale të MegaFon. Tarantool fitoi - tregoi performancën më të mirë.
Nuk mund të themi se sistemet e tjera nuk plotësojnë nevojat e MegaFon. Zgjidhjet aktuale me memorie janë aq të fuqishme saqë kjo kapaciteti është i mjaftueshëm për kompaninë. Por na intereson të kemi të bëjmë me liderin, jo me ata që ndodhen në fund, përfshirë në testin e ngarkesës.
Tarantool mbulon nevojat e kompanisë edhe në perspektivën afatgjatë.
Ămimi TCO. MbĂ«shtetje pĂ«r Couchbase nĂ« kapacitetet e MegaFon kushton shumĂ«, kurse me Tarantool situata Ă«shtĂ« shumĂ« mĂ« e kĂ«ndshme, dhe funksionaliteti i tyre Ă«shtĂ« i ngjashĂ«m.
Një tjetër veçori e këndshme, e cila pak e ndihmoi në zgjedhjen tonë - Tarantool punon më mirë se baza të tjera të të dhënave me memorie. Ai tregon efektivitetin maksimal.
Besueshmëria. MegaFon investon ndoshta më shumë në besueshmëri se kushdo tjetër. Prandaj, kur shikuam Tarantool, e kuptuam që duhet ta bëjmë që ai të përmbushë 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 në disa kompani të tjera.
Tarantool-enterprise na justifikoi plotësisht në aspektin e sigurisë, besueshmërisë, regjistrimit.
Partneriteti
E rëndësishme për mua është kontakti direkt me zhvilluesin. Kjo është ajo që na fitoi të gjithë ne nga Tarantool.
Kur të shkosh te një lojtar, veçanërisht ai që punon me klientë të ngurtë, dhe i thua se të nevojitet që DB të jetë në gjendje të bëjë këtë, këtë dhe këtë, zakonisht ai përgjigjet:
â MirĂ«, vendosni kĂ«rkesat nĂ« fund tĂ« asaj pile â ndoshta njĂ« ditĂ« do t'i arrijmĂ« ato.
Shumë kanë një plan zhvillimi për 2-3 vitet e ardhshme, dhe integrimi atje është praktikisht i pamundur, ndërsa zhvilluesit e Tarantool tërheqin me transparencën e tyre, jo vetëm me MegaFon, dhe adaptojnë sistemin e tyre për klientët. Kjo është e shkëlqyer dhe na pëlqen shumë.
Ku e kemi aplikuar Tarantool
Tek ne, Tarantool pĂ«rdoret nĂ« disa elemente. E para â nĂ« pilotin, qĂ« e bĂ«mĂ« nĂ« sistemin e katalLOGUT tĂ« adresave. NĂ« atĂ« kohĂ«, doja qĂ« tĂ« ishte njĂ« sistem qĂ« ngjante me Yandex.Maps dhe Google Maps, por doli ndryshe.
PĂ«r shembull, katalogu i adresave nĂ« ndĂ«rfaqen e shitjeve. NĂ« Oracle, kĂ«rkimi i adresĂ«s sĂ« nevojshme zgjat 12-13 sekonda â numra jo tĂ« rehatshĂ«m. Kur kalojmĂ« nĂ« Tarantool, zĂ«vendĂ«sojmĂ« Oracle me njĂ« DB tjetĂ«r nĂ« konsol, dhe bĂ«jmĂ« tĂ« njĂ«jtin kĂ«rkim, arrijmĂ« njĂ« pĂ«rshpejtim prej 200 herĂ«! Qyteti shfaqet pas shkronjĂ«s sĂ« tretĂ«. Tani po adaptojmĂ« ndĂ«rfaqen qĂ« tĂ« ndodhte pas shkronjĂ«s sĂ« parĂ«. MegjithatĂ«, shpejtĂ«sia e reagimit Ă«shtĂ« krejt tjetĂ«r â tashmĂ« Ă«shtĂ« milisekonda nĂ« vend sekondash.
Aplikimi i dytĂ« â njĂ« temĂ« e modĂ«s, e cila quhet IT me dy shpejtĂ«si. Kjo Ă«shtĂ« pĂ«r shkak se konsulentĂ«t e çdo kanali thonĂ« se korporatat duhet tĂ« shkojnĂ« atje.
Këtu ka një shtresë infrastrukture, mbi të janë domainet, për shembull, sistemi i faturimit, si te telekomi, sistemet korporative, raportimi korporativ. Kjo është thelbi, të cilin nuk duhet ta prekësh. Domethënë, sigurisht, mundesh, por me paranoia për të garantuar cilësinë, sepse kjo sjell para për korporatën.
Pastaj vjen shtresa e mikrosherbimeve â ato qĂ« diferencojnĂ« operatorin ose lojtarin tjetĂ«r. Mikrosherbimet mund tĂ« krijohen shpejt mbi baza tĂ« disa cache-Ă«ve, duke ngritur tĂ« dhĂ«na nga domain tĂ« ndryshme. KĂ«tu Ă«shtĂ« njĂ« fushĂ« pĂ«r eksperimente â nĂ«se diçka nuk ndodhi, mbylle njĂ« mikrosherbim, hap njĂ« tjetĂ«r. Kjo siguron njĂ« kohĂ« vĂ«rtet tĂ« pĂ«rshpejtuar pĂ«r tregun dhe rrit besueshmĂ«rinĂ« dhe shpejtĂ«sinĂ« e kompanisĂ«.
Mikrosherbimet 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ë surprizueshëm dinamik dhe kreativ. Gjatë realizimit 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 ofruesi ynë Nexign (më parë "Peterservice") - BSS Box (zgjidhje faturimi e paketuar).
Kjo, në njëfarë mënyre, është një projekt historik për tregun rus. Mund ta krahasojmë me atë që është përshkruar në librin e Frederick Brooks "Miti i njeriut-muajt". Atëherë, në vitet '60, për zhvillimin e sistemit të ri operativ OS/360 për mainframe-t, IBM angazhoi 5,000 njerëz. Ne kemi më pak - 1,800, por të gjithë jemi të gatshëm dhe, duke pasur parasysh përdorimin e burimeve të hapura dhe qasje të reja, punojmë më produktivisht.
Më poshtë shfaqen domenet e faturimit ose, nëse flasim më gjerë, - sistemet e biznesit. Njerëzit nga ndërmarrjet e mëdha e dinë shumë mirë CRM. Sistemet e tjera duhet të jenë tashmë te të gjithë: Open API, API Gateway.
Open API
Le të shohim përsëri numrat dhe se si tani funksionon Open API. Ngarkesa e tij është 10,000 transaksione në sekondë. Duke qenë se planifikojmë të zhvillojmë aktivisht shtresën e mikrosherbimeve dhe të ndërtuam API publik të MegaFon, ne presim rritje të mëtejshme në të ardhmen pikërisht në këtë pjesë. 100,000 transaksione me siguri do të jenë.
Nuk e di, a do të arrijmë në të njëjtat nivele SSO me Mail.ru - nga ata, duket, ka 1,000,000 transaksione në sekondë. Zgjidhja e tyre na interesohet shumë dhe ne planifikojmë të marim përvojën e tyre - për shembull, të bëjmë një rezervë funksionale SSO me ndihmën e Tarantool. Tani zhvilluesit nga Mail.ru po punojnë për këtë për ne.
CRM
CRM - janë ata 80 milion klientë, të cilët duam t'i arrijmë deri në një miliard, sepse tashmë kemi 300 milion dokumente, të cilat përfshijnë një histori trevjeçare. Ne me të vërtetë presim shërbime të reja, dhe këtu pikë e rritjes është shërbimet e lidhura. Ky është një sektor që do të rritet, sepse do të ketë gjithnjë e më shumë shërbime. Prandaj, do të jetë e nevojshme një histori, ne nuk duam të bllokohemi në këtë.
Faturimi i vet në aspektin e lëshimit të faturave, punës me borxhet e klientëve u transformua në një domen të veçantë. Për të rritur performancën, u përdor modeli arkitektonik të arkitekturës domain.
Sistemi është e ndarë në fusha, ngarkesa është e shpërndarë dhe është siguruar qëndrueshmëria. Për më tepër, është realizuar puna me arkitekturën e shpërndarë.
Ădo gjĂ« tjetĂ«r Ă«shtĂ« zgjidhje nĂ« nivelin enterprise. NĂ« depozitat e thirrjeve â 2 miliard nĂ« ditĂ«, 60 miliard nĂ« muaj. NdonjĂ«herĂ« duhet t'i ripĂ«rllogarisim ato pĂ«r muajin, dhe Ă«shtĂ« mĂ« mirĂ« tĂ« shpejtojmĂ«. Monitorimi financiar ështĂ« ata 300 milion qĂ« vazhdimisht rriten dhe rriten: abonentĂ«t shpesh lĂ«vizin midis operatorĂ«ve, duke e rritur kĂ«tĂ« pjesĂ«.
Komponenti më telekomunikues i lidhjes mobile është tarifikimi në kohë reale. Këto janë sistemet që ju lejojnë të telefononi ose jo, marrin vendimin në kohë reale. Këtu ngarkesa është 30,000 transaksione në sekondë, por duke marrë parasysh rritjen e transmetimit të të dhënave ne planifikojmë 250,000 transaksione, dhe prandaj jemi shumë të interesuar për Tarantool.
Imazhi i mëparshëm tregon ato fusha ku ne kemi ndërmend të aplikojmë Tarantool. Vetë CRM, sigurisht, është më i gjerë dhe ne kemi ndërmend ta aplikojmë atë në bërthamën e tij.
Shifra jonĂ« e llogaritur TTH nĂ« 100 milion abonentĂ« mĂ« shqetĂ«son si arkitekt â çfarĂ« do tĂ« ndodhte nĂ«se do tĂ« ishim 101 milion? PĂ«rsĂ«ri do tĂ« duhej gjithçka tĂ« rregullohej? PĂ«r tĂ« parandaluar njĂ« gjĂ« tĂ« tillĂ«, ne pĂ«rdorim cache, duke rritur gjithashtu disponueshmĂ«rinĂ«.
Në tërësi, ekzistojnë dy qasje për përdorimin e Tarantool. E para është ndërtimi i të gjitha cache-ve në nivelin e mikroshërbimeve.Sa e kuptoj unë, ky është drejtimi që po ndjek VimpelCom, duke krijuar një cache për klientët.
Ne kemi mĂ« pak varĂ«si nga shitĂ«sit, duke ndryshuar bĂ«rthamĂ«n BSS, prandaj kemi njĂ« registrim tĂ« vetĂ«m tĂ« klientĂ«ve tashmĂ« nga kutia. Por ne duam ta zgjerim atĂ«. Prandaj, ne zbatojmĂ« njĂ« qasje pak mĂ« ndryshe â ndĂ«rtojmĂ« cache nĂ« brendĂ«si tĂ« sistemeve..
Kështu, ka më pak asinkroni - një sistem përgjigjet për cache-in dhe për burimin kryesor master.
Kjo qasje Ă«shtĂ« pĂ«rputhĂ«se me modelin e Tarantool me skeletin transaksional, kur pĂ«rditĂ«sohen vetĂ«m pjesĂ«t qĂ« kanĂ« tĂ« bĂ«jnĂ« me pĂ«rditĂ«simet, pra ndryshimet e tĂ« dhĂ«nave. Ădo gjĂ« tjetĂ«r mund tĂ« ruhet diku tjetĂ«r. Nuk ka njĂ« liqen tĂ« dhĂ«nash tĂ« madh, qĂ« nuk menaxhohet dhe as njĂ« cache global tĂ« pa menaxhuar. Cache-t projektohen pĂ«r sistemin, ose pĂ«r produktet, ose pĂ«r klientĂ«t, ose pĂ«r tĂ« lehtĂ«suar jetĂ«n nĂ« shĂ«rbim. Kur njĂ« abonent i shqetĂ«suar pĂ«r cilĂ«sinĂ« telefonon, dĂ«shiron ta shĂ«rbejĂ« atĂ« me cilĂ«si.
RTO dhe RPO
NĂ« IT ekzistojnĂ« dy terma â RTO dhe RPO.
Objektivi i kohĂ«s sĂ« rikuperimit â Ă«shtĂ« koha e rikuperimit tĂ« shĂ«rbimit pas njĂ« ndĂ«rprerjeje. RTO = 0 do tĂ« thotĂ« se edhe nĂ«se diçka dĂ«shton, shĂ«rbimi vazhdon tĂ« funksionojĂ«.
Objektivi i pikĂ«s sĂ« rikuperimit â Ă«shtĂ« koha e rikuperimit tĂ« tĂ« dhĂ«nave, sa tĂ« dhĂ«na mund tĂ« humbasim pĂ«r njĂ« periudhĂ« tĂ« caktuar. RPO = 0 do tĂ« thotĂ« se ne nuk humbasim tĂ« dhĂ«na.
Detyra për Tarantool
Le të provojmë të zgjidhim detyrën për Tarantool.
E dhënë: një karrocë kërkesash që është e njohur për të gjithë, për shembull, në Amazon ose diku tjetër. Kërkohet që karroca të funksionojë 24 orë, 7 ditë në javë, ose 99.99% të kohës. Porositë që na vijnë duhet të mbajnë një rend, sepse nuk mund të lidhim ose shkëputim lidhjen me klientin në mënyrë haotike - gjithçka duhet të jetë strikte. Abonimi i mëparshëm ndikon në atë të ardhshëm, prandaj të dhënat janë të rëndësishme - asgjë nuk duhet të humbasë.
Zgjidhja. Mund të provojmë të zgjidhim me forcë dhe të pyesim zhvilluesit e DB, por detyra nuk zgjidhet matematikisht. Mund t'i kujtojmë teoremave, ligjeve të ruajtjes, fizikës kuantike, por përse - e pamundshme për t'u zgjidhur në nivelin e DB.
Këtu funksionon qasja e vjetër klasike arkitektonike - është e nevojshme të dihet mirë fusha e temës dhe me atë të zgjidhim këtë enigmë.
Zgjidhja jonë: krijojmë një regjistër të shpërndarë të kërkesave në Tarantool - një kluster gjeo-shpërndarë. Në diagram janë tre qendra të ndryshme të përpunimit të të dhënave - dy para Uraleve, një pas Uraleve, dhe ne shpërndajmë të gjitha kërkesat në këto qendra.
Netflix, i cili tani konsiderohet si një nga liderët në IT, deri në vitin 2012 kishte vetëm një DC. Më 24 Dhjetor, në prag të Krishtlindjes katolike, ky DC ndaloi. 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 DC në bregun perëndimor-lindor dhe një në Evropën perëndimore.
Ne fillimisht ndërtojmë një zgjidhje geoshpërndarëse - na intereson qëndrueshmëria.
Pra, kemi një kluster, por si të sillemi me RPO = 0 dhe RTO = 0? Zgjidhja është e thjeshtë, dhe varet nga tema.
ĂfarĂ« Ă«shtĂ« e rĂ«ndĂ«sishme nĂ« kĂ«rkesa? Dy pjesĂ«: ndĂ«rtimi i karrocĂ«s PARA vendosjes sĂ« vendimit pĂ«r blerje, dhe PASI. Pjesa PARA nĂ« telekom zakonisht quhet kapja e porosisĂ« ose negocimi i porosisĂ«NĂ« telekomunikim, kjo mund tĂ« jetĂ« shumĂ« mĂ« e komplikuar se nĂ« njĂ« dyqan online, sepse aty do tĂ« duhet tĂ« shĂ«rbejmĂ« klientin, t'i ofrojmĂ« 5 alternativa, dhe e gjitha ndodh pĂ«r njĂ« kohĂ«, por shporta mbushet. NĂ« kĂ«tĂ« moment, njĂ« dĂ«shtim Ă«shtĂ« i mundshĂ«m, por kjo nuk Ă«shtĂ« e frikshme, sepse ndodh nĂ« njĂ« modĂ« interaktive nĂ«n mbikĂ«qyrjen e njĂ« personi.
Nëse Qendra të Dhënash e Moskës papritmas dështojnë, atëherë duke u kaluar automatikisht në një Qendër të Dhënash tjetër, ne do të vazhdojmë punën. Teoretikisht mund të humbasim një produkt në shportë, por ju e shihni këtë, e plotësoni përsëri shportën dhe vazhdoni punën. Në këtë rast, RTO = 0.
Po ashtu, ka njĂ« mundĂ«si tjetĂ«r: kur ne shtypim «submit», duam qĂ« tĂ« dhĂ«nat tĂ« mos humbasin. Nga kjo pikĂ« fillon tĂ« funksionojĂ« automatikja â kjo Ă«shtĂ« tashmĂ« RPO = 0. PĂ«rdorimi i kĂ«tyre dy modeleve tĂ« ndryshme nĂ« njĂ« rast mund tĂ« jetĂ« thjesht njĂ« klaster gjeo-distribuar me njĂ« mjeshtĂ«r tĂ« kalueshĂ«m, ndĂ«rsa nĂ« rastin tjetĂ«r ndonjĂ« shĂ«nim me kuorum. Modelet mund tĂ« variojnĂ«, por ne zgjidhim problem.
MĂ« pas, duke pasur njĂ« regjistĂ«r tĂ« shpalljeve tĂ« shpĂ«rndara, ne gjithashtu mund tĂ« shkallĂ«zojmĂ« gjithçka â tĂ« kemi shumĂ« menaxherĂ« dhe ekzekutorĂ« qĂ« i qasen kĂ«tij regjistri.
Cassandra dhe Tarantool së bashku
Ka edhe njĂ« rast tjetĂ«r â «vitrina e bilanceve». Aty Ă«shtĂ« rast interesant pĂ«r pĂ«rdorimin e pĂ«rbashkĂ«t tĂ« Cassandra dhe Tarantool.
Ne pĂ«rdorim Cassandra, sepse 2 miliardĂ« thirrje nĂ« ditĂ« â nuk janĂ« njĂ« kufi, dhe do tĂ« bĂ«hen mĂ« shumĂ«. MarketerĂ«t e duan tĂ« analizojnĂ« trafikun sipas burimeve, duke u shfaqur gjithnjĂ« e mĂ« shumĂ« detaje nga rrjetet sociale, pĂ«r shembull. TĂ« gjitha kĂ«to rritin historinĂ«.
Cassandra lejon që të shkallëzohet horizontalisht në çdo volum.
Ne ndihemi rehat me Cassandra, por ajo ka njĂ« problem â nuk Ă«shtĂ« e mirĂ« pĂ«r lexim. NdĂ«rsa pĂ«r shkrimin Ă«shtĂ« shumĂ« mirĂ«, 30,000 nĂ« sekondĂ« nuk Ă«shtĂ« problem â problemi Ă«shtĂ« nĂ« lexim.
Prandaj erdhi tema e cache-it, dhe ne po ashtu zgjidhëm problemin tjetër: ekziston një rast i vjetër tradicional, kur pajisjet nga switch-i nga tarifimi online vijnë në skedarë që ne i ngarkojmë në Cassandra. Ne luftuam me problemin e ngarkimit të besueshëm të këtyre skedarëve, madje përdorëm sipas rekomandimit të menaxherit të IBM transferimin e skedarëve - ka zgjidhje të tilla që menaxhojnë efektivisht transferimin e skedarëve duke përdorur protokollin UDP, për shembull, në vend të TCP. Kjo është mirë, por përsëri kalojmë minuta, dhe derisa të ngarkohet gjithçka, operatori në call center nuk mund të përgjigjet klientit për atë që ndodhi me bilancin e tij - duhet të pritet.
Që kjo të mos ndodhë, ne përdorim rezervë funksionale paralel. Kur dërgojmë një ngjarje përmes Kafka në Tarantool, duke riporaksuar agregatet në kohë reale, për shembull, për sot, marrim cache-balancet, i cili mund të japë bilance me çdo shpejtësi, për shembull, 100 mijë transaksione në sekondë dhe ato të njëjtat 2 sekonda.
Qëllimi është që pas përfundimit të thirrjes, brenda 2 sekondash, në llogarinë personale të jetë jo vetëm bilanci i ndryshuar, por edhe informata se pse ai u ndryshua.
PĂ«rfundim
Këto ishin 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.
Konsulentët nga BCG ose McKinsey, Accenture ose IBM tashmë kanë të 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ë një vend të merituar në stackun tonë teknologjik dhe do të zëvendësojë shumë teknologji ekzistuese. Jemi në fazën aktive të zhvillimit të këtij projekti.
Referati i Olegut dhe Andrey-t është një nga më të mirët në Konferencën Tarantool të vitit të kaluar, dhe më 17 qershor Oleg Ivlev do të flasë në  me referatin . Gjithashtu nga MegaFon do të flasë Alexander Deulin me referatin . Do të mësojmë se çfarë ka ndryshuar, cilat plane janë realizuar. Bashkohuni - konferenca është falas, vetëm duhet të . Të gjitha dhe programi i konferencës është formuar: raste të reja, përvoja të reja të përdorimit të Tarantool, arkitektura, enterprise, tutoriale dhe mikroshërbime.
Burimi: habr.com
