Uue põlvkonna arveldusarkitektuur: transformatsioon üleminekul Tarantoolile

Miks on sellisel korporatsioonil nagu MegaFon Tarantool arvelduses? Tundub, et tavaliselt toob teenusepakkuja ühe suure kasti, ühendab selle vooluvõrku - ja voilà, arveldus tulebki! Kunagi nii oligi, kuid nüüd on see ajalooline tagasitulek, ja sellised dinosaurused on juba välja surnud või suremas. Algselt oli arveldus süsteem arveteks - arve koostaja või kalkulaator. Kaasaegses telekommunikatsioonis on see kogu kliendisuhete elutsükli automatiseerimise süsteem, alates lepingu sõlmimisest kuni selle lõpetamiseni, sealhulgas reaalajas tariifimine, maksete vastuvõtt ja veel palju muud. Arveldus telekommunikatsiooniettevõtetes sarnaneb sõjasüsteemiga - suur, võimas ja relvastatud varustusega.

Kuidas aga Tarantool siia mahtub? Selgitavad Oleg Ivlev ja Andrei Knyazev. Oleg on ettevõtte MegaFon peamine arhitekt, kellel on tohutu rahvusvaheline kogemus, Andrei on ärisüsteemide juht. Nende ettekande dekodeerimisest Tarantooli konverentsil 2018 saate teada, miks on R&D ettevõtetes vajalik, mis on Tarantool, kuidas vertikaalse skaleerimise ummik ja globaliseerumine kujunesid selle andmebaasi ilmnemise eeltingimusteks, samuti tehnoloogilised väljakutsed, arhitektuuri transformatsioon ja kuidas MegaFoni tehnoloogia kogum sarnaneb Netflixi, Google'i ja Amazoni omaga.

Projekt „Üks arveldus“

Projekt, millest jutt käib, on nimetatud „Üks arveldus“. Just selles näitas Tarantool oma parimaid omadusi.

Hi-End riistvara jõudlus ei suutnud sammu pidada tellijate arvu ja teenuste kasvu korral, oodati edasist kasvu M2M, IoT kaudu, samuti filiaalide eripärad halvendavad toote turule toomise aega. Ettevõte otsustas luua ühtse ärisüsteemi ainulaadse maailmatasemel moodulaarse arhitektuuriga, asendades 8 erinevat arveldussüsteemi.

MegaFon on kaheksa ettevõtet ühes. 2009. aastal lõpetati ümberkorraldamine: filiaalid üle kogu Venemaa liideti ühte ettevõttesse OAO „MegaFon“ (praegu PAO). Nii tekkis ettevõttes 8 arveldussüsteemi, millel on oma „kohandatud“ lahendused, filiaalide omadused ja erinev organisatsiooniline struktuur, IT ja turundus.

Kõik oli hästi, kuni tuli käivitada üks ühine föderaalne toode. Siit hakkasid ilmnema hulgaliselt keerukusi: kellegil on ümberarvutamine ülespoole, kellegil allapoole, ja kellegil - keskmise aritmeetilise järgi. Selliseid hetki on tuhandeid.

Hoolimata sellest, et arvelduse süsteemi versioon on üks, tarnija üks, seaded olnud nii erinevad, et neid kokku liimida oli aeganõudev. Proovisime nende arvu vähendada ja sattusime teise probleemile, mis on paljudele korporatsioonidele tuttav.

Vertikaalne skaleerimine. Isegi kõige paremad toona olemas olnud riistvara ei rahuldanud vajadusi. Tööks kasutati Hewlett-Packardi seadmeid, Superdome Hi-End seeriast, kuid need ei suutnud rahuldada isegi kahe filiaali vajadusi. Soovisime horisontaalset skaleerimist ilma suurte opereerimiskuludeta ja kapitaliinvesteeringuteta.

Ootus abonentide ja teenuste arvu kasvu. Konsultandid on pikka aega toonud telekommunikatsioonimaailma lugusid IoT ja M2M kohta: tulevad ajad, mil igas telefonis ja triikrauas on sim-kaart, ja külmikus kaks. Täna on meil üks abonentide arv, kuid lähitulevikus on neid kümneid kordi rohkem.

Tehnoloogilised väljakutsed

Need neli põhjust viisid meid tõsiste muutuste poole. Oli valik süsteemi moderniseerimise ja nullist projekteerimise vahel. Mõtlesime kaua, tegime tõsiseid otsuseid, korraldasime hanked. Lõpuks otsustasime projekteerida algusest peale ning asusime huvitavatele väljakutsetele - tehnoloogilistele väljakutsetele.

