HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

ቀጣዩ የHighLoad++ ኮንፈረንስ ኤፕሪል 6 እና 7፣ 2020 በሴንት ፒተርስበርግ ይካሄዳል።
ዝርዝሮች እና ቲኬቶች ማያያዣ. ሃይሎድ ++ ሳይቤሪያ 2019. አዳራሽ "Krasnoyarsk". ሰኔ 25, 12:00. እነዚህ እና አቀራረብ.

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

ለንግድ ምርት አስፈላጊ የሆኑ ገጽታዎች ከግምት ውስጥ በማይገቡበት ጊዜ ተግባራዊ መስፈርቶች ከቲዎሪ ጋር የሚጋጩ መሆናቸው ይከሰታል። ይህ ንግግር በንግድ ምርት መስፈርቶች ላይ በመመርኮዝ በአካዳሚክ ምርምር ላይ በመመርኮዝ የምክንያት ወጥነት ክፍሎችን ለመፍጠር የተለያዩ አቀራረቦችን የመምረጥ እና የማጣመር ሂደትን ያቀርባል። አድማጮች ስለ ሎጂካዊ ሰዓቶች፣ የጥገኝነት ክትትል፣ የስርዓት ደህንነት፣ የሰዓት ማመሳሰል እና MongoDB ለምን በተወሰኑ መፍትሄዎች ላይ እንደተቀመጠው ስለ ነባር ቲዎሬቲካል አቀራረቦች ይማራሉ ።

ሚካሂል ታይሌኔቭ (ከዚህ በኋላ ኤምቲ ተብሎ ይጠራል) - ስለ የምክንያት ወጥነት እናገራለሁ - ይህ በሞንጎዲቢ ውስጥ የሰራነው ባህሪ ነው። እኔ በቡድን በተከፋፈሉ ስርዓቶች ውስጥ እሰራለሁ, ከሁለት አመት በፊት ሠርተናል.

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

በሂደቱ ውስጥ ራሴን ከብዙ የአካዳሚክ ምርምር ጋር በደንብ ማወቅ ነበረብኝ ፣ ምክንያቱም ይህ ባህሪ በጥሩ ሁኔታ የተጠና ነው። ምናልባት በማናቸውም የምርት አፕሊኬሽን ውስጥ ባሉ በጣም ልዩ መስፈርቶች ምክንያት በምርት ዳታቤዝ ውስጥ ከሚፈለገው ጋር አንድም መጣጥፍ እንደማይገባ ታወቀ።

እኛ የአካዳሚክ ምርምር ሸማቾች እንደመሆናችን መጠን ከእሱ ውስጥ የሆነ ነገር ለማዘጋጀት እንዴት እንደምናዘጋጅ እናገራለሁ, ከዚያም ለተጠቃሚዎቻችን እንደ ዝግጁ-የተሰራ ምግብ ለመጠቀም ምቹ እና ደህንነቱ የተጠበቀ.

የምክንያት ወጥነት. ፅንሰ-ሀሳቦቹን እንገልፃቸው

ለመጀመር ፣ የምክንያት ወጥነት ምን እንደሆነ በጥቅሉ መናገር እፈልጋለሁ። ሁለት ቁምፊዎች አሉ - ሊዮናርድ እና ፔኒ (የቲቪ ተከታታይ "ቢግ ባንግ ቲዎሪ")፡

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

ፔኒ አውሮፓ ውስጥ ናት እና ሊዮናርድ አስገራሚ ድግስ ሊያደርጋት ይፈልጋል እንበል። እና እሷን ከጓደኛ ዝርዝር ውስጥ ከመጣል የተሻለ ነገር ማሰብ አይችልም, ሁሉንም ጓደኞቹ በምግብ ላይ ማሻሻያ በመላክ: "ፔኒን እናስደስት!" (እሷ አውሮፓ ውስጥ ነው, ተኝታ ሳለ, ይህን ሁሉ አይታይም እና ማየት አይችልም, ምክንያቱም እሷ ስለሌለች). በመጨረሻ፣ ይህን ልጥፍ ትሰርዛለች፣ ከምግቡ ላይ ትሰርዛለች እና ምንም ነገር እንዳታስተውል እና ምንም አይነት ቅሌት እንዳይኖር መዳረሻን ትመልሳለች።
ይህ ሁሉ መልካም እና ጥሩ ነው, ነገር ግን ስርዓቱ ተከፋፍሏል እና ነገሮች ትንሽ ተሳስተዋል ብለን እናስብ. ለምሳሌ፣ ይህ ልጥፍ ከወጣ በኋላ የፔኒ መዳረሻ ገደብ ተከስቶ ሊሆን ይችላል፣ ክስተቶቹ በምክንያት እና በውጤት የማይገናኙ ከሆኑ። በእውነቱ ፣ ይህ የንግድ ሥራን ለማከናወን (በዚህ ጉዳይ ላይ) የምክንያት ወጥነት ሲያስፈልግ ምሳሌ ነው።

እንደ እውነቱ ከሆነ እነዚህ የመረጃ ቋቱ በጣም ቀላል ያልሆኑ ባህሪያት ናቸው - በጣም ጥቂት ሰዎች ይደግፏቸዋል. ወደ ሞዴሎቹ እንሂድ.

ወጥነት ያላቸው ሞዴሎች

በመረጃ ቋቶች ውስጥ በትክክል ወጥነት ያለው ሞዴል ምንድን ነው? እነዚህ የተከፋፈለ ስርዓት ደንበኛው ምን አይነት ውሂብ ሊቀበል እንደሚችል እና በምን ቅደም ተከተል የሚሰጠውን አንዳንድ ዋስትናዎች ናቸው.

በመርህ ደረጃ, ሁሉም ወጥነት ያላቸው ሞዴሎች የተከፋፈለው ስርዓት ምን ያህል እንደሚመሳሰል ይወርዳሉ, ለምሳሌ, በላፕቶፕ ላይ በአንድ መስቀለኛ መንገድ ላይ. እና በሺዎች በሚቆጠሩ የጂኦ-ስርጭት "ኖዶች" ላይ የሚሰራ ስርዓት ከላፕቶፕ ጋር ተመሳሳይነት ያለው ሲሆን እነዚህ ሁሉ ባህሪያት በመርህ ደረጃ በራስ-ሰር ይከናወናሉ.

ስለዚህ, ወጥነት ያላቸው ሞዴሎች ለተከፋፈሉ ስርዓቶች ብቻ ይተገበራሉ. ቀደም ሲል የነበሩት እና በተመሳሳይ ቋሚ ልኬት ላይ የሚሰሩ ሁሉም ስርዓቶች እንደዚህ አይነት ችግሮች አላጋጠማቸውም. አንድ ቋት መሸጎጫ ነበረ፣ እና ሁሉም ነገር ሁልጊዜ ከእሱ ይነበባል።

ሞዴል ጠንካራ

እንደ እውነቱ ከሆነ, የመጀመሪያው ሞዴል ጠንካራ ነው (ወይም የመነሳት ችሎታ መስመር, ብዙውን ጊዜ እንደሚጠራው). ይህ እያንዳንዱ ለውጥ አንዴ መከሰቱን ከተረጋገጠ ለሁሉም የስርዓቱ ተጠቃሚዎች የሚታይ መሆኑን የሚያረጋግጥ ወጥነት ያለው ሞዴል ነው።

ይህ በመረጃ ቋቱ ውስጥ የሁሉንም ሁነቶች ዓለም አቀፋዊ ቅደም ተከተል ይፈጥራል። ይህ በጣም ጠንካራ ወጥነት ያለው ንብረት ነው, እና በአጠቃላይ በጣም ውድ ነው. ሆኖም ግን, በጣም በጥሩ ሁኔታ የተደገፈ ነው. እሱ በጣም ውድ እና ዘገምተኛ ነው - እሱ በጣም አልፎ አልፎ ጥቅም ላይ ይውላል። ይህ የመነሳት ችሎታ ይባላል.

በስፓነር ውስጥ የሚደገፍ ሌላ ጠንካራ ንብረት አለ - ውጫዊ ወጥነት ይባላል። ትንሽ ቆይተን እንነጋገራለን.

ምክንያት

የሚቀጥለው ካውሳል ነው፣ እሱም በትክክል እየተናገርኩት ነው። በጠንካራ እና በምክንያት መካከል የማልናገርባቸው ብዙ ንዑስ ደረጃዎች አሉ፣ ግን ሁሉም ወደ ካውሳል ይወርዳሉ። ይህ በጣም አስፈላጊ ሞዴል ነው, ምክንያቱም ከሁሉም ሞዴሎች ውስጥ በጣም ጠንካራው, በኔትወርክ ወይም ክፍልፋዮች ውስጥ በጣም ጠንካራው ወጥነት ነው.

መንስኤዎች በእውነቱ ክስተቶች በምክንያት እና በውጤት ግንኙነት የተገናኙበት ሁኔታ ነው። ብዙ ጊዜ የመብቶችዎን ከደንበኛው እይታ አንፃር ያንብቡ ተብሎ ይታሰባል። ደንበኛው አንዳንድ እሴቶችን ካስተዋለ, ከዚህ በፊት የነበሩትን እሴቶች ማየት አይችልም. እሱ አስቀድሞ ቅድመ ቅጥያ ንባቦችን ማየት ጀምሯል። ሁሉም ወደ ተመሳሳይ ነገር ይወርዳል.
መንስኤዎች እንደ ወጥነት ሞዴል በአገልጋዩ ላይ ከፊል የክስተቶች ቅደም ተከተል ነው ፣ በዚህ ውስጥ የሁሉም ደንበኞች ክስተቶች በተመሳሳይ ቅደም ተከተል ይታያሉ። በዚህ ጉዳይ ላይ ሊዮናርድ እና ፔኒ.

