"Bizning maxfiy olamimiz: hujayraning yashirin hayoti" filmidan lavha

Investitsion biznes bank dunyosidagi eng murakkab sohalardan biridir, chunki nafaqat kreditlar, qarzlar va depozitlar, balki qimmatli qog'ozlar, valyutalar, tovarlar, derivativlar va tuzilgan mahsulotlar ko'rinishidagi barcha turdagi murakkabliklar mavjud.

So‘nggi paytlarda aholining moliyaviy savodxonligi oshganiga guvoh bo‘ldik. Ko'proq odamlar qimmatli qog'ozlar bozorida savdo qilish bilan shug'ullanmoqda. Individual investitsiya hisoblari yaqinda paydo bo'lgan. Ular sizga qimmatli qog'ozlar bozorida savdo qilish va soliq imtiyozlarini olish yoki soliq to'lashdan qochish imkonini beradi. Va bizga kelgan barcha mijozlar o'z portfelini boshqarishni va real vaqt rejimida hisobotlarni ko'rishni xohlashadi. Bundan tashqari, ko'pincha bu portfel ko'p mahsulotdir, ya'ni odamlar turli biznes yo'nalishlarining mijozlari hisoblanadi.

Bundan tashqari, Rossiya va xorijiy tartibga soluvchi organlarning ehtiyojlari ortib bormoqda.

Mavjud ehtiyojlarni qondirish va kelajakdagi yangilanishlar uchun poydevor qo'yish uchun biz Tarantool asosidagi investitsiya biznesining yadrosini ishlab chiqdik.

Ba'zi statistika. Alfa-Bank investitsiya biznesi jismoniy va yuridik shaxslarga turli qimmatli qog'ozlar bozorlarida savdo qilish imkoniyatini taqdim etish uchun brokerlik xizmatlarini, qimmatli qog'ozlarni saqlash bo'yicha depozitariy xizmatlarini, xususiy va yirik kapitalga ega jismoniy shaxslar uchun ishonchli boshqaruv xizmatlarini, boshqa kompaniyalar uchun qimmatli qog'ozlarni chiqarish bo'yicha xizmatlarni taqdim etadi. . Alfa-Bankning sarmoyaviy biznesi turli savdo platformalaridan yuklab olinadigan soniyada 3 mingdan ortiq kotirovkalarni o'z ichiga oladi. Ish kuni davomida bozorlarda bank yoki uning mijozlari nomidan 300 mingdan ortiq bitim tuziladi. Tashqi va ichki platformalarda soniyada 5 mingtagacha buyurtma bajarilishi sodir bo'ladi. Shu bilan birga, barcha ichki va tashqi mijozlar o'z pozitsiyalarini real vaqt rejimida ko'rishni xohlashadi.

Sana oldin

2000-yillarning boshidan boshlab bizning investitsiya biznesimiz sohalari mustaqil ravishda rivojlandi: birja savdosi, brokerlik xizmatlari, valyuta savdosi, qimmatli qog'ozlar va turli derivativlar bilan birjadan tashqari savdo. Natijada biz funktsional quduqlar tuzog'iga tushib qoldik. Bu nima? Har bir biznes yo'nalishi bir-birining funktsiyalarini takrorlaydigan o'z tizimlariga ega. Har bir tizim o'ziga xos ma'lumotlar modeliga ega, garchi ular bir xil tushunchalar bilan ishlaydi: tranzaktsiyalar, asboblar, kontragentlar, kotirovkalar va boshqalar. Va har bir tizim mustaqil ravishda rivojlanib borar ekan, turli xil texnologiyalar hayvonot bog'i paydo bo'ldi.

Bundan tashqari, tizimlarning kod bazasi allaqachon eskirgan, chunki ba'zi mahsulotlar 1990-yillarning o'rtalarida paydo bo'lgan. Va ba'zi hududlarda bu rivojlanish jarayonini sekinlashtirdi va ishlash bilan bog'liq muammolar mavjud edi.

Yangi yechimga qo'yiladigan talablar

Korxonalar texnologik transformatsiya keyingi rivojlanish uchun juda muhim ekanligini anglab yetdi. Bizga vazifalar berildi:

1. Barcha biznes ma'lumotlarini bitta, tezkor xotirada va yagona ma'lumotlar modelida to'plang.
2. Biz ushbu ma'lumotni yo'qotmasligimiz yoki o'zgartirmasligimiz kerak.
3. Ma'lumotlarning versiyasini yaratish kerak, chunki istalgan vaqtda regulyator o'tgan yillar uchun statistikani so'rashi mumkin.
4. Biz nafaqat yangi, zamonaviy DBMSni olib kelishimiz, balki biznes muammolarini hal qilish uchun platforma yaratishimiz kerak.

Bundan tashqari, bizning me'morlarimiz o'z shartlarini belgilaydilar:

1. Yangi yechim korxona darajasida bo'lishi kerak, ya'ni u allaqachon ba'zi yirik kompaniyalarda sinovdan o'tkazilishi kerak.
2. Yechimning ishlash rejimi muhim vazifa bo'lishi kerak. Bu shuni anglatadiki, biz bir vaqtning o'zida bir nechta ma'lumotlar markazlarida bo'lishimiz va bitta ma'lumot markazining uzilishidan xotirjam omon qolishimiz kerak.
3. Tizim gorizontal ravishda kengaytirilishi kerak. Haqiqat shundaki, bizning barcha mavjud tizimlarimiz faqat vertikal ravishda kengaytirilishi mumkin va biz apparat quvvatining past o'sishi tufayli biz allaqachon shiftga urmoqdamiz. Shu sababli, omon qolish uchun gorizontal ravishda kengaytiriladigan tizimga ega bo'lishimiz kerak bo'lgan vaqt keldi.
4. Boshqa narsalar qatorida, bizga yechim arzon bo'lishi kerakligini aytishdi.

Biz standart marshrutga rioya qildik: biz talablarni shakllantirdik va sotib olish bo'limiga murojaat qildik. U erdan biz, umuman olganda, biz uchun buni qilishga tayyor bo'lgan kompaniyalar ro'yxatini oldik. Biz hammaga muammo haqida gapirib berdik va oltitasidan yechimlar bahosini oldik.

Bankda biz hech kimning so'zini qabul qilmaymiz, biz hamma narsani o'zimiz sinab ko'rishni yaxshi ko'ramiz. Shuning uchun tender tanlovining majburiy sharti yuk sinovlaridan o'tish edi. Biz yuk sinovi topshiriqlarini ishlab chiqdik va oltita kompaniyadan uchtasi uni sinab ko'rish uchun o'z mablag'lari hisobidan xotiradagi texnologiyalarga asoslangan prototip yechimni joriy etishga rozi bo'ldi.

Men sizga hamma narsani qanday sinovdan o'tkazganimizni va qancha vaqt davom etganimizni aytmayman, men shunchaki umumlashtiraman: yuk sinovlarida eng yaxshi ko'rsatkich Mail.ru Group ishlab chiqish jamoasidan Tarantool asosidagi prototip echimida ko'rsatildi. Biz shartnoma imzoladik va rivojlanishni boshladik. Mail.ru guruhidan to'rt kishi, Alfa-Bankdan esa uchta ishlab chiquvchi, uchta tizim tahlilchisi, yechim arxitektori, mahsulot egasi va Scrum ustasi bor edi.

Keyin men sizga bizning tizimimiz qanday o'sganligi, qanday rivojlanganligi, nima qilganimiz va nima uchun aynan shundayligi haqida gapirib beraman.

Rivojlanish

Biz o'zimizga bergan birinchi savol - hozirgi tizimlarimizdan ma'lumotlarni qanday olish kerak edi. Biz HTTP biz uchun juda mos deb qaror qildik, chunki barcha joriy tizimlar HTTP orqali XML yoki JSON yuborish orqali bir-biri bilan aloqa qiladi.

Biz Tarantool-ga o'rnatilgan HTTP serveridan foydalanamiz, chunki SSL seanslarini tugatishimiz shart emas va uning ishlashi biz uchun etarli.

Yuqorida aytib o'tganimdek, bizning barcha tizimlarimiz turli xil ma'lumotlar modellarida yashaydi va kirishda biz ob'ektni o'zimiz tasvirlaydigan modelga keltirishimiz kerak. Ma'lumotlarni o'zgartirishga imkon beradigan til kerak edi. Biz imperativ Lua ni tanladik. Biz barcha ma'lumotlarni konvertatsiya qilish kodini sinov muhitida ishlatamiz - bu xavfsiz joy, undan tashqarida ishlaydigan kod o'tmaydi. Buning uchun biz shunchaki kerakli kodni yuklaymiz, hech narsani bloklay olmaydigan yoki tashlab ketmaydigan funksiyalarga ega muhit yaratamiz.

