“Бидний нууц орчлон: эсийн далд амьдрал” киноны хэсгээс

Хөрөнгө оруулалтын бизнес нь банкны ертөнц дэх хамгийн төвөгтэй салбаруудын нэг юм, учир нь зөвхөн зээл, зээл, хадгаламж төдийгүй үнэт цаас, валют, түүхий эд, дериватив болон бүтэцлэгдсэн бүтээгдэхүүн хэлбэрээр бүх төрлийн нарийн төвөгтэй зүйлүүд байдаг.

Сүүлийн үед бид хүн амын санхүүгийн мэдлэг нэмэгдэж байгааг харж байна. Үнэт цаасны зах зээлд арилжаанд оролцох хүмүүс улам бүр нэмэгдсээр байна. Хувь хүний ​​​​хөрөнгө оруулалтын дансууд саяхан гарч ирсэн. Тэд танд үнэт цаасны зах зээл дээр арилжаа хийх, татварын хөнгөлөлт авах эсвэл татвар төлөхөөс зайлсхийх боломжийг олгодог. Мөн бидэн дээр ирсэн бүх үйлчлүүлэгчид өөрсдийн багцаа удирдаж, бодит цаг хугацаанд тайлагнаж байхыг хүсдэг. Түүгээр ч барахгүй энэ багц нь ихэвчлэн олон төрлийн бүтээгдэхүүн, өөрөөр хэлбэл хүмүүс бизнесийн янз бүрийн чиглэлийн үйлчлүүлэгчид байдаг.

Үүнээс гадна Оросын болон гадаадын зохицуулагчдын хэрэгцээ нэмэгдэж байна.

Одоогийн хэрэгцээг хангах, цаашдын шинэчлэлийн суурийг тавихын тулд бид Tarantool дээр суурилсан хөрөнгө оруулалтын бизнесийн цөмийг боловсруулсан.

Зарим статистик. Альфа-Банкны хөрөнгө оруулалтын бизнес нь хувь хүн, хуулийн этгээдэд янз бүрийн үнэт цаасны зах зээл дээр арилжаа хийх боломжийг олгох брокерийн үйлчилгээ, үнэт цаас хадгалах хадгаламжийн үйлчилгээ, хувийн болон их хэмжээний хөрөнгөтэй иргэдэд итгэмжлэгдсэн удирдлагын үйлчилгээ, бусад компаниудад үнэт цаас гаргах үйлчилгээ үзүүлдэг. . Альфа-Банкны хөрөнгө оруулалтын бизнест янз бүрийн арилжааны платформоос татаж авдаг секундэд 3 мянга гаруй үнийн санал багтдаг. Ажлын өдөр зах зээл дээр банк эсвэл үйлчлүүлэгчийнхээ нэрийн өмнөөс 300 гаруй мянган гүйлгээ хийгддэг. Гадаад болон дотоод платформ дээр секундэд 5 мянга хүртэлх захиалга гүйцэтгэдэг. Үүний зэрэгцээ дотоод болон гадаад бүх үйлчлүүлэгчид өөрсдийн байр сууриа бодит цаг хугацаанд нь харахыг хүсдэг.

Эрьт урьдын түүх

2000-аад оны эхэн үеэс манай хөрөнгө оруулалтын бизнесийн салбарууд бие даан хөгжиж ирсэн: биржийн арилжаа, брокерийн үйлчилгээ, валют арилжаа, үнэт цаас болон төрөл бүрийн деривативын биржийн бус арилжаа. Үүний үр дүнд бид үйл ажиллагааны худгийн урхинд орлоо. Энэ юу вэ? Бизнесийн салбар бүр бие биенийхээ чиг үүргийг давхар гүйцэтгэдэг өөрийн гэсэн системтэй байдаг. Гүйлгээ, хэрэгсэл, эсрэг талууд, үнийн санал гэх мэт ижил ойлголттой ажилладаг хэдий ч систем бүр өөрийн гэсэн өгөгдлийн загвартай байдаг. Систем бүр бие даан хөгжихийн хэрээр олон төрлийн амьтны хүрээлэн бий болсон.

