DBA ቦት ጆ. አናቶሊ ስታንስለር (Postgres.ai)

የ SQL መጠይቅ በ"ምርት" ላይ በጥሩ ሁኔታ እንደሚሰራ የደጋፊ ገንቢ እንዴት ይረዳል? በትልቅ ወይም በፍጥነት በማደግ ላይ ባሉ ኩባንያዎች ውስጥ ሁሉም ሰው "ምርቱን" ማግኘት አይችልም. እና በመዳረስ ፣ ሁሉም ጥያቄዎች ያለ ህመም ሊመረመሩ አይችሉም ፣ እና የውሂብ ጎታ ቅጂ መፍጠር ብዙ ጊዜ ሰዓታት ይወስዳል። እነዚህን ችግሮች ለመፍታት ሰው ሰራሽ DBA - ጆ ፈጠርን. ቀድሞውኑ በበርካታ ኩባንያዎች ውስጥ በተሳካ ሁኔታ ተተግብሯል እና ከደርዘን በላይ ገንቢዎችን ይረዳል.

ቪዲዮ

ሰላም ሁላችሁም! ስሜ አናቶሊ ስታንስለር እባላለሁ። ለአንድ ኩባንያ ነው የምሠራው። postgres.ai. ከፖስትግሬስ ሥራ ጋር የተያያዙ መዘግየቶችን ከገንቢዎች፣ ዲቢኤዎች እና QAዎች በማስወገድ የእድገት ሂደቱን ለማፋጠን ቆርጠን ተነስተናል።

ጥሩ ደንበኞች አሉን እና ዛሬ የሪፖርቱ ክፍል ከእነሱ ጋር ስንሰራ ባገኘናቸው ጉዳዮች ላይ ያተኮረ ይሆናል። በጣም ከባድ ችግሮችን ለመፍታት እንዴት እንደረዳቸው እናገራለሁ.

ውስብስብ ከፍተኛ ጭነት ያላቸው ፍልሰቶችን በማዳበር እና በምናደርግበት ጊዜ እራሳችንን "ይህ ፍልሰት ይነሳ ይሆን?" የሚለውን ጥያቄ እራሳችንን እንጠይቃለን። ግምገማን እንጠቀማለን፣ የበለጠ ልምድ ያላቸውን የስራ ባልደረቦችን፣ የዲቢኤ ባለሙያዎችን እውቀት እንጠቀማለን። እና መብረር ወይም አለመብረር ሊያውቁ ይችላሉ።

ግን ምናልባት እራሳችንን በሙሉ መጠን ቅጂዎች ብንሞክር የተሻለ ሊሆን ይችላል። እና ዛሬ ለሙከራ ምን አይነት አቀራረቦች አሁን እንደሆኑ እና እንዴት በተሻለ ሁኔታ እና በምን መሳሪያዎች እንደሚደረግ ብቻ እንነጋገራለን. እንዲሁም ስለ እንደዚህ አይነት አቀራረቦች ጥቅሞች እና ጉዳቶች እንነጋገራለን, እና እዚህ ምን ማስተካከል እንደምንችል እንነጋገራለን.

በፕሮድ ላይ በቀጥታ ኢንዴክሶችን የሰራው ወይም ምንም ለውጥ ያደረገ ማን ነው? በጣም ትንሽ። እና ይህ መረጃ የጠፋበት ወይም የመዘግየቱ ጊዜ ስለነበረው ለማን አመጣ? ከዚያ ይህን ህመም ያውቃሉ. እግዚአብሔር ይመስገን ምትኬዎች አሉ።

የመጀመሪያው አቀራረብ በፕሮድ ውስጥ መሞከር ነው. ወይም፣ አንድ ገንቢ በአካባቢያዊ ማሽን ላይ ሲቀመጥ፣ የሙከራ ውሂብ አለው፣ የተወሰነ አይነት ምርጫ አለ። እና ወደ ፕሮድ እንጠቀጣለን, እና ይህን ሁኔታ እናገኛለን.

ያማል፣ ውድ ነው። ባይሆን ጥሩ ነው።

እና ምን ለማድረግ የተሻለው መንገድ ነው?

ዝግጅትን እንውሰድ እና የምርቱን የተወሰነ ክፍል እዚያ እንምረጥ። ወይም በምርጥ ሁኔታ፣ ሁሉንም መረጃዎች እውነተኛ ፕሮድ እንውሰድ። እና በአገር ውስጥ ካዳበርን በኋላ፣ ለዝግጅት አቀማመጥ በተጨማሪ እንፈትሻለን።

ይህ አንዳንድ ስህተቶችን እንድናስወግድ ያስችለናል፣ ማለትም በፕሮድ ላይ እንዳይሆኑ እንከለክላለን።

ችግሮቹ ምንድን ናቸው?

• ችግሩ ይህንን ዝግጅት ከባልደረባዎች ጋር መካፈላችን ነው። እና በጣም ብዙ ጊዜ አንድ ዓይነት ለውጥ ሲያደርጉ ይከሰታል, bam - እና ምንም ውሂብ የለም, ስራው ወደታች ነው. ዝግጅት ባለብዙ ቴራባይት ነበር። እና እንደገና እንዲነሳ ረጅም ጊዜ መጠበቅ አለብዎት. እና ነገ ለማጠናቀቅ እንወስናለን. ያ ነው ልማት አለን።
• እና፣ በእርግጥ፣ እዚያ የሚሰሩ ብዙ ባልደረቦች፣ ብዙ ቡድኖች አሉን። እና በእጅ መከናወን አለበት. እና ይሄ የማይመች ነው.

እና አንድ ሙከራ ብቻ አለን ፣ አንድ ጥይት ፣ በመረጃ ቋቱ ላይ አንዳንድ ለውጦችን ለማድረግ ከፈለግን መረጃውን ይንኩ ፣ አወቃቀሩን ይቀይሩ ማለት ተገቢ ነው ። እና የሆነ ችግር ከተፈጠረ፣ በስደት ላይ ስህተት ከተፈጠረ በፍጥነት ወደ ኋላ አንመለስም።

ይህ ከቀዳሚው አቀራረብ የተሻለ ነው ፣ ግን አሁንም አንድ ዓይነት ስህተት ወደ ምርት የመሄድ እድሉ ከፍተኛ ነው።

ለእያንዳንዱ ገንቢ የሙከራ አግዳሚ ወንበር፣ ባለ ሙሉ መጠን ቅጂ እንድንሰጥ የሚከለክለን ምንድን ነው? እንቅፋት የሆነው ነገር ግልፅ ነው ብዬ አስባለሁ።

ከቴራባይት የበለጠ የመረጃ ቋት ያለው ማነው? ከግማሽ በላይ ክፍል.

እና ለእያንዳንዱ ገንቢ ማሽኖች ማቆየት እንዲህ አይነት ትልቅ ምርት ሲኖር በጣም ውድ እንደሆነ ግልጽ ነው, እና በተጨማሪ, ረጅም ጊዜ ይወስዳል.