Konvertatsiya qilingandan so'ng, ma'lumotlar biz yaratayotgan modelga muvofiqligini tekshirish kerak. Biz model qanday bo'lishi kerakligini va uni tasvirlash uchun qaysi tildan foydalanishni uzoq vaqt muhokama qildik. Biz Apache Avro ni tanladik, chunki til sodda va u Tarantool tomonidan qo'llab-quvvatlanadi. Modelning yangi versiyalari va maxsus kodlar kuniga bir necha marta, hatto yuk ostida yoki bo'lmasdan, kunning istalgan vaqtida ishga tushirilishi mumkin va o'zgarishlarga juda tez moslashadi.

Tekshiruvdan so'ng ma'lumotlar saqlanishi kerak. Biz buni vshard yordamida qilamiz (bizda parchalarning geo-tarqalgan nusxalari mavjud).

Bundan tashqari, o'ziga xoslik shundaki, bizga ma'lumotlarni yuboradigan ko'pchilik tizimlar biz uni olgan yoki olmaganligimizga ahamiyat bermaydilar. Shuning uchun biz boshidanoq ta'mirlash navbatini joriy qildik. Bu nima? Agar biron sababga ko'ra ob'ekt ma'lumotlarni o'zgartirish yoki tekshirishdan o'tmasa, biz hali ham qabul qilishni tasdiqlaymiz, lekin ayni paytda ob'ektni ta'mirlash navbatida saqlaymiz. U izchil va asosiy biznes ma'lumotlar omborida joylashgan. Biz darhol uning uchun administrator interfeysini, turli ko'rsatkichlar va ogohlantirishlarni yozdik. Natijada biz ma'lumotlarni yo'qotmaymiz. Manbada biror narsa o'zgargan bo'lsa ham, agar ma'lumotlar modeli o'zgargan bo'lsa, biz uni darhol aniqlaymiz va moslasha olamiz.

Endi siz saqlangan ma'lumotlarni qanday qilib olishni o'rganishingiz kerak. Biz tizimlarimizni sinchkovlik bilan tahlil qildik va Java va Oracle klassik stekida ma'lumotlarni relyatsiondan ob'ektga o'zgartiruvchi qandaydir ORM turi mavjudligini ko'rdik. Xo'sh, nega darhol ob'ektlarni tizimlarga grafik ko'rinishida bermaslik kerak? Shunday qilib, biz barcha ehtiyojlarimizga javob beradigan GraphQL-ni mamnuniyat bilan qabul qildik. Bu sizga grafiklar ko'rinishidagi ma'lumotlarni olish va faqat hozir kerak bo'lgan narsalarni tortib olish imkonini beradi. Siz hatto juda ko'p moslashuvchanlik bilan API versiyasini yaratishingiz mumkin.

Deyarli darhol biz olingan ma'lumotlar etarli emasligini angladik. Biz modeldagi ob'ektlar bilan bog'lanishi mumkin bo'lgan funktsiyalarni yaratdik - asosan hisoblangan maydonlar. Ya'ni, biz, masalan, o'rtacha kotirovka narxini hisoblab chiqadigan maydonga ma'lum bir funktsiyani biriktiramiz. Va ma'lumotlarni so'ragan tashqi iste'molchi bu hisoblangan maydon ekanligini ham bilmaydi.

Autentifikatsiya tizimini joriy qildi.

Keyin qarorimizda bir nechta rollar kristallanganligini payqadik. Rol - bu funksiyalarning bir turi. Odatda, rollar turli xil uskunalardan foydalanish profillariga ega:

• T-Connect: kiruvchi ulanishlarni boshqaradi, CPU cheklangan, kam xotira iste'moli, fuqaroligi yo'q.
• IB-Core: Tarantool protokoli orqali olingan ma'lumotlarni o'zgartiradi, ya'ni jadvallar bilan ishlaydi. Shuningdek, u holatni saqlamaydi va kengaytirilishi mumkin.
• Saqlash: faqat ma'lumotlarni saqlaydi, hech qanday mantiqdan foydalanmaydi. Bu rol eng oddiy interfeyslarni amalga oshiradi. Vshard tufayli kengaytirilishi mumkin.

Ya'ni, rollardan foydalanib, biz klasterning turli qismlarini bir-biridan ajratdik, ular bir-biridan mustaqil ravishda o'lchab qo'yilishi mumkin.

