🥇 የተከፋፈሉ አፕሊኬሽኖች ግንባታ ብሎኮች። ሁለተኛ ግምታዊ

ማስታወቂያ

ባልደረቦች, በበጋው አጋማሽ ላይ ስለ ወረፋ ስርዓቶች ንድፍ ሌላ ተከታታይ ጽሑፎችን ለመልቀቅ እቅድ አለኝ: "የ VTrade ሙከራ" - ለንግድ ስርዓቶች ማዕቀፍ ለመጻፍ ሙከራ. ተከታታዩ የልውውጥ፣ የጨረታ እና የማከማቻ ግንባታ ንድፈ ሃሳብ እና ልምምድ ይመረምራል። በአንቀጹ መጨረሻ ላይ በጣም የሚስቡዎትን ርዕሶች እንዲመርጡ እጋብዝዎታለሁ።

ይህ በተከታታይ በኤርላንግ/ኤሊሲር ውስጥ ስለተከፋፈሉ ምላሽ ሰጪ መተግበሪያዎች የመጨረሻ መጣጥፍ ነው። ውስጥ የመጀመሪያው ጽሑፍ የምላሽ አርክቴክቸር ንድፈ ሃሳባዊ መሠረቶችን ማግኘት ይችላሉ። ሁለተኛ ጽሑፍ እንደነዚህ ያሉ ስርዓቶችን ለመገንባት መሰረታዊ ንድፎችን እና ዘዴዎችን ያሳያል.

ዛሬ የኮድ ቤዝ ልማት ጉዳዮችን እና በአጠቃላይ ፕሮጀክቶችን እናነሳለን.

የአገልግሎቶች አደረጃጀት

በእውነተኛ ህይወት ውስጥ አገልግሎትን በሚገነቡበት ጊዜ በአንድ መቆጣጠሪያ ውስጥ ብዙ የመስተጋብር ዘይቤዎችን ማጣመር አለብዎት። ለምሳሌ፣ የፕሮጀክት ተጠቃሚ መገለጫዎችን የማስተዳደር ችግርን የሚፈታው የተጠቃሚው አገልግሎት ለጥያቄዎች ምላሽ መስጠት እና የመገለጫ ዝመናዎችን በpub-sub በኩል ሪፖርት ማድረግ አለበት። ይህ ጉዳይ በጣም ቀላል ነው፡ ከመልዕክት ጀርባ የአገልግሎቱን አመክንዮ የሚተገብር እና ዝማኔዎችን የሚያትም አንድ መቆጣጠሪያ አለ።

ስህተትን የሚቋቋም የተከፋፈለ አገልግሎት መተግበር ስንፈልግ ሁኔታው ይበልጥ የተወሳሰበ ይሆናል። የተጠቃሚዎች መስፈርቶች ተለውጠዋል ብለን እናስብ፡-

አሁን አገልግሎቱ በ 5 ክላስተር ኖዶች ላይ ጥያቄዎችን ማካሄድ አለበት ፣
የጀርባ ሂደት ስራዎችን ማከናወን መቻል,
እና እንዲሁም ለተለዋዋጭ የመገለጫ ዝመናዎች የደንበኝነት ምዝገባ ዝርዝሮችን ማስተዳደር ይችላሉ።

አስተያየት- ወጥ የሆነ የማከማቻ እና የውሂብ መባዛትን ጉዳይ አንመለከትም። እነዚህ ጉዳዮች ቀደም ብለው እንደተፈቱ እና ስርዓቱ አስተማማኝ እና ሊሰፋ የሚችል የማከማቻ ንብርብር እንዳለው እናስብ እና ተቆጣጣሪዎች ከእሱ ጋር መስተጋብር ለመፍጠር ዘዴዎች አሏቸው።

የተጠቃሚዎች አገልግሎት መደበኛ መግለጫ ይበልጥ የተወሳሰበ ሆኗል. ከፕሮግራመር እይታ አንጻር፣ የመልእክት መላላኪያን በመጠቀም ለውጦች በጣም አናሳ ናቸው። የመጀመሪያውን መስፈርት ለማሟላት, በ req-resp የመለዋወጫ ነጥብ ላይ ማመጣጠን ማዋቀር አለብን.

