Uue põlvkonna arvepidamisarchitektuur: ümberkujundamine Tarantooli kasutuselevõtuga

Miks vajab selline ettevõte nagu MegaFon Tarantooli arvelduse jaoks? Kaugelt vaadates tundub, et tavaliselt tuleb tarnija, toob suure kasti, ühendab pistiku vooluvõrku — ja arveldamine ongi kohal! Kunagi oli see tõsi, kuid täna on see arhaika ning sellised dinosaurused on juba välja surnud või suremas. Alguses oli arveldamine süsteem, mis esitas arveid — arve loendur või kalkulaator. Kaasaegses telekommunikatsioonis on see kogu juurdepääsu elutsükli automatiseerimise süsteem, alates lepingute sõlmimisest kuni lõpetamiseni, sealhulgas reaalajas arveldamine, maksete vastuvõtt ja veel palju muud. Arveldamine telekomifirmades on sarnane sõjamasinale — suurele, võimsale ja relvadega kaetud.

Kuidas seondub siia Tarantool? Sellele vastavad Oleg Ivlev ja Andrei Knyazev. Oleg on ettevõtte peaarhitekt MegaFon suurte rahvusvaheliste kogemustega, Andrei on ärisüsteemide direktor. Nende ettekande salvestus Tarantool Conference 2018 Te saate teada, miks on R&D ettevõtetes vajalik, mis on Tarantool, kuidas vertikaalse skaleerimise ummik ja globaliseerumine said selle andmebaasi ilmumise eeltingimusteks ettevõttes, tehnilised väljakutsed, arhitektuuri transformatsioon ning millega MegaFoni tehnoloogia virn sarnaneb Netflixile, Google'ile ja Amazonile.

Ühtne arveldussüsteem

Projekt, millest juttu tuleb, nimetatakse «Ühtne arveldussüsteem». Just selles on Tarantool näidanud oma parimaid omadusi.

High-End seadmete jõudlus ei pidanud ajalise kasvuga sammu abonenndite arvu ja teenuste arvu suurendamisega. Oodati, et abonenndite ja teenuste arv kasvab tänu M2M-le, IoT-le, ja kohalikud eripärad halvendasid time-to-market'i. Ettevõte otsustas luua ainulaadse moodulaarse arhitektuuriga maailmatasemel äri süsteemi kaheksa erineva arveldussüsteemi asemel.

MegaFon on kaheksa ettevõtet ühes. 2009. aastal toimus ümberkorraldus: kõik Venemaa filiaalid ühinesid ühtseks ettevõtteks OAO „MegaFon” (praegu PAO). Nii tekkis ettevõttes 8 arvelduse süsteemi, mis sisaldasid omaenda „kohandatud” lahendusi, filiaalide eripära ja erinevat organisatsioonilist struktuuri, IT ja turundust.

Kõik sujus hästi, kuni tuli käivitada üks ühtne föderaalne toode. Siit tekkis hulk keerukusi: kellelgi oli arvestus ülespoole ümardamisega, kellelgi allapoole, aga kellelgi - aritmeetilise keskmise järgi. Selliseid olukordi on tuhandeid.

Hoolimata sellest, et arvelduse süsteemi versioon on üks, üks tarnija, seadistused erinevad nii palju, et nende kokkuliimimine võtab kaua aega. Proovisime nende arvu vähendada ja sattusime teise probleemiga, mis on tuttav paljudele korporatsioonidele.

Vertikaalne skaleerimine. Isegi parim sel ajal olnud riistvara ei rahuldanud vajadusi. Töös kasutati Hewlett-Packardi seadmeid, Superdome Hi-End seeriat, kuid nende võimsus ei katnud isegi kahte filiaali. Soovisime horisontaalset skaleerimist ilma suurte opereerimiskulude ja kapitaliinvesteeringuteta.

Ooten kasvavast tellijate ja teenuste arvust. Konsultandid on juba ammu toonud telekommunikatsiooni maailma jutud IoT-st ja M2M-st: tulevad ajad, mil igas telefonis ja triikis on sim-kaart, ning külmkapis kaks. Täna on meil kindel arv tellijaid, aga lähitulevikus on neid kordades rohkem.

Tehnoloogilised väljakutsed