Shunday qilib, biz asinxron tranzaksiyaviy ma'lumotlar oqimini qayd etish va administrator interfeysi bilan ta'mirlash navbatini yaratdik. Yozuv biznes nuqtai nazaridan asinxrondir: agar bizga qaerda bo'lishidan qat'i nazar, o'zimizga ma'lumot yozish kafolatlangan bo'lsa, biz buni tasdiqlaymiz. Agar u tasdiqlanmasa, unda biror narsa noto'g'ri ketdi va ma'lumotlar yuborilishi kerak. Bu asinxron yozuv.

Viktorina

Loyihaning boshidanoq biz sinovga asoslangan rivojlanishni amalga oshirishga harakat qilishga qaror qildik. Biz tarantool/tap tizimidan foydalangan holda Lua-da birlik testlarini va pytest ramkasidan foydalangan holda Python-da integratsiya testlarini yozamiz. Shu bilan birga, biz integratsiya testlarini yozishda ishlab chiquvchilarni ham, tahlilchilarni ham jalb qilamiz.

Sinovga asoslangan rivojlanishdan qanday foydalanamiz?

Agar biz yangi xususiyatni xohlasak, avval u uchun test yozishga harakat qilamiz. Xatoni aniqlaganimizda, avval test yozishga ishonch hosil qilamiz va shundan keyingina uni tuzatamiz. Avvaliga bunday ishlash qiyin, xodimlar tomonidan tushunmovchilik, hatto sabotaj ham mavjud: "Keling, hozir uni tezda tuzatamiz, yangi narsa qilamiz va keyin uni testlar bilan yopamiz." Faqat bu "keyinroq" deyarli hech qachon kelmaydi.

Shuning uchun, siz avval testlarni yozishga majburlashingiz va boshqalardan buni qilishni so'rashingiz kerak. Ishoning, sinov asosidagi rivojlanish hatto qisqa muddatda ham foyda keltiradi. Hayotingiz osonlashganini his qilasiz. Kodning 99 foizi endi sinovlar bilan qoplanganini his qilyapmiz. Bu juda ko'p ko'rinadi, lekin bizda hech qanday muammo yo'q: testlar har bir topshiriqda ishlaydi.

Biroq, biz eng yaxshi ko'rgan narsa bu yuk sinovidir; biz buni eng muhim deb hisoblaymiz va uni muntazam ravishda bajaramiz.

Men sizga birinchi versiyalardan birining yuk sinovining birinchi bosqichini qanday o'tkazganimiz haqida bir oz hikoya aytib beraman. Biz tizimni ishlab chiquvchining noutbukiga o'rnatdik, yukni yoqdik va soniyada 4 ming tranzaksiya oldik. Noutbuk uchun yaxshi natija. Biz uni ishlab chiqarishdan ko'ra zaifroq bo'lgan to'rtta serverdan iborat virtual yuk skameykasiga o'rnatdik. Minimal darajada joylashtirilgan. Biz uni ishga tushiramiz va bitta ipda noutbukdan ko'ra yomonroq natijaga erishamiz. Shok tarkibi.

Biz juda xafa bo'ldik. Biz server yukiga qaraymiz, lekin ular bo'sh ekan.

Biz ishlab chiquvchilarga qo'ng'iroq qilamiz va ular bizga, Java dunyosidan kelgan odamlarga Tarantoolning bir torli ekanligini tushuntiradilar. U yuk ostida faqat bitta protsessor yadrosi tomonidan samarali ishlatilishi mumkin. Keyin biz har bir serverda maksimal mumkin bo'lgan Tarantool nusxalarini joylashtirdik, yukni yoqdik va sekundiga 14,5 ming tranzaksiya oldik.

Yana tushuntiraman. Resurslarni boshqacha ishlatadigan rollarga bo'linganligi sababli, ulanishlarni qayta ishlash va ma'lumotlarni o'zgartirish uchun mas'ul bo'lgan rollarimiz faqat protsessorni yuklaydi va yukga qat'iy proportsionaldir.

Bunday holda, xotira faqat kiruvchi ulanishlar va vaqtinchalik ob'ektlarni qayta ishlash uchun ishlatilgan.

Aksincha, saqlash serverlarida protsessor yuki ortdi, lekin ulanishlarni qayta ishlaydigan serverlarga qaraganda ancha sekinroq.