ሁሉንም ለውጦች በሙሉ መጠን ቅጂዎች መሞከር በጣም አስፈላጊ መሆኑን የተገነዘቡ ደንበኞች አሉን, ነገር ግን የመረጃ ቋታቸው ከቴራባይት ያነሰ ነው, እና ለእያንዳንዱ ገንቢ የሙከራ አግዳሚ ወንበር ለማስቀመጥ ምንም ሀብቶች የሉም. ስለዚህ, ቆሻሻዎችን ወደ ማሽኖቻቸው በማውረድ እና በዚህ መንገድ መሞከር አለባቸው. ብዙ ጊዜ ይወስዳል.

በመሠረተ ልማት አውታሮች ውስጥ ቢያደርጉትም በሰዓት አንድ ቴራባይት ዳታ ማውረድ ቀድሞውንም ጥሩ ነው። ነገር ግን አመክንዮአዊ ቆሻሻዎችን ይጠቀማሉ, ከደመናው ውስጥ በአካባቢው ይወርዳሉ. ለእነሱ ፍጥነቱ በሰዓት ወደ 200 ጊጋባይት ይደርሳል. እና አሁንም ከሎጂካዊ ማጠራቀሚያ ለመዞር, ኢንዴክሶችን ለመጠቅለል, ወዘተ.

ነገር ግን ምርቱን አስተማማኝ እንዲሆን ስለሚያስችላቸው ይህንን ዘዴ ይጠቀማሉ.

እዚህ ምን እናድርግ? የሙከራ አግዳሚ ወንበሮችን ርካሽ እናድርግ እና ለእያንዳንዱ ገንቢ የራሱን የሙከራ አግዳሚ ወንበር እንስጥ።

ይህ ደግሞ ይቻላል.

እና በዚህ አቀራረብ ለእያንዳንዱ ገንቢ ቀጭን ክሎኖችን ስናደርግ በአንድ ማሽን ላይ ልናካፍለው እንችላለን። ለምሳሌ፣ 10TB ዳታቤዝ ካለህ እና ለ10 ገንቢዎች መስጠት የምትፈልግ ከሆነ፣ XNUMX x XNUMXTB ዳታቤዝ ሊኖርህ አይገባም። አንድ ማሽን ተጠቅመው ለእያንዳንዱ ገንቢ ቀጭን ነጠላ ቅጂዎችን ለመስራት አንድ ማሽን ብቻ ያስፈልግዎታል። ትንሽ ቆይቶ እንዴት እንደሚሰራ እነግርዎታለሁ።

እውነተኛ ምሳሌ፡-

• ዲቢ - 4,5 ቴራባይት.

• በ 30 ሰከንድ ውስጥ ገለልተኛ ቅጂዎችን ማግኘት እንችላለን.

ለሙከራ ማቆሚያ መጠበቅ አያስፈልግም እና ምን ያህል ትልቅ እንደሆነ ይወሰናል. በሰከንዶች ውስጥ ማግኘት ይችላሉ. እሱ ሙሉ በሙሉ ገለልተኛ አካባቢዎች ይሆናል ፣ ግን በመካከላቸው መረጃን የሚጋሩ።

ይህ ታላቅ ነው. እዚህ ስለ አስማት እና ስለ ትይዩ አጽናፈ ሰማይ እየተነጋገርን ነው.

በእኛ ሁኔታ, ይህ የ OpenZFS ስርዓትን በመጠቀም ይሰራል.

OpenZFS ከሳጥኑ ውጭ ቅጽበተ-ፎቶዎችን እና ክሎኖችን የሚደግፍ ኮፒ-ላይ-የፋይል ስርዓት ነው። አስተማማኝ እና ሊሰፋ የሚችል ነው. እሷን ለማስተዳደር በጣም ቀላል ነች። በጥሬው በሁለት ቡድን ውስጥ ሊሰማራ ይችላል.

ሌሎች አማራጮች አሉ፡-

• ኤልቪኤም ፣

• ማከማቻ (ለምሳሌ ንጹህ ማከማቻ)።

እኔ የምናገረው የውሂብ ጎታ ቤተ ሙከራ ሞጁል ነው። እነዚህን አማራጮች በመጠቀም ሊተገበር ይችላል. አሁን ግን በOpenZFS ላይ አተኩረናል፣ ምክንያቱም በተለይ ከኤልቪኤም ጋር ችግሮች ነበሩ።

እንዴት እንደሚሰራ? መረጃውን በቀየርን ቁጥር ከመፃፍ ይልቅ፣ ይህ አዲስ መረጃ ከአዲስ ጊዜ፣ ከአዲስ ቅጽበታዊ ገጽ እይታ የመጣ መሆኑን በቀላሉ ምልክት በማድረግ እናስቀምጠዋለን።

እና ወደፊት፣ ወደ ኋላ መመለስ ስንፈልግ ወይም ከአሮጌው ስሪት አዲስ ክሎሎን ለመስራት ስንፈልግ፡- “እሺ፣ እንደዚህ ምልክት የተደረገባቸውን የውሂብ ብሎኮች ስጠን” እንላለን።

እና ይህ ተጠቃሚ ከእንደዚህ አይነት የውሂብ ስብስብ ጋር ይሰራል. እሱ ቀስ በቀስ ይለውጣቸዋል, የራሱን ቅጽበተ-ፎቶዎችን ይሠራል.

እና ቅርንጫፍ እንሰራለን. በእኛ ሁኔታ ውስጥ ያለው እያንዳንዱ ገንቢ የሚያስተካክለው የራሱ ክሎኑ እንዲኖረው እድል ይኖረዋል፣ እና የተጋራው ውሂብ በሁሉም ሰው መካከል ይጋራል።

እንዲህ ዓይነቱን ሥርዓት በቤት ውስጥ ለማሰማራት ሁለት ችግሮችን መፍታት ያስፈልግዎታል-

• የመጀመሪያው የመረጃው ምንጭ ነው, ከየት እንደሚወስዱት. ከምርት ጋር ማባዛትን ማዘጋጀት ይችላሉ. አስቀድመው ያዋቅሯቸውን ምትኬዎችን መጠቀም ይችላሉ, ተስፋ አደርጋለሁ. ዋል-ኢ፣ ዋል-ጂ ወይም ባርማን። እና እንደ RDS ወይም Cloud SQL ያሉ አንዳንድ የክላውድ መፍትሄዎችን እየተጠቀሙ ቢሆንም፣ ከዚያ ምክንያታዊ ቆሻሻዎችን መጠቀም ይችላሉ። ግን አሁንም ቢሆን ምትኬዎችን እንዲጠቀሙ እንመክርዎታለን ፣ ምክንያቱም በዚህ አቀራረብ የፋይሎችን አካላዊ መዋቅርም ያቆያሉ ፣ ይህም እነዚያን ችግሮች ለመያዝ በምርት ውስጥ ወደሚመለከቷቸው መለኪያዎች የበለጠ እንዲቀርቡ ያስችልዎታል ።

• ሁለተኛው የዳታቤዝ ቤተ ሙከራን ማስተናገድ የምትፈልጉበት ቦታ ነው። ክላውድ ሊሆን ይችላል፣ በግቢው ላይ ሊሆን ይችላል። እዚህ ZFS የውሂብ መጨናነቅን ይደግፋል ማለት አስፈላጊ ነው. እና በደንብ ያደርገዋል።