የበስተጀርባ ስራዎችን የማካሄድ መስፈርት በተደጋጋሚ ይከሰታል. በተጠቃሚዎች ውስጥ ይህ የተጠቃሚ ሰነዶችን መፈተሽ፣ የወረዱ መልቲሚዲያን ማካሄድ ወይም ውሂብ ከማህበራዊ ሚዲያ ጋር ማመሳሰል ሊሆን ይችላል። አውታረ መረቦች. እነዚህ ተግባራት በክላስተር ውስጥ መሰራጨት እና የአፈፃፀሙን ሂደት መከታተል አለባቸው። ስለዚህ, ሁለት የመፍትሄ አማራጮች አሉን-ከቀዳሚው ጽሑፍ የተግባር ማከፋፈያ አብነት ይጠቀሙ ፣ ወይም የማይስማማ ከሆነ ፣ የአቀነባባሪዎችን ገንዳ በምንፈልገው መንገድ የሚያስተዳድር ብጁ የተግባር መርሐግብር ይፃፉ።

ነጥብ 3 የፐብ-ንዑስ አብነት ቅጥያ ያስፈልገዋል። እና ለትግበራ ፣ የመጠጥ-ንዑስ ልውውጥ ነጥብ ከፈጠርን በኋላ ፣ በአገልግሎታችን ውስጥ የዚህን ነጥብ ተቆጣጣሪ በተጨማሪ ማስጀመር አለብን። ስለዚህ፣ የደንበኝነት ምዝገባዎችን ለማስኬድ አመክንዮ እና ከደንበኝነት ምዝገባ የመውጣትን ከመልእክት ንብርብር ወደ ተጠቃሚዎች አተገባበር የምናንቀሳቅስ ያህል ነው።

በውጤቱም, የችግሩ መበስበስ መስፈርቶቹን ለማሟላት 5 የአገልግሎቱን አጋጣሚዎች በተለያዩ አንጓዎች ላይ ማስጀመር እና ተጨማሪ አካል መፍጠር አለብን - የፓብ-ንኡስ ተቆጣጣሪ, ለደንበኝነት ምዝገባ ኃላፊነት.
5 ተቆጣጣሪዎችን ለማሄድ የአገልግሎት ኮዱን መቀየር አያስፈልግዎትም። ብቸኛው ተጨማሪ እርምጃ በመለዋወጫ ነጥብ ላይ የማመጣጠን ደንቦችን ማዘጋጀት ነው, ይህም ትንሽ ቆይቶ እንነጋገራለን.
ተጨማሪ ውስብስብነትም አለ፡- የመጠጥ ቤት ተቆጣጣሪ እና ብጁ ተግባር መርሐግብር በአንድ ቅጂ መስራት አለባቸው። እንደገና፣ የመልእክት አገልግሎት፣ እንደ መሠረታዊ፣ መሪን ለመምረጥ ዘዴን መስጠት አለበት።

መሪ ምርጫ

በተከፋፈሉ ስርዓቶች ውስጥ የመሪ ምርጫ የአንዳንድ ሸክሞችን ስርጭት ለማቀድ ኃላፊነት ያለው ነጠላ ሂደትን የመሾም ሂደት ነው።

ለማእከላዊነት በማይጋለጡ ስርዓቶች ውስጥ እንደ ፓክሶስ ወይም ራፍት ያሉ ሁለንተናዊ እና መግባባት ላይ የተመሰረቱ ስልተ ቀመሮች ጥቅም ላይ ይውላሉ።
መልእክት መላክ ደላላ እና ማዕከላዊ አካል ስለሆነ ስለ ሁሉም የአገልግሎት ተቆጣጣሪዎች - የእጩ መሪዎች ያውቃል። መልእክት መላክ ያለ ድምጽ መሪን ሊሾም ይችላል።

