Dlaczego korporacja taka jak MegaFon potrzebuje Tarantool w rozliczeniach? Z zewnątrz wygląda na to, że zazwyczaj przychodzi sprzedawca, przynosi jakieś duże pudło, wkłada wtyczkę do gniazdka – i tyle! Kiedyś tak było, ale teraz jest to archaiczne i takie dinozaury już wyginęły lub wymierają. Początkowo billing to system do wystawiania faktur – maszyna licząca lub kalkulator. We współczesnej telekomunikacji tak jest system automatyzacji całego cyklu życia interakcji z abonentem od zawarcia umowy do jej rozwiązania, w tym rozliczenia w czasie rzeczywistym, akceptacja płatności i wiele więcej. Billing w firmach telekomunikacyjnych jest jak robot bojowy – duży, potężny i naładowany bronią.
Co ma z tym wspólnego Tarantool? Będą o tym rozmawiać Oleg Iwlew и Andriej Knyazjew. Oleg jest głównym architektem firmy Andrey, posiadający bogate doświadczenie w pracy w firmach zagranicznych, jest dyrektorem ds. systemów biznesowych. Z transkrypcji ich raportu dot dowiesz się po co w korporacjach potrzebne są badania i rozwój, czym jest Tarantool, jak impas pionowego skalowania i globalizacji stał się przesłanką pojawienia się tej bazy w firmie, o wyzwaniach technologicznych, transformacji architektonicznej i jak technostack MegaFon przypomina Netflix , Google’a i Amazona.
Projekt „Ujednolicone rozliczanie”
Projekt, o którym mowa, nosi nazwę „Unified Billing”. To tutaj Tarantool pokazał swoje najlepsze cechy.
Wzrost produktywności sprzętu Hi-End nie nadążał za wzrostem bazy abonenckiej i wzrostem liczby usług; oczekiwano dalszego wzrostu liczby abonentów i usług ze względu na cechy M2M, IoT i oddziałowe, które doprowadziły do pogorszenia czasu wprowadzenia produktu na rynek. Firma zdecydowała się stworzyć ujednolicony system biznesowy o unikalnej, światowej klasy architekturze modułowej, zamiast dotychczasowych 8 różnych systemów bilingowych.
MegaFon to osiem firm w jednej. W 2009 roku zakończono reorganizację: oddziały w całej Rosji połączyły się w jedną spółkę MegaFon OJSC (obecnie PJSC). Tym samym firma posiada 8 systemów bilingowych z własnymi rozwiązaniami „niestandardowymi”, cechami branżowymi i różnymi strukturami organizacyjnymi, IT i marketingiem.
Wszystko było w porządku, dopóki nie musieliśmy wypuścić jednego wspólnego produktu federalnego. Tutaj pojawiło się wiele trudności: dla niektórych taryfy są zaokrąglane w górę, dla innych w dół, a dla innych - w oparciu o średnią arytmetyczną. Takich momentów są tysiące.
Pomimo tego, że istniała tylko jedna wersja systemu bilingowego, jeden dostawca, ustawienia tak się od siebie różniły, że ich ułożenie zajęło dużo czasu. Próbowaliśmy zmniejszyć ich liczbę i natknęliśmy się na drugi problem, znany wielu korporacjom.
Skalowanie pionowe. Nawet najfajniejszy sprzęt tamtych czasów nie odpowiadał potrzebom. Korzystaliśmy ze sprzętu Hewlett-Packarda z linii Superdome Hi-End, jednak nie zaspokajał on potrzeb nawet dwóch branż. Zależało mi na skalowaniu poziomym bez dużych kosztów operacyjnych i inwestycji kapitałowych.
Oczekiwanie wzrostu liczby abonentów i usług. Konsultanci od dawna wprowadzają do świata telekomunikacji historie o IoT i M2M: nadejdzie czas, gdy każdy telefon i żelazko będzie miało kartę SIM, a dwie w lodówce. Dziś mamy jedną liczbę abonentów, ale w najbliższej przyszłości będzie ich znacznie więcej.
Wyzwania technologiczne
Te cztery powody zmotywowały nas do wprowadzenia poważnych zmian. Do wyboru był upgrade systemu lub projektowanie od zera. Długo myśleliśmy, podejmowaliśmy poważne decyzje, graliśmy w przetargi. W efekcie od początku postanowiliśmy projektować i podjęliśmy ciekawe wyzwania – wyzwania technologiczne.
Skalowalność
Jeśli było wcześniej, powiedzmy, powiedzmy 8 rozliczeń dla 15 milionów abonentówi teraz powinno zadziałać 100 milionów subskrybentów i więcej - obciążenie jest o rząd wielkości większe.
Staliśmy się porównywalni pod względem skali do dużych graczy internetowych, takich jak Mail.ru czy Netflix.
Jednak dalsze działania mające na celu zwiększenie obciążenia i bazy abonentów postawiły przed nami poważne wyzwania.
Geografia naszego rozległego kraju
Między Kaliningradem a Władywostokiem 7500 km i 10 stref czasowych. Prędkość światła jest skończona i przy takich odległościach opóźnienia są już znaczne. 150 ms na najfajniejszych nowoczesnych kanałach optycznych to za dużo, aby móc rozliczać się w czasie rzeczywistym, zwłaszcza że ma to obecnie miejsce w telekomunikacji w Rosji. Poza tym trzeba dokonać aktualizacji w ciągu jednego dnia roboczego, a przy różnych strefach czasowych stanowi to problem.
Świadczymy usługi nie tylko w ramach abonamentu, mamy rozbudowane taryfy, pakiety i różne modyfikatory. Musimy nie tylko pozwolić abonentowi na rozmowę lub zabronić mu rozmowy, ale także dać mu określony limit - obliczać połączenia i działania w czasie rzeczywistym, aby tego nie zauważył.
tolerancja błędów
To jest druga strona centralizacji.
Jeśli zbierzemy wszystkich abonentów w jednym systemie, wówczas wszelkie zdarzenia awaryjne i katastrofy będą katastrofalne dla biznesu. Dlatego projektujemy system w taki sposób, aby wyeliminować wpływ wypadków na całą bazę abonencką.
Jest to znowu konsekwencja odmowy skalowania wertykalnego. Skalując poziomo, zwiększyliśmy liczbę serwerów z setek do tysięcy. Muszą być zarządzane i wymienne, automatycznie tworzyć kopie zapasowe infrastruktury IT i przywracać system rozproszony.
Stanęliśmy przed ciekawymi wyzwaniami. Zaprojektowaliśmy system i na ten moment staraliśmy się znaleźć najlepsze światowe praktyki, aby sprawdzić, w jakim jesteśmy trendzie, na ile podążamy za zaawansowanymi technologiami.
Światowe doświadczenie
Co zaskakujące, nie znaleźliśmy ani jednej wzmianki w globalnej telekomunikacji.
Europa odpadła pod względem liczby abonentów i skali, USA – pod względem płaskości stawek. Przyjrzeliśmy się niektórym w Chinach, znaleźliśmy niektórych w Indiach i zatrudniliśmy specjalistów z Vodafone India.
Do analizy architektury powołaliśmy Dream Team kierowany przez IBM – architektów z różnych dziedzin. Ci ludzie potrafili właściwie ocenić to, co robimy i wnieść pewną wiedzę do naszej architektury.
Skala
Kilka liczb dla ilustracji.
Projektujemy system dla 80 milionów abonentów z rezerwą wynoszącą miliard. W ten sposób usuwamy przyszłe progi. Nie dzieje się tak dlatego, że zamierzamy przejąć Chiny, ale z powodu ataku Internetu Rzeczy i M2M.
300 milionów dokumentów przetwarzanych w czasie rzeczywistym. Mimo, że mamy 80 milionów abonentów, współpracujemy zarówno z potencjalnymi klientami, jak i tymi, którzy od nas odeszli, jeśli zajdzie potrzeba dochodzenia należności. Dlatego rzeczywiste objętości są zauważalnie większe.
2 miliardy transakcji Saldo zmienia się codziennie - są to płatności, opłaty, połączenia i inne zdarzenia. 200 TB danych aktywnie się zmienia, zmieniaj trochę wolniej 8 PB danychi nie jest to archiwum, ale aktualne dane w ramach jednego rozliczenia. Skalowanie według centrum danych — 5 tysięcy serwerów w 14 lokalizacjach.
Stos technologii
Kiedy planowaliśmy architekturę i zaczynaliśmy składać system, importowaliśmy najciekawsze i najbardziej zaawansowane technologie. Rezultatem jest stos technologii znany każdemu graczowi internetowemu i korporacjom tworzącym systemy o dużym obciążeniu.
Stos jest podobny do stosów innych głównych graczy: Netflix, Twitter, Viber. Składa się z 6 elementów, ale chcemy go skrócić i ujednolicić.
Elastyczność jest dobra, ale w dużej korporacji nie ma mowy o unifikacji.
Nie zamierzamy zmieniać tej samej Oracle na Tarantool. W realiach dużych firm jest to utopia, czyli krucjata na 5-10 lat z niejasnym skutkiem. Jednak Cassandrę i Couchbase można łatwo zastąpić Tarantoolem i do tego właśnie dążymy.
Dlaczego Tarantool?
Istnieją 4 proste kryteria, dla których wybraliśmy tę bazę danych.
prędkość. Przeprowadziliśmy testy obciążeniowe systemów przemysłowych MegaFon. Zwyciężył Tarantool, który pokazał się z najlepszej strony.
Nie oznacza to, że inne systemy nie spełniają potrzeb MegaFon. Obecne rozwiązania pamięci są tak produktywne, że rezerwy firmy są więcej niż wystarczające. Nas jednak interesuje kontakt z liderem, a nie z kimś, kto pozostaje w tyle, także w teście obciążenia.
Tarantool pokrywa potrzeby firmy nawet w dłuższej perspektywie.
Koszt całkowitego kosztu posiadania. Obsługa Couchbase na wolumenach MegaFon kosztuje astronomiczne kwoty, ale z Tarantool sytuacja jest znacznie przyjemniejsza, a funkcjonalnością są podobne.
Kolejną miłą funkcją, która nieznacznie wpłynęła na nasz wybór, jest to, że Tarantool lepiej współpracuje z pamięcią niż inne bazy danych. On pokazuje maksymalna wydajność.
Niezawodność. MegaFon inwestuje w niezawodność prawdopodobnie bardziej niż ktokolwiek inny. Kiedy więc spojrzeliśmy na Tarantool, zdaliśmy sobie sprawę, że musimy sprawić, aby spełniał nasze wymagania.
Zainwestowaliśmy swój czas i finanse i wspólnie z Mail.ru stworzyliśmy wersję Enterprise, która jest obecnie używana w kilku innych firmach.
Tarantool-enterprise całkowicie nas usatysfakcjonowało pod względem bezpieczeństwa, niezawodności i logowania.
Współpraca
Dla mnie najważniejsze jest bezpośredni kontakt z deweloperem. Właśnie tym przekupili chłopaki z Tarantool.
Jeśli podchodzisz do gracza, zwłaszcza takiego, który pracuje z klientem zakotwiczonym, i mówisz, że potrzebujesz bazy danych, aby móc zrobić to, to i to, zwykle odpowiada:
- OK, umieść wymagania na dole tej sterty - pewnego dnia prawdopodobnie do nich dotrzemy.
Wielu ma plan działania na najbliższe 2-3 lata i integracja tam jest prawie niemożliwa, ale programiści Tarantool urzekają swoją otwartością, i to nie tylko ze strony MegaFona, i dostosowują swój system do klienta. Jest fajnie i naprawdę nam się to podoba.
Gdzie użyliśmy Tarantoolu
Tarantool wykorzystujemy w kilku elementach. Pierwsza z nich jest w pilocie, który zrobiliśmy w systemie katalogów adresowych. Kiedyś chciałem, żeby był to system podobny do Yandex.Maps i Google Maps, ale wyszło trochę inaczej.
Na przykład katalog adresowy w interfejsie sprzedażowym. W Oracle wyszukiwanie żądanego adresu zajmuje 12-13 sekund. - niewygodne liczby. Kiedy przejdziemy na Tarantool, zastąpimy Oracle inną bazą danych w konsoli i wykonamy to samo wyszukiwanie, otrzymamy przyspieszenie 200x! Miasto pojawia się po trzeciej literze. Teraz dostosowujemy interfejs tak, aby działo się to po pierwszym. Jednak szybkość reakcji jest zupełnie inna - milisekundy zamiast sekund.
Druga aplikacja to modny motyw o nazwie IT dwóch prędkości. Dzieje się tak dlatego, że konsultanci z każdego zakątka twierdzą, że korporacje powinny tam się udać.
Jest warstwa infrastruktury, nad nią znajdują się domeny np. system billingowy typu telekomunikacyjny, systemy korporacyjne, raportowanie korporacyjne. To jest rdzeń, którego nie trzeba dotykać. To oczywiście jest możliwe, ale z paranoicznym zapewnieniem jakości, bo to przynosi korporacji pieniądze.
Następna jest warstwa mikroserwisów – co wyróżnia operatora lub innego gracza. W oparciu o określone pamięci podręczne można szybko tworzyć mikrousługi, przenosząc tam dane z różnych domen. Tutaj pole do eksperymentów — jeśli coś nie wychodziło, zamykałem jeden mikroserwis i otwierałem inny. Zapewnia to naprawdę wydłużony czas wprowadzenia produktu na rynek oraz zwiększa niezawodność i szybkość działania firmy.
Mikrousługi to chyba główna rola Tarantoola w MegaFon.
Gdzie planujemy zastosować Tarantool
Jeśli porównamy nasz udany projekt rozliczeniowy z programami transformacji w Deutsche Telekom, Svyazcom, Vodafone India, jest on zaskakująco dynamiczny i kreatywny. W trakcie realizacji tego projektu przekształceniom uległ nie tylko MegaFon i jego struktura, ale także na Mail.ru pojawił się Tarantool-enterprise i nasz dostawca Nexign (dawniej Peter-Service) - BSS Box (pudełkowe rozwiązanie rozliczeniowe).
To w pewnym sensie projekt historyczny dla rynku rosyjskiego. Można to porównać do tego, co opisano w książce „The Mythical Man-Month” Fredericka Brooksa. Następnie, w latach 60., IBM zatrudnił 360 osób do opracowania nowego systemu operacyjnego OS/5 dla komputerów mainframe. Mamy mniej - 000, ale nasi są w kamizelkach i biorąc pod uwagę wykorzystanie open source i nowe podejścia, pracujemy wydajniej.
Poniżej znajdują się domeny billingowe, czyli szerzej systemy biznesowe. Osoby z przedsiębiorstw bardzo dobrze znają CRM. Każdy powinien już mieć inne systemy: Open API, API Gateway.
Otwórz API
Przyjrzyjmy się jeszcze raz liczbom i temu, jak obecnie działa Open API. Jego obciążenie jest 10 000 transakcji na sekundę. Ponieważ planujemy aktywny rozwój warstwy mikroserwisów i budowę publicznego API MegaFon, spodziewamy się w przyszłości większego rozwoju tej części. Na pewno będzie 100 000 transakcji.
Nie wiem, czy możemy porównać z Mail.ru w SSO - wydaje się, że chłopaki mają 1 000 0000 transakcji na sekundę. Ich rozwiązanie jest dla nas niezwykle interesujące i planujemy wykorzystać ich doświadczenia - na przykład wykonanie funkcjonalnego kopii zapasowej SSO przy użyciu Tarantoola. Teraz robią to za nas programiści z Mail.ru.
CRM
CRM to te same 80 milionów abonentów, które chcemy zwiększyć do miliarda, bo jest już 300 milionów dokumentów obejmujących trzyletnią historię. Nie możemy się już doczekać nowych usług i tutaj punktem wzrostu są usługi połączone. To jest kula, która będzie rosła, bo usług będzie coraz więcej. W związku z tym będziemy potrzebować historii, nie chcemy się na nią natknąć.
Samo rozliczanie w zakresie wystawiania faktur, praca z należnościami klientów przekształciła się w odrębną domenę. Aby poprawić wydajność, zastosowany wzór architektoniczny architektury domeny.
System jest podzielony na domeny, obciążenie jest rozdzielone i zapewniona jest odporność na awarie. Dodatkowo pracowaliśmy z architekturą rozproszoną.
Cała reszta to rozwiązania na poziomie przedsiębiorstwa. W pamięci połączeń - 2 miliardy dziennie, 60 miliardów miesięcznie. Czasem trzeba je policzyć w ciągu miesiąca, a lepiej szybko. Monitoring finansowy - to dokładnie te same 300 milionów, które stale rosną i rosną: abonenci często biegają między operatorami, zwiększając tę część.
Najbardziej telekomunikacyjnym elementem komunikacji mobilnej jest rozliczenia internetowe. To systemy, które pozwalają dzwonić lub nie dzwonić, podejmować decyzje w czasie rzeczywistym. Tutaj obciążenie wynosi 30 000 transakcji na sekundę, ale biorąc pod uwagę wzrost transferu danych, tak planujemy 250 000 transakcjii dlatego jesteśmy bardzo zainteresowani Tarantoolem.
Poprzednie zdjęcie przedstawia domeny, w których będziemy używać Tarantoola. Sam CRM jest oczywiście szerszy i będziemy go używać w samym rdzeniu.
Nasza szacunkowa liczba TTX wynosząca 100 milionów abonentów wprawia mnie jako architekta w zakłopotanie – a co jeśli 101 milionów? Czy trzeba wszystko od nowa? Aby temu zapobiec, korzystamy z pamięci podręcznych, zwiększając jednocześnie dostępność.
Ogólnie rzecz biorąc, istnieją dwa podejścia do korzystania z Tarantoolu. Pierwszy - zbuduj wszystkie pamięci podręczne na poziomie mikroserwisów. O ile rozumiem, VimpelCom podąża tą ścieżką, tworząc pamięć podręczną klientów.
Jesteśmy mniej zależni od dostawców, zmieniamy rdzeń BSS, więc mamy jeden plik klienta od razu po wyjęciu z pudełka. Ale chcemy to rozwinąć. Dlatego stosujemy nieco inne podejście – tworzyć pamięci podręczne wewnątrz systemów.
W ten sposób występuje mniejsza synchronizacja – jeden system odpowiada zarówno za pamięć podręczną, jak i główne źródło główne.
Metoda dobrze wpisuje się w podejście Tarantool ze szkieletem transakcyjnym, gdzie aktualizowane są tylko te części, które dotyczą aktualizacji, czyli zmian danych. Wszystko inne można przechowywać gdzie indziej. Nie ma ogromnego jeziora danych, niezarządzanej globalnej pamięci podręcznej. Pamięci podręczne są przeznaczone dla systemu, produktów, klientów lub w celu ułatwienia życia w utrzymaniu. Kiedy abonent dzwoni i jest zdenerwowany jakością Twoich usług, chcesz świadczyć usługi wysokiej jakości.
RTO i RPO
W IT istnieją dwa terminy - RTO и RPO.
Docelowy czas regeneracji to czas potrzebny na przywrócenie usługi po awarii. RTO = 0 oznacza, że nawet jeśli coś się nie powiedzie, usługa będzie nadal działać.
Cel punktu przywracania - to czas odzyskiwania danych, czyli ile danych możemy stracić w danym okresie czasu. RPO = 0 oznacza, że nie tracimy danych.
Zadanie Tarantool
Spróbujmy rozwiązać problem dla Tarantool.
Dany: koszyk aplikacji zrozumiałych dla każdego, na przykład w Amazonie lub gdzie indziej. Wymagane tak, aby koszyk działał 24 godziny na dobę, 7 dni w tygodniu, czyli przez 99,99% czasu. Zamówienia, które do nas przychodzą, muszą być uporządkowane, ponieważ nie możemy losowo włączyć lub wyłączyć łącza abonenta – wszystko musi być ściśle spójne. Poprzednia subskrypcja wpływa na następną, więc dane są ważne - nic nie powinno zaginąć.
decyzja. Możesz spróbować rozwiązać ten problem bezpośrednio i zapytać twórców baz danych, ale problemu nie da się rozwiązać matematycznie. Twierdzenia, prawa zachowania, fizykę kwantową pamiętasz, ale dlaczego - nie da się tego rozwiązać na poziomie DB.
Tutaj sprawdza się stare, dobre podejście architektoniczne – trzeba dobrze poznać tematykę i wykorzystać ją do rozwiązania tej zagadki.
Nasze rozwiązanie: utworzenie rozproszonego rejestru aplikacji na Tarantool – klastrze rozproszonym geograficznie. Na schemacie są to trzy różne centra przetwarzania danych - dwa przed Uralem, jedno za Uralem i rozdzielamy wszystkie żądania pomiędzy tymi ośrodkami.
Netflix, obecnie uważany za jednego z liderów branży IT, do 2012 roku miał tylko jedno centrum danych. W przeddzień katolickiego Bożego Narodzenia, 24 grudnia, to centrum danych uległo awarii. Użytkownicy w Kanadzie i USA zostali bez swoich ulubionych filmów, byli bardzo zdenerwowani i pisali o tym w sieciach społecznościowych. Netflix ma obecnie trzy centra danych na zachodnio-wschodnim wybrzeżu i jedno w Europie Zachodniej.
Początkowo budujemy rozwiązanie rozproszone geograficznie – ważna jest dla nas odporność na awarie.
Mamy więc klaster, ale co z RPO = 0 i RTO = 0? Rozwiązanie jest proste, w zależności od tematu.
Co jest ważne w aplikacjach? Dwie części: rzucanie koszem PRZED podjęcie decyzji o zakupie oraz PO. Część DO w telekomunikacji nazywa się zwykle przechwytywanie zamówień lub negocjacje zamówień. W telekomunikacji może to być znacznie trudniejsze niż w sklepie internetowym, bo tam trzeba obsłużyć klienta, zaproponować mu 5 opcji i to wszystko trwa jakiś czas, ale koszyk jest zapełniony. W tym momencie awaria jest możliwa, ale nie jest straszna, ponieważ dzieje się interaktywnie pod nadzorem człowieka.
Jeśli centrum danych w Moskwie nagle ulegnie awarii, automatycznie przełączając się do innego centrum danych, będziemy kontynuować pracę. Teoretycznie może zaginąć jeden produkt w koszyku, ale widzisz go, dodajesz go ponownie do koszyka i pracujesz dalej. W tym przypadku RTO = 0.
Jednocześnie istnieje druga możliwość: klikając „wyślij” chcemy, aby dane nie zostały utracone. Od tego momentu zaczyna działać automatyzacja – jest to RPO = 0. Stosując te dwa różne wzorce, w jednym przypadku mógłby to być po prostu rozproszony geograficznie klaster z jednym przełączalnym modułem głównym, w innym przypadku jakiś zapis kworum. Wzory mogą się różnić, ale rozwiązujemy problem.
Co więcej, mając rozproszony rejestr aplikacji, możemy to wszystko skalować - mieć wielu dyspozytorów i wykonawców mających dostęp do tego rejestru.
Cassandra i Tarantool razem
Jest jeszcze jeden przypadek – „prezentacja sald”. Oto ciekawy przypadek wspólnego wykorzystania Cassandry i Tarantoola.
Używamy Cassandry, ponieważ 2 miliardy połączeń dziennie to nie limit, a będzie ich więcej. Marketerzy uwielbiają koloryzować ruch według źródła, na przykład w sieciach społecznościowych pojawia się coraz więcej szczegółów. To wszystko dodaje opowieści.
Cassandra umożliwia skalowanie w poziomie do dowolnego rozmiaru.
Dobrze się czujemy z Cassandrą, ma ona jednak jeden problem – nie radzi sobie dobrze z czytaniem. Na nagraniu wszystko OK, 30 000 na sekundę to nie problem - problem z czytaniem.
W związku z tym pojawił się temat z pamięcią podręczną, a jednocześnie rozwiązaliśmy następujący problem: istnieje stary, tradycyjny przypadek, gdy sprzęt z przełącznika z fakturowania online trafia do plików, które ładujemy do Cassandry. Zmagaliśmy się z problemem niezawodnego pobierania tych plików, nawet korzystając z porad IBM managera transferu plików - istnieją rozwiązania, które sprawnie zarządzają przesyłaniem plików, wykorzystując na przykład protokół UDP, a nie TCP. To dobrze, ale to jeszcze minuty, a my jeszcze wszystkiego nie załadowaliśmy, operator w call center nie jest w stanie odpowiedzieć klientowi, co stało się z jego saldem - musimy poczekać.
Aby temu zapobiec, my używamy równoległej rezerwy funkcjonalnej. Gdy wyślemy zdarzenie poprzez Kafkę do Tarantoola, przeliczając agregaty w czasie rzeczywistym np. na dzień dzisiejszy, otrzymamy salda gotówkowe, który może przesyłać salda z dowolną prędkością, na przykład 100 tysięcy transakcji na sekundę i te same 2 sekundy.
Celem jest, aby po wykonaniu połączenia w ciągu 2 sekund na Twoim koncie osobistym znajdowało się nie tylko zmienione saldo, ale także informacja o przyczynie zmiany.
wniosek
To były przykłady wykorzystania Tarantoolu. Naprawdę podobała nam się otwartość Mail.ru i ich chęć rozpatrywania różnych przypadków.
Konsultantom z BCG czy McKinsey, Accenture czy IBM jest już trudno zaskoczyć nas czymś nowym – większość z tego, co oferują, albo już zrobiliśmy, zrobiliśmy, albo planujemy zrobić. Myślę, że Tarantool zajmie należne mu miejsce w naszym stosie technologicznym i zastąpi wiele istniejących technologii. Jesteśmy w aktywnej fazie rozwoju tego projektu.
Sprawozdanie Olega i Andrieja jest jednym z najlepszych na ubiegłorocznej konferencji Tarantool, a 17 czerwca Oleg Ivlev będzie przemawiał na z raportem . Prezentację MegaFon wygłosi także Alexander Deulin . Dowiedzmy się, co się zmieniło, jakie plany zostały wdrożone. Dołącz - konferencja jest bezpłatna, wystarczy, że weźmiesz w niej udział , wszystko i powstał program konferencji: nowe przypadki, nowe doświadczenia w korzystaniu z Tarantoola, architektura, Enterprise, tutoriale i mikroserwisy.
Źródło: www.habr.com