ከመሠረቱ ጋር በምናደርጋቸው ኦፕሬሽኖች ላይ በመመስረት ለእያንዳንዱ እንደዚህ ያለ ክሎሎን ፣ አንድ ዓይነት ዴቭ እንደሚያድግ አስቡት። ለዚህ, dev እንዲሁ ቦታ ያስፈልገዋል. ነገር ግን የ 4,5 ቴራባይት መሰረትን ስለወሰድን, ZFS ወደ 3,5 ቴራባይት ይጨመቃል. ይህ እንደ ቅንጅቶቹ ሊለያይ ይችላል. እና አሁንም ለዴቭ ቦታ አለን።

እንዲህ ዓይነቱ ሥርዓት ለተለያዩ ጉዳዮች ጥቅም ላይ ሊውል ይችላል.

• እነዚህ ገንቢዎች፣ DBAs ለጥያቄ ማረጋገጫ፣ ለማመቻቸት ናቸው።

• ይህ የተወሰነ ፍልሰትን ወደ ምርት ከመልቀቃችን በፊት ለመፈተሽ በQA ሙከራ ውስጥ ሊያገለግል ይችላል። እና ለ QA ልዩ አካባቢዎችን ከእውነተኛ ውሂብ ጋር ማሳደግ እንችላለን፣ አዲስ ተግባርን ሊፈትሹ ይችላሉ። እና ከተጠባባቂ ሰዓቶች ይልቅ ሰከንዶችን ይወስዳል, እና ምናልባት በአንዳንድ ሌሎች ጉዳዮች ላይ ቀጭን ቅጂዎች ጥቅም ላይ በማይውሉ ቀናት ውስጥ ቀናትን ይወስዳል.

• እና ሌላ ጉዳይ። ካምፓኒው የትንታኔ ስርዓት ከሌለው የምርት መሰረቱን ቀጭን ክሎሉን ለይተን ለረጅም ጥያቄዎች ወይም በትንታኔ ውስጥ ጥቅም ላይ ሊውሉ የሚችሉ ልዩ ኢንዴክሶችን መስጠት እንችላለን።

በዚህ አቀራረብ፡-

1. በ "prod" ላይ የስህተት ዝቅተኛ ዕድል, ምክንያቱም ሁሉንም ለውጦች በሙሉ መጠን ውሂብ ላይ ስለሞከርን.

2. የመፈተሽ ባህል አለን።

3. እና ምንም እንቅፋት የለም, በፈተናዎች መካከል መጠበቅ የለም. በትክክል መሄድ እና ማረጋገጥ ይችላሉ. እናም ልማቱን ስናፋጥን በዚህ መንገድ የተሻለ ይሆናል።

• ያነሰ የመልሶ ማቋቋም ሂደት ይኖራል. ያነሱ ሳንካዎች በምርት ውስጥ ያበቃል። ትንሽ ቆይተን እናስተካክላቸዋለን።

• የማይመለሱ ለውጦችን መቀልበስ እንችላለን። ይህ መደበኛ አካሄድ አይደለም.

1. ይህ ጠቃሚ ነው, ምክንያቱም የሙከራ ወንበሮችን ሀብቶች ስለምንጋራ ነው.

ቀድሞውኑ ጥሩ ነው ፣ ግን ሌላ ምን ማፋጠን ይቻላል?

ለእንዲህ ዓይነቱ ሥርዓት ምስጋና ይግባውና ወደ እንደዚህ ዓይነት ፈተና ለመግባት ያለውን ገደብ በእጅጉ መቀነስ እንችላለን.

አሁን አንድ ገንቢ እውነተኛ ሙሉ መጠን ያለው መረጃ ለማግኘት ባለሙያ መሆን ሲገባው ክፉ ክበብ አለ። በእንደዚህ ዓይነት መዳረሻ መታመን አለበት.

ግን እዚያ ከሌለ እንዴት እንደሚያድግ. ግን ለእርስዎ የሚገኝ በጣም ትንሽ የሆነ የሙከራ ውሂብ ብቻ ካለዎትስ? ከዚያ ምንም እውነተኛ ልምድ አያገኙም።

ከዚህ ክበብ እንዴት መውጣት ይቻላል? እንደ መጀመሪያው በይነገጽ ፣ ለማንኛውም ደረጃ ላሉ ገንቢዎች ምቹ ፣ Slack bot ን መርጠናል ። ግን ሌላ ማንኛውም በይነገጽ ሊሆን ይችላል.

ምን እንዲያደርጉ ይፈቅድልዎታል? የተወሰነ መጠይቅ ወስደህ ለዳታቤዝ ወደ ልዩ ቻናል መላክ ትችላለህ። በሰከንዶች ውስጥ አንድ ቀጭን ክሎሎን በራስ-ሰር እናሰማራለን። ይህን ጥያቄ እናካሂድ። መለኪያዎችን እና ምክሮችን እንሰበስባለን. ምስላዊነት እናሳይ። እና ይህ መጠይቅ በሆነ መንገድ እንዲሻሻል፣ ኢንዴክሶችን ለመጨመር፣ ወዘተ እንዲችል ይህ ክሎኑ ይቀራል።

እና ደግሞ Slack ከሳጥን ውጭ የትብብር እድሎችን ይሰጠናል። ይህ ቻናል ብቻ ስለሆነ፣ ለእንደዚህ አይነት ጥያቄ በክርክሩ ውስጥ ስለዚህ ጥያቄ፣ በኩባንያው ውስጥ ያሉ ባልደረቦችዎን፣ ዲቢኤዎችን ፒንግ ማድረግ ይችላሉ።

ግን በእርግጥ, ችግሮች አሉ. ይህ የገሃዱ አለም ስለሆነ እና በአንድ ጊዜ ብዙ ክሎኖችን የሚያስተናግድ አገልጋይ እየተጠቀምን ያለነው፣ ለክሎኖች ያለውን የማህደረ ትውስታ መጠን እና የሲፒዩ ሃይል መጭመቅ አለብን።

ነገር ግን እነዚህ ሙከራዎች አሳማኝ እንዲሆኑ, ይህንን ችግር በሆነ መንገድ መፍታት ያስፈልግዎታል.

አስፈላጊው ነጥብ ተመሳሳይ ውሂብ መሆኑን ግልጽ ነው. እኛ ግን አስቀድመን አለን። እና ተመሳሳይ ውቅር ማግኘት እንፈልጋለን. እና እንደዚህ አይነት ከሞላ ጎደል ተመሳሳይ ውቅር መስጠት እንችላለን።

በምርት ውስጥ እንዳለው ተመሳሳይ ሃርድዌር ቢኖረው ጥሩ ይሆናል፣ ግን ሊለያይ ይችላል።

ፖስትግሬስ ከማስታወስ ጋር እንዴት እንደሚሰራ እናስታውስ። ሁለት መሸጎጫዎች አሉን. አንዱ ከፋይል ሲስተም እና አንድ ቤተኛ Postgres፣ ማለትም የተጋራ ቋት መሸጎጫ።

