Miért van szüksége egy olyan vállalatnak, mint a MegaFon a Tarantool-ra a számlázás során? Kívülről úgy tűnik, hogy általában jön az eladó, hoz valami nagy dobozt, bedugja a csatlakozót a konnektorba - és ez a számlázás! Ez valamikor így volt, de mára archaikus, és az ilyen dinoszauruszok már kihaltak vagy kihalóban vannak. Kezdetben a számlázás egy számlák kiállítására szolgáló rendszer - számlálógép vagy számológép. A modern távközlésben ez van automatizálási rendszer az előfizetővel való interakció teljes életciklusára a szerződés megkötésétől a felmondásig, beleértve a valós idejű számlázást, a fizetés elfogadását és még sok mást. A távközlési cégeknél a számlázás olyan, mint egy harci robot – nagy, erős és fegyverekkel megrakott.
Mi köze ehhez a Tarantool-nak? Majd beszélnek róla Oleg Ivlev и Andrej Knyazev. Oleg a cég főépítésze A külföldi cégeknél szerzett széleskörű tapasztalattal Andrey az üzleti rendszerek igazgatója. című jelentésük átiratából megtudhatja, miért van szükség a K+F-re a vállalatoknál, mi az a Tarantool, hogyan vált a vertikális skálázás és a globalizáció zsákutcájává az adatbázis megjelenésének előfeltétele a vállalatnál, megtudhatja a technológiai kihívásokat, az építészeti átalakulást, és hogyan hasonlít a MegaFon technostackje a Netflixhez. , a Google és az Amazon.
"Egységes számlázás" projekt
A szóban forgó projekt neve „Egységes számlázás”. A Tarantool itt mutatta meg legjobb tulajdonságait.
A Hi-End berendezések termelékenységének növekedése nem tartott lépést az előfizetői bázis és a szolgáltatások számának növekedésével, az előfizetők számának és a szolgáltatások számának további növekedése várható az M2M, az IoT és a fiókszolgáltatások miatt. a forgalomba hozatali idő romlására. A cég úgy döntött, hogy a jelenlegi 8 különböző számlázási rendszer helyett egy egységes üzleti rendszert hoz létre, egyedülálló világszínvonalú moduláris architektúrával.
A MegaFon nyolc vállalat egyben. 2009-ben az átszervezés befejeződött: a fióktelepek Oroszország-szerte egyetlen vállalatba, a MegaFon OJSC-be (ma PJSC) egyesültek. Így a cég 8 számlázási rendszerrel rendelkezik saját „egyedi” megoldásokkal, ágazati jellemzőkkel és eltérő szervezeti felépítéssel, informatikával és marketinggel.
Minden rendben volt egészen addig, amíg egy közös szövetségi terméket nem kellett piacra dobnunk. Itt sok nehézség merült fel: egyeseknél a tarifákat felfelé kerekítik, másoknak lefelé, másoknak pedig a számtani átlag alapján. Ezer ilyen pillanat van.
Annak ellenére, hogy a számlázási rendszernek csak egy verziója, egy szállítója volt, a beállítások annyira eltértek egymástól, hogy sok időt vett igénybe az összeállítás. Megpróbáltuk csökkenteni a számukat, és egy második, sok vállalat számára ismerős problémára bukkantunk.
Függőleges méretezés. Az akkori legmenőbb hardver sem felelt meg az igényeknek. A munkához a Superdome Hi-End vonal Hewlett-Packard berendezéseit használták, de még két fiók igényeit sem elégítették ki. Vízszintes skálázást szerettem volna nagy üzemeltetési költségek és tőkebefektetések nélkül.
Az előfizetők és a szolgáltatások számának növekedésére számítanak. A tanácsadók már régóta hozták az IoT-ről és az M2M-ről szóló történeteket a távközlési világba: eljön az idő, amikor minden telefonban és vasalóban lesz SIM-kártya, kettő pedig a hűtőben. Ma egy számú előfizetőnk van, de a közeljövőben sokkal több lesz.
Technológiai kihívások
Ez a négy ok motivált bennünket komoly változtatásokra. Választani lehetett a rendszer frissítése és a nulláról történő tervezés között. Sokáig gondolkodtunk, komoly döntéseket hoztunk, pályázatokat játszottunk. Ennek eredményeként a kezdetektől fogva a tervezés mellett döntöttünk, és érdekes kihívásokat – technológiai kihívásokat – vállaltunk.
Méretezhetőség
Ha korábban volt, mondjuk, mondjuk 8 számlázás 15 millió előfizetőnek, és most működnie kellett volna 100 millió előfizető és még több - a terhelés egy nagyságrenddel nagyobb.
Méretben összehasonlíthatóvá váltunk az olyan nagy internetes lejátszókkal, mint a Mail.ru vagy a Netflix.
De a terhelés és az előfizetői bázis további növelése komoly kihívások elé állított bennünket.
Hatalmas országunk földrajza
Kalinyingrád és Vlagyivosztok között 7500 km és 10 időzóna. A fénysebesség véges, és ilyen távolságoknál a késések már jelentősek. A 150 ms a legmenőbb modern optikai csatornákon túl sok a valós idejű számlázáshoz, különösen, ha Oroszországban a telekommunikációban ez van. Ezenkívül egy munkanapon belül frissítenie kell, és különböző időzónák esetén ez probléma.
Nem csak előfizetési díj ellenében nyújtunk szolgáltatásokat, komplex tarifáink, csomagjaink és különféle módosítóink vannak. Nemcsak meg kell engednünk vagy meg kell tagadnunk az előfizetőnek, hogy beszéljen, hanem bizonyos kvótát is adjunk neki - valós időben számítsuk ki a hívásokat és a műveleteket, hogy ne vegye észre.
hibatűrés
Ez a központosítás másik oldala.
Ha az összes előfizetőt egy rendszerbe gyűjtjük, akkor minden vészhelyzet és katasztrófa katasztrofális az üzleti élet számára. Ezért a rendszert úgy alakítjuk ki, hogy a balesetek hatását a teljes előfizetői körre kiküszöböljük.
Ez ismét a vertikális méretezés elutasításának a következménye. Amikor vízszintesen méreteztük, több százról ezerre növeltük a szerverek számát. Ezeket fel kell kezelni és fel kell cserélni, automatikusan biztonsági másolatot kell készíteni az informatikai infrastruktúráról és vissza kell állítani az elosztott rendszert.
Ilyen érdekes kihívásokkal néztünk szembe. Megterveztük a rendszert, és abban a pillanatban megpróbáltuk megtalálni a globális legjobb gyakorlatokat, hogy ellenőrizzük, mennyire vagyunk trendben, mennyire követjük a fejlett technológiákat.
Világélmény
Meglepő módon egyetlen referenciát sem találtunk a globális távközlésben.
Európa az előfizetők számát és méretét tekintve, az USA - tarifáinak egyenetlenségét tekintve esett le. Megnéztünk néhányat Kínában, néhányat Indiában találtunk, és a Vodafone India szakembereit fogadtuk fel.
Az architektúra elemzésére összeállítottunk egy Dream Team-et, amelyet az IBM – különböző területekről érkező építészek – vezetett. Ezek az emberek megfelelően felmérhették, amit csinálunk, és bizonyos ismereteket vihetnek az építészetünkbe.
Skála
Néhány szám illusztrációként.
A rendszert erre tervezzük 80 millió előfizető egymilliárdos tartalékkal. Így távolítjuk el a jövőbeli küszöböket. Ennek nem az az oka, hogy meg akarjuk venni Kínát, hanem az IoT és az M2M támadása.
300 millió dokumentum valós időben feldolgozva. Habár 80 millió előfizetőnk van, a potenciális ügyfelekkel és a tőlünk távozókkal is együttműködünk, ha követeléseket kell beszednünk. Ezért a tényleges mennyiségek észrevehetően nagyobbak.
2 milliárd tranzakció Az egyenleg naponta változik – ezek fizetések, díjak, hívások és egyéb események. 200 TB adat aktívan változik, váltson egy kicsit lassabban 8 PB adat, és ez nem archívum, hanem élő adatok egyetlen számlázásban. Méretezés adatközpont szerint - 5 ezer szerver 14 oldalon.
Technológiai verem
Amikor megterveztük az architektúrát és elkezdtük a rendszer összeállítását, a legérdekesebb és legfejlettebb technológiákat importáltuk. Az eredmény egy olyan technológiai halom, amelyet minden internetes lejátszó és nagy terhelésű rendszereket gyártó vállalat ismer.
A stack hasonló a többi nagy játékos stackéhez: Netflix, Twitter, Viber. 6 komponensből áll, de szeretnénk rövidíteni, egységesíteni.
A rugalmasság jó, de egy nagyvállalatnál nincs út egységesítés nélkül.
Nem fogjuk ugyanazt az Oracle-t Tarantool-ra cserélni. A nagyvállalatok valóságában ez egy utópia, vagy egy 5-10 évre szóló keresztes hadjárat, melynek kimenetele nem világos. De Cassandra és Couchbase könnyen lecserélhető Tarantoolra, és erre törekszünk.
Miért a Tarantool?
4 egyszerű kritérium van, amiért ezt az adatbázist választottuk.
Sebesség. Terhelési teszteket végeztünk MegaFon ipari rendszereken. A Tarantool nyert – a legjobb teljesítményt nyújtotta.
Ez nem azt jelenti, hogy más rendszerek nem felelnek meg a MegaFon igényeinek. A jelenlegi memóriamegoldások annyira termelékenyek, hogy a cég tartalékai bőven elegendőek. De az érdekel, hogy egy vezetővel foglalkozzunk, és ne azzal, aki lemaradt, beleértve a terhelési tesztet is.
A Tarantool hosszú távon is fedezi a vállalat igényeit.
TCO költség. A Couchbase támogatása MegaFon köteteken csillagászati összegekbe kerül, de a Tarantool-al sokkal kellemesebb a helyzet, és a funkcionalitásban is hasonlóak.
Egy másik jó tulajdonság, amely némileg befolyásolta a választásunkat, hogy a Tarantool jobban működik a memóriával, mint más adatbázisok. Ő mutatja maximális hatékonyság.
Megbízhatóság. A MegaFon a megbízhatóságba fektet, valószínűleg többet, mint bárki más. Így amikor megnéztük a Tarantool-t, rájöttünk, hogy meg kell felelnünk a követelményeinknek.
Időnket és pénzünket fektettük, és a Mail.ru-val közösen létrehoztunk egy vállalati verziót, amelyet már több más cég is használ.
A Tarantool-enterprise teljes mértékben megelégedett minket a biztonság, a megbízhatóság és a naplózás terén.
társaság
A legfontosabb számomra az közvetlen kapcsolat a fejlesztővel. Pontosan ezzel vesztegeltek a tarantooli srácok.
Ha odajön egy játékoshoz, különösen aki egy horgonyklienssel dolgozik, és azt mondja, hogy szüksége van az adatbázisra, hogy ezt, ezt és ezt meg tudja tenni, akkor általában azt válaszolja:
- Oké, tedd a követelményeket annak a kupacnak az aljára - egy nap valószínűleg rájuk is fogunk jutni.
Sokaknak van útiterve a következő 2-3 évre, és ott szinte lehetetlen beilleszkedni, de a Tarantool fejlesztői nyitottságukkal rabul ejtik, és nem csak a MegaFontól, és a megrendelőhöz igazítják rendszerüket. Nagyon klassz és nagyon szeretjük.
Ahol Tarantoolt használtunk
Több elemben használjuk a Tarantool-t. Az első a pilotban van, amelyet a címtárrendszeren készítettünk. Egy időben azt akartam, hogy ez egy olyan rendszer legyen, ami hasonlít a Yandex.Mapshez és a Google Mapshez, de ez egy kicsit másképp alakult.
Például a címkatalógus az értékesítési felületen. Oracle-en a kívánt cím keresése 12-13 másodpercet vesz igénybe. - kellemetlen számok. Amikor áttérünk a Tarantoolra, lecseréljük az Oracle-t egy másik adatbázisra a konzolban, és végrehajtjuk ugyanazt a keresést, 200-szoros gyorsulást kapunk! A harmadik levél után felbukkan a város. Most úgy alakítjuk át a felületet, hogy ez az első után történjen meg. A válaszsebesség azonban teljesen más – másodpercek helyett ezredmásodpercek.
A második alkalmazás egy divatos téma, az úgynevezett kétsebességes IT. Ez azért van, mert a tanácsadók minden sarkon azt mondják, hogy a vállalatoknak oda kell menniük.
Van egy infrastrukturális réteg, felette vannak tartományok, például egy számlázási rendszer, mint egy távközlés, vállalati rendszerek, vállalati jelentés. Ez az a mag, amit nem kell megérinteni. Ez persze lehetséges, de paranoid módon a minőséget biztosítva, mert ez pénzt hoz a vállalatnak.
Ezután következik a mikroszolgáltatások rétege – ami megkülönbözteti az üzemeltetőt vagy a másik játékost. A mikroszolgáltatások gyorsan létrehozhatók bizonyos gyorsítótárak alapján, és különböző tartományokból hozhatók oda adatok. Itt kísérleti terep - ha valami nem sikerült, bezártam egy mikroszolgáltatást, és megnyitottam egy másikat. Ez valóban megnöveli a piacra jutási időt, és növeli a vállalat megbízhatóságát és sebességét.
A mikroszolgáltatások talán a Tarantool fő szerepe a MegaFonnál.
Ahol tervezzük a Tarantool alkalmazását
Ha összehasonlítjuk sikeres számlázási projektünket a Deutsche Telekom, Svyazcom, Vodafone India átalakítási programjaival, meglepően dinamikus és kreatív. A projekt megvalósítása során nemcsak a MegaFon és annak struktúrája átalakult, hanem a Tarantool-enterprise is megjelent a Mail.ru-n, valamint a Nexign (korábban Peter-Service) - BSS Box (dobozos számlázási megoldás) szállítónk.
Ez bizonyos értelemben történelmi projekt az orosz piac számára. Összehasonlítható Frederick Brooks „The Mythical Man-Month” című könyvében leírtakkal. Aztán a 60-as években az IBM 360 embert vett fel az új OS/5 operációs rendszer fejlesztésére nagyszámítógépekhez. Nálunk kevesebb - 000, de a mieink mellényben vannak, és figyelembe véve a nyílt forráskód használatát és az új megközelítéseket, eredményesebben dolgozunk.
Az alábbiakban a számlázási vagy tágabb értelemben az üzleti rendszerek területeit mutatjuk be. A vállalati emberek nagyon jól ismerik a CRM-et. Mindenkinek más rendszerekkel kell rendelkeznie: Open API, API Gateway.
Nyissa meg az API-t
Nézzük újra a számokat, és hogy jelenleg hogyan működik az Open API. A terhelése az 10 000 tranzakció másodpercenként. Mivel a mikroszolgáltatási réteg aktív fejlesztését és a MegaFon nyilvános API kiépítését tervezzük, a jövőben nagyobb növekedésre számítunk ezen a területen. Biztosan lesz 100 000 tranzakció.
Nem tudom, hogy összehasonlíthatjuk-e a Mail.ru-val az SSO-ban - úgy tűnik, hogy a srácoknak másodpercenként 1 000 0000 tranzakciójuk van. Megoldásuk rendkívül érdekes számunkra, és tervezzük tapasztalataikat átvenni – például funkcionális SSO biztonsági mentést készíteni a Tarantool segítségével. Most a Mail.ru fejlesztői ezt teszik meg helyettünk.
CRM
A CRM ugyanaz a 80 millió előfizető, amelyet egymilliárdra szeretnénk növelni, mert már 300 millió olyan dokumentum van, amely három éves múltra tekint vissza. Nagyon várjuk az új szolgáltatásokat és itt növekedési pont a kapcsolódó szolgáltatások. Ez egy olyan bál, ami növekedni fog, mert egyre több szolgáltatás lesz. Ennek megfelelően szükségünk lesz egy történetre, nem akarunk ebbe belebotlani.
Maga a számlázás a számlák kiállítása szempontjából, a vevői kintlévőségekkel való munka külön tartománygá alakult át. A teljesítmény javítása érdekében, alkalmazott tartomány architektúra építészeti minta.
A rendszer tartományokra van felosztva, a terhelés megoszlik és a hibatűrés biztosított. Emellett elosztott architektúrával dolgoztunk.
Minden más vállalati szintű megoldás. A hívástárolóban - 2 milliárd naponta, 60 milliárd havonta. Néha egy hónap alatt kell megszámolni őket, és ez gyorsan jobb. Pénzügyi ellenőrzés - ez pontosan ugyanaz a 300 millió, ami folyamatosan növekszik és növekszik: az előfizetők gyakran futnak a szolgáltatók között, növelve ezt a részt.
A mobilkommunikáció leginkább telekommunikációs összetevője az online számlázás. Ezek azok a rendszerek, amelyek lehetővé teszik, hogy hívjon vagy ne hívjon, valós időben hozzon döntéseket. Itt 30 000 tranzakció/másodperc a terhelés, de az adatátvitel növekedését figyelembe véve tervezzük 250 000 tranzakció, és ezért nagyon érdekel minket a Tarantool.
Az előző képen azok a tartományok láthatók, ahol a Tarantool-t fogjuk használni. Maga a CRM természetesen szélesebb, és magában a magban fogjuk használni.
A becsült 100 milliós TTX-előfizetőnk összezavar engem, mint építészt – mi van, ha 101 millió? Újra kell csinálnod mindent? Ennek elkerülése érdekében gyorsítótárakat használunk, ezzel egyidejűleg növelve a hozzáférhetőséget.
Általában két megközelítés létezik a Tarantool használatára. Első - az összes gyorsítótárat mikroszolgáltatási szinten építse fel. Ha jól értem, a VimpelCom ezt az utat követi, létrehozva az ügyfelek gyorsítótárát.
Kevésbé függünk a szállítóktól, változtatjuk a BSS magot, így egyetlen kliens fájl áll rendelkezésünkre. De szeretnénk bővíteni. Ezért egy kicsit más megközelítést alkalmazunk - gyorsítótárakat készíteni a rendszereken belül.
Így kevesebb a szinkronizálás – egy rendszer felelős mind a gyorsítótárért, mind a fő főforrásért.
A módszer jól illeszkedik a tranzakciós vázas Tarantool-megközelítéshez, amikor csak a frissítésekhez, azaz az adatváltozásokhoz kapcsolódó részek frissülnek. Minden mást el lehet tárolni máshol. Nincs hatalmas adattó, kezeletlen globális gyorsítótár. A gyorsítótárak a rendszerhez, a termékekhez vagy az ügyfelekhez készültek, vagy hogy megkönnyítsék a karbantartást. Amikor egy előfizető felhív, és ideges a szolgáltatás minősége miatt, minőségi szolgáltatást szeretne nyújtani.
RTO és RPO
Az informatikában két kifejezés létezik: OTR и RPO.
A helyreállítási idő célja az az idő, amely a szolgáltatás visszaállításához szükséges meghibásodás után. Az RTO = 0 azt jelenti, hogy még ha valami meghibásodik, a szolgáltatás továbbra is működik.
A helyreállítási pont célja - ez az adathelyreállítási idő, hogy mennyi adatot veszíthetünk el egy bizonyos idő alatt. Az RPO = 0 azt jelenti, hogy nem veszítünk adatot.
Tarantool feladat
Próbáljunk meg megoldani egy problémát a Tarantool számára.
Adott: olyan alkalmazások kosara, amelyeket mindenki megért, például az Amazonon vagy máshol. kötelező hogy a bevásárlókosár a hét minden napján 24 órában, vagyis az idő 7%-ában működjön. A hozzánk érkező megrendeléseknek rendben kell maradniuk, mert nem tudjuk véletlenszerűen bekapcsolni vagy kikapcsolni az előfizetői kapcsolatot - mindennek szigorúan következetesnek kell lennie. Az előző előfizetés hatással van a következőre, ezért fontosak az adatok – semmi sem fog eltűnni.
döntés. Megpróbálhatja megoldani, és megkérdezni az adatbázis-fejlesztőket, de a probléma matematikailag nem megoldható. Emlékezhetsz tételekre, megmaradási törvényekre, kvantumfizikára, de miért - DB szinten nem lehet megoldani.
Itt működik a jó öreg építészeti megközelítés – jól kell ismerni a tárgykört, és ennek segítségével megoldani ezt a rejtvényt.
Megoldásunk: az alkalmazások elosztott nyilvántartásának létrehozása a Tarantoolon - egy földrajzilag elosztott klaszteren. Az ábrán ez három különböző adatfeldolgozó központ - kettő az Urál előtt, egy az Urálon túl, és az összes kérést ezek között a központok között osztjuk el.
A ma az IT egyik vezetőjének számító Netflixnek 2012-ig egyetlen adatközpontja volt. A katolikus karácsony előestéjén, december 24-én ez az adatközpont leállt. A kanadai és az amerikai felhasználók kedvenc filmjeik nélkül maradtak, nagyon idegesek voltak, és írtak róla a közösségi hálózatokon. A Netflix immár három adatközponttal rendelkezik a nyugat-keleti parton és egy Nyugat-Európában.
Kezdetben földrajzilag elosztott megoldást építünk – a hibatűrés fontos számunkra.
Tehát van egy klaszterünk, de mi a helyzet RPO = 0 és RTO = 0 esetén? A megoldás egyszerű, témától függően.
Mi a fontos az alkalmazásokban? Két rész: Kosárdobás ELŐTT vásárlási döntés meghozatala, és UTÁN. A DO részt a távközlésben általában ún rendelés elfogása vagy megrendelés egyeztetése. A távközlésben ez sokkal nehezebb lehet, mint egy webáruházban, mert ott ki kell szolgálni az ügyfelet, fel kell ajánlani 5 lehetőséget, és ez egy ideig meg is történik, de a kosár betelt. Ebben a pillanatban a kudarc lehetséges, de nem ijesztő, mert interaktívan, emberi felügyelet mellett történik.
Ha a moszkvai adatközpont hirtelen meghibásodik, akkor automatikusan egy másik adatközpontra váltva folytatjuk a munkát. Elméletileg előfordulhat, hogy egy termék elveszett a kosárban, de ha látja, tegye újra a kosárba, és folytassa a munkát. Ebben az esetben RTO = 0.
Ugyanebben a pillanatban van egy második lehetőség is: amikor a „beküld” gombra kattintottunk, azt szeretnénk, hogy az adatok ne vesszenek el. Ettől a pillanattól kezdve az automatizálás elkezd működni - ez az RPO = 0. E két különböző minta használatával az egyik esetben egyszerűen egy földrajzilag elosztott klaszter lehet egy kapcsolható mesterrel, a másik esetben pedig valamilyen kvórumrekord. A minták változhatnak, de mi megoldjuk a problémát.
Továbbá, az alkalmazások elosztott nyilvántartásával, mindezt méretezhetjük is – sok diszpécsere és végrehajtó fér hozzá ehhez a nyilvántartáshoz.
Cassandra és Tarantool együtt
Van egy másik eset - "egyenlegek kirakata". Itt van egy érdekes eset Cassandra és Tarantool közös használatáról.
A Cassandrát azért használjuk, mert a napi 2 milliárd hívás nem a határ, és lesz még több. A marketingesek előszeretettel színezik a forgalmat forrás szerint, egyre több részlet jelenik meg például a közösségi oldalakon. Mindez hozzátesz a történethez.
A Cassandra lehetővé teszi a vízszintes méretezést bármilyen méretre.
Jól érezzük magunkat Cassandrával, de van egy probléma: nem tud jól olvasni. A felvételen minden rendben van, másodpercenként 30 000 nem probléma - olvasási probléma.
Ezért megjelent egy gyorsítótárral rendelkező téma, és ezzel egyidejűleg a következő problémát is megoldottuk: van egy régi hagyományos eset, amikor az online számlázásról való átállásból eszköz kerül a Cassandra-ba betöltött fájlokba. Ezen fájlok megbízható letöltésének problémájával küszködtünk, még az IBM manager fájlátvitel tanácsait is felhasználva – vannak olyan megoldások, amelyek hatékonyan kezelik a fájlátvitelt, például UDP protokollt használnak a TCP helyett. Ez jó, de még percek, és még nem töltöttük fel az egészet, a call center operátora nem tud válaszolni az ügyfélnek, hogy mi történt az egyenlegével - várnunk kell.
Hogy ez ne forduljon elő, mi párhuzamos funkcionális tartalékot használunk. Amikor Kafkán keresztül elküldünk egy eseményt a Tarantoolnak, valós időben újraszámolva az aggregátumokat, például a mai napra, azt kapjuk készpénz egyenlegek, amely bármilyen sebességgel képes egyenleget átvinni, például 100 ezer tranzakciót másodpercenként és ugyanazt a 2 másodpercet.
A cél az, hogy hívást követően 2 másodpercen belül személyes fiókjában ne csak a megváltozott egyenleg legyen, hanem információ arról, hogy miért változott.
Következtetés
Ezek példák voltak a Tarantool használatára. Nagyon tetszett nekünk a Mail.ru nyitottsága és hajlandósága a különböző esetek mérlegelésére.
A BCG vagy a McKinsey, az Accenture vagy az IBM tanácsadóinak már most is nehéz meglepni minket valami újjal – az általuk kínált termékek nagy részét vagy már megtesszük, megtettük vagy tervezzük. Úgy gondolom, hogy a Tarantool elfoglalja az őt megillető helyet technológiai halmazunkban, és számos meglévő technológiát felvált. A projekt fejlesztésének aktív szakaszában vagyunk.
Oleg és Andrey jelentése a tavalyi Tarantool Konferencia egyik legjobbja, június 17-én pedig Oleg Ivlev beszél jelentéssel . Alexander Deulin is előadást tart a MegaFontól . Nézzük meg, mi változott, milyen tervek valósultak meg. Csatlakozzon – a konferencia ingyenes, mindössze annyit kell tennie, hogy ... Minden és kialakult a konferencia programja: új esetek, új tapasztalatok a Tarantool használatában, architektúra, vállalkozás, oktatóanyagok és mikroszolgáltatások.
Forrás: will.com