ከተጀመረ በኋላ እና ወደ ልውውጥ ነጥብ ከተገናኘ በኋላ ሁሉም አገልግሎቶች የስርዓት መልእክት ይቀበላሉ #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. ከሆነ LeaderPid ጋር ይገጥማል pid የአሁኑ ሂደት, እንደ መሪ ይሾማል, እና ዝርዝር Servers ሁሉንም አንጓዎች እና መመዘኛዎቻቸውን ያካትታል.
በአሁኑ ጊዜ አዲስ ብቅ አለ እና የሚሰራ የክላስተር መስቀለኛ መንገድ ተቋርጧል፣ ሁሉም የአገልግሎት ተቆጣጣሪዎች ይቀበላሉ። #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} በየደረጃው.

በዚህ መንገድ, ሁሉም አካላት ሁሉንም ለውጦች ያውቃሉ, እና ክላስተር በማንኛውም ጊዜ አንድ መሪ እንደሚኖረው ዋስትና ተሰጥቶታል.

አማላጆች

ውስብስብ የተከፋፈሉ የማቀነባበሪያ ሂደቶችን ለመተግበር, እንዲሁም አሁን ያለውን አርክቴክቸር የማመቻቸት ችግሮች ውስጥ, መካከለኛዎችን ለመጠቀም ምቹ ነው.
የአገልግሎት ደንቡን ላለመቀየር እና ለምሳሌ የተጨማሪ ሂደት፣ የማዘዋወር ወይም የመግቢያ መልእክቶች ችግሮችን ለመፍታት ከአገልግሎቱ በፊት ፕሮክሲ ተቆጣጣሪን ማንቃት ይችላሉ ፣ ይህም ሁሉንም ተጨማሪ ስራዎችን ያከናውናል ።

የሚታወቅ የፐብ-ንኡስ ማሻሻያ ምሳሌ ከቢዝነስ ኮር ጋር የተከፋፈለ አፕሊኬሽን ነው እንደ በገበያ ላይ ያሉ የዋጋ ለውጦች እና የመዳረሻ ንብርብር - ለድር ደንበኞች የዌብሶኬት ኤፒአይ የሚያቀርቡ N አገልጋዮች።
በራስህ ላይ ከወሰንክ የደንበኞች አገልግሎት ይህን ይመስላል።

ደንበኛው ከመድረክ ጋር ግንኙነቶችን ይፈጥራል. ትራፊኩን በሚያቋርጠው አገልጋይ በኩል፣ ይህንን ግንኙነት ለማገልገል ሂደት ተጀምሯል።
በአገልግሎት ሂደቱ አውድ ውስጥ፣ ለዝማኔዎች ፈቃድ እና ምዝገባ ይከሰታል። ሂደቱ ለርዕሶች የደንበኝነት መመዝገቢያ ዘዴን ይጠራል.
በከርነል ውስጥ አንድ ክስተት ከተፈጠረ በኋላ ግንኙነቱን ወደሚያገለግሉ ሂደቶች ይደርሳል።

ለ "ዜና" ርዕስ 50000 ተመዝጋቢዎች እንዳሉን እናስብ። ተመዝጋቢዎች በ5 አገልጋዮች ላይ በእኩል ይሰራጫሉ። በውጤቱም, እያንዳንዱ ዝመና, ወደ ልውውጥ ቦታ ሲደርስ, 50000 ጊዜ ይባዛል: በእያንዳንዱ አገልጋይ ላይ 10000 ጊዜ, በእሱ ላይ ባለው የደንበኝነት ተመዝጋቢዎች ቁጥር. በጣም ውጤታማ እቅድ አይደለም, አይደል?
ሁኔታውን ለማሻሻል፣ ከመለዋወጫ ነጥቡ ጋር ተመሳሳይ ስም ያለው ፕሮክሲ እናስተዋውቅ። የአለምአቀፍ ስም መዝጋቢ በጣም ቅርብ የሆነውን ሂደት በስም መመለስ መቻል አለበት, ይህ አስፈላጊ ነው.

ይህን ፕሮክሲ በመዳረሻ ንብርብር አገልጋዮች ላይ እናስጀምር፣ እና ሁሉም የዌብሶኬት ኤፒአይን የሚያገለግሉ ሂደቶቻችን ይመዘገባሉ እንጂ በከርነል ውስጥ ላለው የመጀመሪያው መጠጥ-ንዑስ መለዋወጫ ነጥብ አይደለም። ተኪ ለዋናው የደንበኝነት ምዝገባ በልዩ የደንበኝነት ምዝገባ ጊዜ ብቻ ነው እና ገቢ መልእክት ለሁሉም ተመዝጋቢዎቹ ይደግማል።
በዚህ ምክንያት ከ5 ይልቅ 50000 መልእክቶች በከርነል እና በመዳረሻ አገልጋዮች መካከል ይላካሉ።