Postgres ሲጀምር የተጋራው Buffer Cache የተመደበው በአወቃቀሩ ውስጥ በምን ያህል መጠን እንደሚወሰን ነው።

እና ሁለተኛው መሸጎጫ ሁሉንም የሚገኘውን ቦታ ይጠቀማል።

እና በአንድ ማሽን ላይ ብዙ ክሎኖችን ስንሠራ ቀስ በቀስ ማህደረ ትውስታውን እንደሞላን ያሳያል። እና በጥሩ ሁኔታ የተጋራ Buffer Cache በማሽኑ ላይ ካለው አጠቃላይ የማህደረ ትውስታ መጠን 25% ነው።

እናም ይህንን ግቤት ካልቀየርን ፣ በአንድ ማሽን ላይ 4 አጋጣሚዎችን ብቻ ማሄድ እንችላለን ፣ ማለትም ፣ ከእነዚህ ውስጥ 4 ቀጭን ክሎኖች በአጠቃላይ። እና ይሄ, በእርግጥ, መጥፎ ነው, ምክንያቱም ከእነሱ ብዙ እንዲኖረን እንፈልጋለን.

ግን በሌላ በኩል፣ Buffer Cache ለመረጃ ጠቋሚዎች መጠይቆችን ለማስፈጸም ይጠቅማል፣ ማለትም፣ ዕቅዱ መሸጎጫችን ምን ያህል ትልቅ እንደሆነ ይወሰናል። እና ይህን ግቤት ብቻ ከወሰድን እና ከቀነስን, እቅዶቻችን ብዙ ሊለወጡ ይችላሉ.

ለምሳሌ በፕሮድ ላይ ትልቅ መሸጎጫ ካለን ፖስትግሬስ ኢንዴክስን መጠቀም ይመርጣል። እና ካልሆነ፣ ከዚያ SeqScan ይኖራል። እና እቅዳችን ባይጣጣም ምን ዋጋ ይኖረዋል?

ግን እዚህ መደምደሚያ ላይ ደርሰናል በእውነቱ በ Postgres ውስጥ ያለው እቅድ በእቅዱ ውስጥ ባለው የተጋራ ቋት ውስጥ በተገለጸው የተወሰነ መጠን ላይ የተመካ አይደለም ፣ እሱ በውጤታማ_cache_size ላይ የተመሠረተ ነው።

Effective_cache_size ለእኛ ያለው የተገመተው የመሸጎጫ መጠን ማለትም የ Buffer Cache እና የፋይል ስርዓት መሸጎጫ ድምር ነው። ይህ በማዋቀሪያው ተዘጋጅቷል. እና ይህ ማህደረ ትውስታ አልተመደበም.

እና በዚህ ግቤት ምክንያት፣ ምንም እንኳን ይህ ውሂብ ባይኖረንም ብዙ ውሂብ አለን በማለት ፖስትግሬስን ማታለል እንችላለን። እና ስለዚህ ፣ እቅዶቹ ከምርት ጋር ሙሉ በሙሉ ይጣጣማሉ።

ነገር ግን ይህ በጊዜው ላይ ተጽዕኖ ሊያሳድር ይችላል. እና መጠይቆችን በጊዜ አጠባበቅ እናመቻቻለን፣ነገር ግን የጊዜ አወሳሰድ በብዙ ሁኔታዎች ላይ የተመሰረተ መሆኑ አስፈላጊ ነው፡-

• በአሁኑ ጊዜ በምርታማነት ላይ ባለው ጭነት ላይ የተመሰረተ ነው.

• እንደ ማሽኑ ራሱ ባህሪያት ይወሰናል.

እና ይህ ቀጥተኛ ያልሆነ መለኪያ ነው, ነገር ግን በእውነቱ ውጤቱን ለማግኘት ይህ መጠይቅ በሚያነበው የውሂብ መጠን በትክክል ማመቻቸት እንችላለን.

እና ጊዜው በፕሮድ ውስጥ ከምናየው ጋር እንዲቀራረብ ከፈለጉ በጣም ተመሳሳይ የሆነውን ሃርድዌር መውሰድ አለብን እና ምናልባትም ሁሉም ክሎኖች እንዲገጣጠሙ የበለጠ። ግን ይህ ስምምነት ነው ፣ ማለትም ፣ ተመሳሳይ እቅዶችን ያገኛሉ ፣ አንድ የተወሰነ መጠይቅ ምን ያህል ውሂብ እንደሚነበብ ያያሉ እና ይህ መጠይቅ ጥሩ (ወይም ስደት) ወይም መጥፎ መሆኑን ለመደምደም ይችላሉ ፣ አሁንም ማመቻቸት አለበት ። .

እስቲ ጆ እንዴት እንደተመቻቸ እንመልከት።

ከእውነተኛ ስርዓት ጥያቄን እንውሰድ። በዚህ ሁኔታ የውሂብ ጎታ 1 ቴራባይት ነው. እና ከ10 በላይ መውደዶች የነበሯቸውን ትኩስ ልጥፎች ብዛት መቁጠር እንፈልጋለን።

ወደ ቻናሉ መልእክት እየጻፍን ነው ፣ ክሎሎን ለእኛ ተዘርግቷል ። እና እንደዚህ አይነት ጥያቄ በ 2,5 ደቂቃዎች ውስጥ እንደሚጠናቀቅ እናያለን. እኛ የምናስተውለው የመጀመሪያው ነገር ነው።

ቢ ጆ በእቅዱ እና በመለኪያዎች ላይ በመመስረት አውቶማቲክ ምክሮችን ያሳየዎታል።

በአንጻራዊ ሁኔታ አነስተኛ ቁጥር ያላቸውን ረድፎች ለማግኘት መጠይቁ ብዙ ውሂብ እንደሚያስኬድ እናያለን። እና በጥያቄው ውስጥ በጣም ብዙ የተጣሩ ረድፎች እንዳሉ ስለተገነዘብን አንድ ዓይነት ልዩ መረጃ ጠቋሚ ያስፈልጋል።

የሆነውን ነገር ጠለቅ ብለን እንመርምር። በእርግጥ ከፋይል መሸጎጫ አልፎ ተርፎም ከዲስክ ወደ አንድ ጊጋባይት የሚጠጋ መረጃ እንዳነበብን እናያለን። እና ይሄ ጥሩ አይደለም, ምክንያቱም እኛ ያገኘነው 142 መስመሮች ብቻ ነው.

እና፣ እዚህ ኢንዴክስ ስካን ያለን ይመስላል እና በፍጥነት መስራት ነበረብን፣ ነገር ግን ብዙ መስመሮችን ስላጣራን (መቁጠር ነበረብን)፣ ጥያቄው ቀስ በቀስ ሰራ።

እና ይህ በእቅዱ ውስጥ የተከሰተው በጥያቄው ውስጥ ያሉት ሁኔታዎች እና በመረጃ ጠቋሚው ውስጥ ያሉት ሁኔታዎች በከፊል የማይዛመዱ በመሆናቸው ነው።

