Dîsa ji fîlima "Gerîna me veşartî: Jiyana veşartî ya hucreyê"

Karsaziya veberhênanê di cîhana bankingê de yek ji deverên herî tevlihev e, ji ber ku ne tenê deyn, deyn û depo, lê di heman demê de ewlekarî, dirav, kelûmel, derûv û her cûre tevliheviyên di forma hilberên sazkirî de jî hene.

Di van demên dawî de, me dît ku xwendina aborî ya nifûsê zêde bûye. Zêdetir kes di bazarên ewlehiyê de mijûlî bazirganiyê dibin. Hesabên veberhênanê yên kesane ne ewqas demek berê xuya bûn. Ew dihêlin ku hûn bazarên ewlehiyê bazirganî bikin û an daxistina bacê bistînin an ji dayîna bacê dûr bixin. Û hemî xerîdarên ku têne ba me dixwazin portfolioya xwe îdare bikin û di wextê rast de raporê bibînin. Wekî din, pir caran ev portfolio pir-hilber e, ango mirov xerîdarên cûrbecûr xetên karsaziyê ne.

Wekî din, hewcedariyên sazûmankeran, hem rûsî û hem jî biyanî, zêde dibin.

Ji bo bicihanîna hewcedariyên heyî û danîna bingehek ji nûvekirinên pêşerojê re, me bingehek karsaziya veberhênanê li ser bingeha Tarantool pêşxistiye.

Hin statîstîk. Karsaziya veberhênanê ya Alfa-Bank ji bo kes û saziyên dadrêsî karûbarên brokerkirinê peyda dike da ku fersendê danûstendinê li ser bazarên cihêreng ên ewlehiyê, karûbarên depokirinê ji bo hilanîna ewlehiyê, karûbarên rêveberiya pêbaweriyê ji bo kesên xwedî sermayeya taybet û mezin, karûbarên derxistina ewlehiyê ji bo pargîdaniyên din. . Karsaziya veberhênanê ya Alfa-Bank di çirkeyê de zêdetirî 3 hezar quotes digire, ku ji platformên bazirganiyê yên cihêreng têne dakêşandin. Di nava roja xebatê de li ser navê bankê yan jî muwekîlên wê li bazaran zêdeyî 300 hezar danûstandin tên kirin. Li ser platformên derve û hundir di çirkeyê de heta 5 hezar ferman pêk tên. Di heman demê de, hemî xerîdar, hem hundur hem jî derveyî, dixwazin pozîsyonên xwe di wextê rast de bibînin.

pêşdîrok

Li deverek ji destpêka salên 2000-an ve, qadên me yên karsaziya veberhênanê serbixwe pêş ketin: bazirganiya danûstendinê, karûbarên brokerkirinê, bazirganiya diravî, bazirganiya li ser-counter li ser ewlehiyê û derûvên cihêreng. Di encamê de em ketine xefika bîrên fonksîyonel. Ew çi ye? Her rêzek karsaziyê pergalên xwe hene ku fonksiyonên hevdu dubare dikin. Her pergal xwedan modela daneya xwe ye, her çend ew bi heman têgehan tevdigerin: danûstendin, amûr, hevalbend, quotes û hwd. Û her ku her pergal bi rengek serbixwe pêş ket, zooyek cihêreng a teknolojiyê derket holê.

Wekî din, bingeha kodê ya pergalan jixwe pir kevn e, ji ber ku hin hilber di nîvê salên 1990-an de derketine. Û li hin deveran ev pêvajoya pêşveçûnê hêdî kir, û pirsgirêkên performansê hebûn.

Pêdiviyên ji bo çareseriya nû

Karsaz fêm kirine ku veguherîna teknolojîk ji bo pêşkeftina pêşdetir girîng e. Ji me re peywir hatin dayîn:

1. Hemî daneyên karsaziyê di hilanînek yek, bilez û di modelek daneyê de berhev bikin.
2. Divê em vê agahiyê winda nekin an biguherînin.
3. Pêdivî ye ku daneyan versiyon bikin, ji ber ku di her kêliyê de regulator dikare statîstîkên salên berê bixwaze.
4. Pêdivî ye ku em ne tenê hin DBMS-ên nû, moda bînin, lê ji bo çareserkirina pirsgirêkên karsaziyê platformek biafirînin.