Need neli põhjust sundisid meid tõeliselt muutuma. Oli valik süsteemi täiendamise ja nullist projekteerimise vahel. Mõtlesime kaua, tegime tõsiseid otsuseid, mängisime hangetes. Lõpuks otsustasime projekteerida algusest peale ja püüdlesime huvitavate väljakutsete poole — tehnoloogilistele väljakutsetele.

Skaleeritavus

Kui varem oli, ütleme niimoodi, 8 arveldust 15 miljonile tellijale, siis praegu pidi saama 100 miljonit tellijat ja rohkem — koormus on kordades suurem.

Oleme muutunud võrreldavaks suurte internetimängijatega, nagu Mail.ru või Netflix.

Aga edasine liikumine koormuse ja tellijate arvu suurendamiseks tõi meile tõsised ülesanded.

Meie hiiglaslik riigi geograafia

Kaliningradi ja Vladivostoki vahel 7500 km ja 10 ajavööndit. Valguse kiirus on lõplik ja neil kaugustel on viivitused juba märkimisväärsed. 150 ms kõige tipptasemel modernsetes optilistes kanalites - see on palju real-time-tasumiseks, eriti selliseks nagu praegu telekomis Venemaal. Lisaks on vaja värskendada ühe tööpäeva jooksul, ja erinevate ajavöönditega - see on probleem.

Me ei teeni lihtsalt teenust maksu kaudu; meil on keerulised tariifid, paketid ja erinevad modifikaatorid. Meie peame mitte ainult lubama või keelama abonendil rääkida, vaid andma talle teatud kvoodi - arvestama kõnesid ja toiminguid reaalajas nii, et ta ei märkaks.

Katastroofitaluvus

See on keskse süsteemi teine külg.

Kui me kogume kõik abonendid ühte süsteemi, on kõik õnnetused ja katastroofid äritegevuse jaoks katastroofilised. Seetõttu projekteerime süsteemi nii, et välistada avariide mõju kogu abonendibaasile.

See, see on jälle tagasilükkamine vertikaalsest skaleerimisest. Kui me läksime horisontaalsesse skaleerimisse, suurendasime serverite arvu sadadest tuhandeteni. Nendega tuleb hallata ja luua vahetatavust, automaatselt varundada IT-infrastruktuuri ja taastada jaotatud süsteemi.

Ees seisis meil huvitav väljakutse. Me kavandasime süsteemi ja sel hetkel üritasime leida globaalseid tipptavasid, et kontrollida, kui palju oleme trendis, kui palju järgime uusimaid tehnoloogiaid.

Üks globaalne praktika

Imelik, kuid globaalsetes telekommunikatsioonides ei leidnud me ühtegi viidatud näidet.

Euroopa kukkus välja abonentide arvu ja ulatuse tõttu, USA oma pakettide taseme tõttu. Vaatasime midagi Hiinas, kuid leidsime ka Indiast ja palkasime spetsialiste Vodafone Indiast.

Arhitektuuri analüüsimiseks kogusime unistuste tiimi, mille eesotsas oli IBM — arhitektid erinevatest valdkondadest. Need inimesed suudavad adekvaatselt hinnata, mida me teeme, ja tuua meie arhitektuurisse kindlaid teadmisi.

Ulatus

Mõned numbrid illustreerimiseks.

Kavandame süsteemi 80 miljonile abonendile, varuga miljardile.. Nii eemaldame tulevased künnist. See ei ole sellepärast, et me plaanime Hiinat vallutada, vaid IoT ja M2M surve tõttu.

300 miljonit dokumenti töödeldakse reaalajas. Kuigi meil on 80 miljonit abonenti, tegeleme ka potentsiaalsete klientidega ja nendega, kes on meie juurest lahkunud, kui tuleb sissenõudmisega tegeleda. Seetõttu on tegelikud mahud märkimisväärselt suuremad.

2 miljardit tehingut muudavad taset iga päev — need on maksed, arvestused, kõned ja muud sündmused. 200 TB andmeid muutuvad aktiivselt, veidi aeglasemalt muutuvad 8 PB andmeid, ja see ei ole arhiiv, vaid elavad andmed ühes arveldamises. Skaala andmekeskustele — 5000 serverit 14 paiknemises.

Tehnoloogiline alus

Kui planeerisime arhitektuuri ja hakkasime süsteemi ehitama, importisime endale kõige huvitavamad ja tipptasemel tehnoloogiad. Tuli välja tehnoloogiline alus, mille tunnevad ära kõik internetimängijad ja korporatsioonid, kes loovad kõrge koormuse süsteeme.