Skaleeritavus

Kui varem oli, ütleme tinglikult, 8 arvelduse süsteemi 15 miljoni abonendiga, siis nüüd pidi tulema 100 miljonit abonenti ja rohkem — koormus on oluliselt suurem.

Meie mõõtmed hakati võrdlema suurte internetimängijatega, nagu Mail.ru või Netflix.

Aga edasine liikumine koormuse ja abonentide arvu suurendamise suunas esitas meile tõsiseid ülesandeid.

Meie piiramatust riigist

Kaliningradi ja Vladivostoki vahel 7500 km ja 10 ajavööndit. Valguse kiirus on lõplik ja sellistel vahemaadel on viivitused juba olulised. 150 ms kõige paremates kaasaegsetes optilistes kanalites on liiga palju reaalajas arveldamiseks, eriti selliseks, nagu praegu on telekommunikatsioonis Venemaal. Lisaks peab olema uuendamine ühe tööpäeva jooksul, ja erinevate ajavöönditega, see on probleem.

Me ei paku lihtsalt tellimuspõhiseid teenuseid, meil on keerulised plaanid, paketid ja erinevad modifikaatorid. Me peame mitte ainult lubama või keelama tellijal rääkida, vaid andma neile kindla kvoodi — arvestama kõnesid ja toiminguid reaalajas nii, et nad ei märkaks.

Talitluskatkestustunne

See on tsentraliseerimise tagajärg.

Kui me kogume kõik tellijad ühte süsteemi, siis võivad igasugused hädaolukorrad ja katastroofid olla ettevõtte jaoks hävitavad. Seetõttu projekteerime süsteemi nii, et välistame hädaolukordade mõju kogu tellijabaasile.

See on jälle tagasilükkamine vertikaalsest skaleerimisest. Kui me läksime horisontaalsesse skaleerimisse, suurenes serverite arv sadadelt tuhandeteni. Nendega tuleb hallata ja luua vastastikune asendatavus, automatiseerida IT-infrastruktuuri varundamine ja taastada jaotatud süsteem.

Meie ees seisis selline huvitav väljakutse. Projekteerisime süsteemi ja sel hetkel püüdsime leida maailma parimat kogemust, et kontrollida, kui palju me oleme trendiga, kui palju järgime tipptasemel tehnoloogiaid.

Maailmakogemus

Üllatav, kuid maailmatasemel telekommunikatsioonis ei leidnud me ühtegi viidatud näidet.

Euroopa jääb maha tellijate arvu ja mastaabi poolest, USA — oma hindade taseme poolest. Vaatasime midagi Hiinas ja leidsime midagi Indiast ning kaasasime spetsialiste Vodafone India'lt.

Arhitektuuri analüüsimiseks kogusime Dream Teami, mille eesotsas oli IBM — arhitektid erinevatest valdkondadest. Need inimesed suutsid adekvaatselt hinnata, mida me teeme, ja tuua meie arhitektuuri teatud teadmisi.

Mastaap

Mõned numbrid illustratsiooniks.

Me projekteerime süsteemi 80 miljonile tellijale, varuga miljardile. Nii kõrvaldame tulevased piirangud. See ei ole sellepärast, et kavatseksime Hiinat vallutada, vaid IoT ja M2M surve tõttu.

300 miljonit dokumenti töödeldakse reaalajas. Kuigi meil on 80 miljonit tellijat, tegeleme ka potentsiaalsete klientidega ja nendega, kes on meist lahkunud, kui on vaja sissenõudmist. Seetõttu on tegelikud mahud märgatavalt suuremad.

2 miljardit tehingut muudavad saldo igapäevaselt — need on maksed, arvestused, kõned ja muud sündmused. 200 TB andmed muutuvad aktiivselt, veidi aeglasemalt muudavad 8 PB andmed, ja see ei ole arhiiv, vaid elavad andmed ühes arveldamises. Skaala andmekeskuste lõikes — 5 tuhat serverit 14 asukohas.

Tehnoloogiline tipptehnoloogia

Kui me kavandasime arhitektuuri ja asusime süsteemi kokku panema, importisime endale kõige huvitavamad ja uuenduslikumad tehnoloogiad. Tulemuseks sai tehnoloogiline tipptehnoloogia, mis on tuttav igaühele interneti mängijale ja korporatsioonidele, kes arendavad suurt koormust kannatavaid süsteeme.