Wekî din, mîmarên me şertên xwe destnîşan dikin:

1. Pêdivî ye ku çareseriya nû ji pola pargîdanî be, ango, divê ew berê di hin pargîdaniyên mezin de were ceribandin.
2. Divê moda xebatê ya çareseriyê mîsyonek krîtîk be. Ev tê vê wateyê ku divê em bi hevdemî li çend navendên daneyê amade bin û bi aramî ji qutbûna yek navendek daneyê rizgar bibin.
3. Pêdivî ye ku pergal bi rengek horizontî berbelav be. Rastî ev e ku hemî pergalên me yên heyî tenê bi rengek berbi berbelavkirî ne, û ji ber mezinbûna kêm a hêza hardware em berê xwe didin tavan. Ji ber vê yekê, kêliya ku em hewce ne ku ji bo zindîbûnê xwedan pergalek berbelavkirî ya horîzontal be.
4. Di nav tiştên din de ji me re gotin ku divê çareserî erzan be.

Me rêça standard şopand: me hewcedarî formule kir û bi beşa kirînê re têkilî danî. Ji wir me navnîşek pargîdaniyan wergirt ku, bi gelemperî, amade ne ku vê yekê ji bo me bikin. Me ji her kesî re behsa pirsgirêkê kir, û ji şeş ji wan re nirxandina çareseriyê wergirt.

Li bankê, em gotina kesek nagirin; em dixwazin her tiştî bi xwe biceribînin. Ji ber vê yekê, şertek mecbûrî ya pêşbaziya me ya îhaleyê derbaskirina ceribandinên barkirinê bû. Me peywirên ceribandina barkirinê formule kir, û sê ji şeş pargîdaniyan berê li hev kirine ku ji bo ceribandina wê çareseriyek prototîpek li ser bingeha teknolojiyên bîranînê bi lêçûnên xwe bicîh bikin.

Ez ê ji we re nebêjim ka me her tişt çawa ceriband û çiqas dirêj girt, ez ê tenê kurt bikim: performansa çêtirîn di ceribandinên barkirinê de ji hêla çareseriyek prototîp a li ser bingeha Tarantool ji tîmê pêşkeftina Koma Mail.ru hate destnîşan kirin. Me peymanek îmze kir û dest bi pêşveçûnê kir. Ji Koma Mail.ru çar kes hebûn, û ji Alfa-Bank sê pêşdebir, sê analîstên pergalê, mîmarek çareseriyê, xwedan hilberê û masterek Scrum hebûn.

Dûv re ez ê ji we re vebêjim ka pergala me çawa mezin bû, ew çawa pêş ket, me çi kir û çima bi rastî ev.

Pêşveçûn

Pirsa yekem ku me ji xwe pirsî ev bû ku meriv çawa daneyan ji pergalên xwe yên heyî werdigire. Me biryar da ku HTTP ji bo me pir maqûl bû, ji ber ku hemî pergalên heyî bi şandina XML an JSON li ser HTTP bi hev re diaxivin.

Em servera HTTP ya ku di Tarantool de hatî çêkirin bikar tînin ji ber ku em ne hewce ne ku danişînên SSL biqedînin, û performansa wê ji me re bes e.

Wekî ku min berê jî got, hemî pergalên me di modelên daneya cihêreng de dijîn, û di têketinê de pêdivî ye ku em tiştê ku em ji xwe re diyar dikin bînin. Zimanek hewce bû ku destûrê bide guhertina daneyan. Me Lua mecbûrî hilbijart. Em hemî koda guheztina daneyê di sandboxek de dimeşînin - ev cîhek ewle ye ku ji wê derê koda xebitandinê naçe. Ji bo vê yekê, em bi tenê koda pêwîst bar dikin, hawîrdorek bi fonksiyonan diafirînin ku nikaribin tiştek asteng bikin an bavêjin.