ማዘዋወር እና ማመጣጠን

Req-Resp

አሁን ባለው የመልእክት መላላኪያ ትግበራ 7 የጥያቄ ማከፋፈያ ስልቶች አሉ፡-

default. ጥያቄው ለሁሉም ተቆጣጣሪዎች ይላካል።
round-robin. ጥያቄዎች ተዘርዝረዋል እና በተቆጣጣሪዎች መካከል በብስክሌት ይሰራጫሉ።
consensus. አገልግሎቱን የሚያገለግሉ ተቆጣጣሪዎች ወደ መሪዎች እና ባሪያዎች የተከፋፈሉ ናቸው. ጥያቄዎች የሚላኩት ለመሪው ብቻ ነው።
consensus & round-robin. ቡድኑ መሪ አለው፣ ነገር ግን ጥያቄዎች በሁሉም አባላት መካከል ይሰራጫሉ።
sticky. የሃሽ ተግባሩ ይሰላል እና ለአንድ የተወሰነ ተቆጣጣሪ ተመድቧል። ከዚህ ፊርማ ጋር ተከታይ ጥያቄዎች ወደ ተመሳሳዩ ተቆጣጣሪ ይሄዳሉ።
sticky-fun. የልውውጥ ነጥቡን ሲጀምሩ የሃሽ ስሌት ተግባር ለ sticky ማመጣጠን.
fun. ከተጣበቀ-አዝናኝ ጋር በሚመሳሰል መልኩ፣ እርስዎ ብቻ በተጨማሪ አቅጣጫ መቀየር፣ ውድቅ ማድረግ ወይም ቀድመው ሊያስሩት ይችላሉ።

የመለዋወጫ ነጥቡ ሲጀመር የማከፋፈያው ስልት ይዘጋጃል.

ከማመጣጠን በተጨማሪ መልእክት መላላክ አካላትን መለያ እንድትሰጥ ይፈቅድልሃል። በስርዓቱ ውስጥ ያሉትን የመለያ ዓይነቶች እንይ፡-

የግንኙነት መለያ። ክስተቶቹ በየትኛው ግንኙነት እንደመጡ እንዲረዱ ያስችልዎታል። የመቆጣጠሪያው ሂደት ከተመሳሳይ የመለዋወጫ ነጥብ ጋር ሲገናኝ ነገር ግን በተለያዩ የማዞሪያ ቁልፎች ጥቅም ላይ ይውላል።
የአገልግሎት መለያ። ለአንድ አገልግሎት ተቆጣጣሪዎችን በቡድን እንዲያዋህዱ እና የማዘዋወር እና የማመጣጠን ችሎታዎችን ለማስፋት ይፈቅድልዎታል። ለ req-resp ጥለት፣ ማዞሪያ መስመራዊ ነው። ጥያቄን ወደ ልውውጥ ነጥብ እንልካለን, ከዚያም ወደ አገልግሎቱ ያስተላልፋል. ነገር ግን ተቆጣጣሪዎቹን ወደ ሎጂካዊ ቡድኖች መከፋፈል ካስፈለገን መለያየት የሚከናወነው መለያዎችን በመጠቀም ነው። መለያ ሲገልጹ፣ ጥያቄው ለተወሰኑ የተቆጣጣሪዎች ቡድን ይላካል።
መለያ ጠይቅ በመልሶች መካከል እንዲለዩ ያስችልዎታል። ስርዓታችን የማይመሳሰል ስለሆነ የአገልግሎት ምላሾችን ለመስራት ጥያቄ ስንልክ RequestTag መግለፅ መቻል አለብን። ከእሱ የትኛው ጥያቄ ወደ እኛ እንደመጣ መልሱን ለመረዳት እንችላለን.

ፐብ-ንኡስ