የመረጃ ጠቋሚውን የበለጠ ትክክለኛ ለማድረግ እንሞክር እና ከዚያ በኋላ የጥያቄው አፈፃፀም እንዴት እንደሚቀየር ይመልከቱ።

የመረጃ ጠቋሚው መፈጠር በጣም ረጅም ጊዜ ፈጅቷል ፣ ግን አሁን መጠይቁን እንፈትሻለን እና ከ 2,5 ደቂቃዎች ይልቅ ጊዜው 156 ሚሊ ሰከንድ ብቻ እንደሆነ እናያለን ፣ ይህ በቂ ነው። እና 6 ሜጋባይት ዳታ ብቻ እናነባለን።

እና አሁን ኢንዴክስን ብቻ እንጠቀማለን.

ሌላው አስፈላጊ ታሪክ እቅዱን ይበልጥ ለመረዳት በሚያስችል መንገድ ማቅረብ እንፈልጋለን. የፍላም ግራፎችን በመጠቀም ምስላዊነትን ተግባራዊ አድርገናል።

ይህ የተለየ ጥያቄ ነው፣ የበለጠ ኃይለኛ። እና የነበልባል ግራፎችን በሁለት መመዘኛዎች መሰረት እንገነባለን-ይህ የተወሰነ መስቀለኛ መንገድ በእቅዱ እና በጊዜ ውስጥ የተቆጠረው የውሂብ መጠን ነው, ማለትም የመስቀለኛ መንገዱ የአፈፃፀም ጊዜ.

እዚህ የተወሰኑ አንጓዎችን እርስ በርስ ማወዳደር እንችላለን. እና ከመካከላቸው የትኛው ብዙ ወይም ያነሰ እንደሚወስድ ግልጽ ይሆናል, ይህም አብዛኛውን ጊዜ በሌሎች የአተረጓጎም ዘዴዎች ውስጥ ለመስራት አስቸጋሪ ነው.

እርግጥ ነው, ሁሉም ያውቃል explain.depesz.com. የዚህ ምስላዊነት ጥሩ ገፅታ የፅሁፍ እቅዱን እናስቀምጠዋለን እና እንዲሁም አንዳንድ መሰረታዊ መለኪያዎችን ወደ ሠንጠረዥ ውስጥ በማስገባት መደርደር እንችላለን.

እና በዚህ ርዕስ ውስጥ ገና ያልገቡ ገንቢዎችም explain.depesz.com ን ይጠቀማሉ፣ ምክንያቱም የትኞቹ መለኪያዎች አስፈላጊ እንደሆኑ እና የትኞቹ እንደሌሉ ማወቅ ለእነሱ ቀላል ነው።

የእይታ እይታ አዲስ አቀራረብ አለ - ይህ explain.dalibo.com ነው። የዛፍ እይታን ይሠራሉ, ግን አንጓዎችን እርስ በርስ ማወዳደር በጣም ከባድ ነው. እዚህ አወቃቀሩን በደንብ ሊረዱት ይችላሉ, ነገር ግን, ትልቅ ጥያቄ ካለ, ከዚያ ወደ ኋላ እና ወደ ፊት ማሸብለል ያስፈልግዎታል, ግን ደግሞ አማራጭ.

ትብብር

እና፣ እንዳልኩት፣ Slack የመተባበር እድል ይሰጠናል። ለምሳሌ፣ እንዴት ማመቻቸት እንዳለብን ግልጽ ያልሆነ ውስብስብ ጥያቄ ካጋጠመን፣ ይህንን ጉዳይ ከባልደረባዎቻችን ጋር በ Slack ውስጥ ግልጽ ማድረግ እንችላለን።

ሙሉ መጠን ባለው መረጃ ላይ መሞከር አስፈላጊ እንደሆነ ለእኛ ይመስላል. ይህንን ለማድረግ በክፍት ምንጭ የሚገኘውን አዘምን ዳታቤዝ ቤተ ሙከራን መሳሪያ አድርገናል። የጆ ቦትንም መጠቀም ይችላሉ። አሁኑኑ ወስደህ በምትኖርበት ቦታ መተግበር ትችላለህ። ሁሉም መመሪያዎች እዚያ ይገኛሉ።

በተጨማሪም መፍትሔው ራሱ አብዮታዊ እንዳልሆነ ልብ ሊባል የሚገባው ነው, ምክንያቱም ዴልፊክስ አለ, ግን የድርጅት መፍትሄ ነው. ሙሉ በሙሉ ተዘግቷል, በጣም ውድ ነው. እኛ በተለይ በፖስትግሬስ ውስጥ ልዩ ነን። እነዚህ ሁሉ ክፍት ምንጭ ምርቶች ናቸው። ተቀላቀለን!

እዚህ ላይ ነው የምጨርሰው። አመሰግናለሁ!

ጥያቄዎች

ሀሎ! ለሪፖርቱ እናመሰግናለን! በጣም አስደሳች ፣ በተለይም ለእኔ ፣ ምክንያቱም ከተወሰነ ጊዜ በፊት ስለ ተመሳሳይ ችግር ስለፈታሁ። እና ስለዚህ በርካታ ጥያቄዎች አሉኝ. ቢያንስ በከፊል አገኛለሁ ብዬ ተስፋ አደርጋለሁ።

ለዚህ አካባቢ ቦታውን እንዴት እንደሚያሰሉ አስባለሁ? ቴክኖሎጂው በተወሰኑ ሁኔታዎች ውስጥ የእርስዎ ክሎኖች ወደ ከፍተኛ መጠን ሊያድግ ይችላል. በግምት አሥር ቴራባይት ዳታቤዝ እና 10 ክሎኖች ካሉዎት እያንዳንዱ ክሎኑ 10 ልዩ መረጃዎችን የሚመዝንበትን ሁኔታ መምሰል ቀላል ነው። እነዚህ ክሎኖች የሚኖሩበትን ይህንን ቦታ ማለትም እርስዎ የተናገሩትን ዴልታ እንዴት ያስሉታል?

ጥሩ ጥያቄ. እዚህ የተወሰኑ ክሎኖችን መከታተል አስፈላጊ ነው. እና ክሎኑ በጣም ትልቅ ለውጥ ካለው ፣ ማደግ ይጀምራል ፣ ከዚያ በመጀመሪያ ስለዚህ ጉዳይ ለተጠቃሚው ማስጠንቀቂያ እንሰጣለን ፣ ወይም ያልተሳካ ሁኔታ እንዳይኖርብን ይህንን ክሎኑን ወዲያውኑ ማቆም እንችላለን።

አዎ፣ አንድ ጥያቄ አለኝ። ያም ማለት የእነዚህን ሞጁሎች የሕይወት ዑደት እንዴት ማረጋገጥ ይቻላል? ይህ ችግር እና የተለየ ታሪክ አለን. ይህ እንዴት ይሆናል?

ለእያንዳንዱ ክሎል የተወሰነ tl አለ። በመሠረቱ, ቋሚ tl አለን.

ምስጢር ካልሆነስ?