በመጨረሻም

ሦስተኛው ሞዴል የመጨረሻው ወጥነት ነው. ይህ በፍፁም ሁሉም የተከፋፈሉ ስርዓቶች የሚደግፉት ነው, ምንም ትርጉም ያለው አነስተኛ ሞዴል. የሚከተለው ማለት ነው፡ በመረጃው ላይ አንዳንድ ለውጦች ሲኖሩን, በተወሰነ ደረጃ ላይ ወጥነት ይኖራቸዋል.

በእንደዚህ ዓይነት ቅጽበት ምንም አትናገርም, አለበለዚያ ወደ ውጫዊ ወጥነት ትለውጣለች - ፍጹም የተለየ ታሪክ ይሆናል. ቢሆንም, ይህ በጣም ተወዳጅ ሞዴል ነው, በጣም የተለመደው. በነባሪነት ሁሉም የተከፋፈሉ ስርዓቶች ተጠቃሚዎች ውሎ አድሮ ወጥነትን ይጠቀማሉ።

አንዳንድ ተነጻጻሪ ምሳሌዎችን መስጠት እፈልጋለሁ፡-

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

እነዚህ ቀስቶች ምን ማለት ናቸው?

  • መዘግየት። የወጥነት ጥንካሬው እየጨመረ በሄደ ቁጥር ግልጽ በሆኑ ምክንያቶች ትልቅ ይሆናል፡ ብዙ መዝገቦችን መስራት፣ መረጃው አስቀድሞ እንዳለ በክላስተር ውስጥ ከሚሳተፉ ሁሉም አስተናጋጆች እና አንጓዎች ማረጋገጫ ማግኘት ያስፈልግዎታል። በዚህ መሠረት የመጨረሻው ወጥነት በጣም ፈጣኑ መልስ አለው, ምክንያቱም እዚያ እንደ አንድ ደንብ, ለማስታወስ እንኳን ሊያደርጉት ይችላሉ እና ይህ በመርህ ደረጃ, በቂ ይሆናል.
  • መገኘት. የስርአቱ የኔትዎርክ መቆራረጥ፣ ክፍልፋዮች ወይም ብልሽቶች ባሉበት ጊዜ ምላሽ የመስጠት አቅም እንደሆነ ከተረዳን አንድ አስተናጋጅ መኖር በቂያችን ስለሆነ የስህተት መቻቻል እየጨመረ ይሄዳል። ጊዜ አንዳንድ ውሂብ ይፈጥራል. የመጨረሻው ወጥነት ሾለ ውሂቡ ምንም ዋስትና አይሰጥም - ምንም ሊሆን ይችላል።
  • ያልተለመዱ ነገሮች. በተመሳሳይ ጊዜ, እርግጥ ነው, anomalies ቁጥር ይጨምራል. በጠንካራ ወጥነት ውስጥ እነሱ ከሞላ ጎደል መኖር የለባቸውም፣ ነገር ግን በመጨረሻው ወጥነት ምንም ሊሆኑ ይችላሉ። ጥያቄው የሚነሳው፡- ለምንድነው ሰዎች ያልተለመዱ ነገሮችን ከያዘው ለምንድነው? መልሱ የመጨረሻው ወጥነት ሞዴሎች ተፈፃሚነት ያላቸው እና ያልተለመዱ ነገሮች አሉ, ለምሳሌ በአጭር ጊዜ ውስጥ; ለማንበብ ጠንቋዩን መጠቀም እና ብዙ ወይም ባነሰ ተከታታይ ውሂብ ማንበብ ይቻላል; ብዙውን ጊዜ ጠንካራ ወጥነት ያላቸው ሞዴሎችን መጠቀም ይቻላል. በተግባር ይህ ይሠራል, እና ብዙ ጊዜ ያልተለመዱ ነገሮች ቁጥር በጊዜ የተገደበ ነው.

CAP ቲዎረም

ቃላቶቹን ሲመለከቱ ወጥነት, ተገኝነት - ወደ አእምሮዎ የሚመጣው ምንድን ነው? ልክ ነው - የ CAP ቲዎረም! አሁን አፈ ታሪኩን ማስወገድ እፈልጋለሁ ... እኔ አይደለሁም - አስደናቂ ጽሁፍ፣ ድንቅ መጽሐፍ የጻፈው ማርቲን ክሌፕማን ነው።

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

የCAP ቲዎረም በ2000ዎቹ ውስጥ ወጥነት፣ ተገኝነት፣ ክፍልፍሎች፡ ሁለቱንም ይውሰዱ እና ሶስት መምረጥ አይችሉም የሚለው መርህ ነው። የተወሰነ መርህ ነበር። ከጥቂት አመታት በኋላ በጊልበርት እና በሊንች እንደ ቲዎሪ ተረጋግጧል። ከዚያም ይህ እንደ ማንትራ ጥቅም ላይ መዋል ጀመረ - ስርዓቶች ወደ CA, CP, AP እና የመሳሰሉት መከፋፈል ጀመሩ.

ይህ ጽንሰ-ሐሳብ በእውነቱ ለሚከተሉት ጉዳዮች የተረጋገጠ ነው… በመጀመሪያ ፣ ተገኝነት ከዜሮ እስከ በመቶዎች ድረስ እንደ ቀጣይ እሴት ተደርጎ አይቆጠርም (0 - ስርዓቱ “ሞተ” ፣ 100 - በፍጥነት ምላሽ ይሰጣል ፣ እሱን እንደዚያ ለመመልከት እንለማመዳለን) , ግን እንደ አልጎሪዝም ንብረት ነው, እሱም ለሁሉም አፈፃፀሞቹ መረጃን እንደሚመልስ ዋስትና ይሰጣል.

ስለ ምላሽ ጊዜ ምንም ቃል የለም! ከ 100 ዓመታት በኋላ መረጃን የሚመልስ ስልተ ቀመር አለ - ፍጹም አስደናቂ የሆነ አልጎሪዝም ፣ እሱም የ CAP ቲዎሬም አካል ነው።
ሁለተኛ፡ ንድፈ ሀሳቡ በተመሳሳይ ቁልፍ እሴቶች ላይ ለተደረጉ ለውጦች ተረጋግጧል፣ ምንም እንኳን እነዚህ ለውጦች ሊቀየሩ የሚችሉ ቢሆኑም። ይህ ማለት በእውነቱ እነሱ በተግባር ጥቅም ላይ አይውሉም, ምክንያቱም ሞዴሎቹ የተለያዩ ናቸው የመጨረሻው ወጥነት , ጠንካራ ወጥነት (ምናልባት).

ይህ ሁሉ ለምንድነው? በተጨማሪም ፣ የ CAP ቲዎሬም በትክክል በተረጋገጠበት ቅጽ ውስጥ በተግባር የማይተገበር እና ብዙም ጥቅም ላይ የማይውል ነው። በንድፈ ሀሳባዊ መልክ, በሆነ መንገድ ሁሉንም ነገር ይገድባል. በትክክል ትክክለኛ የሆነ አንድ የተወሰነ መርህ ይወጣል ፣ ግን በአጠቃላይ አልተረጋገጠም።

የምክንያት ወጥነት በጣም ጠንካራው ሞዴል ነው።

አሁን እየሆነ ያለው ነገር ሦስቱን ነገሮች ማግኘት ይችላሉ: ወጥነት, ክፍልፋይ በመጠቀም ተገኝነት. በተለይም የምክንያት ወጥነት በጣም ጠንካራው ወጥነት ያለው ሞዴል ነው ፣ አሁንም በክፍሎች (በአውታረ መረቡ ውስጥ መሰባበር) ባሉበት ይሠራል። ለዚያም ነው ትልቅ ፍላጎት ያለው, እና ለዚህ ነው የወሰድነው.

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

በመጀመሪያ ደረጃ, የመተግበሪያ ገንቢዎችን ስራ ቀላል ያደርገዋል. በተለይም ከአገልጋዩ ከፍተኛ ድጋፍ መኖሩ: በአንድ ደንበኛ ውስጥ የሚከሰቱ ሁሉም መዝገቦች በሌላ ደንበኛ ላይ በተመሳሳይ ቅደም ተከተል ሲደርሱ. በሁለተኛ ደረጃ, ክፍልፋዮችን ይቋቋማል.

MongoDB የውስጥ ወጥ ቤት

ምሳ መሆኑን በማስታወስ ወደ ኩሽና እንሄዳለን። ስለ ስርዓቱ ሞዴል እነግራችኋለሁ, ማለትም, MongoDB ስለ እንደዚህ አይነት የውሂብ ጎታ ለመጀመሪያ ጊዜ ለሚሰሙት ሰዎች ምን ማለት ነው.

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

MongoDB (ከዚህ በኋላ "MongoDB") ተብሎ የሚጠራው አግድም ሚዛንን የሚደግፍ የተከፋፈለ ስርዓት ነው, ማለትም, sharding; እና በእያንዳንዱ ሸርተቴ ውስጥ እንዲሁ የውሂብ ድግግሞሽን ይደግፋል ፣ ማለትም ፣ ማባዛት።