Va xotira iste'moli yuklangan ma'lumotlar miqdoriga to'g'ridan-to'g'ri proportsional ravishda o'sdi.

xizmatlar

Yangi mahsulotimizni amaliy platforma sifatida ishlab chiqish uchun biz unda xizmatlar va kutubxonalarni joylashtirish uchun komponent yaratdik.

Xizmatlar faqat ba'zi sohalarda ishlaydigan kodning kichik qismlari emas. Ular klasterning bir qismi bo'lgan, ma'lumotnoma ma'lumotlarini tekshirish, biznes mantig'ini boshqarish va javoblarni qaytarish uchun juda katta va murakkab tuzilmalar bo'lishi mumkin. Shuningdek, biz xizmat sxemasini GraphQL-ga eksport qilamiz va iste'molchi butun model bo'ylab introspektsiya bilan ma'lumotlarga universal kirish nuqtasini oladi. Bu juda qulay.

Xizmatlar ko'plab boshqa funktsiyalarni o'z ichiga olganligi sababli, biz tez-tez ishlatiladigan kodlarni ko'chiradigan kutubxonalar bo'lishi kerak deb qaror qildik. Biz ularni xavfsiz muhitga qo'shdik, bu biz uchun hech narsani buzmasligini oldindan tekshirib ko'rdik. Va endi biz kutubxonalar ko'rinishidagi funktsiyalarga qo'shimcha muhitlarni belgilashimiz mumkin.

Biz nafaqat saqlash uchun, balki hisoblash uchun ham platformaga ega bo'lishni xohladik. Va bizda allaqachon bir nechta nusxalar va parchalar bo'lganligi sababli, biz taqsimlangan hisoblashning bir turini amalga oshirdik va uni xaritani qisqartirish deb nomladik, chunki u asl xaritani qisqartirishga o'xshash bo'lib chiqdi.

Eski tizimlar

Bizning barcha eski tizimlarimiz bizga HTTP orqali qo'ng'iroq qila olmaydi va GraphQL-dan foydalana olmaydi, garchi ular protokolni qo'llab-quvvatlaydi. Shuning uchun biz ma'lumotlarni ushbu tizimlarga ko'paytirish imkonini beruvchi mexanizmni yaratdik.

Agar biz uchun biror narsa o'zgargan bo'lsa, "Saqlash" rolida noyob triggerlar ishga tushiriladi va o'zgarishlar kiritilgan xabar ishlov berish navbatida tugaydi. U alohida replikator roli yordamida tashqi tizimga yuboriladi. Bu rol holatni saqlamaydi.

Yangi yaxshilanishlar

Esingizda bo'lsa, biz biznes nuqtai nazaridan asinxron yozishni amalga oshirdik. Ammo keyin ular bu etarli bo'lmasligini tushunishdi, chunki operatsiya holati to'g'risida darhol javob olish kerak bo'lgan tizimlar sinfi mavjud. Shunday qilib, biz GraphQL-ni kengaytirdik va mutatsiyalarni qo'shdik. Ular ma'lumotlar bilan ishlashning mavjud paradigmasiga organik ravishda mos keladi. Biz uchun bu boshqa tizimlar sinfi uchun o'qish va yozishning yagona nuqtasidir.

Biz, shuningdek, xizmatlarning o'zi biz uchun etarli emasligini angladik, chunki kuniga, haftasiga, oyiga bir marta qurilishi kerak bo'lgan juda og'ir hisobotlar mavjud. Bu uzoq vaqt talab qilishi mumkin va hisobotlar hatto Tarantoolning voqealar tsiklini bloklashi mumkin. Shuning uchun biz alohida rollarni yaratdik: rejalashtiruvchi va yuguruvchi. Yuguruvchilar holatni saqlamaydilar. Ular biz tezda hisoblab bo'lmaydigan og'ir vazifalarni bajaradilar. Va rejalashtiruvchi roli konfiguratsiyada tasvirlangan ushbu vazifalarni ishga tushirish jadvalini nazorat qiladi. Vazifalarning o'zi biznes ma'lumotlari bilan bir joyda saqlanadi. Kerakli vaqt kelganda, rejalashtiruvchi topshiriqni oladi, uni bir necha yuguruvchiga beradi, u hisoblaydi va natijani saqlaydi.