1 ሰዓት, ​​ማለትም ስራ ፈት - 1 ሰዓት. ጥቅም ላይ ካልዋለ, ከዚያም እንፈነዳዋለን. ነገር ግን ክሎሉን በሰከንዶች ውስጥ ማሳደግ ስለምንችል እዚህ ምንም የሚያስደንቅ ነገር የለም. እና እንደገና ከፈለጉ እባክዎን.

ቴክኖሎጂዎችን ለመምረጥም ፍላጎት አለኝ, ምክንያቱም ለምሳሌ, በአንድ ወይም በሌላ ምክንያት በርካታ ዘዴዎችን በትይዩ እንጠቀማለን. ለምን ZFS? ለምን LVM አልተጠቀሙም? LVM ላይ ችግሮች እንደነበሩ ጠቅሰዋል። ችግሮቹ ምን ነበሩ? በእኔ አስተያየት, በጣም ጥሩው አማራጭ ከማከማቻ ጋር ነው, በአፈፃፀም.

የ ZFS ዋና ችግር ምንድነው? በተመሳሳዩ አስተናጋጅ ላይ መሮጥ ያለብዎት ፣ ማለትም ሁሉም አጋጣሚዎች በተመሳሳይ ስርዓተ ክወና ውስጥ ይኖራሉ። እና በማከማቻው ውስጥ, የተለያዩ መሳሪያዎችን ማገናኘት ይችላሉ. እና ማነቆው በማከማቻ ስርዓቱ ላይ ያሉት እገዳዎች ብቻ ናቸው. እና የቴክኖሎጂዎች ምርጫ ጥያቄው አስደሳች ነው. ለምን LVM አይሆንም?

በተለይም LVMን በስብሰባ ላይ መወያየት እንችላለን። ስለ ማከማቻ - በጣም ውድ ነው። የ ZFS ስርዓቱን በየትኛውም ቦታ መተግበር እንችላለን. በማሽንዎ ላይ ማሰማራት ይችላሉ። በቀላሉ ማከማቻውን ማውረድ እና ማሰማራት ይችላሉ። ስለ ሊኑክስ እየተነጋገርን ከሆነ ZFS በሁሉም ቦታ ተጭኗል። ማለትም, በጣም ተለዋዋጭ መፍትሄ እናገኛለን. እና ከሳጥኑ ውስጥ, ZFS ብዙ ይሰጣል. የፈለጉትን ያህል ውሂብ መስቀል ይችላሉ, ብዙ ቁጥር ያላቸውን ዲስኮች ያገናኙ, ቅጽበተ-ፎቶዎች አሉ. እና፣ እንዳልኩት፣ ለማስተዳደር ቀላል ነው። ማለትም ፣ ለመጠቀም በጣም አስደሳች ይመስላል። ተፈትኗል፣ እድሜው ብዙ ነው። እያደገ ያለው በጣም ትልቅ ማህበረሰብ አለው። ZFS በጣም አስተማማኝ መፍትሄ ነው.

Nikolai Samokhvalov: ተጨማሪ አስተያየት መስጠት እችላለሁ? ስሜ ኒኮላይ ነው, ከአናቶሊ ጋር አብረን እንሰራለን. ማከማቻ በጣም ጥሩ እንደሆነ እስማማለሁ። እና አንዳንድ ደንበኞቻችን ንጹህ ማከማቻ ወዘተ አላቸው።

እኛ ሞዱላሪቲ ላይ ያተኮረ መሆናችንን አናቶሊ በትክክል ተናግሯል። እና ለወደፊቱ አንድ በይነገጽ መተግበር ይችላሉ - ቅጽበታዊ ገጽ እይታን ያንሱ ፣ ክሎሎን ያድርጉ ፣ ክሎኑን ያጠፋሉ ። ሁሉም ነገር ቀላል ነው። እና ማከማቻው አሪፍ ነው, ከሆነ.

ግን ZFS ለሁሉም ሰው ይገኛል። ዴልፊክስ ቀድሞውኑ በቂ ነው ፣ 300 ደንበኞች አሏቸው። ከእነዚህ ውስጥ ሀብቱ 100 50 ደንበኞች አሉት ማለትም ናሳ ላይ ያነጣጠሩ ናቸው ወዘተ. ሁሉም ሰው ይህን ቴክኖሎጂ የሚያገኝበት ጊዜ ነው. እና ለዚህ ነው ክፍት ምንጭ ኮር ያለን. ክፍት ምንጭ ያልሆነ የበይነገጽ ክፍል አለን። ይህ የምናሳየው መድረክ ነው። ግን ለሁሉም ሰው ተደራሽ እንዲሆን እንፈልጋለን። ሁሉም ሞካሪዎች በላፕቶፖች ላይ መገመት እንዲያቆሙ አብዮት መፍጠር እንፈልጋለን። SELECT ብለን መፃፍ እና ቀርፋፋ መሆኑን ወዲያውኑ ማየት አለብን። DBA ስለእሱ እንዲነግርዎ መጠበቅዎን ያቁሙ። ዋናው ግብ እዚህ አለ. እና ሁላችንም ወደዚህ እንመጣለን ብዬ አስባለሁ. እና ይህን ነገር ሁሉም ሰው እንዲኖረው እናደርጋለን. ስለዚህ ZFS, ምክንያቱም በሁሉም ቦታ የሚገኝ ይሆናል. ህብረተሰቡ ለችግሮች መፍትሄ እና ክፍት ምንጭ ፍቃድ ወዘተ ምስጋና ይግባው.

ሰላምታ! ለሪፖርቱ እናመሰግናለን! ስሜ ማክስም ነው። ተመሳሳይ ጉዳዮችን አስተናግደናል። በራሳቸው ወሰኑ። በእነዚህ ክሎኖች መካከል ሀብቶችን እንዴት ይጋራሉ? እያንዳንዱ ክሎክ በማንኛውም ጊዜ የራሱን ነገር ማድረግ ይችላል-አንዱ አንድ ነገር ይፈትናል, ሌላ, አንድ ሰው ኢንዴክስ ይገነባል, አንድ ሰው ከባድ ስራ አለው. እና አሁንም በሲፒዩ መከፋፈል ከቻሉ፣ ከዚያም በ IO፣ እንዴት ይከፋፈላሉ? ይህ የመጀመሪያው ጥያቄ ነው።

ሁለተኛው ጥያቄ ደግሞ የቋሚዎቹ አለመመሳሰል ነው። እዚህ ZFS አለኝ እንበል እና ሁሉም ነገር አሪፍ ነው፣ ነገር ግን ፕሮድ ላይ ያለው ደንበኛ ZFS የለውም፣ ግን ለምሳሌ ext4። በዚህ ጉዳይ ላይ እንዴት?