ለመጠጥ ቤት ሁሉም ነገር ትንሽ ቀላል ነው። መልዕክቶች የሚታተሙበት የመለዋወጫ ነጥብ አለን። የመለዋወጫ ነጥቡ ለሚፈልጉት የማዞሪያ ቁልፎች በተመዘገቡ ተመዝጋቢዎች መካከል መልዕክቶችን ያሰራጫል (ይህ ከርዕሶች ጋር ተመሳሳይ ነው ማለት እንችላለን)።

የመጠን አቅም እና ስህተት መቻቻል

በአጠቃላይ የስርዓቱ መጠነ-ሰፊነት በስርዓቱ የንብርብሮች እና አካላት የመጠን መጠን ይወሰናል.

ለዚህ አገልግሎት ተጨማሪ አንጓዎችን ወደ ክላስተር ከተቆጣጣሪዎች ጋር በመጨመር አገልግሎቶቹ ይለካሉ። በሙከራ ክዋኔ ወቅት፣ በጣም ጥሩውን የማመጣጠን ፖሊሲ መምረጥ ይችላሉ።
በተለየ ክላስተር ውስጥ ያለው የመልእክት መላላኪያ አገልግሎት በአጠቃላይ ሚዛኑን የሚይዘው በተለይ የተጫኑ የመለዋወጫ ነጥቦችን ወደ የክላስተር ኖዶች በማንቀሳቀስ ወይም የተኪ ሂደቶችን ወደ ክላስተር በተጫኑ ቦታዎች በመጨመር ነው።
የአጠቃላዩ ስርዓት መስፋፋት እንደ ባህሪው በህንፃው ተለዋዋጭነት እና የግለሰብ ስብስቦችን ወደ አንድ የጋራ ሎጂካዊ አካል የማጣመር ችሎታ ላይ የተመሠረተ ነው።

የፕሮጀክት ስኬት በአብዛኛው የተመካው በመጠን ቀላልነት እና ፍጥነት ላይ ነው. አሁን ባለው ስሪት ውስጥ ያለው መልእክት ከመተግበሪያው ጋር አብሮ ያድጋል። ከ50-60 ማሽን ክላስተር ቢጎድለንም ወደ ፌዴሬሽን መግባት እንችላለን። እንደ አለመታደል ሆኖ የፌዴሬሽኑ ርዕሰ ጉዳይ ከዚህ ጽሑፍ ወሰን በላይ ነው።

ቦታ ማስያዝ

ጭነትን ማመጣጠን ስንመረምር፣ የአገልግሎት ተቆጣጣሪዎች ድጋሚ ስለመሆኑ አስቀድመን ተወያይተናል። ሆኖም፣ መልእክት መላላኪያም እንዲሁ መቀመጥ አለበት። የመስቀለኛ መንገድ ወይም የማሽን ብልሽት በሚከሰትበት ጊዜ፣ የመልእክት ልውውጥ በራስ-ሰር ማገገም አለበት፣ እና በተቻለ መጠን በአጭር ጊዜ።

በፕሮጀክቶቼ ውስጥ በመውደቅ ጊዜ ጭነቱን የሚወስዱ ተጨማሪ አንጓዎችን እጠቀማለሁ. Erlang ለኦቲፒ አፕሊኬሽኖች መደበኛ የተከፋፈለ ሞድ ትግበራ አለው። የተከፋፈለ ሁነታ ያልተሳካውን መተግበሪያ በሌላ ቀደም በተጀመረ መስቀለኛ መንገድ ላይ በማስጀመር ያልተሳካ ከሆነ መልሶ ማግኘትን ያከናውናል. ሂደቱ ግልጽ ነው፣ ከውድቀት በኋላ፣ አፕሊኬሽኑ በራስ-ሰር ወደ ውድቀት መስቀለኛ መንገድ ይንቀሳቀሳል። ስለዚህ ተግባር የበለጠ ማንበብ ይችላሉ። እዚህ.

ምርታማነት

ቢያንስ የ rabbitmq አፈጻጸምን እና ብጁ የመልእክት መላላኪያችንን ለማነፃፀር እንሞክር።
አገኘሁ ኦፊሴላዊ ውጤቶች Rabbitmq ሙከራ ከ openstack ቡድን።