Нэмж дурдахад зарим бүтээгдэхүүн 1990-ээд оны дундуур гарч ирсэн тул системийн кодын суурь нь аль хэдийн хоцрогдсон байна. Мөн зарим газарт энэ нь хөгжлийн явцыг удаашруулж, гүйцэтгэлийн асуудал гарсан.

Шинэ шийдэлд тавигдах шаардлага

Технологийн өөрчлөлт нь цаашдын хөгжилд амин чухал гэдгийг бизнесүүд ойлгосон. Бидэнд даалгавар өгсөн:

1. Бизнесийн бүх өгөгдлийг нэг, хурдан хадгалах сан, нэг өгөгдлийн загварт цуглуул.
2. Бид энэ мэдээллийг алдах эсвэл өөрчлөх ёсгүй.
3. Зохицуулагч нь ямар ч үед өмнөх жилүүдийн статистик мэдээллийг авахыг хүсч болох тул өгөгдлийг хувилбар болгох шаардлагатай.
4. Бид зүгээр л шинэ, загварлаг DBMS авчрахаас гадна бизнесийн асуудлыг шийдвэрлэх платформыг бий болгох ёстой.

Нэмж дурдахад манай архитекторууд өөрсдийн нөхцөлийг тавьдаг.

1. Шинэ шийдэл нь аж ахуйн нэгжийн түвшний байх ёстой, өөрөөр хэлбэл зарим томоохон компаниудад аль хэдийн туршиж үзсэн байх ёстой.
2. Шийдлийн ажиллагааны горим нь чухал үүрэг гүйцэтгэх ёстой. Энэ нь бид хэд хэдэн дата төвд нэгэн зэрэг байж, нэг дата төвийн тасалдлыг тайван даван туулах ёстой гэсэн үг юм.
3. Систем нь хэвтээ байдлаар өргөтгөх боломжтой байх ёстой. Баримт нь манай одоогийн бүх системүүд зөвхөн босоо чиглэлд өргөжин тэлж байгаа бөгөөд техник хангамжийн хүчин чадал бага байгаатай холбоотойгоор бид аль хэдийн таазанд хүрч байна. Тиймээс бид оршин тогтнохын тулд хэвтээ байдлаар өргөжүүлэх боломжтой системтэй болох цаг иржээ.
4. Үүний дотор шийдэл нь хямд байх ёстой гэж бидэнд хэлсэн.

Бид стандарт маршрутыг баримталсан: бид шаардлагыг боловсруулж, худалдан авах хэлтэстэй холбоо барьсан. Тэндээс бид ерөнхийдөө бидний төлөө үүнийг хийхэд бэлэн байгаа компаниудын жагсаалтыг авсан. Бид бүгдэд тулгамдсан асуудлаа хэлж, зургаагаас нь хэрхэн шийдвэрлэх арга замын үнэлгээг авсан.

Банкинд бид хэн нэгний үгийг хүлээж авдаггүй, бид бүгдийг өөрсдөө туршиж үзэх дуртай. Тиймээс манай тендерийн зайлшгүй нөхцөл бол ачааллын туршилтыг давах явдал байв. Бид ачааллын туршилтын даалгавруудыг томъёолсон бөгөөд зургаан компани тутмын гурав нь санах ойн технологид суурилсан туршилтын шийдлийг өөрсдийн зардлаар хэрэгжүүлэхээр аль хэдийн тохиролцсон байна.

Бид бүх зүйлийг хэрхэн туршиж, хэр хугацаа зарцуулсан талаар би танд хэлэхгүй, би зүгээр л дүгнэж хэлье: ачааллын туршилтын хамгийн сайн гүйцэтгэлийг Mail.ru группын хөгжүүлэлтийн багийн Tarantool дээр суурилсан прототип шийдэл харуулсан. Бид гэрээ байгуулж, бүтээн байгуулалтыг эхлүүлсэн. Mail.ru группээс дөрвөн хүн байсан бол Альфа-Банкнаас гурван хөгжүүлэгч, гурван системийн шинжээч, шийдлийн архитектор, бүтээгдэхүүний эзэн, Scrum мастер зэрэг хүмүүс байсан.

Дараа нь би манай систем хэрхэн өссөн, хэрхэн хувьсан өөрчлөгдөж, юу хийсэн, яагаад ийм болсон талаар танд хэлэх болно.