Tehnoloogiline baas on sarnane teiste suurte mängijate, nagu Netflix, Twitter, Viber, omadega. See koosneb 6 komponendist, kuid soovime seda lühendada ja ühtlustada.

Paindlikkus on hea, kuid suures korporatsioonis ei saa ilma ühtlustamiseta hakkama.

Me ei kavatse Oracle'it Tarantooliga asendada. Suurtes ettevõtetes on see utoopia või ristileitmine, mis kestab 5-10 aastat ja mille lõpptulemust on raske ennustada. Kuid Cassandra ja Couchbase'i võib kindlasti Tarantooliga asendada, ja me püüame seda teha.

Miks Tarantool?

On 4 lihtsat kriteeriumi, miks me selle andmebaasi valisime.

Kiirus. Me tegime koormustestid MegaFoni tööstussüsteemides. Tarantool võitis — see näitas parimat jõudlust.

Ei saa öelda, et teised süsteemid ei rahuldaks MegaFoni vajadusi. Praegused mälupõhised lahendused on nii võimsad, et sellest piisab ettevõtte jaoks. Kuid me tahame tegeleda liidriga, mitte kellelegi, kes on sabas, sealhulgas koormustesti osas.

Tarantool katab ettevõtte vajadused isegi pikaajalises perspektiivis.

TCO kulu. Couchbase'i tugi MegaFoni mahus maksab kosmilisi summasid, Tarantooliga on olukord aga palju meeldivam ja funktsionaalsus on nende vahel sarnane.

Veel üks meeldiv omadus, mis mõjutas meie valikut — Tarantool töötab mäluga paremini kui teised andmebaasid. See saavutab maximaalne efektiivsus.

Usaldusväärsus. MegaFon investeerib usaldusväärsusse, nagu keegi teine. Seega, kui me Tarantoolile pilku peale viskasime, mõistsime, et peame selle vastama meie nõudmistele.

Me investeerisime oma aega ja raha ning koos Mail.ru'ga lõime ettevõtte versiooni, mida kasutatakse juba mitmes teises ettevõttes.

Tarantool-enterprise rahuldas meid täielikult turvalisuse, usaldusväärsuse ja logimise osas.

Partnerlus

Minu jaoks on kõige olulisem — otsene kontakt arendajaga. See on täpselt see, millega Tarantooli meeskond meid võitis.

Kui sa tuled mängija juurde, eriti kui see töötab ankurklientidega, ja ütled, et sul on vaja, et andmebaas suudaks seda, seda ja seda, vastab ta tavaliselt:

— Hästi, kirjutage nõuded selle paki põhja — kunagi, ilmselt, jõuame nende juurde.

Paljusid on lähituleviku 2-3 aasta tegevuskavad, ja sinna inteerumine on praktiliselt võimatu, aga Tarantooli arendajad on avatuses ülimalt köitvad, ja mitte ainult MegaFoniga, ja kohandavad oma süsteemi kliendi järgi. See on lahe ja meile meeldib see väga.

Kus me Tarantooli rakendasime

Meie juures kasutatakse Tarantooli mitmes elemendis. Esiteks — pilootprojektis, mille me tegime aadressikatalooge süsteemi põhjal. Aegade alguses soovisime, et sellest saaks süsteem, mis sarnaneb Yandex.Maps ja Google Maps, aga tuli välja mõnevõrra teisiti.

Näiteks, aadressikataloog müügiliideses. Oracle'il võtab vajaliku aadressi leidmine aega 12-13 sekundit — ebamugavad numbrid. Kui me lülitume Tarantoolile, asendame Oracle'i teise andmebaasiga konsoolis, ja teeme sama otsingu, saame kiirusetõusu 200 korda! Linn ilmub ekraanile pärast kolmandat tähte. Praegu kohandame liidest, et see juhtuks pärast esimest. Siiski, vastamisaeg on täiesti teine — juba millisekundid, mitte sekundid.

Teine rakendus — moes teema, mida nimetatakse kahekordseks IT-ks. Sellepärast räägivad konsultandid igal pool, et ettevõtted peaksid sinna liikuma.

Siin on infrastruktuuri kiht, selle kohal domeenid, näiteks arveldussüsteem nagu telekomis, ettevõtte süsteemid, ettevõtte aruandlus. See on alus, mida ei tohi puudutada. Loomulikult võib, aga paranoia tasemel kvaliteedi tagamiseks, sest see toob ettevõttele raha.