በMongoDB ውስጥ መጋራት (ተዛማጅ ዳታቤዝ አይደለም) አውቶማቲክ ሚዛንን ያከናውናል ፣ ማለትም ፣ እያንዳንዱ የሰነዶች ስብስብ (ወይም “ጠረጴዛ” በግንኙነት መረጃ) ወደ ቁርጥራጮች ይከፋፈላል ፣ እና አገልጋዩ በራስ-ሰር በሻርዶች መካከል ያንቀሳቅሳቸዋል።

ጥያቄዎችን የሚያሰራጭ የጥያቄ ራውተር ለደንበኛ የሚሠራበት የተወሰነ ደንበኛ ነው። የት እና ምን ውሂብ እንደሚገኝ አስቀድሞ ያውቃል እና ሁሉንም ጥያቄዎች ወደ ትክክለኛው ሸርተቴ ይመራል።

ሌላ አስፈላጊ ነጥብ: MongoDB ነጠላ ዋና ነው. አንድ የመጀመሪያ ደረጃ አለ - በውስጡ የያዘውን ቁልፎች የሚደግፉ መዝገቦችን ሊወስድ ይችላል. መልቲ-ማስተር መፃፍ አይችሉም።

4.2 መልቀቅን አደረግን - አዲስ አስደሳች ነገሮች እዚያ ታዩ። በተለይም ሉሴን - ፍለጋ - ማለትም executable java በቀጥታ ወደ ሞንጎ አስገብተው ነበር፣ እና እዚያም በኤልስቲካ እንደነበረው በሉሴን በኩል ፍለጋዎችን ማድረግ ተችሏል።

እና አዲስ ምርት ሰሩ - ገበታዎች፣ እሱም በአትላስ (የሞንጎ የራሱ ደመና) ላይም ይገኛል። ነፃ ደረጃ አላቸው - ከእሱ ጋር መጫወት ይችላሉ። ገበታዎችን በጣም ወድጄዋለሁ - የውሂብ እይታ ፣ በጣም የሚታወቅ።

ግብዓቶች የምክንያት ወጥነት

በዚህ ርዕስ ላይ የታተሙ ወደ 230 የሚጠጉ ጽሑፎችን ቆጠርኩ - ከሌስሊ ላምፐርት። አሁን ከማስታወሻዬ የእነዚህን ቁሳቁሶች አንዳንድ ክፍሎች እነግርዎታለሁ።

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

ይህ ሁሉ የተጀመረው በ1970ዎቹ በተጻፈው በሌስሊ ላምፐርት መጣጥፍ ነው። እንደምታየው በዚህ ርዕስ ላይ አንዳንድ ጥናቶች አሁንም በመካሄድ ላይ ናቸው. አሁን የምክንያት ወጥነት ከተከፋፈሉ ስርዓቶች ልማት ጋር በተያያዘ ፍላጎት እያጋጠመው ነው።

ገደቦች

ምን ገደቦች አሉ? ይህ በእውነቱ ከዋና ዋናዎቹ አንዱ ነው, ምክንያቱም የምርት ስርዓት የሚጥላቸው ገደቦች በአካዳሚክ መጣጥፎች ውስጥ ካሉ ገደቦች በጣም የተለዩ ናቸው. እነሱ ብዙውን ጊዜ ሰው ሰራሽ ናቸው።

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

  • በመጀመሪያ፣ “MongoDB” ቀደም ብዬ እንዳልኩት ነጠላ ጌታ ነው (ይህ በጣም ያቃልላል)።
  • ስርዓቱ ወደ 10 ሺህ የሚጠጉ ሻርዶችን መደገፍ አለበት ብለን እናምናለን. ይህንን እሴት በግልፅ የሚገድቡ ማንኛውንም የስነ-ህንፃ ውሳኔዎችን ማድረግ አንችልም።
  • ደመና አለን, ነገር ግን አንድ ሰው ሁለትዮሽ ሲያወርድ, በላፕቶፑ ላይ ሲያስነሳ እና ሁሉም ነገር በጥሩ ሁኔታ ሲሰል አሁንም እድሉ ሊኖረው ይገባል ብለን እናስባለን.
  • ምርምር እምብዛም የማይገምተውን ነገር እንገምታለን፡ የውጭ ደንበኞች የፈለጉትን ማድረግ ይችላሉ። MongoDB ክፍት ምንጭ ነው። በዚህ መሠረት ደንበኞች በጣም ብልህ እና ቁጡ ሊሆኑ ይችላሉ - ሁሉንም ነገር መስበር ይፈልጋሉ። የባይዛንታይን ፌይለሮች ሊመነጩ እንደሚችሉ እንገምታለን።
  • ከፔሚሜትር ውጭ ለሆኑ የውጭ ደንበኞች, አስፈላጊ ገደብ አለ: ይህ ባህሪ ከተሰናከለ, ምንም የአፈፃፀም ውድቀት መታየት የለበትም.
  • ሌላው ነጥብ በአጠቃላይ ፀረ-አካዳሚክ ነው-የቀድሞዎቹ ስሪቶች እና የወደፊት ስሪቶች ተኳሃኝነት. የድሮ አሽከርካሪዎች አዲስ ዝመናዎችን መደገፍ አለባቸው፣ እና የውሂብ ጎታው የቆዩ አሽከርካሪዎችን መደገፍ አለበት።

በአጠቃላይ ይህ ሁሉ ገደቦችን ያስገድዳል.

የምክንያት ወጥነት ክፍሎች

አሁን ስለ አንዳንድ አካላት እናገራለሁ. የምክንያት ወጥነትን በአጠቃላይ ካሰብን ብሎኮችን መምረጥ እንችላለን። የአንድ የተወሰነ ብሎክ ከሆኑ ሥራዎች መረጥን-ጥገኛ መከታተል ፣ሰዓቶችን መምረጥ ፣እነዚህ ሰዓቶች እርስበርስ እንዴት እንደሚመሳሰሉ እና እንዴት ደህንነትን እንደምናረጋግጥ - ይህ ስለ የምናገረው አጭር መግለጫ ነው።

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

ሙሉ ጥገኝነት መከታተል

ለምን ያስፈልጋል? ስለዚህ ውሂብ ሲባዛ, እያንዳንዱ መዝገብ, እያንዳንዱ የውሂብ ለውጥ በየትኛው ለውጦች ላይ እንደሚወሰን መረጃ ይይዛል. የመጀመሪያው እና የዋህ ለውጥ እያንዳንዱ መዝገብ የያዘ መልእክት ስለቀደሙት መልዕክቶች መረጃ ሲይዝ ነው።

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

በዚህ ምሳሌ፣ በጥምዝ ቅንፎች ውስጥ ያለው ቁጥር የመመዝገቢያ ቁጥሮች ነው። አንዳንድ ጊዜ እነዚህ እሴቶች ያላቸው መዝገቦች ሙሉ በሙሉ ይተላለፋሉ ፣ አንዳንድ ጊዜ አንዳንድ ስሪቶች ይተላለፋሉ። ዋናው ነገር እያንዳንዱ ለውጥ ስለ ቀዳሚው መረጃ ይዟል (ይህን ሁሉ በራሱ ውስጥ እንደሚይዝ ግልጽ ነው).

ይህንን አካሄድ (ሙሉ ክትትልን) ላለመጠቀም የወሰንነው ለምንድነው? በግልጽ ለማየት እንደሚቻለው, ይህ አካሄድ ተግባራዊ ሊሆን የማይችል ነው-በማህበራዊ አውታረመረብ ላይ የሚደረግ ማንኛውም ለውጥ በማህበራዊ አውታረመረብ ላይ በነበሩት ሁሉም ለውጦች ላይ የተመሰረተ ነው, በእያንዳንዱ ዝመና ውስጥ ፌስቡክን ወይም VKontakteን በማስተላለፍ ላይ ነው. ቢሆንም፣ ሙሉ ጥገኝነት መከታተል ላይ ብዙ ጥናቶች አሉ - እነዚህ ቅድመ-ማህበራዊ አውታረ መረቦች ናቸው፤ ለአንዳንድ ሁኔታዎች በትክክል ይሰራል።

ግልጽ ጥገኝነት መከታተል

የሚቀጥለው የበለጠ የተገደበ ነው. የመረጃ ዝውውሩ እዚህም ግምት ውስጥ ይገባል, ግን በግልጽ የሚመረኮዝ ብቻ ነው. ምን ላይ ይወሰናል, እንደ አንድ ደንብ, በመተግበሪያው ይወሰናል. ውሂብ ሲባዛ፣ መጠይቁ ምላሾችን የሚመለሰው የቀደሙት ጥገኞች ሲሟሉ ብቻ ነው፣ ማለትም፣ ሲታዩ። የምክንያት ወጥነት እንዴት እንደሚሰራ ዋናው ነገር ይህ ነው።

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

እሷ ያንን መዝገብ 5 በመዝገቦች 1, 2, 3, 4 ላይ የተመሰረተ እንደሆነ ትመለከታለች - በዚህ መሠረት ደንበኛው በፔኒ የመዳረሻ ውሳኔ የተደረጉ ለውጦችን ከማግኘቱ በፊት ትጠብቃለች, ሁሉም የቀደሙት ለውጦች ቀድሞውኑ በመረጃ ቋቱ ውስጥ አልፈዋል.