Piştî veguheztinê, pêdivî ye ku dane ji bo lihevhatina modela ku em diafirînin were kontrol kirin. Me demek dirêj nîqaş kir ku divê model çi be û bi kîjan zimanî vebêjin. Me Apache Avro hilbijart ji ber ku ziman hêsan e û ji Tarantool piştgirî heye. Guhertoyên nû yên modêl û koda xwerû dikare rojê çend caran, tewra di bin barkirinê de an jî bêyî, di her wextê rojê de were xebitandin û pir zû xwe bi guhertinan re biguncîne.

Piştî verastkirinê, pêdivî ye ku dane bêne tomar kirin. Em vê yekê bi karanîna vshard-ê dikin (me kopiyên perçeyên jeo-belavbûyî hene).

Wekî din, taybetmendî wusa ye ku pir pergalên ku ji me re daneyan dişînin ferq nakin ka me ew standiye an na. Ji ber vê yekê me ji destpêkê ve rêza tamîrê pêk anî. Ew çi ye? Ger ji ber hin sedeman tiştek veguheztin an verastkirina daneyê nekeve, em dîsa jî wergirtinê piştrast dikin, lê di heman demê de tiştê di rêza tamîrkirinê de hilînin. Ew domdar e û di depoya daneya karsaziya sereke de cih digire. Me tavilê ji bo wê navbeynkarek rêveberê nivîsand, metrîk û hişyariyên cihêreng. Wekî encamek, em daneyan winda nakin. Her çend di çavkaniyê de tiştek hatibe guhertin, heke modela daneyê guherîbe, em ê tavilê wê tespît bikin û dikarin xwe biguncînin.

Naha hûn hewce ne ku fêr bibin ka meriv çawa daneyên tomarkirî vedigire. Me pergalên xwe bi baldarî analîz kir û dît ku stûna klasîk a Java û Oracle bi hewceyî cûreyek ORM-ê ye ku daneyan ji têkilî diguhezîne objektê. Ji ber vê yekê çima tavilê tiştan di forma grafîkê de nadin pergalan? Ji ber vê yekê me bi kêfxweşî GraphQL, ku hemî hewcedariyên me bicîh anî, pejirand. Ew dihêle hûn daneyan di forma grafikan de bistînin û tenê tiştê ku hûn niha hewce ne derxînin. Tewra hûn dikarin API-yê bi pir nermbûnek guherto bikin.

Hema di cih de me fêm kir ku daneyên ku me derdixin têrê nakin. Me fonksiyonên ku dikarin bi tiştên di modelê de werin girêdan afirandin - bi bingehîn, qadên hesabkirî. Ango, em fonksiyonek diyarkirî bi zeviyê ve girêdidin, ku, mînakî, bihayê navînî ya navgîniyê hesab dike. Û xerîdarê derveyî yê ku daneyê daxwaz dike jî nizane ku ev qadek hesabkirî ye.

Pergalek pejirandinê bicîh kir.

Dûv re me dît ku di biryara me de çend rol hatin qewirandin. Rol celebek berhevkarê fonksiyonan e. Bi gelemperî, rolan profîlên karanîna alavên cûda hene:

• T-Connect: Têkiliyên hatinê bi rê ve dibe, CPU sînorkirî, mezaxtina bîranîna kêm, bê dewlet.
• IB-Core: Daneyên ku bi protokola Tarantool distîne diguhezîne, ango bi tabloyan re dixebite. Ew di heman demê de dewletê hilnagire û berbelav e.
• Storage: tenê daneyan hilîne, ti mantiqê bikar nayîne. Ev rola navberên herî hêsan pêk tîne. Scalable bi saya vshard.

Ango, bi karanîna rolan, me beşên cihêreng ên komê ji hev veqetandin, ku dikarin ji hev serbixwe werin pîvandin.