Edasi läheb mikroteenuste kiht — see, mis diferentseerib operaatorit või muud mängijat. Mikroteenuseid saab kiiresti luua erinevate vahemälu alusel, väljatõstes andmeid erinevatest domeenidest. Siin on katsetamiseks ruumi — kui midagi ei õnnestunud, sulgesid ühe mikroteenuse, avasid teise. See tagab tõeliselt suurenenud turuletoomise aja ja suurendab ettevõtte usaldusväärsust ja kiirus.

Mikroteenused on ilmselt Tarantooli peamine roll MegaFonis.

Kus plaanime Tarantooli rakendada

Kui võrrelda meie eduka arvelduse projekti Deutsche Telekomi, Связьком ja Vodafone India transformatsiooniprogrammidega, on see üllatavalt dünaamiline ja loominguline. Selle projekti elluviimise protsessis mitte ainult ei transformeeritud MegaFon ja selle struktuur, vaid tekkis ka Mail.ru Tarantool-enterprise ning meie tarnija Nexign (endine „Peterservice”) - BSS Box (kastilahenduse arveldamise lahendus).

See on mingil mõttes ajalooline projekt Venemaa turul. Seda võib võrrelda Frederic Brooksi raamatus "Müüdiline meeskuu" kirjeldatuga. Tol ajal, 60. aastatel, kaasas IBM uusi peajõudude operatsioonisüsteemi OS/360 arendamiseks 5000 inimest. Meil on vähem - 1800, aga meie teeme seda efektiivsemalt, kasutades avatud lähtekoodi ja uusi lähenemisviise.

Allpool on näidatud arvelduse domeenid või, kui rääkida laiemalt, ärisüsteemid. Enterprise'i inimesed tunnevad CRM-i hästi. Teised süsteemid peaksid olema kõigil: Open API, API Gateway.

Open API

Vaadakem jälle numbreid ja seda, kuidas Open API praegu töötab. Selle koormus on 10,000 tehingut sekundis.Kuna plaanime aktiivselt arendada mikroteenuste kihti ja ehitada MegaFoni avalikku API-d, siis ootame tulevikus selles osas rohkem kasvu. 100,000 tehingut kindlasti tuleb..

Ma ei tea, kas saame Mail.ru SSO-ga võrrelda - neil on vist 1,000,000 tehingut sekundis. Meie jaoks on nende lahendus äärmiselt huvitav ja plaanime omandada nende kogemusi - näiteks, koostada SSO funktsionaalne varukoopia Tarantooli abil. Praegu tegelevad Mail.ru arendajad sellega meie juures.

CRM

CRM - need on 80 miljonit abonenti, keda tahame viia miljardi lähedale, kuna meil on juba 300 miljonit dokumenti, mis hõlmavad kolmeaastast ajalugu. Ootame tõeliselt uusi teenuseid ja siin kasvupunkt on ühendatud teenused.See on sfäär, mis kasvab, kuna teenuseid tuleb aina rohkem. Seega on vajalik ajalugu, me ei soovi sellel komistada.

Ise arveldus, kliendi tasumata arvete töötlemine on transformeerunud eraldi domeeniks.Täiendava tootlikkuse nimel rakendati domeeni arhitektuuri arhitektuurimustrit..

Süsteem on jagatud domeenideks, koormus on jaotatud ja tagatud on tõrketaluvus. Lisaks on tehtud tööd hajutatud arhitektuuriga.

Kõik muu on ettevõtte taseme lahendused. Kõnede salvestamisel on 2 miljardit päevas, 60 miljardit kuus. Mõnikord tuleb neid kuus ümber lugeda, ja parem on kiiresti. Finantsmonitooring on just need 300 miljonit, mis pidevalt kasvavad: abonendid jooksevad sageli operaatorite vahel, suurendades seda osa.

Kõige telekommunikatsiooniga seotud komponent mobiilsides on online-tariifimine. Need on süsteemid, mis võimaldavad teil helistada või mitte helistada, teevad otsuseid reaalajas. Siin on koormus 30 000 tehingut sekundis, kuid andmeside edasise kasvu arvesse võttes plaanime 250 000 tehingut, seega oleme väga huvitatud Tarantoolist.

Eelmine pilt on need domeenid, kus plaanime Tarantooli rakendada. CRM on muidugi laiem ja plaanime seda rakendada tuumprotsessis.

Minu jaoks arhitektina tekitab meie arvutatud näitaja TTH 100 miljonit abonenti segadust – ent mis siis, kui 101 miljonit? Kas peame taas kõik ümber tegema? Sellise olukorra vältimiseks rakendame vahemälusid, tõstes samal ajal kättesaadavust.