ይሄ እኛንም አይስማማንም, ምክንያቱም አሁንም ብዙ መረጃ አለ, እና ነገሮችን ይቀንሳል. ሌላ አካሄድ አለ...

ላምፖርት ሰዓት

በጣም ያረጁ ናቸው። Lamport Clock ማለት እነዚህ ጥገኞች ወደ scalar function ይታጠፉ ማለት ነው፣ እሱም Lamport ሰዓት ይባላል።

ስካላር ተግባር የተወሰነ ረቂቅ ቁጥር ነው። ብዙውን ጊዜ ምክንያታዊ ጊዜ ይባላል. በእያንዳንዱ ክስተት, ይህ ቆጣሪ ይጨምራል. በአሁኑ ጊዜ በሂደቱ የሚታወቀው ቆጣሪ እያንዳንዱን መልእክት ይልካል። ሂደቶች ሊበታተኑ እንደሚችሉ ግልጽ ነው, ሙሉ ለሙሉ የተለያዩ ጊዜዎች ሊኖራቸው ይችላል. የሆነ ሆኖ ስርዓቱ በሆነ መንገድ ሰዓቱን ከእንደዚህ አይነት መልእክት ጋር ያስተካክላል። በዚህ ጉዳይ ላይ ምን ይሆናል?

ግልፅ ለማድረግ ያን ትልቅ ስብርባሪዎች ለሁለት ከፍዬዋለሁ፡ ጓደኞቼ በአንድ መስቀለኛ መንገድ መኖር ይችላሉ፣ እሱም የክምችቱን ቁራጭ ይይዛል፣ እና ፊድ በሌላ መስቀለኛ መንገድ መኖር ይችላል፣ እሱም የዚህ ስብስብ ቁራጭ ይይዛል። ከመስመር እንዴት መውጣት እንደሚችሉ ግልጽ ነው? የመጀመሪያ ምግብ እንዲህ ይላል፡- “የተደገመ”፣ እና ከዚያ ጓደኞች። ስርዓቱ በጓደኞች ስብስብ ውስጥ ያሉ የጓደኛዎች ጥገኝነት እስካልተሰጠ ድረስ ምግቡ እንደማይታይ አንድ ዓይነት ዋስትና ካልሰጠ፣ ያኔ የጠቀስኩት በትክክል ይኖረናል።

በምግብ ላይ ያለው የቆጣሪ ጊዜ በሎጂክ እንዴት እንደሚጨምር ያያሉ፡

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

ስለዚህ የዚህ ላምፖርት ሰዓት እና የምክንያት ወጥነት (በ Lamport Clock በኩል የተገለፀው) ዋናው ንብረቱ ይህ ነው፡- ክስተቶች A እና B ካሉን እና ክስተት B በክስተት A* ላይ የተመሰረተ ከሆነ የሚከተለው የ LogicalTime of Event A ከ ያነሰ ነው. LogicalTime ከክስተት ቢ.

* አንዳንድ ጊዜ ደግሞ ሀ ከ B በፊት ተከስቷል ይላሉ ፣ ማለትም ፣ ሀ ከ B በፊት ተከስቷል - ይህ በአጠቃላይ የተከሰቱትን አጠቃላይ ክስተቶች በከፊል የሚያዝ የተወሰነ ግንኙነት ነው።

ተቃራኒው ትክክል አይደለም። ይህ በእውነቱ የ Lamport Clock ዋና ጉዳቶች አንዱ ነው - ከፊል ቅደም ተከተል። በአንድ ጊዜ ስለሚደረጉ ክስተቶች፣ ማለትም፣ (ሀ ከ B በፊት ያልተከሰተ) ወይም (ሀ ከ B በፊት ያልተከሰቱ) ክስተቶች ጽንሰ-ሀሳብ አለ። ምሳሌ የሊዮናርድ ትይዩ የሆነ ሌላ ሰው እንደ ጓደኛ መጨመር ነው (ሌናርድ እንኳን ሳይሆን ሼልደን ለምሳሌ)።
ይህ ከላምፖርት ሰዓቶች ጋር ሲሰራ ብዙውን ጊዜ ጥቅም ላይ የሚውለው ንብረት ነው: በተለይ ተግባሩን ይመለከታሉ እና ከዚህ በመነሳት ምናልባት እነዚህ ክስተቶች ጥገኛ ናቸው ብለው ይደመድማሉ. ምክንያቱም አንደኛው መንገድ እውነት ነው፡ LogicalTime A ከ LogicalTime B ያነሰ ከሆነ፣ B ከ A በፊት ሊከሰት አይችልም። እና የበለጠ ከሆነ, ከዚያ ምናልባት.

የቬክተር ሰዓት

የ Lamport ሰዓት ምክንያታዊ እድገት የቬክተር ሰዓት ነው. እዚህ ያለው እያንዳንዱ መስቀለኛ መንገድ የራሱ የሆነ ሰዓት ስላለው ይለያያሉ, እና እንደ ቬክተር ይተላለፋሉ.
በዚህ ሁኔታ, የቬክተር ዜሮ ኢንዴክስ ለምግብነት ተጠያቂ እንደሆነ ታያለህ, እና የቬክተሩ የመጀመሪያ ጠቋሚ ለጓደኞች (እያንዳንዱ እነዚህ አንጓዎች) ነው. እና አሁን ይጨምራሉ፡- ሲጽፉ የ“ምግብ” ዜሮ መረጃ ጠቋሚ ይጨምራል - 1፣ 2፣ 3፡

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

የቬክተር ሰዓት ለምን የተሻለ ነው? ምክንያቱም የትኞቹ ክስተቶች በአንድ ጊዜ እንደሆኑ እና በተለያዩ አንጓዎች ላይ ሲከሰቱ እንዲያውቁ ያስችሉዎታል. ይህ እንደ MongoDB ላለ የሻርዲንግ ስርዓት በጣም አስፈላጊ ነው። ቢሆንም፣ ይህን አልመረጥነውም፣ ምንም እንኳን አስደናቂ ነገር ቢሆንም፣ እና በጣም ጥሩ ይሰራል፣ እና ምናልባት ይስማማናል...

10 ሼዶች ካሉን, 10 ክፍሎችን ማስተላለፍ አንችልም, ምንም እንኳን ጨምቀን ወይም ሌላ ነገር ብንመጣም - ክፍያው አሁንም ከዚህ ሙሉ የቬክተር መጠን ብዙ እጥፍ ያነሰ ይሆናል. ስለዚህ ልባችንን እና ጥርሳችንን እያፋክን ይህን አካሄድ ትተን ወደ ሌላ ሄድን።

Spanner TrueTime. የአቶሚክ ሰዓት

ስለ ስፓነር ታሪክ ይኖራል አልኩኝ። ይህ ጥሩ ነገር ነው፣ ከXNUMXኛው ክፍለ ዘመን ጀምሮ፡ የአቶሚክ ሰዓቶች፣ የጂፒኤስ ማመሳሰል።

ሃሳቡ ምንድን ነው? "ስፓነር" በቅርብ ጊዜ ለሰዎች እንኳን የተገኘ (SQL ን አክለዋል) የGoogle ስርዓት ነው። እዚያ ያለው እያንዳንዱ ግብይት የተወሰነ የጊዜ ማህተም አለው። ጊዜ የተመሳሰለ ስለሆነ * እያንዳንዱ ክስተት የተወሰነ ጊዜ ሊመደብ ይችላል - አቶሚክ ሰዓቶች የጥበቃ ጊዜ አላቸው, ከዚያ በኋላ የተለየ ጊዜ "ለመከሰት" ዋስትና ተሰጥቶታል.

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

ስለዚህ, በቀላሉ ወደ ዳታቤዝ በመጻፍ እና ለተወሰነ ጊዜ በመጠባበቅ, የዝግጅቱ ተከታታይነት በራስ-ሰር ይረጋገጣል. በመርህ ደረጃ ሊታሰብ የሚችል በጣም ጠንካራው የወጥነት ሞዴል አላቸው - ውጫዊ ወጥነት ነው።

* ይህ የ Lampart ሰዓቶች ዋነኛ ችግር ነው - በተከፋፈሉ ስርዓቶች ላይ ፈጽሞ አይመሳሰሉም. ሊለያዩ ይችላሉ፤ በኤንቲፒ እንኳን ቢሆን፣ አሁንም በደንብ አይሰሩም። "ስፓነር" የአቶሚክ ሰዓት አለው እና ማመሳሰል ማይክሮ ሰከንድ ይመስላል።

ለምን አልመረጥንም? ተጠቃሚዎቻችን አብሮ የተሰራ የአቶሚክ ሰዓት አላቸው ብለን አናስብም። ሲታዩ በእያንዳንዱ ላፕቶፕ ውስጥ ተገንብተው አንድ ዓይነት እጅግ በጣም ጥሩ የጂፒኤስ ማመሳሰል ይኖራል - ከዚያ አዎ ... አሁን ግን ምርጡ የሆነው Amazon, Base Stations - ለአክራሪዎች ... ስለዚህ ሌሎች ሰዓቶችን እንጠቀማለን. .

ድብልቅ ሰዓት

የምክንያት ወጥነትን በሚያረጋግጥበት ጊዜ በMongoDB ውስጥ የሚጠቁመው ይህ ነው። እንዴት ነው ድቅል የሆኑት? ዲቃላ scalar እሴት ነው፣ ግን ሁለት አካላት አሉት።

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

  • የመጀመሪያው የዩኒክስ ዘመን ("የኮምፒዩተር አለም መጀመሪያ" ከጀመረበት ጊዜ ጀምሮ ስንት ሴኮንዶች አልፈዋል)።
  • ሁለተኛው የተወሰነ ጭማሪ ነው፣ እንዲሁም ባለ 32-ቢት ያልተፈረመ ኢንት።