Alus on sarnane teiste suurte mängijate, nagu Netflix, Twitter, Viber, omadele. See koosneb 6 komponendist, kuid me tahame seda lühendada ja ühtlustada.

Paindlikkus on hea, kuid suurtes korporatsioonides ei saa ilma ühtlustamiseta hakkama.

Me ei kavatse sama Oracle'i asendada Tarantooliga. Suurte ettevõtete reaalsuses on see utoopia või ristisõda, mis kestab 5-10 aastat ja mille tulemus pole teada. Kuid Cassandra ja Couchbase'i saab Tarantooliga täiesti asendada, ja me pürgime selle poole.

Miks Tarantool?

On neli lihtsat kriteeriumi, miks me valisime just selle andmebaasi.

Kiirus. Me tegime koormustestid Megafoni tööstussüsteemidel. Tarantool võitis - see näitas parimat jõudlust.

Ei saa öelda, et teised süsteemid ei rahuldaks Megafoni vajadusi. Praegused mälulahendused on nii võimsad, et ettevõtte varu on enam kui piisav. Kuid meile on huvitav tegeleda liidriga, mitte nende tagaolijatega, sealhulgas koormustestide osas.

Tarantool katab ettevõtte vajadused isegi pikaajalises perspektiivis.

TCO hind. Couchbase'i tugi Megafoni mahtudel maksab kosmilisi summasid, Tarantooliga on olukord aga palju meeldivam ja funktsionaalsuses on nad sarnased.

Veel meeldivam omadus, mis mõjutas meie valikut, on see, et Tarantool töötab mäluhalduse osas paremini kui teised andmebaasid. Ta näitab maksimaalset efektiivsust.

Usaldusväärsus. MegaFon investeerib usaldusväärsusesse tõenäoliselt rohkem kui keegi teine. Seetõttu, kui vaatasime Tarantooli, mõistsime, et peame tagama, et see vastaks meie nõudmistele.

Oleme investeerinud oma aega ja ressursse ning koos Mail.ru'ga lõime ettevõtte versiooni, mis on nüüdseks juba mõnedes teistes ettevõtetes kasutusel.

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

Partnerlus

Minu jaoks on kõige olulisem otsene kontakt arendajaga. Just see on see, millega Tarantooli tiim mind võitis.

Kui sa lähed mängijaga, eriti sellisega, kes töötab suure kliendiga, ja ütled, et sul on vaja, et andmebaas suudaks seda, seda ja seda, vastab ta tavaliselt:

— Hästi, pange nõuded sinna madalaima hunniku alla – kunagi, ilmselt, jõuame nende juurde.

Paljuski on teinud lähituleviku plaanid 2-3 aastaks, kuhu on peaaegu võimatu sisse saada, kuid Tarantooli arendajad kompenseerivad oma avatuses, mitte vaid MegaFoni tootega, ja kohandavad oma süsteemi kliendi vajadustele. See on äge ja meile tõesti meeldib.

Kus me rakendasime Tarantoolit

Meie Tarantool on kasutusel mitmes elemendis. Esimene on meie piloot, mille lõime aadressikataloogisüsteemile. Omast ajast tahtsime, et see oleks sarnane Yandex.Mapsile ja Google Mapsile, kuid välja tuli veidi teisiti.

Näiteks aadressikataloog müügiliideses. Oracle'is võtab õige aadressi otsimine aega 12-13 s — ebamugavad numbrid. Kui me lülitame Tarantoolile, vahetame Oracle'i välja teise andmebaasi vastu konsoolis ja teeme sama otsingu, saame 200-kordse kiiruskasvu! Linn hüppab peale kolmandat tähte. Praegu kohandame liidese, et see toimuks peale esimest. Sellegipoolest on reageerimiskiirus täiesti erinev — juba millisekundid sekundite asemel.

Teine rakendus on moes teema, mida nimetatakse kahekordseks IT-ks. Kõik selle tõttu, et igaühe konsultandid ütlevad, et organisatsioonidel on sinna suunduda.