Üldiselt on Tarantooli rakendamiseks kaks lähenemist. Esimene on ehitada kõik vahemälud mikroteenuste tasemele.Nii palju kui mina aru saan, läheb sel teel VimpelCom, luues klientide vahemälu.

Meie oleme vähem sõltuvad tarnijatelt, muudame BSS-i tuuma, seega on meil juba valmis klientide kaust. Kuid me tahame seda laiendada. Seetõttu rakendame veidi teistsugust lähenemist – teeme vahemälusid süsteemide sees..

Nii on vähem desünkroniseerimist – üks süsteem vastutab nii vahemälu kui ka põhiallikate eest.

Meetod sobib hästi Tarantooli lähenemisega, kus tehingute raamistik uuendab ainult osi, mis puudutavad uuendusi, st andmete muutusi. Kõike muud saab hoida kuskil mujal. Ei ole tohutut andmejärve, haldamata globaalset vahemälu. Vahemälud projekteeritakse süsteemi, toodete või klientide järgi, või et elu oleks täiendavteenindusele lihtsam. Kui helistab kvaliteedi üle kurvastav abonent, tahaks teda kvaliteetselt teenindada.

RTO ja RPO

IT-s on kaks mõistet – RTO ja RPO.

Recovery time objective — see taastumise aeg pärast riket. RTO = 0 tähendab, et isegi kui midagi juhtub, jätkab teenus töötamist.

taastumise punkti eesmärk — see on andmete taastamise aeg, kui palju andmeid me saame kuskil ajavahemikus kaotada. RPO = 0 tähendab, et me ei kaota andmeid.

Ülesanne Tarantoolis

Proovime lahendada ülesande Tarantoolile.

Antud: kõigile arusaadav ostukorv, näiteks Amazonis või mujal. Vajaliku on see, et ostukorv töötaks 24 tundi 7 päeva nädalas, või 99,99% ajast. Tellimused, mis meile tulevad, peavad säilitama järjekorra, kuna me ei saa kaootiliselt kliendi side sisse või välja lülitada — kõik peab olema rangelt järjestatud. Eelmise tellimuse mõju järgnevatele, seega on andmed olulised — mitte midagi ei tohi kaduda.

Lahendus. Võib proovida lahendada otseselt ja küsida andmebaasi arendajatelt, kuid probleem matemaatiliselt ei lahendata. Võib meenutada teoreeme, säilimise seadusi, kvantfüüsikat, kuid miks — seda ei saa lahendada andmebaasi tasandil.

Siin töötab vana hea arhitektuuri lähenemisviis — tuleb hästi tundma õppida valdkonda ja selle abil see mõistatus lahendada.

Meie lahendus: loome jaotatud taotluste registri Tarantoolis — geograafiliselt jaotatud kluster. Skeemil on need kolm erinevat andmekeskust — kaks Uurali ees ja üks Uurali taga, ning me jaotame kõik taotlused nende keskuste vahel.

Netflixil, mis on praegu üks IT valdkonna juhte, oli 2012. aastani ainult üks andmekeskus. Katoliikliku jõulupüha eelõhtul, 24. detsembril, see andmekeskus kukkus. Kanada ja USA kasutajad jäid ilma oma lemmikfilmidest, olid sellest väga pettunud ja kirjutasid sotsiaalmeedias sellest. Nüüd on Netflixil kolm andmekeskust lääne-idapoolsel rannikul ja üks läänes Euroopas.

Me ehitame algusest peale geograafiliselt jaotatud lahendust — meile on oluline riketekindlus.

Nii et meil on kluster, aga kuidas olla RPO = 0 ja RTO = 0? Lahendus on lihtne, sõltudes valdkonnast.

Mis on taotluste puhul oluline? Kaks osa: ostukorvi koostamine ENNE otsuse tegemist ostmise kohta, ja PEALE. Enne ostufaas peab telekommunikatsioonis tavaliselt olema tellimuse registreerimine või tellimuse läbirääkimineTelekommunikatsioonis on see sageli palju keerulisem kui veebipoes, kuna klienti tuleb teenindada, pakkuda 5 võimalust ja see kõik toimub mingil hetkel, kuid ostukorv täitub. Just sel hetkel võib juhtuda rike, kuid see ei ole hirmutav, kuna tegevus toimub interaktiivses režiimis inimese järelevalve all.