Хөгжил

Бидний өөрөөсөө асуусан хамгийн эхний асуулт бол одоогийн системээсээ өгөгдлийг хэрхэн олж авах тухай байв. Одоогийн бүх системүүд HTTP-ээр XML эсвэл JSON илгээх замаар хоорондоо харилцдаг тул HTTP нь бидэнд маш тохиромжтой гэж бид шийдсэн.

Бид Tarantool-д суулгасан HTTP серверийг ашигладаг, учир нь бид SSL сешнүүдийг зогсоох шаардлагагүй бөгөөд түүний гүйцэтгэл нь бидэнд хангалттай.

Миний хэлсэнчлэн манай бүх системүүд өөр өөр өгөгдлийн загварт амьдардаг бөгөөд оролтод бид объектыг өөрсдийнхөө дүрсэлсэн загварт оруулах хэрэгтэй. Өгөгдлийг өөрчлөх боломжийг олгодог хэл хэрэгтэй байсан. Бид зайлшгүй шаардлагатай Луаг сонгосон. Бид бүх өгөгдөл хувиргах кодыг хамгаалагдсан хязгаарлагдмал орчинд ажиллуулдаг - энэ нь ажиллаж байгаа кодыг давж гарахгүй аюулгүй газар юм. Үүнийг хийхийн тулд бид зүгээр л шаардлагатай кодыг ачаалж, юуг ч хаах эсвэл буулгах боломжгүй функц бүхий орчинг бий болгоно.

Хөрвүүлсний дараа өгөгдөл нь бидний үүсгэж буй загварт нийцэж байгаа эсэхийг шалгах ёстой. Загвар нь ямар байх, ямар хэлээр дүрслэх талаар бид удаан ярилцсан. Хэл нь энгийн бөгөөд Tarantool-ийн дэмжлэгтэй тул бид Apache Avro-г сонгосон. Загварын шинэ хувилбарууд болон захиалгат кодууд нь өдөрт хэд хэдэн удаа ачаалалтай, ачаалалгүй ч гэсэн өдрийн аль ч цагт ашиглалтад орох боломжтой бөгөөд өөрчлөлтөд маш хурдан дасан зохицдог.

Баталгаажуулсны дараа өгөгдлийг хадгалах ёстой. Бид үүнийг vshard ашиглан хийдэг (бидэнд хэлтэрхийнүүдийн гео-тарсан хуулбарууд байдаг).

Түүгээр ч барахгүй өвөрмөц онцлог нь бидэнд өгөгдөл илгээдэг ихэнх систем нь бид үүнийг хүлээн авсан эсэхээс үл хамаарна. Тиймээс ч анхнаасаа засварын дарааллыг хэрэгжүүлсэн. Энэ юу вэ? Хэрэв ямар нэг шалтгааны улмаас объект өгөгдөл хувиргах, баталгаажуулалтад ороогүй бол бид хүлээн авсан баримтыг баталгаажуулсан хэвээр байгаа боловч засварын дараалалд объектыг хадгалдаг. Энэ нь тогтвортой бөгөөд бизнесийн мэдээллийн үндсэн агуулахад байрладаг. Бид тэр даруй администраторын интерфейс, янз бүрийн хэмжигдэхүүн, сэрэмжлүүлэг бичсэн. Үүний үр дүнд бид өгөгдлийг алдахгүй. Хэдийгээр эх сурвалжид ямар нэг зүйл өөрчлөгдсөн ч өгөгдлийн загвар өөрчлөгдсөн бол бид үүнийг даруй илрүүлж, дасан зохицож чадна.

Одоо та хадгалсан өгөгдлийг хэрхэн сэргээх талаар сурах хэрэгтэй. Бид системээ сайтар судалж үзээд, Java болон Oracle-ийн сонгодог стек нь өгөгдлийг хамаарлаас объект руу хөрвүүлдэг ямар нэгэн ORM-г агуулсан байх ёстойг олж харсан. Тэгэхээр яагаад нэн даруй системд объектуудыг график хэлбэрээр өгч болохгүй гэж? Тиймээс бид бүх хэрэгцээг хангасан GraphQL-г баяртайгаар хүлээн авсан. Энэ нь танд график хэлбэрээр өгөгдлийг хүлээн авч, яг одоо хэрэгтэй байгаа зүйлээ гаргах боломжийг олгоно. Та API-г нэлээд уян хатан байдлаар хувилбар болгож болно.