ጥያቄዎቹ በጣም ጥሩ ናቸው። ይህንን ችግር በጥቂቱ የጠቀስኩት ሃብትን ስለምንጋራ ነው። መፍትሔውም ይህ ነው። በመድረክ ላይ እየሞከርክ እንደሆነ አስብ። እንዲሁም አንድ ሰው አንድ ጭነት, ሌላ ሰው በሚሰጥበት ጊዜ እንደዚህ አይነት ሁኔታ ሊኖርዎት ይችላል. እና በውጤቱም, ለመረዳት የማይቻሉ መለኪያዎችን ይመለከታሉ. ተመሳሳይ ችግር እንኳን ከፕሮድ ጋር ሊሆን ይችላል. አንዳንድ ጥያቄን ለመፈተሽ ሲፈልጉ እና በእሱ ላይ አንዳንድ ችግሮች እንዳሉ ሲመለከቱ - ቀስ ብሎ ይሰራል, ከዚያ በእውነቱ ችግሩ በጥያቄው ውስጥ አልነበረም, ነገር ግን አንድ አይነት ትይዩ ጭነት አለ.

እና ስለዚህ, እቅዱ ምን እንደሚሆን, በእቅዱ ውስጥ ምን እርምጃዎችን እንደምንወስድ እና ለዚህ ምን ያህል መረጃ እንደምናነሳ ላይ ማተኮር አስፈላጊ ነው. የእኛ ዲስኮች, ለምሳሌ, በአንድ ነገር ላይ የሚጫኑ መሆናቸው, በተለይም በጊዜው ላይ ተጽዕኖ ያሳድራል. ነገር ግን ይህ ጥያቄ ምን ያህል እንደተጫነ በመረጃው መጠን መገመት እንችላለን። በተመሳሳይ ጊዜ አንድ ዓይነት ግድያ ሊኖር ስለሚችል በጣም አስፈላጊ አይደለም.

ሁለት ጥያቄዎች አሉኝ። ይህ በጣም አሪፍ ነገር ነው። እንደ ክሬዲት ካርድ ቁጥሮች ያሉ የምርት መረጃዎች ወሳኝ የሆኑባቸው አጋጣሚዎች ነበሩ? አስቀድሞ የተዘጋጀ ነገር አለ ወይንስ የተለየ ተግባር ነው? እና ሁለተኛው ጥያቄ - ለ MySQL እንደዚህ ያለ ነገር አለ?

ስለ መረጃው. እስክንሰራ ድረስ ማደብዘዝን እናደርጋለን. ነገር ግን በትክክል ጆን ካሰማራህ፣ ለገንቢዎች መዳረሻ ካልሰጠህ የውሂብ መዳረሻ የለም። ለምን? ምክንያቱም ጆ ውሂብ አያሳይም። እሱ መለኪያዎችን ፣ እቅዶችን ብቻ ያሳያል እና ያ ነው። ይህ የተደረገው ሆን ተብሎ ነው, ምክንያቱም ይህ የደንበኞቻችን መስፈርቶች አንዱ ነው. ለሁሉም ሰው መዳረሻ ሳይሰጡ ማመቻቸት መቻል ይፈልጋሉ።

ስለ MySQL ይህ ስርዓት በዲስክ ላይ ሁኔታን ለሚያከማች ለማንኛውም ነገር ሊያገለግል ይችላል። እና Postgres እየሰራን ስለሆነ አሁን ሁሉንም አውቶማቲክስ ለ Postgres እያደረግን ነው። ከመጠባበቂያ ቅጂ መረጃን በራስ ሰር ማግኘት እንፈልጋለን። Postgresን በትክክል እያዋቀርን ነው። ዕቅዶችን እንዴት ማዛመድ እንደምንችል፣ ወዘተ እናውቃለን።

ግን ስርዓቱ ሊሰፋ የሚችል ስለሆነ ለ MySQL መጠቀምም ይችላል። እና እንደዚህ አይነት ምሳሌዎች አሉ. Yandex ተመሳሳይ ነገር አለው, ግን የትም አያትሙትም. በ Yandex.Metrica ውስጥ ይጠቀማሉ. እና ስለ MySQL ታሪክ ብቻ አለ። ግን ቴክኖሎጂዎቹ ተመሳሳይ ናቸው, ZFS.

ለሪፖርቱ እናመሰግናለን! እኔም ሁለት ጥያቄዎች አሉኝ። ክሎኒንግ ለትንታኔ ጥቅም ላይ ሊውል እንደሚችል ጠቅሰዋል፣ ለምሳሌ እዚያ ተጨማሪ ኢንዴክሶችን ለመገንባት። እንዴት እንደሚሰራ ትንሽ ተጨማሪ መንገር ይችላሉ?

እና ወዲያውኑ ስለ ቋሚዎች ተመሳሳይነት, የእቅዶቹን ተመሳሳይነት ሁለተኛውን ጥያቄ እጠይቃለሁ. ዕቅዱ በ Postgres በተሰበሰበው ስታቲስቲክስ ላይም ይወሰናል. ይህን ችግር እንዴት ፈቱት?

እንደ ትንታኔው, ምንም ልዩ ጉዳዮች የሉም, ምክንያቱም እስካሁን አልተጠቀምንበትም, ግን እንደዚህ አይነት እድል አለ. ስለ ኢንዴክሶች እየተነጋገርን ከሆነ፣ ጥያቄው በመቶ ሚሊዮኖች የሚቆጠሩ መዝገቦችን እና አብዛኛውን ጊዜ በምርት ውስጥ ኢንዴክስ ያልተመዘገበበት አምድ ያለበትን ጠረጴዛ እያሳደደ እንደሆነ አስቡት። እና እዚያ አንዳንድ መረጃዎችን ማስላት እንፈልጋለን. ይህ ጥያቄ ወደ ፕሮድ ከተላከ፣ በፕሮድ ላይ ቀላል የመሆን እድሉ አለ፣ ምክንያቱም ጥያቄው ለአንድ ደቂቃ እዚያ ይካሄዳል።

እሺ፣ ለጥቂት ደቂቃዎች ለማቆም አስፈሪ ያልሆነ ቀጭን ክሎሎን እንስራ። እና ትንታኔውን ለማንበብ የበለጠ ምቹ ለማድረግ፣ መረጃን የምንፈልግባቸው አምዶች ጠቋሚዎችን እንጨምራለን ።

መረጃ ጠቋሚው በእያንዳንዱ ጊዜ ይፈጠራል?

መረጃውን እንድንነካ ፣ ቅጽበተ-ፎቶዎችን እንድንሰራ ፣ ከዚያ ከዚህ ቅጽበታዊ ገጽ እይታ እናገግማለን እና አዲስ ጥያቄዎችን እንነዳለን። ማለትም ፣ ቀደም ሲል በተለጠፈ ኢንዴክሶች አዳዲስ ክሎኖችን ከፍ ለማድረግ እንዲችሉ ማድረግ ይችላሉ።

ስለ ስታቲስቲክስ ጥያቄ, ከመጠባበቂያ ቅጂ ወደነበረበት ከመለስን, ብዜት ካደረግን, የእኛ ስታቲስቲክስ በትክክል አንድ አይነት ይሆናል. ሙሉውን የአካላዊ ዳታ መዋቅር ስላለን፣ ማለትም፣ በሁሉም የስታቲስቲክስ መለኪያዎችም ቢሆን ውሂቡን እናመጣለን።