በአንቀጽ 6.14.1.2.1.2.2. ዋናው ሰነድ የ RPC CAST ውጤት ያሳያል፡-

ለ OS kernel ምንም ተጨማሪ ቅንጅቶችን አናደርግም ወይም ቪኤምን አስቀድመን አናደርግም። ለሙከራ ሁኔታዎች;

erl መርጦዎች፡ +A1 +sbtu።
በነጠላ erlang node ውስጥ ያለው ሙከራ በተንቀሳቃሽ ስልክ ስሪት ውስጥ አሮጌ i7 ባለው ላፕቶፕ ላይ ይካሄዳል።
የክላስተር ሙከራዎች የሚከናወኑት የ10ጂ ኔትወርክ ባላቸው አገልጋዮች ላይ ነው።
ኮዱ በዶከር ኮንቴይነሮች ውስጥ ይሰራል። አውታረ መረብ በ NAT ሁነታ.

የሙከራ ኮድ

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

ሁኔታ 1፡ ሙከራው በላፕቶፕ ላይ የሚሰራው ከአሮጌ i7 የሞባይል ስሪት ጋር ነው። ሙከራው፣ መላላኪያው እና አገልግሎቱ በአንድ መስቀለኛ መንገድ በአንድ ዶከር መያዣ ውስጥ ይፈጸማል፡-

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

ሁኔታ 2በዶክተር (ኤንኤቲ) ስር በተለያዩ ማሽኖች ላይ የሚሰሩ 3 አንጓዎች።

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

በሁሉም ሁኔታዎች የሲፒዩ አጠቃቀም ከ 250% አይበልጥም.

ውጤቶች

ይህ ዑደት እንደ አእምሮ የማይታይ አይመስልም እናም የእኔ ልምድ ለሁለቱም የተከፋፈሉ ስርዓቶች ተመራማሪዎች እና ለንግድ ስርዓታቸው የተከፋፈሉ አርክቴክቸር በመገንባት ላይ ላሉ እና ኤርላንግ/ኤሊሲርን በፍላጎት ለሚመለከቱት ባለሙያዎች እውነተኛ ጥቅም እንደሚኖረው ተስፋ አደርጋለሁ። ግን ጥርጣሬ ይኑረው ይህ ዋጋ አለው ...

ፎቶ @chuttersnap

በዳሰሳ ጥናቱ ውስጥ የተመዘገቡ ተጠቃሚዎች ብቻ መሳተፍ ይችላሉ። ስግን እንእባክህን።

እንደ የVTrade ሙከራ ተከታታዮች የትኞቹን ርዕሶች በዝርዝር መሸፈን አለብኝ?

ቲዎሪ፡ ገበያዎች፣ ትዕዛዞች እና ጊዜያቸው፡ DAY፣ GTD፣ GTC፣ IOC፣ FOK፣ MOO፣ MOC፣ LOO፣ LOC
የትዕዛዝ መጽሐፍ። መጽሐፍን ከቡድን ጋር የመተግበር ጽንሰ-ሀሳብ እና ልምምድ
የግብይት እይታ: መዥገሮች, ቡና ቤቶች, ጥራቶች. እንዴት ማከማቸት እና እንዴት እንደሚጣበቅ
የኋላ ጽሕፈት ቤት። እቅድ እና ልማት. የሰራተኞች ክትትል እና ክስተት ምርመራ
ኤፒአይ ምን በይነገጾች እንደሚያስፈልጉ እና እንዴት እንደሚተገበሩ እንወቅ
የመረጃ ማከማቻ፡ PostgreSQL፣ Timecale፣ Tarantool በንግድ ስርዓቶች ውስጥ
በግብይት ስርዓቶች ውስጥ ምላሽ መስጠት
ሌላ. በአስተያየቶቹ ውስጥ እጽፋለሁ

6 ተጠቃሚዎች ድምጽ ሰጥተዋል። 4 ተጠቃሚዎች ድምፀ ተአቅቦ አድርገዋል።

ምንጭ: hab.com

የተከፋፈሉ መተግበሪያዎች ግንባታ ብሎኮች። ሁለተኛ ግምት