Бидний гаргаж авсан өгөгдөл хангалтгүй байгааг бид бараг тэр даруй ойлгосон. Бид загварт байгаа объектуудтай холбож болох функцуудыг үүсгэсэн - үндсэндээ тооцоолсон талбарууд. Өөрөөр хэлбэл, бид талбарт тодорхой функцийг хавсаргадаг бөгөөд энэ нь жишээлбэл дундаж үнийн саналыг тооцдог. Мөн өгөгдөл хүссэн гадаад хэрэглэгч энэ нь тооцоолсон талбар гэдгийг мэддэггүй.

Баталгаажуулалтын системийг нэвтрүүлсэн.

Дараа нь бидний шийдвэрт хэд хэдэн үүрэг тодорхой болсон гэдгийг бид анзаарсан. Үүрэг бол функцүүдийн нэг төрлийн нэгтгэгч юм. Дүрүүд нь ихэвчлэн өөр өөр тоног төхөөрөмжийн ашиглалтын профайлтай байдаг:

• T-Connect: ирж буй холболтыг зохицуулдаг, CPU хязгаарлагдмал, санах ойн хэрэглээ бага, харьяалалгүй.
• IB-Core: Tarantool протоколоор дамжуулан хүлээн авсан өгөгдлийг хувиргадаг, өөрөөр хэлбэл хүснэгтүүдтэй ажилладаг. Энэ нь мөн төлөвийг хадгалахгүй бөгөөд өргөтгөх боломжтой.
• Хадгалалт: зөвхөн өгөгдлийг хадгалдаг, ямар ч логик ашигладаггүй. Энэ үүрэг нь хамгийн энгийн интерфейсүүдийг хэрэгжүүлдэг. Vshard-ийн ачаар өргөтгөх боломжтой.

Өөрөөр хэлбэл, үүргүүдийг ашигласнаар бид кластерын өөр өөр хэсгүүдийг бие биенээсээ хамааралгүйгээр хуваах боломжтой.

Тиймээс бид асинхрон гүйлгээний өгөгдлийн урсгалын бичлэг болон админ интерфейстэй засварын дарааллыг бий болгосон. Бичлэг нь бизнесийн үүднээс асинхрон юм: хэрвээ бид хаана ч хамаагүй өөрсдөдөө өгөгдөл бичих баталгаатай бол бид үүнийг баталгаажуулах болно. Хэрэв энэ нь батлагдаагүй бол ямар нэг зүйл буруу болсон тул өгөгдлийг илгээх шаардлагатай болно. Энэ бол асинхрон бичлэг юм.

Тест хийх

Төсөл хэрэгжиж эхэлсэн цагаасаа л бид туршилтад суурилсан хөгжүүлэлтийг хэрэгжүүлэхээр шийдсэн. Бид Lua хэл дээр tarantool/tap framework ашиглан нэгж тестийг, pytest хүрээг ашиглан Python дээр интеграцийн тест бичдэг. Үүний зэрэгцээ бид интеграцийн тест бичихэд хөгжүүлэгчид болон шинжээчдийг оролцуулдаг.

Бид туршилтанд суурилсан хөгжлийг хэрхэн ашигладаг вэ?

Хэрэв бид шинэ функц авахыг хүсч байвал эхлээд тест бичихийг хичээдэг. Алдаа илрүүлэх үед бид эхлээд тест бичиж, дараа нь засдаг. Эхэндээ ингэж ажиллахад хэцүү байдаг, ажилчдын дунд үл ойлголцол, бүр хорлон сүйтгэх ажиллагаа ч бий: "Одоо хурдан засч, шинэ зүйл хийцгээе, дараа нь туршилтаар бүрхье." Зөвхөн энэ "дараа нь" бараг хэзээ ч ирдэггүй.