Siin on infrastruktuuri kiht, mille kohal on domeenid, näiteks arveldamise süsteem, nagu telekommunikatsioonis, ettevõtte süsteemid ja korporatiivne aruandlus. See on lõpp, mida ei tohi puudutada. Loomulikult on võimalik, kuid kvaliteedi tagamine peab olema äärmiselt tähelepanelik, sest see genereerib ettevõttele tulu.

Edasi liigub mikroteenuste kiht – see, mis eristab operaatorit või teisi mängijaid. Mikroteenuseid saab kiiresti luua erinevate vahemälu põhjal, tõstes sinna andmeid erinevatelt domeenidelt. Siin on eksperimentide ala — kui midagi ei läinud korda, sulgesin ühe mikroteenuse ja avasin teise. See tagab tõeliselt lühema time-to-market’i ja suurendab ettevõtte usaldusväärsust ja kiirus.

Mikroteenused on tõenäoliselt Tarantooli peamine roll MegaFon’is.

Kus kavatseme Tarantooli rakendada

Kui võrrelda meie edukat arveldamise projekti Deutsche Telekomi, Svjaztcomi ja Vodafone India transformatsiooniprogrammidega, on see üllatavalt dünaamiline ja loominguline. Selle projekti elluviimise käigus ei ole mitte ainult MegaFoni ja selle struktuuri ümberkujundamine toimunud, vaid on ilmnenud ka Tarantool-enterprise Mail.ru-s ning meie tarnija Nexign (endise nimega «Peter-Service») juures — BSS Box (karbitüüpi arvelduse lahendus).

See on mingil moel ajalooline projekt Venemaa turul. Seda võib võrrelda Frederick Brooksi raamatus «Müüdiline kuud» kirjeldatud sündmustega. 60. aastatel kaasas IBM uue OS/360 operatsioonisüsteemi väljatöötamiseks oma peamistele arvutitele 5 000 inimest. Meil on vähem — 1 800, kuid meie töötavad nagu sidrunipeenral, ja avatud lähtekoodi ja uute lähenemiste kasutamisega töötame tootlikumalt.

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

Open API

Vaadakem jälle numbreid ja seda, kuidas Open API nüüd töötab. Selle koormus on — 10 000 tehingut sekundis. Kuna me plaanime aktiivselt arendada mikroteenuste kihti ja luua MTS avalikku API-d, ootame tulevikus sellel alal suuremat kasvu. 100 000 tehingut kindlasti tuleb..

Ei tea, kas suudame Mail.ru-ga SSO-s võrrelda — neil on ju 1 000 000 tehingut sekundis. Nende lahendused on meile äärmiselt huvitavad ja plaanime nende kogemust üle võtta — näiteks luua funktsionaalne SSO reserv Tarantooli abil. Praegu tegelevad Mail.ru arendajad sellega meie juures.

CRM

CRM on need 80 miljonit tellijat, kelle arvu tahame tõsta miljardini, sest meil on juba 300 miljonit dokumenti, mis hõlmavad kolmeaastast ajalugu. Ootame tõeliselt uusi teenuseid ja siin kasvupunkt on lisateenuste aktiveerimine.See on sfäär, mis hakkab kasvama, sest teenuseid tuleb järjest rohkem. Vastavalt on vajalik ajalugu, me ei soovi sellel takerduda.

Kogu arveldus teenuste osas, mis puudutab arve esitamist ja klientide debitoorseid nõudeid on hakanud arenema eraldi domeeniks.Selleks et suurendada tootlikkust, rakendatakse domeeniarhitektuuri arhitektuurimudelit..

Süsteem on jagatud domeenideks, koormus on jaotatud ja tagatud on talitlushäirete vältimine. Lisaks on tehtud tööd hajutatud arhitektuuriga.

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

Kõige telekommunikatsioonialasem komponent mobiiliteenustes on reaalajas tariifimine. Need on süsteemid, mis võimaldavad teil helistada või mitte helistada, tehes otsuse reaalajas. Siin on koormus 30 000 tehingut sekundis, kuid andmeedastuse kasvu arvestades plaanime 250 000 tehingut, seetõttu oleme tugevalt huvitatud Tarantoolist.

Eelmine pilt on need domeenid, kus plaanime Tarantoolit rakendada. CRM on muidugi laiem ja plaanime seda rakendada sügavamal tasemel.

Minu jaoks, kui arhitekt, on meie tehniliste näitajate arv 100 miljonit abonenti murettekitav — mis siis, kui 101 miljonit? Kas peame uuesti kõik üle tegema? Selle vältimiseks kasutame vahemälusüsteeme, mis tõstab ka kättesaadavust.