ያ ብቻ ነው፣ በእውነቱ። ይህ አቀራረብ አለ: ለጊዜ ተጠያቂው ክፍል ሁል ጊዜ ከሰዓት ጋር ይመሳሰላል; ዝመና በተፈጠረ ቁጥር ይህ ክፍል ከሰዓቱ ጋር ይመሳሰላል እና ጊዜው ሁል ጊዜ የበለጠ ወይም ያነሰ ትክክል ነው ፣ እና ጭማሪው በተመሳሳይ ጊዜ የተከሰቱትን ክስተቶች ለመለየት ያስችልዎታል።

ለምንድነው ይህ ለMongoDB አስፈላጊ የሆነው? ምክንያቱም በተወሰነ ጊዜ ውስጥ አንዳንድ ዓይነት የመጠባበቂያ ምግብ ቤቶችን እንዲሰሩ ይፈቅድልዎታል, ማለትም, ክስተቱ በጊዜ ጠቋሚ ነው. አንዳንድ ክስተቶች አስፈላጊ ሲሆኑ ይህ አስፈላጊ ነው; ለዳታቤዝ፣ ሁነቶች በመረጃ ቋቱ ውስጥ በተወሰነ የጊዜ ልዩነት ውስጥ የተከሰቱ ለውጦች ናቸው።

በጣም አስፈላጊ የሆነውን ምክንያት ለእርስዎ ብቻ እነግራችኋለሁ (እባክዎ, ለማንም አይናገሩ)! ይህንን ያደረግነው በMongoDB OpLog ውስጥ የተደራጀ፣ የተጠቆመው መረጃ ይህ ስለሚመስል ነው። OpLog በመረጃ ቋቱ ውስጥ ሙሉ ለሙሉ ለውጦችን የሚያካትት የውሂብ መዋቅር ነው፡ በመጀመሪያ ወደ ኦፕሎግ ይሄዳሉ፣ ከዚያም በተደጋገመበት ቀን ወይም ሸርተቴ በሚሆንበት ጊዜ ማከማቻው ላይ እራሱ ይተገበራል።

ዋናው ምክንያት ይህ ነበር። አሁንም ቢሆን የውሂብ ጎታ ለማዘጋጀት ተግባራዊ መስፈርቶችም አሉ, ይህም ማለት ቀላል መሆን አለበት - ትንሽ ኮድ, በተቻለ መጠን ጥቂት የተበላሹ ነገሮች እንደገና መፃፍ እና መሞከር አለባቸው. የእኛ ኦፕሎጎች በድብልቅ ሰዓቶች መጠቆማቸው ብዙ ረድቶናል እናም ትክክለኛውን ምርጫ እንድናደርግ አስችሎናል። እሱ በትክክል ተከፍሏል እና በሆነ መንገድ በመጀመሪያው ፕሮቶታይፕ ላይ በአስማት ሰራ። በጣም አሪፍ ነበር!

የሰዓት ማመሳሰል

በሳይንሳዊ ጽሑፎች ውስጥ የተገለጹ በርካታ የማመሳሰል ዘዴዎች አሉ. እኔ ስለ ማመሳሰል እያወራሁ ያለሁት ሁለት የተለያዩ ሻርዶች ሲኖረን ነው። አንድ የተባዛ ስብስብ ካለ, ምንም አይነት ማመሳሰል አያስፈልግም: ይህ "ነጠላ ጌታ" ነው; ሁሉም ለውጦች የሚወድቁበት OpLog አለን። ነገር ግን ሁለት የተለያዩ ሻርዶች ካሉን, የጊዜ ማመሳሰል እዚህ አስፈላጊ ነው. የቬክተር ሰዓቱ የበለጠ የረዳው እዚህ ነው! እኛ ግን የለንም።

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

ሁለተኛው ተስማሚ ነው - ይህ "የልብ ምት" ነው. በእያንዳንዱ የጊዜ አሃድ የሚከሰቱ አንዳንድ ምልክቶችን መለዋወጥ ይቻላል. ነገር ግን የልብ ምቶች በጣም ቀርፋፋ ናቸው፣ ለደንበኛችን መዘግየት አንችልም።

እውነተኛ ጊዜ በእርግጥ አስደናቂ ነገር ነው። ግን ፣ እንደገና ፣ ይህ ምናልባት የወደፊቱ ነው… ምንም እንኳን ቀድሞውኑ በአትላስ ውስጥ ሊከናወን ይችላል ፣ ቀድሞውኑ ፈጣን “አማዞን” ጊዜ ማመሳሰል አለ። ግን ለሁሉም ሰው አይገኝም።

ወሬ ማማት ሁሉም መልእክቶች ጊዜን ሲጨምሩ ነው። ይህ የምንጠቀመው በግምት ነው። በኖዶች፣ በሾፌር፣ በዳታ መስቀለኛ መንገድ ራውተር መካከል ያለው እያንዳንዱ መልእክት፣ ለMongoDB ሁሉም ነገር አንድ ዓይነት ኤለመንት ነው፣ የሚሰራ ሰዓትን የያዘ የውሂብ ጎታ አካል ነው። በየቦታው የተዳቀለ ጊዜ ትርጉም አላቸው, ይተላለፋል. 64 ቢትስ? ይህ ይፈቅዳል, ይህ ይቻላል.

እንዴት ነው ሁሉም በአንድነት የሚሰራው?

እዚህ ትንሽ ቀላል ለማድረግ አንድ የተባዛ ስብስብ እየተመለከትኩ ነው። የመጀመሪያ ደረጃ እና ሁለተኛ ደረጃ አሉ. ሁለተኛ ደረጃ ማባዛትን ይሠራል እና ሁልጊዜ ከዋና ጋር ሙሉ በሙሉ አይመሳሰልም።

ከተወሰነ የጊዜ እሴት ጋር ወደ "ዋና" ማስገባት ይከሰታል። ይህ ማስገባቱ ከፍተኛው ከሆነ የውስጥ ቆጠራውን በ11 ይጨምራል። ወይም የሰዓት እሴቶቹን ይፈትሻል እና የሰዓት እሴቶቹ የበለጠ ከሆኑ ከሰዓቱ ጋር ይመሳሰላል። ይህ በጊዜ እንዲደራጁ ያስችልዎታል.

ቀረጻውን ካደረገ በኋላ አንድ አስፈላጊ ጊዜ ይከሰታል. ሰዓቱ በ "MongoDB" ውስጥ ነው እና ወደ "Oplog" ለመጻፍ ብቻ ይጨምራል. ይህ የስርዓቱን ሁኔታ የሚቀይር ክስተት ነው. በፍፁም በሁሉም አንጋፋ መጣጥፎች ውስጥ አንድ ክስተት መልእክት መስቀለኛ መንገድ ላይ ሲመታ ተደርጎ ይቆጠራል፡ መልዕክቱ ደርሷል፣ ይህ ማለት ስርዓቱ ሁኔታውን ቀይሯል ማለት ነው።

ይህ የሆነበት ምክንያት በጥናት ወቅት ይህ መልእክት እንዴት እንደሚተረጎም ሙሉ በሙሉ ግልፅ ስላልሆነ ነው። በ "ኦፕሎግ" ውስጥ ካልተንጸባረቀ, በምንም መልኩ ሊተረጎም እንደማይችል በእርግጠኝነት እናውቃለን, እና የስርዓቱ ሁኔታ ለውጥ በ "ኦፕሎግ" ውስጥ መግባት ብቻ ነው. ይህ ሁሉንም ነገር ያቀልልናል: አምሳያው ቀለል ያደርገዋል, እና በአንድ ቅጂ ስብስብ ውስጥ እና ሌሎች ብዙ ጠቃሚ ነገሮችን ለማደራጀት ያስችለናል.

ቀደም ሲል ወደ “ኦፕሎግ” የተጻፈው እሴት ተመልሷል - “ኦፕሎግ” ቀድሞውኑ ይህንን እሴት እንደያዘ እናውቃለን ፣ እና ጊዜው 12 ነው። አሁን ፣ እንበል ፣ ንባብ ከሌላ መስቀለኛ መንገድ (ሁለተኛ ደረጃ) ይጀምራል እና ከClusterTime በኋላ ያስተላልፋል መልዕክቱ. እሱ እንዲህ ይላል: "ቢያንስ ከ 12 በኋላ ወይም በአስራ ሁለት ጊዜ የተከሰተውን ሁሉ እፈልጋለሁ" (ከላይ ያለውን ምስል ይመልከቱ).

ይህ Causal a consistent (CAT) የሚባለው ነው። በንድፈ ሀሳብ ውስጥ ይህ የተወሰነ የጊዜ ቁራጭ ነው ፣ እሱም በራሱ ወጥነት ያለው ጽንሰ-ሀሳብ አለ። በዚህ ጉዳይ ላይ በጊዜ 12 የታየው የስርዓቱ ሁኔታ ይህ ነው ማለት እንችላለን።