Ji ber vê yekê, me tomara herikîna daneya danûstendinê ya asynkron û rêzek tamîrkirinê bi navgînek rêveberiyê re çêkiriye. Tomar ji hêla karsaziyê ve asynkron e: heke em garantî bikin ku daneyan ji xwe re binivîsin, li ku derê be jî, wê hingê em ê wê piştrast bikin. Ger ew neyê pejirandin, wê hingê tiştek xelet derket û pêdivî ye ku dane bêne şandin. Ev tomarkirina asynkron e.

Îmtîhanê

Ji destpêka projeyê ve, me biryar da ku em ê hewl bidin ku pêşveçûna ceribandinê bicîh bikin. Em testên yekîneyê li Lua bi karanîna çarçoweya tarantool/tap, û ceribandinên entegrasyonê li Python bi karanîna çarçoweya pytest dinivîsin. Di heman demê de, em hem pêşdebiran û hem jî analîstan di nivîsandina testên entegrasyonê de beşdar dikin.

Em çawa pêşkeftina ceribandinê bikar tînin?

Ger em hin taybetmendiyek nû dixwazin, em hewl didin ku pêşî ji bo wê ceribandinek binivîsin. Dema ku em xeletiyek kifş dikin, em piştrast dikin ku pêşî ceribandinek binivîsin, û tenê dûv re wê rast bikin. Di destpêkê de karkirina bi vî rengî dijwar e, ji hêla karmendan ve têgihîştinek heye, tewra sabotaj jî heye: "Werin em niha zû rast bikin, tiştek nû bikin, û dûv re bi ceribandinan veşêrin." Tenê ev "paşê" hema qet nayê.

Ji ber vê yekê, hûn hewce ne ku xwe zorê bikin ku pêşî ceribandinan binivîsin û ji yên din bixwazin ku wê bikin. Ji min bawer bikin, pêşkeftina ceribandinê di demek kurt de jî feydeyan tîne. Hûn ê hîs bikin ku jiyana we hêsantir bûye. Em hîs dikin ku 99% ji kodê naha ji hêla ceribandinan ve tê vegirtin. Ev pir xuya dike, lê ti pirsgirêkek me tune: ceribandin li ser her peywirê têne meşandin.

Lêbelê, ya ku em pir jê hez dikin ceribandina barkirinê ye; em wê ya herî girîng dibînin û bi rêkûpêk pêk tînin.

Ez ê çîrokek piçûk ji we re vebêjim ka me çawa qonaxa yekem a ceribandina barkirinê ya yek ji guhertoyên yekem pêk anî. Me pergal li ser laptopa pêşdebirker saz kir, bar vekir û di çirkeyê de 4 hezar danûstandin standin. Encamek baş ji bo laptopê. Me ew li ser çar serverek barkirina virtual, ji hilberînê qelstir saz kir. Bi kêmanî ve hatî şandin. Em wê dimeşînin, û em encamek ji ya laptopek xirabtir di yek mijarê de digirin. Naveroka şokê.

Em pir xemgîn bûn. Em li barkirina serverê dinêrin, lê derdikeve holê ku ew bêkar in.

Em gazî pêşdebiran dikin, û ew ji me re rave dikin, mirovên ku ji cîhana Java-yê têne, ku Tarantool yek-têlek e. Ew tenê dikare ji hêla yek bingehek pêvajoyek di bin barkirinê de bi bandor were bikar anîn. Dûv re me li ser her serverek herî zêde hejmara gengaz a nimûneyên Tarantool bicîh kir, bar kir û berê 14,5 hezar danûstendinan di çirkeyê de wergirt.

Ez dîsa rave bikim. Ji ber dabeşbûna li ser rolên ku çavkaniyan bi rengek cûda bikar tînin, rolên me yên ku ji bo pêvajoykirina girêdan û veguheztina daneyê berpirsiyar in tenê pêvajoker bar kirin, û bi giranî bi barkirinê re têkildar in.

Di vê rewşê de, bîranîn tenê ji bo pêvajokirina girêdanên gihîştî û tiştên demkî hate bikar anîn.

Berevajî vê, li ser serverên hilanînê, barkirina pêvajoyê zêde bû, lê ji serverên ku pêwendiyan pêvajoyê dikin pir hêdîtir bû.