Тиймээс эхлээд өөрийгөө хүчлэн тест бичиж, бусдаас хийлгэх хэрэгтэй. Надад итгээрэй, туршилтанд суурилсан хөгжил нь богино хугацаанд ч гэсэн ашиг тусаа өгдөг. Таны амьдрал илүү хялбар болсон гэдгийг та мэдрэх болно. Одоо кодын 99% нь туршилтанд хамрагдсан гэж бид мэдэрч байна. Энэ нь маш их юм шиг санагдаж байна, гэхдээ бидэнд ямар ч асуудал байхгүй: туршилтууд ажил бүр дээр явагддаг.

Гэсэн хэдий ч бидний хамгийн дуртай зүйл бол ачааллын туршилт бөгөөд бид үүнийг хамгийн чухал гэж үздэг бөгөөд үүнийг тогтмол хийдэг.

Эхний хувилбаруудын аль нэгний ачааллын туршилтын эхний үе шатыг хэрхэн гүйцэтгэсэн тухай бяцхан түүхийг би танд хэлье. Бид системийг хөгжүүлэгчийн зөөврийн компьютер дээр суулгаж, ачааллыг асааж, секундэд 4 мянган гүйлгээг хүлээн авсан. Зөөврийн компьютерын хувьд сайн үр дүн. Бид үүнийг дөрвөн серверийн виртуал ачааллын вандан сандал дээр суурилуулсан бөгөөд энэ нь үйлдвэрлэлийнхээс сул юм. Хамгийн бага хэмжээнд байрлуулсан. Бид үүнийг ажиллуулж, нэг урсгалд зөөврийн компьютерээс илүү муу үр дүнд хүрдэг. Шок контент.

Бид маш их гунигтай байсан. Бид серверийн ачааллыг харж байгаа боловч тэд идэвхгүй байна.

Бид хөгжүүлэгчдийг дууддаг бөгөөд тэд Жава ертөнцөөс ирсэн хүмүүст Tarantool нь нэг урсгалтай гэдгийг тайлбарладаг. Үүнийг ачаалалтай үед зөвхөн нэг процессорын цөм үр дүнтэй ашиглах боломжтой. Дараа нь бид сервер бүр дээр хамгийн их боломжтой тооны Tarantool инстанцуудыг байрлуулж, ачааллыг асааж, секундэд 14,5 мянган гүйлгээг хүлээн авсан.

Дахин тайлбарлая. Нөөцийг өөр өөрөөр ашигладаг дүрүүдэд хуваагдсан тул холболтыг боловсруулах, өгөгдлийг хувиргах үүрэгтэй бидний үүрэг нь зөвхөн процессорыг ачаалж, ачаалалтай пропорциональ байна.

Энэ тохиолдолд санах ойг зөвхөн ирж буй холболтууд болон түр зуурын объектуудыг боловсруулахад ашигладаг байсан.

Эсрэгээр, хадгалах серверүүд дээр процессорын ачаалал нэмэгдсэн боловч холболт боловсруулдаг серверүүдээс хамаагүй удаан байв.

Мөн санах ойн хэрэглээ нь ачаалагдсан өгөгдлийн хэмжээтэй шууд пропорциональ өссөн.

үйлчилгээ

Шинэ бүтээгдэхүүнээ хэрэглээний платформ болгон хөгжүүлэхийн тулд бид түүн дээр үйлчилгээ, номын санг байрлуулах бүрэлдэхүүн хэсгийг бий болгосон.

Үйлчилгээ нь зөвхөн зарим талбарт ажилладаг кодын жижиг хэсгүүд биш юм. Эдгээр нь кластерын нэг хэсэг болох, лавлагааны өгөгдлийг шалгах, бизнесийн логикийг ажиллуулах, хариу өгөх зэрэг нэлээд том, төвөгтэй бүтэц байж болно. Мөн бид үйлчилгээний схемийг GraphQL руу экспортлох ба хэрэглэгч бүх загвараар дамжуулан мэдээлэлд хандах бүх нийтийн цэгийг хүлээн авдаг. Энэ нь маш тухтай байдаг.