አሁን እዚህ ምንም ነገር የለም, ምክንያቱም ይህ አይነት ከዋናው ላይ ያለውን ውሂብ ለመድገም ሁለተኛ ደረጃን በሚያስፈልግበት ጊዜ ሁኔታውን ያስመስላል. እሱ ይጠብቃል ... እና አሁን ውሂቡ ደርሷል - እነዚህን እሴቶች መልሶ ይመልሳል።

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

ይህ ሁሉ እንዴት እንደሚሰራ ቆንጆ ነው. ማለት ይቻላል።

"በቅርቡ" ማለት ምን ማለት ነው? ይህ ሁሉ እንዴት እንደሚሰራ አንብቦ የተረዳ ሰው እንዳለ እናስብ። ክላስተርታይም በተከሰተ ቁጥር የውስጥ ሎጂክ ሰዓቱን እንደሚያዘምን ተገነዘብኩ እና የሚቀጥለው ግቤት በአንድ ይጨምራል። ይህ ተግባር 20 መስመሮችን ይወስዳል. ይህ ሰው ትልቁን ባለ 64-ቢት ቁጥር ያስተላልፋል እንበል፣ አንድ ሲቀነስ።

ለምን "አንድ ሲቀነስ"? ምክንያቱም የውስጥ ሰዓቱ በዚህ እሴት ውስጥ ስለሚተካ (በእርግጥ ይህ ሊሆን የሚችለው ትልቁ እና አሁን ካለው ጊዜ የበለጠ ነው) ፣ ከዚያ በ “ኦፕሎግ” ውስጥ ግቤት ይከሰታል ፣ እና ሰዓቱ በሌላ ክፍል ይጨምራል - እና ቀድሞውኑም ይኖራል። ከፍተኛ እሴት ይሁኑ (በቀላሉ ሁሉም ክፍሎች አሉ ፣ ሌላ የሚሄዱበት ቦታ የለም) ፣ ያልተቀደሱ ኢንቶች)።

ከዚህ በኋላ ስርዓቱ ለማንኛውም ነገር ፈጽሞ የማይደረስበት እንደሚሆን ግልጽ ነው. ሊወርድ እና ሊጸዳ የሚችለው ብቻ ነው - ብዙ የእጅ ሥራ. ሙሉ ተገኝነት፡-

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

በተጨማሪም ፣ ይህ በሌላ ቦታ ከተደገመ ፣ ከዚያ ሙሉው ስብስብ በቀላሉ ይወድቃል። ማንም ሰው በፍጥነት እና በቀላሉ ሊያደራጅ የሚችል ፍጹም ተቀባይነት የሌለው ሁኔታ! ስለዚህ, ይህን ጊዜ በጣም አስፈላጊ ከሆኑት እንደ አንዱ አድርገን ነበር. እንዴት መከላከል ይቻላል?

የእኛ መንገድ ክላስተርታይምን መፈረም ነው።

በመልእክቱ ውስጥ የሚተላለፈው በዚህ መንገድ ነው (ከሰማያዊው ጽሑፍ በፊት)። ነገር ግን ፊርማ ማመንጨት ጀመርን (ሰማያዊ ጽሑፍ)፡-

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

ፊርማው የሚመነጨው በመረጃ ቋቱ ውስጥ በተከማቸ ቁልፍ፣ ደህንነቱ በተጠበቀ ፔሪሜትር ውስጥ ነው፣ ራሱ የመነጨ እና የዘመነ ነው (ተጠቃሚዎች ስለሱ ምንም ነገር አያዩም)። ሃሽ ይፈጠራል፣ እና እያንዳንዱ መልዕክት ሲፈጠር ይፈርማል እና ሲደርሰው ይረጋገጣል።
ምናልባት በሰዎች አእምሮ ውስጥ የሚነሳው ጥያቄ "ይህ ምን ያህል ነገሮችን ይቀንሳል?" በተለይ ይህ ባህሪ በማይኖርበት ጊዜ በፍጥነት መስራት እንዳለበት ነግሬዎታለሁ.

በዚህ ጉዳይ ላይ የምክንያት ወጥነት መጠቀም ምን ማለት ነው? ይህ ከClusterTime በኋላ ያለውን መለኪያ ለማሳየት ነው። ያለዚህ ፣ በቀላሉ እሴቶችን ያልፋል። ከስሪት 3.6 ጀምሮ ሀሜት ሁሌም ይሰራል።

ፊርማዎችን የማያቋርጥ ትውልድ ትተን ከሄድን, የእኛን አቀራረቦች እና መስፈርቶች የማያሟላ ባህሪ በሌለበት ጊዜ እንኳን ስርዓቱን ይቀንሳል. ታዲያ ምን አደረግን?

በፍጥነት ያድርጉት!

በጣም ቀላል ነገር ነው, ግን ዘዴው አስደሳች ነው - እኔ እካፈላለሁ, ምናልባት አንድ ሰው ፍላጎት ይኖረዋል.
የተፈረመውን ውሂብ የሚያከማች ሃሽ አለን። ሁሉም መረጃዎች በመሸጎጫው ውስጥ ያልፋሉ. መሸጎጫው የተወሰነውን ጊዜ አይፈርምም, ግን ክልል. የተወሰነ እሴት ሲመጣ ክልልን እናመነጫለን፣የመጨረሻዎቹን 16 ቢት እናስወግዳለን እና ይህን እሴት እንፈርማለን።

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

እንደዚህ አይነት ፊርማ በመቀበል ስርዓቱን (በአንፃራዊነት) 65 ሺህ ጊዜ እናፋጥናለን. በጣም ጥሩ ይሰራል፡ ሙከራዎችን በምናደርግበት ጊዜ፣ ተከታታይ ማሻሻያ ባደረግንበት ጊዜ በእውነቱ በ10 ሺህ ጊዜ ቀንሷል። እርስ በርስ በሚጋጩበት ጊዜ ይህ እንደማይሠራ ግልጽ ነው. ግን በአብዛኛዎቹ ተግባራዊ ጉዳዮች ላይ ይሰራል. የሬንጅ ፊርማ ከፊርማው ጋር ጥምረት የደህንነት ችግሩን ፈትቷል.

ምን ተማርን?

ከዚህ የተማርናቸው ትምህርቶች፡-

  • ብዙ አስደሳች ነገሮች ስላሉን ቁሳቁሶችን, ታሪኮችን, ጽሑፎችን ማንበብ አለብን. አንዳንድ ባህሪ ላይ ስንሰራ (በተለይ አሁን፣ ግብይቶችን ስንሰራ፣ ወዘተ.) ማንበብ እና መረዳት አለብን። ጊዜ ይወስዳል ነገር ግን የት እንዳለን ግልጽ ስለሚያደርግ በእውነቱ በጣም ጠቃሚ ነው. ምንም አዲስ ነገር ያመጣን አይመስልም - እቃዎቹን ብቻ ወስደናል.

    በአጠቃላይ, የአካዳሚክ ኮንፈረንስ ሲኖር በአስተሳሰብ ውስጥ የተወሰነ ልዩነት አለ (ሲግሞን, ለምሳሌ) - ሁሉም ሰው በአዲስ ሀሳቦች ላይ ያተኩራል. ስለ አልጎሪዝም ምን አዲስ ነገር አለ? እዚህ ምንም የተለየ አዲስ ነገር የለም. አዲሱ ነገር አሁን ያሉትን አቀራረቦች በአንድ ላይ በማዋሃድ ላይ ነው። ስለዚህ, የመጀመሪያው ነገር ከላምፓርት ጀምሮ አንጋፋዎቹን ማንበብ ነው.

  • በምርት ውስጥ, መስፈርቶቹ ሙሉ ለሙሉ የተለያዩ ናቸው. እርግጠኛ ነኝ ብዙዎቻችሁ በአብስትራክት ቫክዩም ውስጥ “ሉላዊ” የመረጃ ቋቶች እንዳትጋጠሟችሁ፣ ነገር ግን ከመደበኛ እና ከእውነተኛ ነገሮች ጋር በተገኝነት፣ በመዘግየት እና በስህተት መቻቻል ላይ ችግር ያለባቸው ነገሮች እንዳሉ እርግጠኛ ነኝ።
  • የመጨረሻው ነገር የተለያዩ ሀሳቦችን መመልከት እና በርካታ ሙሉ ለሙሉ የተለያዩ መጣጥፎችን ወደ አንድ አቀራረብ በአንድ ላይ ማጣመር ነበረብን። የመፈረም ሀሳቡ ለምሳሌ የፓክሶስ ፕሮቶኮልን ከሚመለከተው አንቀጽ የመጣ ሲሆን ይህም የባይዛንታይን ላልሆኑ ውድቀቶች በፈቃድ ፕሮቶኮል ውስጥ ነው ፣ ለባይዛንታይን - ከፍቃድ ፕሮቶኮል ውጭ ... በአጠቃላይ ፣ እኛ በትክክል የምንመለከተው ነው። በማድረግ አበቃ።

    እዚህ ምንም አዲስ ነገር የለም! ግን ሁሉንም አንድ ላይ እንደቀላቀልን ... ልክ እንደ ኦሊቪየር ሰላጣ የምግብ አዘገጃጀት ዘዴ ትርጉም የለሽ ነው ከማለት ጋር ተመሳሳይ ነው, ምክንያቱም እንቁላል, ማዮኔዝ እና ዱባዎች ቀድሞውኑ ተፈለሰፉ ... ስለ ተመሳሳይ ታሪክ ነው.

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

በዚህ እጨርሳለሁ። አመሰግናለሁ!

ጥያቄዎች