Û mezaxtina bîranînê li gorî rêjeya daneya barkirî bi rêjeya rasterast mezin bû.

Xizmet

Ji bo ku hilbera xweya nû bi taybetî wekî platformek serîlêdanê pêşve bixin, me pêkhateyek ji bo bicihkirina karûbar û pirtûkxane li ser wê çêkir.

Karûbar ne tenê perçeyên piçûk ên kodê ne ku li ser hin qadan dixebitin. Ew dikarin strukturên pir mezin û tevlihev bin ku beşek ji komekê ne, daneyên referansê kontrol bikin, mantiqa karsaziyê dimeşînin û bersivên vedigerin. Em di heman demê de şemaya karûbarê hinardeyî GraphQL jî dikin, û xerîdar xalek gihîştina gerdûnî ya daneyê, digel hundurîn li seranserê modelê distîne. Pir rehet e.

Ji ber ku karûbar gelek fonksiyonên din dihewîne, me biryar da ku divê pirtûkxane hebin ku em ê koda ku pir caran tê bikar anîn tê de biguhezînin. Me wan li hawîrdora ewle zêde kir, me berê kontrol kir ku ew tiştek ji me re naşkîne. Û naha em dikarin di forma pirtûkxaneyan de jîngehên din ji fonksiyonan re destnîşan bikin.

Me dixwest ku ne tenê ji bo hilanînê, lê ji bo hesabkirinê jî platformek hebe. Û ji ber ku me berê komek kopya û şûşeyên me hebûn, me cûreyek hesabkirina belavkirî pêk anî û jê re got kêmkirina nexşeyê, ji ber ku ew dişibihe kêmkirina nexşeya orîjînal.

Sîstemên kevn

Ne hemî pergalên me yên mîras dikarin li ser HTTP bangî me bikin û GraphQL bikar bînin, her çend ew protokolê piştgirî dikin. Ji ber vê yekê, me mekanîzmayek çêkir ku destûrê dide daneyên ku di van pergalan de bêne dubare kirin.

Ger tiştek ji bo me biguhezîne, di rola Storage de rêgezên bêhempa têne destnîşan kirin û peyama bi guhertinan re di rêza pêvajoyê de diqede. Ew bi karanîna rolek veqetandî ya cihêreng ji pergalek derveyî re tê şandin. Ev rola dewletê naparêze.

Pêşveçûnên nû

Wekî ku tê bîra we, ji hêla karsaziyê ve, me tomarkirina asynchronous kir. Lê paşê wan fêm kir ku ew ê ne bes be, ji ber ku çînek pergalan heye ku hewce dike ku tavilê bersivek di derbarê rewşa operasyonê de werbigire. Ji ber vê yekê me GraphQL-ya xwe dirêj kir û mutasyon lê zêde kir. Ew bi organîkî di nav paradîgmaya heyî ya xebata bi daneyan de cih digirin. Ji bo me, ev yek xalek xwendin û nivîsandinê ye ji bo çînek din a pergalê.

Me jî fêm kir ku xizmet bi tenê têra me nake, ji ber ku raporên pir giran hene ku divê rojê, hefteyekê, mehê carekê bêne çêkirin. Ev dikare demek dirêj bigire, û rapor tewra dikarin lûleya bûyera Tarantool asteng bikin. Ji ber vê yekê, me rolên cihêreng afirandin: plansaz û rêveker. Runners nade dewletê. Ew karên giran ên ku em nikanin di firê de hesab bikin dimeşînin. Û rola plansazker nexşeya destpêkirina van karan, ya ku di veavakirinê de tête diyar kirin, dişopîne. Karên xwe li heman cîhê daneyên karsaziyê têne hilanîn. Dema ku wextê rast tê, plansazker peywirê digire, dide hin bezvan, yê ku wê dihejmêre û encamê xilas dike.

Ne hewce ye ku hemî peywir li gorî nexşeyek bêne meşandin. Pêdivî ye ku hin rapor li gorî daxwazê ​​bêne xwendin. Hema ku ev hewcedarî tê, peywirek di sandboxê de tê afirandin û ji bo darvekirinê ji runner re tê şandin. Piştî demekê, bikarhêner bersivek asynkron distîne ku her tişt hatiye hesibandin û rapor amade ye.