Үйлчилгээнүүд нь өөр олон функцийг агуулдаг тул бид байнга ашигладаг кодыг зөөх номын сангууд байх ёстой гэж шийдсэн. Бид тэднийг аюулгүй орчинд нэмсэн бөгөөд энэ нь бидний хувьд юу ч эвдэхгүй гэдгийг өмнө нь шалгаж үзсэн. Одоо бид номын сан хэлбэрээр функцүүдэд нэмэлт орчныг оноож болно.

Бид зөвхөн хадгалах зориулалттай платформтой болохоос гадна компьютерт зориулсан платформтой болохыг хүссэн. Бид аль хэдийн олон тооны хуулбар, хэлтэрхийтэй байсан тул бид нэг төрлийн тархсан тооцоололыг хэрэгжүүлж, анхны газрын зургийн бууралттай төстэй болсон тул үүнийг газрын зураг бууруулах гэж нэрлэсэн.

Хуучин системүүд

Манай бүх хуучин системүүд протоколыг дэмждэг ч HTTP-ээр бидэн рүү залгаж, GraphQL-г ашиглаж чадахгүй. Тиймээс бид эдгээр системд өгөгдлийг хуулбарлах боломжийг олгодог механизмыг бий болгосон.

Хэрэв бидний хувьд ямар нэг зүйл өөрчлөгдвөл Хадгалах үүрэг дээр өвөрмөц триггерүүд идэвхжиж, өөрчлөлттэй мессеж нь боловсруулах дараалалд дуусна. Энэ нь тусдаа хуулбарлагч үүрэг ашиглан гадаад систем рүү илгээгддэг. Энэ үүрэг нь төлөвийг хадгалахгүй.

Шинэ сайжруулалтууд

Таны санаж байгаагаар бизнесийн үүднээс бид асинхрон бичлэг хийсэн. Гэвч дараа нь тэд энэ нь хангалттай биш гэдгийг ойлгосон, учир нь үйл ажиллагааны төлөв байдлын талаар нэн даруй хариу авах шаардлагатай системүүдийн ангилал байдаг. Тиймээс бид GraphQL-ээ өргөтгөж, мутаци нэмсэн. Эдгээр нь өгөгдөлтэй ажиллах одоо байгаа парадигмд органик байдлаар нийцдэг. Бидний хувьд энэ нь өөр ангиллын системийн хувьд унших, бичих нэг цэг юм.

Өдөрт, долоо хоногт, сард нэг удаа барих шаардлагатай нэлээд хүнд тайлангууд байдаг тул зөвхөн үйлчилгээ бидэнд хангалтгүй гэдгийг бид ойлгосон. Энэ нь удаан хугацаа шаардагдах бөгөөд тайлангууд нь Tarantool-ийн үйл явдлын давталтыг хааж болно. Тиймээс бид хуваарь гаргагч ба гүйгч гэсэн тусдаа дүрүүдийг бүтээсэн. Гүйгчид төлөвийг хадгалдаггүй. Тэд бидний тооцоолж чадахгүй хүнд даалгавруудыг гүйцэтгэдэг. Төлөвлөгчийн үүрэг нь тохиргоонд тайлбарласан эдгээр ажлуудыг эхлүүлэх хуваарийг хянадаг. Даалгаврууд нь бизнесийн өгөгдөлтэй нэг газар хадгалагддаг. Тохиромжтой цаг ирэхэд хуваарь гаргагч даалгавраа авч, гүйгчдэд өгч, түүнийг тоолж, үр дүнг хадгалдаг.

Бүх ажлыг хуваарийн дагуу хийх шаардлагагүй. Зарим тайланг хүсэлтээр унших шаардлагатай. Энэ шаардлага ирсэн даруйд хамгаалагдсан хязгаарлагдмал орчинд даалгаврыг үүсгэж, гүйгч рүү гүйцэтгэхээр илгээдэг. Хэсэг хугацааны дараа хэрэглэгч бүх зүйлийг тооцоолж, тайлан бэлэн болсон гэсэн асинхрон хариултыг хүлээн авдаг.

Эхэндээ бид бүх өгөгдлийг хадгалах, хувилбар болгох, устгахгүй байх парадигмыг баримталсан. Гэвч амьдрал дээр үе үе та ямар нэг зүйлийг, ихэнхдээ түүхий эсвэл завсрын мэдээллийг устгах хэрэгтэй болдог. Хугацаа дууссаны үндсэн дээр бид хадгалах санг хуучирсан мэдээллээс цэвэрлэх механизмыг бий болгосон.