Kui Moskva andmekeskus ootamatult ebaõnnestub, saame automaatselt üle lülitada teise andmekeskusse ning me jätkame tööd. Teoreetiliselt võib ühes ostukorvis kaduda üks toode, kuid te näete seda, täiendate ostukorvi uuesti ja jätkate tööd. Sel juhul RTO = 0.

Samal hetkel on olemas ka teine võimalus: kui me vajutame "submit", siis tahame, et andmed ei kaoks. Sellest hetkest alates hakkab automaatika tööle – see on juba RPO = 0. Nende kahe erineva malli rakendamine ühes juhul võib olla lihtsalt geojaotatud klaster ühe lülitatava meistriga, teises juhul mõni kvoorumikirje. Mallid võivad varieeruda, kuid me lahendame probleemi.

Jätkates, omades jaotatud taotluste registrit, saame veelgi kõik seda skaleerida – omada palju tegijaid ja täitjaid, kes pöörduvad selle registri poole.

Cassandra ja Tarantool koos

On veel üks juhtum – "bilansi vitriin". Siin on tõeliselt huvitav juhtum Cassandra ja Tarantooli ühiseks kasutamiseks.

Kasutame Cassandrat, kuna 2 miljardit kõnet päevas ei ole piir ja neid tuleb veelgi rohkem. Turundajad armastavad jagada liiklust allikate kaupa, näiteks sotsiaalmeedia kohta tuleb juurde üha enam detaile. See kõik suurendab ajalugu.

Cassandra võimaldab horisontaalset skaleerimist kõigile mahtudele.

Me tunneme end Cassandraga mugavalt, kuid sellel on üks probleem – see pole lugemise jaoks hea. Kirjutamise osas on kõik korras, 30 000 sekundis pole probleem – probleem on lugemises.

Seetõttu tuli jutuks vahemälu ja me lahendasime samal ajal järgmise probleemi: on olemas vana traditsiooniline juhtum, kus varustus, mis tuleb lülitilt online-arvestusse, jõuab failidesse, mida me laadime Cassandrasse. Oleme võidelnud nende failide usaldusväärse laadimise probleemiga, kasutasime isegi IBM-i juhtkonna soovitust failide edastamiseks – on olemas sellised lahendused, mis haldavad failide edastamist tõhusalt, kasutades näiteks UDP-protokolli, mitte TCP-d. See on hea, aga ikkagi võtavad need minutid, ja me ei saa, kuni kõik on üle laaditud, operaator kõnekeskkonnas ei saa vastata kliendile, mis toimub tema bilansiga – tuleb oodata.

Selle vältimiseks kasutame paralleelset funktsionaalset reservi. Kui saadame sündmuse Kafka kaudu Tarantoolisse, ümber arvutades agregaate reaalajas, näiteks täna, siis saame bilansivahemälu, mis võib edastada bilansid mis tahes kiirusel, näiteks 100 tuhat tehingut sekundis ja sama 2 sekundiga.

Eesmärk on see, et pärast kõne sooritamist oleks isiklikus kabinetis juba 2 sekundi pärast mitte ainult muudetud saldo, vaid ka teave selle kohta, miks see muutus.

Kokkuvõte

Need olid Tarantooli kasutamise näited. Meile meeldis Mail.ru avatus, nende valmisolek arvestada erinevaid juhtumeid.

BCG, McKinsey, Accenture või IBM konsultantidel on raske meid millegagi uuega üllatada - paljusid asju, mida nad pakuvad, teeme me kas juba, oleme teinud või plaanime teha. Arvan, et Tarantool leiab meie tehnoloogilises kihis väärika koha ja asendab palju juba olemasolevaid tehnoloogiaid. Oleme aktiivses arendusfaasis selle projektiga.

Olegi ja Andrei ettekandega oli üks parimaid Tarantooli konverentsil mullu, ning juba 17. juunil esineb Oleg Ivlev T+ Konverentsil 2019 ettekandega „Miks on Tarantool ettevõttes vajalik“. Samuti esindab MegaFon Alexander Deulin ettekandega „Tarantooli vahemälud ja Oracle'i replikatsioon“. Saame teada, mis on muutunud, milliseid plaane on õnnestunud ellu viia. Liituge - konverents on tasuta, tuleb ainult registreeruda. Kõik ettekanded on aktsepteeritud ja konverentsi programm on moodustatud: uued juhtumid, uus kogemus Tarantooli kasutamisest, arhitektuur, ettevõte, õpetused ja mikroteenused.

Allikas: habr.com