Kokkuvõttes on Tarantooli rakendamiseks kaks lähenemist. Esimene — ehitada kõik vahemälud mikroteenuste tasemel. Kui ma õigesti aru saan, siis seda teed läheb VimpelCom, luues klientide vahemälu.

Meie oleme enam sõltumatud teenusepakkujatest, muutes BSS-i tuuma, seega on meil juba kastist välja tulnud ühtne klientide registri süsteem. Kuid me tahame seda laiendada. Seetõttu rakendame natuke teistsugust lähenemist — teeme vahemälud süsteemide sisse.

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

Meetod sobib hästi Tarantooli lähenemesse koos tehingute raamistiku ja osaliste uuendustega, see tähendab andmete muutmisega. Kõik muu saab salvestada kuskile mujale. Ei ole suurt andmejärve, haldamata globaalseid vahemäleid. Vahemälud projekteeritakse süsteemi, toote või kliendi jaoks või selleks, et teenindamist lihtsustada. Kui helistab kvaliteedi üle ärritunud klient, siis tahaks teda kvalitatiivselt teenindada.

RTO ja RPO

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

Recovery time objective — see on teenuse taastamise aeg pärast tõrget. RTO = 0 tähendab, et isegi kui midagi kukub, teenus jätkab tööd.

Recovery point objective — see on andmete taastamise aeg, kui palju andmeid me saame kaotada teatud aja jooksul. RPO = 0 tähendab, et me ei kaota andmeid.

Tarantooli ülesanne

Proovime lahendada Tarantooli ülesanne.

Antud: kõigile arusaadav taotluste korv, näiteks Amazonis või kuskil mujal. Nõutav et korv töötaks 24 tundi ööpäevas, 7 päeva nädalas, või 99,99% ajast. Tellimused, mis meieni jõuavad, peavad säilitama järjekorra, kuna me ei saa tellijale ühendust kaootiliselt sisse ja välja lülitada — kõik peab olema rangelt järjepidev. Eelmine tellimus mõjutab järgmist, seetõttu on andmed olulised — miski ei tohi kaduma minna.

Lahendus. Saaksin proovida lahendada otse ja küsida andmebaasi arendajatelt, kuid probleem ei lahene matemaatiliselt. Saame meenutada teoreeme, säilimise seadusi, kvantfüüsikat, kuid milleks — seda ei saa lahendada andmebaasi tasemel.

Siin töötab vana hea arhitektuuri lähenemine — peab hästi teadma teemat ja selle tõttu lahendama selle mõistatuse.

Meie lahendus: loome hajutatud taotlusregister Tarantoolis — geograafiliselt hajutatud klaster. Skeemil on see kolm erinevat andmekeskust — kaks Uuralite enne, üks Uuralite taga, ja me jagame kõik taotlused nende keskuste vahel.

Netflix, mis peetakse praegu üheks IT-juhtidest, oli kuni 2012. aastani vaid üks andmekeskus. Katoliku jõulude eel, 24. detsembril, see andmekeskus kadus. Kanada ja Ameerika Ühendriikide kasutajad jäid ilma oma lemmikfilmidest, olid väga pettunud ja tõid sellest sotsiaalmeedias juttu. Nüüd on Netflixil kolm andmekeskust lääne-ida rannikul ja üks läänes Euroopas.

Me ehitame algusest peale geograafiliselt jaotatud lahenduse — meile on oluline rikke taluvus.

Nii et meil on klaster, aga kuidas olla RPO = 0 ja RTO = 0? Lahendus on lihtne ja sõltub teemast.

Mis on taotlustes oluline? Kaks osa: ostukorvi täitmine ENNE ostuotsuse tegemist, ja PE after. ENNE osa telecomis kutsutakse tavaliselt order capturing või order negotiation. Telekommunikatsioonis võib see olla oluliselt keerulisem kui veebipoodides, sest seal tuleb klienti teenindada, pakkuda 5 varianti, ja see kõik kestab teatud aja, kuid ostukorv täitub. Sel hetkel on tõrge võimalik, kuid see ei ole hirmutav, sest see toimub interaktiivses režiimis inimese järelevalve all.