ከአድማጮች የቀረበ ጥያቄ (ከዚህ በኋላ ለ)፡- - ሚካሂል ለሪፖርቱ አመሰግናለሁ! ስለ ጊዜ የሚናገረው ርዕስ አስደሳች ነው። ወሬን እየተጠቀምክ ነው። ሁሉም ሰው የራሱ ጊዜ አለው, ሁሉም የአካባቢያቸውን ጊዜ ያውቃል. እኔ እንደተረዳሁት፣ ሹፌር አለን - ከአሽከርካሪዎች ጋር ብዙ ደንበኞች ሊኖሩ ይችላሉ፣ መጠይቅ-እቅድ አውጪዎችም እንዲሁ፣ ፍርስራሾችም... እና በድንገት ልዩነት ካጋጠመን ስርዓቱ ምን ላይ ይወርዳል፡ አንድ ሰው ለ ደቂቃ ወደፊት፣ አንድ ሰው በደቂቃ በኋላ? የት እንጨርሰዋለን?

ኤምቲ፡ - በጣም ጥሩ ጥያቄ! ስለ ሻርዶች ማውራት ፈልጌ ነበር። ጥያቄውን በትክክል ከተረዳሁት, የሚከተለው ሁኔታ አለን: ሻርድ 1 እና ሸርተቴ 2 አለ, ከእነዚህ ሁለት ንጣፎች ውስጥ ማንበብ ይከሰታል - ልዩነት አላቸው, እርስ በእርሳቸው አይገናኙም, ምክንያቱም የሚያውቁት ጊዜ የተለየ ነው. በተለይም በኦፕሎጎች ውስጥ የሚኖሩበት ጊዜ.
እንበልና ሻርድ 1 አንድ ሚሊዮን መዝገቦችን ሠራ, ሻርድ 2 ምንም ነገር አላደረገም, እና ጥያቄው ወደ ሁለት ቁርጥራጮች መጣ. እና የመጀመሪያው ከክላስተር ጊዜ ከአንድ ሚሊዮን በላይ አለው። በእንደዚህ ዓይነት ሁኔታ, እንደገለጽኩት, shard 2 በጭራሽ ምላሽ አይሰጥም.

AT: - እንዴት እንደሚመሳሰሉ ማወቅ እና አንድ ምክንያታዊ ጊዜ መምረጥ ፈልጌ ነበር?

ኤምቲ፡ - ለማመሳሰል በጣም ቀላል። ሻርድ ከClusterTime በኋላ ወደ እሱ ሲመጣ እና በ"ኦፕሎግ" ውስጥ ጊዜ ሳያገኝ ሲቀር ምንም ተቀባይነት አላገኝም። ያም ማለት ጊዜውን በእጆቹ ወደዚህ እሴት ያነሳል. ይህ ማለት ከዚህ ጥያቄ ጋር የሚዛመዱ ክስተቶች የሉትም። እሱ ይህንን ክስተት ሰው ሰራሽ በሆነ መንገድ ፈጠረ እና በዚህም ምክንያት የምክንያት ወጥነት ያለው ይሆናል።

AT: - ከዚህ በኋላ በኔትወርኩ ውስጥ የሆነ ቦታ የጠፉ ሌሎች ክስተቶች ወደ እሱ ቢመጡስ?

ኤምቲ፡ - ሻርድ አንድ ነጠላ ጌታ ስለሆነ እንደገና እንዳይመጡ በሚያስችል መንገድ ተዘጋጅቷል. እሱ አስቀድሞ ተመዝግቧል ከሆነ, ከዚያም አይመጡም, ነገር ግን በኋላ ይመጣሉ. የሆነ ነገር አንድ ቦታ ላይ ተጣብቆ ፣ ከዚያ እሱ አይፃፍም ፣ እና እነዚህ ክስተቶች ይደርሳሉ - እና የምክንያቱ ወጥነት ተሰብሯል። እሱ ሳይጽፍ ሲቀር, ሁሉም ቀጥለው መምጣት አለባቸው (ይጠብቃቸዋል).

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

AT: - ሰልፍን በተመለከተ ብዙ ጥያቄዎች አሉኝ. የምክንያት ወጥነት መከናወን ያለበት የተወሰነ የድርጊት ወረፋ እንዳለ ያስባል። ከፓኬጆቻችን አንዱ ቢጠፋ ምን ይሆናል? እነሆ 10ኛው፣ 11ኛው... 12ኛው ጠፋ፣ እና ሁሉም ሰው እውነት እንዲሆን እየጠበቀ ነው። እና በድንገት መኪናችን ሞተ, ምንም ነገር ማድረግ አንችልም. ከመተግበሩ በፊት የሚከማቸው ከፍተኛው የወረፋ ርዝመት አለ? የትኛውም ግዛት ሲጠፋ ምን ገዳይ ውድቀት ይከሰታል? ከዚህም በላይ አንዳንድ የቀድሞ ግዛት እንዳለ ከጻፍን, ከዚያም በሆነ መንገድ ከእሱ መጀመር አለብን? ግን አልገፋፉትም!