Эрт орой хэзээ нэгэн цагт санах ойд өгөгдөл хадгалах хангалттай зай байхгүй, гэхдээ өгөгдлийг хадгалах ёстой гэдгийг бид ойлгож байна. Эдгээр зорилгын үүднээс бид удахгүй дискний хадгалалт хийх болно.

дүгнэлт

Бид өгөгдлийг нэг загварт ачаалах ажлыг эхлүүлж, гурван сарыг боловсруулахад зарцуулсан. Бид зургаан мэдээллийн хангамжийн системтэй байсан. Нэг загвар болгон хувиргах бүх код нь Луа дахь 30 мянга орчим мөр юм. Мөн ихэнх ажил урагштай хэвээр байна. Заримдаа хөрш зэргэлдээ багуудын урам зориг дутмаг, ажлыг хүндрүүлдэг олон нөхцөл байдал бий. Хэрэв та үүнтэй төстэй ажилтай тулгарвал түүнийг хэрэгжүүлэхэд тань хэвийн мэт санагдах хугацааг гурав, бүр дөрөв дахин үржүүлээрэй.

Бизнесийн үйл явц дахь одоо байгаа асуудлуудыг шинэ DBMS, тэр ч байтугай маш бүтээмжтэй ч гэсэн ашиглах боломжгүй гэдгийг санаарай. Би юу гэсэн үг вэ? Төсөл маань эхлэхэд бид үйлчлүүлэгчдэд одоо шинэ хурдан мэдээллийн сан авчрах болно, бид амьдрах болно гэсэн сэтгэгдэл төрүүлсэн! Процессууд хурдан явагдах болно, бүх зүйл сайхан болно. Үнэн хэрэгтээ технологи нь бизнесийн үйл явцтай холбоотой асуудлуудыг шийдэж чадахгүй, учир нь бизнесийн үйл явц нь хүмүүс юм. Мөн та технологитой биш хүмүүстэй ажиллах хэрэгтэй.

Туршилтанд суурилсан хөгжил нь эхний үе шатанд өвдөлттэй, цаг хугацаа их шаарддаг. Гэхдээ үүний эерэг үр нөлөө нь регрессийн тест хийхэд юу ч хийх шаардлагагүй богино хугацаанд ч мэдэгдэхүйц байх болно.

Хөгжлийн бүх үе шатанд ачааллын туршилт хийх нь туйлын чухал юм. Архитектурт ямар нэгэн согогийг эрт анзаарах тусам үүнийг засах нь илүү хялбар байх бөгөөд энэ нь ирээдүйд танд маш их цаг хэмнэх болно.

Луад буруу зүйл байхгүй. Үүнд хэн ч бичиж сурах боломжтой: Java хөгжүүлэгч, JavaScript хөгжүүлэгч, Python хөгжүүлэгч, урд эсвэл арын төгсгөл. Энэ талаар манай шинжээчид хүртэл бичдэг.

Бидэнд SQL байхгүй гэж ярихаар хүмүүсийг айлгадаг. "SQL-гүйгээр та хэрхэн өгөгдлийг авах вэ? Энэ боломжтой юу? Мэдээж. OLTP ангиллын системд SQL шаардлагагүй. Баримт бичигт чиглэсэн харагдац руу нэн даруй буцаах зарим төрлийн хэл хэлбэрээр өөр хувилбар байдаг. Жишээлбэл, GraphQL. Мөн тархсан тооцооллын хэлбэрээр өөр хувилбар бий.

Хэрэв та цар хүрээг нэмэгдүүлэх шаардлагатай гэдгийг ойлгож байгаа бол Tarantool дээрх шийдлээ олон арван Tarantool instance дээр зэрэгцэн ажиллахаар зохион бүтээгээрэй. Хэрэв та үүнийг хийхгүй бол Tarantool нь зөвхөн нэг процессорын цөмийг үр дүнтэй ашиглах боломжтой тул дараа нь хэцүү бөгөөд өвдөлттэй байх болно.

Эх сурвалж: www.habr.com