Di destpêkê de, me bi paradîgmaya hilanîna hemî daneyan, guhertoya wê û ne jêbirina wê ve girêda. Lê di jiyanê de, dem bi dem hûn hîn jî neçar in ku tiştek jêbirin, bi piranî hin agahdariya xav an navîn. Li ser bingeha qediya, me mekanîzmayek ji bo paqijkirina hilanînê ji daneyên kevnar çêkir.

Em di heman demê de fam dikin ku zû an dereng dê rewşek were ku cîhê têr tune ku daneyan di bîranînê de hilîne, lê dîsa jî divê dane bêne hilanîn. Ji bo van armancan, em ê di demek nêzîk de hilanîna dîskê çêbikin.

encamê

Me bi peywira barkirina daneyan di modelek yekane de dest pê kir û sê meh ji bo pêşxistina wê derbas kir. Me şeş pergalên dabînkirina daneyê hebûn. Tevahiya koda veguherînê di modelek yekane de li Lua bi qasî 30 hezar xetên e. Û piraniya kar hîn li pêş e. Carinan kêmasiya motîvasyona tîmên cîran heye, û gelek şert û merc hene ku xebatê tevlihev dikin. Ger hûn carî bi peywirek wekhev re rû bi rû bimînin, wê hingê dema ku ji bo pêkanîna wê ji we re normal xuya dike bi sê, an jî çaran zêde bikin.

Di heman demê de ji bîr mekin ku pirsgirêkên heyî yên di pêvajoyên karsaziyê de bi karanîna DBMSek nû, hetta ya pir hilberîner, nayê çareser kirin. Mebesta min çi ye? Di destpêka projeya xwe de, me di nav xerîdaran de nerînek çêkir ku naha em ê databasek nû ya bilez bînin û em ê bijîn! Pêvajo dê zûtir biçe, her tişt dê baş bibe. Bi rastî, teknolojî pirsgirêkên ku pêvajoyên karsaziyê hene çareser nake, ji ber ku pêvajoyên karsaziyê mirov in. Û hûn hewce ne ku bi mirovan re bixebitin, ne teknolojî.

Pêşveçûna ceribandinê dikare di qonaxên destpêkê de bi êş û demdirêj be. Lê bandora wê ya erênî dê di demek kurt de jî xuya bibe, gava ku hûn ne hewce ne ku tiştek bikin da ku ceribandina paşveçûnê bikin.

Pir girîng e ku meriv ceribandina barkirinê di hemî qonaxên pêşkeftinê de bike. Zû zû hûn di mîmariyê de hin xeletiyek bibînin, ew ê hêsantir be ku wê rast bike, ku dê di pêşerojê de ji we re gelek wext xilas bike.

Tiştek bi Lua re tune. Her kes dikare fêrî nivîsandina wê bibe: Pêşdebirê Java, pêşdebirê JavaScript, pêşdebirê Python, pêş-end an paş-dawî. Tewra analîstên me jî li ser dinivîsin.

Dema ku em li ser vê yekê diaxivin ku me SQL tune, ew mirovan ditirsîne. "Hûn çawa bêyî SQL daneyan digirin? Ma ew gengaz e? Bicî. Di pergalek pola OLTP de, SQL ne hewce ye. Di forma zimanekî de alternatîfek heye ku di cih de we vedigerîne nêrînek belge-oriented. Mînakî, GraphQL. Û di forma komputera belavkirî de alternatîfek heye.

Ger hûn fêm bikin ku hûn ê hewce bikin ku pîvandinê bikin, wê hingê çareseriya xwe li ser Tarantool bi vî rengî sêwirînin ku ew li ser bi dehan mînakên Tarantool-ê paralel bimeşîne. Ger hûn wiya nekin, ew ê paşê dijwar û biêş be, ji ber ku Tarantool tenê dikare yek bingehek pêvajoyê bi bandor bikar bîne.

Source: www.habr.com