ኤምቲ፡ - እንዲሁም በጣም ጥሩ ጥያቄ! ምን እየሰራን ነው? MongoDB የምልአተ ጉባኤ ፅንሰ ሀሳብ አለው፣ ምልአተ ጉባኤ ያነባል። መልእክት በየትኛው ሁኔታዎች ሊጠፋ ይችላል? መፃፍ ምልአተ ጉባኤ ካልሆነ ወይም የተነበበ ምልአተ ጉባኤ ካልሆነ (አንዳንድ አይነት ቆሻሻዎችም ሊጣበቁ ይችላሉ።
የምክንያት ወጥነትን በተመለከተ ትልቅ የሙከራ ፈተና ተካሂዷል፣ ውጤቱም ሲፃፍ እና ሲነበብ ምልአተ ጉባኤ ካልሆኑ የምክንያት ወጥነት ጥሰቶች ይከሰታሉ። በትክክል የምትናገረው!

የኛ ምክር፡ የምክንያት ወጥነት ሲጠቀሙ ቢያንስ ኮረም ንባብ ይጠቀሙ። በዚህ ጉዳይ ላይ ምንም ነገር አይጠፋም, ምንም እንኳን የምልአተ ጉባኤው መዝገብ ቢጠፋም ... ይህ የኦርቶዶክስ ሁኔታ ነው: ተጠቃሚው ውሂብ እንዲጠፋ ካልፈለገ, ምልአተ ጉባኤን መጠቀም ያስፈልገዋል. የምክንያት ወጥነት ዘላቂነት ዋስትና አይሰጥም. ዘላቂነት የሚረጋገጠው በማባዛት እና ከማባዛት ጋር በተያያዙ ማሽኖች ነው።

AT: - ለእኛ ሻርዲንግ የሚያከናውን ምሳሌ ስንፈጥር (ጌታ ሳይሆን ባርያ በቅደም ተከተል) በራሱ ማሽን በዩኒክስ ጊዜ ወይም በ "ጌታው" ጊዜ ላይ ይመሰረታል; ለመጀመሪያ ጊዜ ወይም በየጊዜው ይመሳሰላል?

ኤምቲ፡ - አሁን ግልጽ አደርጋለሁ. ሻርድ (ማለትም አግድም ክፍልፍል) - ሁል ጊዜ አንደኛ ደረጃ እዚያ አለ። እና ሻርዶ "ማስተር" ሊኖረው ይችላል እና ቅጂዎች ሊኖሩ ይችላሉ. ነገር ግን ሻርዱ ሁልጊዜ መቅዳትን ይደግፋል, ምክንያቱም አንዳንድ ጎራዎችን መደገፍ አለበት (ሻርዱ የመጀመሪያ ደረጃ አለው).

AT: - ስለዚህ ሁሉም ነገር በ "ጌታው" ላይ ብቻ የተመካ ነው? ማስተር ጊዜ ሁል ጊዜ ጥቅም ላይ ይውላል?

ኤምቲ፡ - አዎ. በምሳሌያዊ ሁኔታ እንዲህ ማለት ይችላሉ-ወደ "ማስተር" ውስጥ, ወደ "ኦፕሎግ" ውስጥ ሲገባ ሰዓቱ እየጠበበ ነው.

AT: - የሚያገናኘው ደንበኛ አለን እና ስለ ጊዜው ምንም ነገር ማወቅ አያስፈልገውም?

ኤምቲ፡ - ምንም ነገር ማወቅ አያስፈልግዎትም! በደንበኛው ላይ እንዴት እንደሚሰራ ከተነጋገርን: ደንበኛው የምክንያት ወጥነት መጠቀም ሲፈልግ, ክፍለ ጊዜ መክፈት ያስፈልገዋል. አሁን ሁሉም ነገር አለ: በክፍለ-ጊዜው ውስጥ ግብይቶች, እና መብቶችን ሰርስረው ያግኙ ... አንድ ክፍለ ጊዜ ከደንበኛው ጋር የሚከሰቱ ምክንያታዊ ክስተቶችን ማዘዝ ነው.

ይህንን ክፍለ ጊዜ ከከፈተ እና እዚያ የምክንያት ወጥነት እንደሚፈልግ ከተናገረ (ክፍለ ጊዜው በነባሪነት የምክንያት ወጥነትን የሚደግፍ ከሆነ) ሁሉም ነገር በራስ-ሰር ይሰራል። አሽከርካሪው ይህንን ጊዜ ያስታውሳል እና አዲስ መልእክት ሲደርሰው ይጨምራል. ውሂቡን ከመለሰው አገልጋይ ቀዳሚው ምን ምላሽ እንደተመለሰ ያስታውሳል። የሚቀጥለው ጥያቄ ከክላስተር በኋላ ("ከዚህ የሚበልጥ ጊዜ") ይይዛል።

ደንበኛው ምንም ነገር በትክክል ማወቅ አያስፈልገውም! ይህ ለእሱ ሙሉ በሙሉ ግልጽ ያልሆነ ነው. ሰዎች እነዚህን ባህሪያት የሚጠቀሙ ከሆነ ምን ማድረግ ይችላሉ? አንደኛ፣ ሁለተኛ ደረጃን በደህና ማንበብ ትችላለህ፡ ወደ አንደኛ ደረጃ መጻፍ እና ከጂኦግራፊያዊ የተደጋገሙ ሁለተኛ ደረጃዎች ማንበብ እና እንደሚሰራ እርግጠኛ ሁን። በተመሳሳይ ጊዜ በመጀመሪያ ደረጃ የተመዘገቡ ክፍለ-ጊዜዎች ወደ ሁለተኛ ደረጃ ሊተላለፉ ይችላሉ, ማለትም አንድ ክፍለ ጊዜ ሳይሆን ብዙ መጠቀም ይችላሉ.

AT: - አዲስ የኮምፒዩት ሳይንስ ንብርብር - CRDT (ከግጭት-ነጻ የተባዙ የውሂብ አይነቶች) የውሂብ አይነቶች - ከመጨረሻው ወጥነት ርዕስ ጋር በጥብቅ የተያያዘ ነው። እነዚህን አይነት መረጃዎች በመረጃ ቋቱ ውስጥ ለማዋሃድ አስበዋል እና ስለሱ ምን ማለት ይችላሉ?

ኤምቲ፡ - ጥሩ ጥያቄ! CRDT ግጭቶችን ለመፃፍ ትርጉም ይሰጣል፡ በሞንጎዲቢ፣ ነጠላ ማስተር።

AT: - ከዶፕስ አንድ ጥያቄ አለኝ. በገሃዱ ዓለም የባይዛንታይን ውድቀት ሲከሰት እና በተጠበቀው ፔሪሜትር ውስጥ ያሉ ክፉ ሰዎች ወደ ፕሮቶኮሉ መግባት ሲጀምሩ እንደዚህ አይነት የጄሱሳዊ ሁኔታዎች አሉ ልዩ በሆነ መንገድ የእጅ ሥራ ፓኬጆችን ይልካሉ?

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

ኤምቲ፡ - በፔሪሜትር ውስጥ ያሉ ክፉ ሰዎች እንደ ትሮጃን ፈረስ ናቸው! በፔሪሜትር ውስጥ ያሉ ክፉ ሰዎች ብዙ መጥፎ ነገሮችን ሊያደርጉ ይችላሉ።

AT: – በግምት በአገልጋዩ ውስጥ የዝሆኖችን መካነ አራዊት የምታስቀምጥበት እና ክላስተርን ለዘለአለም የምትፈርስበት ቀዳዳ መውጣቱ ግልፅ ነው... በእጅ ለማገገም ጊዜ ይወስዳል። ስህተት። በሌላ በኩል, ይህ አስደሳች ነው: በእውነተኛ ህይወት, በተግባር, በተፈጥሮ ተመሳሳይ ውስጣዊ ጥቃቶች ሲከሰቱ ሁኔታዎች አሉ?

ኤምቲ፡ - በእውነተኛ ህይወት ውስጥ የደህንነት ጥሰቶች እምብዛም ስለማይገጥሙኝ, እነሱ እንደሚከሰቱ መናገር አልችልም. ስለ ልማት ፍልስፍና ከተነጋገርን ግን እንደዚህ እናስባለን-ደህንነት የሚሠሩትን ወንዶች የሚያቀርብ ፔሪሜትር አለን - ይህ ግንብ ፣ ግድግዳ ነው ። እና በፔሚሜትር ውስጥ የፈለጉትን ማድረግ ይችላሉ. የማየት ችሎታ ያላቸው ተጠቃሚዎች እንዳሉ ግልጽ ነው, እና ማውጫውን ለማጥፋት ችሎታ ያላቸው ተጠቃሚዎች አሉ.

በመብቶቹ ላይ በመመስረት ተጠቃሚዎች የሚያደርሱት ጉዳት አይጥ ሊሆን ይችላል ወይም ዝሆን ሊሆን ይችላል. ሙሉ መብት ያለው ተጠቃሚ ማንኛውንም ነገር ማድረግ እንደሚችል ግልጽ ነው። የተወሰነ መብት ያለው ተጠቃሚ ያነሰ ጉዳት ሊያደርስ ይችላል። በተለይም ስርዓቱን ማፍረስ አይችልም.

AT: - በተጠበቀው ፔሪሜትር ውስጥ, አንድ ሰው አገልጋዩን ሙሉ በሙሉ ለማጥፋት ለአገልጋዩ ያልተጠበቁ ፕሮቶኮሎችን ለመፍጠር ሞክሯል, እና እድለኛ ከሆንክ, አጠቃላይ ክላስተር ... ያን "ጥሩ" አግኝቷል?

ኤምቲ፡ "ስለዚህ አይነት ነገር ሰምቼ አላውቅም" በዚህ መንገድ አገልጋይን ማጨናገፍ መቻልዎ ሚስጥር አይደለም። በውስጥ አለመሳካት፣ ከፕሮቶኮሉ መሆን፣ በመልእክቱ ውስጥ እንደዚህ ያለ ነገር መፃፍ የሚችል ስልጣን ያለው ተጠቃሚ መሆን... እንደውም የማይቻል ነው፣ ምክንያቱም አሁንም ይረጋገጣል። ይህንን ማረጋገጫ ለማይፈልጉ ተጠቃሚዎች ማሰናከል ይቻላል - ያ ችግራቸው ነው; እነሱ በግምት አነጋገር ግድግዳውን እራሳቸው አወደሙ እና ዝሆንን እዚያ ውስጥ መግፋት ይችላሉ ፣ እሱም ይረግጣል ... በአጠቃላይ ግን እንደ ጥገና ባለሙያ መልበስ ፣ መጥተው ያውጡት!

AT: – ለሪፖርቱ እናመሰግናለን። ሰርጌይ (Yandex). በሞንግ ውስጥ በሪፕሊፕ ስብስብ ውስጥ የድምጽ ሰጪ አባላትን ቁጥር የሚገድብ ቋሚ አለ፣ እና ይህ ቋሚ 7 (ሰባት) ነው። ይህ ለምን ቋሚ ነው? ለምንድነው ይህ አንድ ዓይነት መለኪያ ያልሆነው?

ኤምቲ፡ - 40 አንጓዎች ያሉት ቅጂዎች አለን። ሁሌም አብላጫ አለ። የትኛውን ስሪት አላውቅም...

AT: - በ Replica Set ውስጥ ድምጽ የማይሰጡ አባላትን ማሄድ ይችላሉ ነገር ግን ቢበዛ 7 ድምጽ ሰጪ አባላት አሉ ።የእኛ ቅጂ ስብስብ በ 3 የመረጃ ቋቶች ላይ ከተሰራጨ በዚህ ጉዳይ ላይ ከመዘጋቱ እንዴት ልንተርፍ እንችላለን? አንድ የመረጃ ማዕከል በቀላሉ ሊጠፋ ይችላል, እና ሌላ ማሽን ሊወድቅ ይችላል.

ኤምቲ፡ - ይህ ከሪፖርቱ ወሰን ትንሽ ያለፈ ነው። ይህ አጠቃላይ ጥያቄ ነው። ምናልባት በኋላ ስለ ጉዳዩ ልነግርዎ እችላለሁ.

HighLoad++፣ Mikhail Tyulenev (MongoDB)፡ የምክንያት ወጥነት፡ ከንድፈ ሃሳብ ወደ ልምምድ

አንዳንድ ማስታወቂያዎች 🙂

ከእኛ ጋር ስለቆዩ እናመሰግናለን። ጽሑፎቻችንን ይወዳሉ? የበለጠ አስደሳች ይዘት ማየት ይፈልጋሉ? ትእዛዝ በማዘዝ ወይም ለጓደኞች በመምከር ይደግፉን፣ ደመና ቪፒኤስ ለገንቢዎች ከ$4.99, በእኛ ለእርስዎ የተፈለሰፈው ልዩ የመግቢያ ደረጃ አገልጋዮች አናሎግ፡- ስለ VPS (KVM) ሙሉ እውነት E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ከ$19 ወይንስ እንዴት አገልጋይ መጋራት ይቻላል? (በRAID1 እና RAID10፣ እስከ 24 ኮሮች እና እስከ 40GB DDR4 ድረስ ይገኛል።

በአምስተርዳም ውስጥ በ Equinix Tier IV የመረጃ ማዕከል ውስጥ Dell R730xd 2x ርካሽ? እዚህ ብቻ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ከ$199 በኔዘርላንድስ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ከ$99! ስለ አንብብ የመሠረተ ልማት ኮርፖሬሽን እንዴት እንደሚገነባ ክፍል ጋር Dell R730xd E5-2650 v4 አገልጋዮች ዋጋ 9000 አንድ ሳንቲም ዩሮ?

ምንጭ: hab.com

አስተያየት ያክሉ