Kui Moskva andmekeskus peaks äkki välja kukkuma, siis lülitumine automaatselt teise andmekeskusse võimaldab meil jätkata tööd. Teoreetiliselt võib üks toode ostukorvis kaduma minna, kuid te märkate seda, täiendate ostukorvi uuesti ja jätkate töötamist. Sellisel juhul on RTO = 0.

Samas on teine variant: kui me vajutame „esita“, tahame, et andmed ei kaduks. Sellest hetkest alates käivitub automaatika — see on juba RPO = 0. Neid kahte erinevat mustrit võib ühe juhtumi puhul kasutada geograafiliselt jaotatud klastrina ühe lülitatava masteriga, teise puhul aga mõne kvoorumi kirjutamise abil. Mustrid võivad varieeruda, kuid meie lahendame probleemi.

Edasi liikudes, omades jaotatud taotluste registrit, saame seda kõike veelgi skaleerida — omada palju dispetšereid ja täitjaid, kes pöörduvad selle registraatide poole.

Cassandra ja Tarantool koos

On veel üks juhtum — „balansihaldus“. Siin on huvitav juhtum Cassandra ja Tarantooli ühiseks kasutamiseks.

Kasutame Cassandrat, sest 2 miljardit kõnet päevas ei ole piir ja neid tuleb rohkem. Turundajad armastavad liiklust allikate kaupa värvida, ning sotsiaalmeedia andmed muutuvad järjest detailsemaks. See kõik suurendab looga seotud konteksti.

Cassandra võimaldab horisontaalset skaleerimist igasuguste mahtude jaoks.

Me tunneme end Cassandraga mugavalt, kuid tal on üks probleem – lugemine pole tema tugevus. Kirjapanek on korras, 30 000 sekundis pole probleem – probleem on lugemises..

Seetõttu tuli kõne alla vahemälu teema ning samal ajal lahendasime järgmise probleemi: olemas on vana traditsiooniline juhtum, kus kommutatori varustuse andmed veebiarvestusest jõuavad failidena, mille me laadime Cassandrasse. Oleme võidelnud nende failide usaldusväärse laadimise probleemiga, rakendanud isegi IBM-i soovitusel failide ülekande haldamise lahendusi – on selliseid süsteeme, mis haldavad failide edastust efektiivselt, kasutades näiteks UDP-protokolli, mitte TCP-d. See on hea, kuid ikkagi kulub minuteid, ja seni, kuni me seda kõike ei laadi, ei saa operaator kõnekeskuses kliendile vastata, mis juhtus tema saldo – tuleb ootama jääda.

Selle vältimiseks me rakendame paralleelset funktsionaalset reservi. Kui me saadame sündmuse Kafka kaudu Tarantooli, arvutades reaalaegseid aggregaate, näiteks tänase päeva kohta, saame saldo vahekogud, mis suudab edastada saldosid mistahes kiirusel, näiteks 100 tuhat tehingut sekundis ja täpselt need 2 sekundit.

Eesmärk on see, et pärast kõne tegemist oleks isiklikus kabinetis 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 meeldib väga Mail.ru avatus ja nende valmidus kaaluda erinevaid juhtumeid.

BCG või McKinsey, Accenture või IBM konsultandid on meid juba keeruline millegagi üllatada — palju sellest, mida nad pakuvad, me kas teeme juba, oleme teinud või plaanime teha. Arvan, et Tarantool leiab meie tehnoloogia virnas väärilise koha ja asendab mitmeid juba olemasolevaid tehnoloogiaid. Oleme selle projekti arenduses aktiivses faasis.

Olegi ja Andrei ettekande Tarantooli konverentsil eelmisel aastal oli üks parimaid, ja juba 17. juunil esindab Oleg Ivlev T+ Konverents 2019 ettekandega „Miks on Tarantool Enterprise’is vajalik“. Lisaks MegaFonilt esineb Alexander Deulin ettekandega "Tarantooli vahemälud ja replikaat Oracle'ist". Uurime, mis on muutunud, milliseid plaane on õnnestunud ellu viia. Liituge - konverents on tasuta, tuleb vaid registreerimine. Kõik ettekanded on aktsepteeritud ja konverentsi programmid on koostatud: uued juhtumiuuringud, uus kogemus Tarantooli kasutamisel, arhitektuur, ettevõtte tasand, õpetused ja mikroteenused.

Allikas: habr.com