እዚህ ሌላ ችግር አለ. የደመና መፍትሄን ከተጠቀሙ ሎጂካዊ ቆሻሻዎች ብቻ ይገኛሉ ምክንያቱም Google, Amazon አካላዊ ቅጂ እንዲወስዱ አይፈቅድልዎትም. ችግር ይኖራል።

ለሪፖርቱ እናመሰግናለን። ስለ MySQL እና ስለ ሀብት መጋራት ሁለት ጥሩ ጥያቄዎች እዚህ ነበሩ። ግን ፣ በእውነቱ ፣ ሁሉም የሚመጣው ይህ የተወሰነ የ DBMS ርዕስ አይደለም ፣ ግን የፋይል ስርዓቱ በአጠቃላይ። እናም በዚህ መሠረት የግብአት መጋራት ጉዳዮችም ከዚያ መፈታት አለባቸው፣ መጨረሻ ላይ Postgres አይደለም ፣ ግን በፋይል ስርዓቱ ፣ በአገልጋዩ ፣ ለምሳሌ።

የኔ ጥያቄ ትንሽ የተለየ ነው። ብዙ ንብርብሮች ባሉበት ወደ ባለ ብዙ ሽፋን የውሂብ ጎታ ቅርብ ነው. ለምሳሌ፣ የአስር ቴራባይት ምስል ማሻሻያ አዘጋጅተናል፣ እየደጋገምን ነው። እና ይህን መፍትሔ በተለይ ለዳታቤዝ እንጠቀማለን። ማባዛት በሂደት ላይ ነው፣ ውሂብ በመዘመን ላይ ነው። በትይዩ የሚሰሩ 100 ሰራተኞች አሉ, እነዚህ የተለያዩ ጥይቶችን ያለማቋረጥ እየጀመሩ ነው. ምን ለማድረግ? ግጭት አለመኖሩን እንዴት ማረጋገጥ እንደሚቻል, አንዱን እንደጀመሩ እና ከዚያ የፋይል ስርዓቱ ተቀይሯል, እና እነዚህ ምስሎች ሁሉም ሄዱ?

አይሄዱም ምክንያቱም ZFS የሚሰራው እንደዚህ ነው። በማባዛት ምክንያት የሚመጡትን የፋይል ስርዓት ለውጦችን በአንድ ክር ውስጥ በተናጠል ማቆየት እንችላለን። እና ገንቢዎች የሚጠቀሙባቸውን ክሎኖች በአሮጌው የውሂብ ስሪቶች ላይ ያቆዩ። እና ለእኛ ይሰራል, ሁሉም ነገር ከዚህ ጋር በቅደም ተከተል ነው.

ዝመናው እንደ ተጨማሪ ንብርብር ይከናወናል ፣ እና ሁሉም አዲስ ስዕሎች ቀድሞውኑ ይሄዳሉ ፣ በዚህ ንብርብር ላይ በመመስረት ፣ አይደል?

ከቀደምት ድግግሞሾች ከቀደምት ንብርብሮች.

የቀደሙት ንብርብሮች ይወድቃሉ, ነገር ግን የድሮውን ንብርብር ያመለክታሉ, እና በዝማኔው ውስጥ ከተቀበለው የመጨረሻው ንብርብር አዲስ ምስሎችን ይወስዳሉ?

በአጠቃላይ, አዎ.

ከዚያ በውጤቱ እስከ አንድ የበለስ ንብርብሮች ይኖረናል. እና ከጊዜ በኋላ መጨናነቅ ያስፈልጋቸዋል?

አዎ ሁሉም ነገር ትክክል ነው። አንዳንድ መስኮት አለ. ሳምንታዊ ቅጽበተ-ፎቶዎችን እናስቀምጣለን። ምን አይነት ሃብት እንዳለህ ይወሰናል። ብዙ ውሂብ የማከማቸት ችሎታ ካሎት, ቅጽበተ-ፎቶዎችን ለረጅም ጊዜ ማከማቸት ይችላሉ. በራሳቸው አይጠፉም። የውሂብ መበላሸት አይኖርም. ቅጽበተ-ፎቶዎቹ ጊዜ ያለፈባቸው ከሆነ, ለእኛ እንደሚመስለን, ማለትም በኩባንያው ውስጥ ባለው ፖሊሲ ላይ የተመሰረተ ነው, ከዚያም በቀላሉ መሰረዝ እና ቦታ ማስለቀቅ እንችላለን.

ሰላም ለሪፖርቱ አመሰግናለሁ! ስለ ጆ ጥያቄ። ደንበኛው ለሁሉም ሰው የመረጃውን መዳረሻ መስጠት እንደማይፈልግ ተናግረሃል። በትክክል መናገር፣ አንድ ሰው የማብራራት ትንተና ውጤት ካለው፣ ውሂቡን ማየት ይችላል።

እንደዛ ነው። ለምሳሌ፡-" ከ WHERE ኢሜይል = ወደዛ ምረጥ" ብለን መፃፍ እንችላለን። ያም ማለት ውሂቡን እራሱ አናየውም, ነገር ግን አንዳንድ ቀጥተኛ ያልሆኑ ምልክቶችን ማየት እንችላለን. ይህ መረዳት አለበት. ግን በሌላ በኩል, ሁሉም ነገር እዚያ ነው. የሎግ ኦዲት አለን ፣ ሌሎች ገንቢዎቹ ምን እየሰሩ እንደሆነ የሚመለከቱ ሌሎች ባልደረቦች ቁጥጥር አለን ። እና አንድ ሰው ይህን ለማድረግ ከሞከረ, የደህንነት አገልግሎቱ ወደ እነርሱ መጥቶ በዚህ ጉዳይ ላይ ይሰራል.

እንደምን አረፈድክ ለሪፖርቱ እናመሰግናለን! አጭር ጥያቄ አለኝ። ኩባንያው Slackን የማይጠቀም ከሆነ አሁን ከእሱ ጋር የሚያያዝ ነገር አለ ወይንስ ገንቢዎች የሙከራ መተግበሪያን ከመረጃ ቋቶች ጋር ለማገናኘት ምሳሌዎችን ማሰማራት ይቻል ይሆን?

አሁን ወደ Slack የሚያገናኝ አለ፣ ማለትም ሌላ መልእክተኛ የለም፣ ግን በእውነት ለሌሎች መልእክተኞችም ድጋፍ ማድረግ እፈልጋለሁ። ምን ማድረግ ትችላለህ? ዲቢ ላብ ያለ ጆ ማሰማራት ትችላለህ፣ በREST API እርዳታ ወይም በመድረክ እገዛ ሂድ እና ክሎኖችን መፍጠር እና ከPSQL ጋር መገናኘት ትችላለህ። ነገር ግን ይህ ለገንቢዎችዎ የውሂብ መዳረሻ ለመስጠት ዝግጁ ከሆኑ ይህን ማድረግ ይቻላል, ምክንያቱም ከአሁን በኋላ ምንም ማያ ገጽ አይኖርም.

ይህን ንብርብር አያስፈልገኝም, ግን እንደዚህ አይነት እድል እፈልጋለሁ.

ከዚያ አዎ, ማድረግ ይቻላል.

ምንጭ: hab.com