Barcha vazifalarni jadval asosida bajarish shart emas. Ba'zi hisobotlar talab bo'yicha o'qilishi kerak. Ushbu talab kelishi bilanoq, qum qutisida vazifa yaratiladi va bajarish uchun yuguruvchiga yuboriladi. Biroz vaqt o'tgach, foydalanuvchi hamma narsa hisoblangan va hisobot tayyor bo'lgan asinxron javob oladi.

Dastlab, biz barcha ma'lumotlarni saqlash, uni versiyalash va o'chirmaslik paradigmasiga amal qildik. Ammo hayotda vaqti-vaqti bilan siz hali ham biror narsani, asosan, xom yoki oraliq ma'lumotlarni o'chirib tashlashingiz kerak. Muddati tugaganidan kelib chiqib, biz xotirani eskirgan ma'lumotlardan tozalash mexanizmini yaratdik.

Shuningdek, biz ertami-kechmi xotirada ma'lumotlarni saqlash uchun etarli joy bo'lmagan vaziyat yuzaga kelishini tushunamiz, ammo shunga qaramay, ma'lumotlar saqlanishi kerak. Ushbu maqsadlar uchun biz tez orada disk xotirasini yaratamiz.

xulosa

Biz ma'lumotlarni yagona modelga yuklash vazifasidan boshladik va uni ishlab chiqish uchun uch oy vaqt sarfladik. Bizda oltita ma'lumot ta'minoti tizimi mavjud edi. Bitta modelga aylantirishning butun kodi Luada taxminan 30 ming qatorni tashkil qiladi. Va ishning katta qismi hali oldinda. Ba'zida qo'shni jamoalarda motivatsiya yetishmayapti, ishni murakkablashtiradigan holatlar ko'p bo'ladi. Agar siz ham shunga o'xshash vazifaga duch kelsangiz, uni amalga oshirish uchun sizga odatiy bo'lib tuyulgan vaqtni uch yoki hatto to'rtga ko'paytiring.

Shuni ham yodda tutingki, biznes jarayonlaridagi mavjud muammolarni yangi DBMS yordamida, hatto juda samarali bo'lsa ham hal qilib bo'lmaydi. Nima demoqchiman? Loyihamizning boshida biz mijozlarda endi yangi tezkor ma'lumotlar bazasini olib kelamiz va biz yashaymiz degan taassurot qoldirdik! Jarayonlar tezroq ketadi, hamma narsa yaxshi bo'ladi. Aslida, texnologiya biznes jarayonlaridagi muammolarni hal qilmaydi, chunki biznes jarayonlari odamlardir. Va siz texnologiya emas, balki odamlar bilan ishlashingiz kerak.

Sinovga asoslangan rivojlanish dastlabki bosqichlarda og'riqli va ko'p vaqt talab qilishi mumkin. Ammo uning ijobiy ta'siri qisqa muddatda ham sezilarli bo'ladi, regressiya testini o'tkazish uchun hech narsa qilish kerak emas.

Rivojlanishning barcha bosqichlarida yuk sinovlarini o'tkazish juda muhimdir. Arxitekturadagi ba'zi bir kamchilikni qanchalik tez sezsangiz, uni tuzatish osonroq bo'ladi, bu kelajakda ko'p vaqtni tejaydi.

Lua bilan hech qanday yomon narsa yo'q. Unda har kim yozishni o'rganishi mumkin: Java dasturchisi, JavaScript dasturchisi, Python dasturchisi, front-end yoki back-end. Hatto bizning tahlilchilarimiz ham bu haqda yozishadi.

Bizda SQL yo'qligi haqida gapirganda, bu odamlarni dahshatga soladi. “SQLsiz ma’lumotlarni qanday olish mumkin? Bu mumkinmi? Albatta. OLTP sinf tizimida SQL kerak emas. Sizni darhol hujjatga yo'naltirilgan ko'rinishga qaytaradigan qandaydir til shaklida muqobil mavjud. Masalan, GraphQL. Va taqsimlangan hisoblash shaklida muqobil mavjud.

Agar siz masshtab qo'yishingiz kerakligini tushunsangiz, Tarantool-da yechimingizni o'nlab Tarantool misollarida parallel ravishda ishlay oladigan tarzda loyihalashtiring. Agar buni qilmasangiz, keyinchalik bu qiyin va og'riqli bo'ladi, chunki Tarantool faqat bitta protsessor yadrosidan samarali foydalanishi mumkin.

Manba: www.habr.com