ውድ DELETE። ኒኮላይ ሳሞክቫሎቭ (Postgres.ai)

ከተወሰነ ጊዜ በኋላ፣ አላስፈላጊ መረጃዎችን በራስ ሰር ማስወገድ ከዲቢኤምኤስ [1] አስፈላጊ ተግባራት ውስጥ አንዱ ይሆናል። እስከዚያው ድረስ፣ እኛ እራሳችን አላስፈላጊ መረጃዎችን ለመሰረዝ ወይም ለማንቀሳቀስ ብዙ ወጪ የማይጠይቁ የማከማቻ ስርዓቶችን መንከባከብ አለብን። ጥቂት ሚሊዮን ረድፎችን ለመሰረዝ ወስነሃል እንበል። በትክክል ቀላል ተግባር ፣ በተለይም ሁኔታው ​​​​የሚታወቅ ከሆነ እና ተስማሚ ኢንዴክስ ካለ። "ከሠንጠረዥ 1 ሰርዝ col1 = : እሴት" - ምን ቀላል ሊሆን ይችላል, ትክክል?

ቪዲዮ

• ከመጀመሪያው ዓመት ጀምሮ ማለትም ከ2007 ጀምሮ በሃይሎድ ፕሮግራም ኮሚቴ ውስጥ ነኝ።

• እና ከ2005 ጀምሮ ከፖስትግሬስ ጋር ነበርኩ። በብዙ ፕሮጀክቶች ውስጥ ተጠቅሞበታል.

• ከ 2007 ጀምሮ ከRuPostges ጋር ይመድቡ።

• በMetup ወደ 2100+ ተሳታፊዎች አድገናል። በሳን ፍራንሲስኮ ለረጅም ጊዜ ከኒውዮርክ ቀጥሎ በአለም ሁለተኛ ነው።

• ካሊፎርኒያ ውስጥ ለብዙ ዓመታት ኖሬአለሁ። ትልልቅ ኩባንያዎችን ጨምሮ ከአሜሪካ ኩባንያዎች ጋር የበለጠ እሰራለሁ። የ Postgres ንቁ ተጠቃሚዎች ናቸው። እና ሁሉም አይነት አስደሳች ነገሮች አሉ.

https://postgres.ai/ የእኔ ኩባንያ ነው. የእድገት መዘግየቶችን የሚያስወግዱ ስራዎችን በራስ ሰር የማዘጋጀት ስራ ላይ ነን።

የሆነ ነገር እየሰሩ ከሆነ፣ አንዳንድ ጊዜ በፖስትግሬስ አካባቢ አንዳንድ አይነት መሰኪያዎች አሉ። አስተዳዳሪው የመሞከሪያ ቦታ እስኪያዘጋጅልዎት መጠበቅ አለቦት ወይም DBA ምላሽ እስኪሰጥ መጠበቅ አለቦት እንበል። እና በልማት, በሙከራ እና በአስተዳደር ሂደት ውስጥ እንደዚህ ያሉ ማነቆዎችን እናገኛለን እና በአውቶሜሽን እና በአዳዲስ አቀራረቦች እገዛ እነሱን ለማስወገድ እንሞክራለን.

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

በቅርቡ በሎስ አንጀለስ VLDB ነበርኩ። ይህ በመረጃ ቋቶች ላይ ትልቁ ኮንፈረንስ ነው። እና ወደፊት DBMS ማከማቸት ብቻ ሳይሆን ውሂብን በራስ-ሰር እንደሚሰርዝ አንድ ሪፖርት ነበር። ይህ አዲስ ርዕስ ነው።

በዜታባይት ዓለም ውስጥ ብዙ እና ብዙ መረጃዎች አሉ - ያ 1 petabytes ነው። እና አሁን በዓለም ላይ የተከማቸ ከ000 በላይ ዜታባይት መረጃ እንዳለን ይገመታል። እና ከእነሱ የበለጠ እና ብዙ ናቸው.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

እና ምን ይደረግ? መወገድ እንዳለበት ግልጽ ነው። የዚህ አስደሳች ዘገባ ማገናኛ እነሆ። ግን እስካሁን ይህ በዲቢኤምኤስ ውስጥ አልተተገበረም።

ገንዘብ መቁጠር የሚችሉ ሁለት ነገሮችን ይፈልጋሉ። እንድንሰርዝ ይፈልጋሉ፣ ስለዚህ በቴክኒካል እኛ ማድረግ መቻል አለብን።

ቀጥሎ የምናገረው ብዙ ተጨባጭ ሁኔታዎችን የሚያጠቃልል ረቂቅ ሁኔታን ነው፣ ማለትም በእኔ እና በዙሪያው ባሉ የውሂብ ጎታዎች ላይ ብዙ ጊዜ፣ ብዙ አመታት ያጋጠሙትን የተቀናበረ አይነት ነው። ራኮች በሁሉም ቦታ አሉ እና ሁሉም ሰው ሁል ጊዜ በእነሱ ላይ ይራመዳሉ።

እያደጉ ያሉ መሰረት ወይም በርካታ መሰረቶች አሉን እንበል። አንዳንድ መዝገቦች ደግሞ ቆሻሻዎች ናቸው። ለምሳሌ, ተጠቃሚው አንድ ነገር እዚያ ማድረግ ጀመረ, ነገር ግን አልጨረሰውም. እና ከተወሰነ ጊዜ በኋላ ይህ ያልተጠናቀቀ ከእንግዲህ ሊከማች እንደማይችል እናውቃለን። ማለትም፣ ቦታን ለመቆጠብ፣ አፈጻጸምን ለማሻሻል፣ ወዘተ አንዳንድ ቆሻሻ ነገሮችን ማጽዳት እንፈልጋለን።

በአጠቃላይ, ተግባሩ በተወሰኑ ሠንጠረዥ ውስጥ የተወሰኑ ነገሮችን, የተወሰኑ መስመሮችን በራስ ሰር መሰረዝ ነው.

እና እንደዚህ አይነት ጥያቄ አለን, ስለ ዛሬ የምንናገረው, ማለትም ስለ ቆሻሻ ማስወገጃ ነው.

አንድ ልምድ ያለው ገንቢ እንዲሰራ ጠይቀን ነበር። ይህንን ጥያቄ ወሰደ, ለራሱ ፈትሽ - ሁሉም ነገር ይሰራል. በመድረክ ላይ ተፈትኗል - ሁሉም ነገር ደህና ነው። ተዘርግቷል - ሁሉም ነገር ይሰራል. በቀን አንድ ጊዜ እናካሂዳለን - ሁሉም ነገር ደህና ነው.

የመረጃ ቋቱ ያድጋል እና ያድጋል። ዕለታዊ DELETE በትንሹ በትንሹ በዝግታ መስራት ይጀምራል።

ከዚያ አሁን የግብይት ኩባንያ እንዳለን እንረዳለን እና ትራፊኩ ብዙ እጥፍ እንደሚበልጥ እንረዳለን፣ ስለዚህ አላስፈላጊ ነገሮችን ለጊዜው ለማቆም ወስነናል። እና መመለስን ይረሱ።

ከጥቂት ወራት በኋላ አስታወሱ። እና ያ ገንቢ አቁሟል ወይም በሌላ ነገር ተጠምዷል፣ ሌላ እንዲመልስ አዘዘ።

እሱ በዴቭ ላይ ተመለከተ ፣ በዝግጅት ላይ - ሁሉም ነገር ደህና ነው። በተፈጥሮ, አሁንም የተጠራቀመውን ማጽዳት ያስፈልግዎታል. ሁሉም ነገር እንደሚሰራ አረጋግጧል።

ቀጥሎ ምን ይሆናል? ከዚያ ሁሉም ነገር ለእኛ ይፈርሳል። በአንድ ወቅት ሁሉም ነገር እንዲወድቅ ይወርዳል. ሁሉም ሰው በድንጋጤ ውስጥ ነው, እየሆነ ያለውን ማንም አይረዳም. እና ከዚያ ጉዳዩ በዚህ DELETE ውስጥ እንደነበረ ታወቀ።

የሆነ ስህተት ተከስቷል? ስህተት ሊፈጠር የሚችለውን ዝርዝር እነሆ። ከእነዚህ ውስጥ በጣም አስፈላጊ የሆነው የትኛው ነው?

• ለምሳሌ፣ ምንም ግምገማ አልነበረም፣ ማለትም የዲቢኤ ባለሙያው አላየውም። ወዲያውኑ ችግሩን በአንድ ልምድ ባለው ዓይን ያገኝ ነበር, እና በተጨማሪ, ብዙ ሚሊዮን መስመሮች የተጠራቀሙበትን ፕሮዳክሽን ማግኘት ይችላል.

• ምናልባት የሆነ ስህተት ፈትሸው ሊሆን ይችላል።

• ምናልባት ሃርድዌሩ ጊዜው አልፎበታል እና ይህን መሰረት ማሻሻል ያስፈልግዎታል.

• ወይም በመረጃ ቋቱ በራሱ የሆነ ችግር አለ እና ከፖስትግሬስ ወደ MySQL መሄድ አለብን።

• ወይም ምናልባት በቀዶ ጥገናው ላይ የሆነ ችግር አለ.

• ምናልባት በስራ ድርጅት ውስጥ አንዳንድ ስህተቶች ሊኖሩ ይችላሉ እና አንድን ሰው ማባረር እና ምርጥ ሰዎችን መቅጠር ያስፈልግዎታል?

የ DBA ቼክ አልነበረም። ዲቢኤ ካለ፣ እነዚህን በርካታ ሚሊዮን መስመሮች ያያቸዋል፣ እና ምንም አይነት ሙከራዎች ባይኖሩም እንኳ “ያን አያደርጉትም” ይላል። እንበል ይህ ኮድ በ GitLab፣ GitHub ውስጥ ከሆነ እና የኮድ ግምገማ ሂደት ካለ እና ያለ DBA ፈቃድ ይህ ክዋኔ በፕሮድ ላይ የሚከናወን አልነበረም፣ እናም በግልጽ DBA እንዲህ ይላል፡- “ይህ ማድረግ አይቻልም። ”

እና እሱ በዲስክ አይኦ ላይ ችግሮች ያጋጥምዎታል እና ሁሉም ሂደቶች ያበድላሉ ፣ መቆለፊያዎች ሊኖሩ ይችላሉ ፣ እና እንዲሁም ለብዙ ደቂቃዎች አውቶቫኪዩምን ያግዱታል ፣ ይህ ጥሩ አይደለም ።

http://bit.ly/nancy-hl2018-2

ሁለተኛው ስህተት - በተሳሳተ ቦታ ላይ ምልክት አድርገዋል. በፕሮድ ላይ ብዙ የቆሻሻ መጣያ መረጃዎች ሲከማቹ አይተናል ነገር ግን ገንቢው በዚህ ዳታቤዝ ውስጥ የተከማቸ መረጃ አልነበረውም እና ይህንን ቆሻሻ በማዘጋጀት ጊዜ የፈጠረው ማንም የለም። በዚህ መሠረት በፍጥነት የሚሰሩ 1 መስመሮች ነበሩ.

የእኛ ፈተናዎች ደካማ መሆናቸውን እንረዳለን, ማለትም የተገነባው ሂደት ችግሮችን አይይዝም. በቂ የዲቢ ሙከራ አልተደረገም።

ተስማሚ ሙከራ በተመሳሳዩ መሳሪያዎች ላይ ይመረጣል. ይህንን በተመሳሳዩ መሳሪያዎች ላይ ሁልጊዜ ማድረግ አይቻልም, ነገር ግን ሙሉ መጠን ያለው የውሂብ ጎታ ቅጂ መሆኑ በጣም አስፈላጊ ነው. ለብዙ ዓመታት እየሰበክኩት ያለሁት ይህንኑ ነው። እና ከአንድ አመት በፊት ስለዚህ ጉዳይ ተናግሬያለሁ, ሁሉንም በዩቲዩብ ላይ ማየት ይችላሉ.

ምናልባት የእኛ መሳሪያ መጥፎ ነው? ብመንጽር እዚ ቅልጡፍ ዝበለጸ እዩ። አጠቃቀሙ 100% መሆኑን አይተናል። በእርግጥ እነዚህ ዘመናዊ የNVMe ድራይቮች ከሆኑ ምናልባት ለእኛ በጣም ቀላል ይሆንልን ነበር። እና ምናልባት ከእሱ አንተኛም.

ደመናዎች ካሉዎት, ማሻሻያው በቀላሉ እዚያ ይከናወናል. በአዲሱ ሃርድዌር ላይ አዲስ ቅጂዎች ተነስተዋል። መቀየር. እና ሁሉም ነገር ደህና ነው። በጣም ቀላል።

ትንንሾቹን ዲስኮች እንደምንም መንካት ይቻላል? እና እዚህ፣ ልክ በዲቢኤ እርዳታ፣ ወደ አንድ የተወሰነ ርዕስ ውስጥ እንገባለን የፍተሻ ነጥብ ማስተካከያ። የፍተሻ ነጥብ ማስተካከያ አልነበረንም።

የፍተሻ ነጥብ ምንድን ነው? በማንኛውም ዲቢኤምኤስ ውስጥ ነው። የሚቀየር መረጃ በማህደረ ትውስታ ውስጥ ሲኖርዎት ወዲያውኑ ወደ ዲስክ አይፃፍም። ውሂቡ የተለወጠው መረጃ በመጀመሪያ ወደ ቀድሞ መዝገብ መዝገብ ይፃፋል። እና በአንድ ወቅት፣ ዲቢኤምኤስ እውነተኛ ገጾችን ወደ ዲስክ የምንጥልበት ጊዜ እንደሆነ ይወስናል፣ ስለዚህም ውድቀት ካጋጠመን፣ REDOን ያነሰ ማድረግ እንችላለን። ልክ እንደ አሻንጉሊት ነው. ከተገደልን ጨዋታውን ከመጨረሻው ፍተሻ እንጀምራለን ። እና ሁሉም ዲቢኤምኤስ ተግባራዊ ያደርጋሉ።

በ Postgres ውስጥ ያሉ ቅንብሮች ወደ ኋላ ቀርተዋል። የተነደፉት ከ10-15 አመት ለሆኑ የውሂብ መጠን እና ግብይቶች ነው። እና የፍተሻ ቦታ ምንም የተለየ አይደለም.

ከፖስትግሬስ የፍተሻ ዘገባ፣ ማለትም አውቶማቲክ የጤና ፍተሻ ያገኘነው መረጃ ይኸውና። እና የበርካታ ቴራባይት አንዳንድ የውሂብ ጎታ እዚህ አለ። እናም ወደ 90% ከሚሆኑት ጉዳዮች ውስጥ የግዳጅ ኬላዎችን እንደሚያስገድዱ በደንብ ማየት ይቻላል ።

ምን ማለት ነው? እዚያ ሁለት ቅንብሮች አሉ። የፍተሻ ነጥብ በጊዜ ማብቂያ ሊመጣ ይችላል፣ ለምሳሌ በ10 ደቂቃ። ወይም ብዙ ውሂብ ሲሞላ ሊመጣ ይችላል።

እና በነባሪ max_wal_saze ወደ 1 ጊጋባይት ተቀናብሯል። እንደ እውነቱ ከሆነ, ይህ በእውነቱ ከ 300-400 ሜጋባይት በኋላ በ Postgres ውስጥ ይከሰታል. በጣም ብዙ ውሂብ ቀይረሃል እና የፍተሻ ነጥብህ ይከሰታል።

እና ማንም ካላስተካከለው ፣ እና አገልግሎቱ እያደገ ፣ እና ኩባንያው ብዙ ገንዘብ ካገኘ ፣ ብዙ ግብይቶች አሉት ፣ ከዚያ የፍተሻ ነጥቡ በደቂቃ አንድ ጊዜ ፣ ​​አንዳንድ ጊዜ በየ 30 ሰከንድ እና አንዳንዴም መደራረብ ይመጣል። ይህ በጣም መጥፎ ነው።

እና ብዙ ጊዜ እየመጣ መሆኑን ማረጋገጥ አለብን። ማለትም፣ max_wal_sizeን ማሳደግ እንችላለን። እና ያነሰ በተደጋጋሚ ይመጣል.

ነገር ግን በትክክል እንዴት ማድረግ እንዳለብን አጠቃላይ ዘዴን አዘጋጅተናል, ማለትም, መቼቶችን ለመምረጥ እንዴት ውሳኔ ማድረግ እንደሚቻል, በተለየ መረጃ ላይ በግልፅ.

በዚህ መሠረት በመረጃ ቋቶች ላይ ሁለት ተከታታይ ሙከራዎችን እያደረግን ነው።

የመጀመሪያው ተከታታይ - max_wal_sizeን እንለውጣለን. እና ትልቅ ኦፕሬሽን እየሰራን ነው። በመጀመሪያ, በ 1 ጊጋባይት ነባሪ ቅንብር ላይ እናደርጋለን. እና ብዙ ሚሊዮኖች የሚቆጠር መስመሮችን አንድ ትልቅ DELETE እናደርጋለን።

ለእኛ ምን ያህል ከባድ እንደሆነ ማየት ይችላሉ. ዲስክ IO በጣም መጥፎ መሆኑን እናያለን. ምን ያህል WAL እንዳፈጠርን እንመለከታለን፣ ምክንያቱም ይህ በጣም አስፈላጊ ነው። የፍተሻ ነጥቡ ስንት ጊዜ እንደተከሰተ እንይ። እና ጥሩ እንዳልሆነ እናያለን.

በመቀጠል max_wal_sizeን እንጨምራለን. እንደግመዋለን. እንጨምራለን, እንደጋግማለን. እና ብዙ ጊዜ። በመርህ ደረጃ, 10, 1, 2, 4 ጊጋባይት 8 ነጥብ ጥሩ ነው. እና የአንድ የተወሰነ ስርዓት ባህሪን እንመለከታለን. እዚህ መሳሪያዎቹ እንደ ፕሮድ ላይ መሆን እንዳለባቸው ግልጽ ነው. ተመሳሳይ ዲስኮች፣ ተመሳሳይ የማህደረ ትውስታ መጠን እና ተመሳሳይ የፖስትግሬስ መቼቶች ሊኖሩዎት ይገባል።

እናም በዚህ መንገድ ስርዓታችንን እንለዋወጣለን፣ እና DBMS መጥፎ የጅምላ ሰርዝ በሚፈጠርበት ጊዜ እንዴት እንደሚታይ፣ እንዴት እንደሚፈተሽ እናውቃለን።

በሩሲያኛ የፍተሻ ነጥብ የፍተሻ ቦታዎች ናቸው።

ምሳሌ፡- በርካታ ሚሊዮን ረድፎችን በመረጃ አጥፋ፣ ረድፎች በገጾች ላይ "ተበተኑ" ናቸው።

አንድ ምሳሌ እዚህ አለ። ይህ የተወሰነ መሠረት ነው። እና በነባሪው የ1 ጊጋባይት መቼት ለ max_wal_size፣ የእኛ ዲስኮች ለመቅዳት ወደ መደርደሪያ እንደሚሄዱ በጣም ግልፅ ነው። ይህ ሥዕል በጣም የታመመ ሕመምተኛ ዓይነተኛ ምልክት ነው, ማለትም, እሱ በእርግጥ መጥፎ ስሜት ተሰምቶት ነበር. እና አንድ ነጠላ ቀዶ ጥገና ነበር፣ ብዙ ሚሊዮን መስመሮች ያለው ሰርዝ ብቻ ነበር።

እንዲህ ዓይነቱ ቀዶ ጥገና በፕሮድ ውስጥ ከተፈቀደ, እኛ ዝም ብለን እንተኛለን, ምክንያቱም አንድ DELETE በመደርደሪያው ውስጥ እንደሚገድለን ግልጽ ነው.

በተጨማሪ, 16 ጊጋባይት, ጥርሶቹ ቀድሞውኑ እንደጠፉ ግልጽ ነው. ጥርሶች ቀድሞውኑ የተሻሉ ናቸው, ማለትም, ጣሪያውን እያንኳኳ ነው, ግን በጣም መጥፎ አይደለም. እዚያም የተወሰነ ነፃነት ነበረ። በቀኝ በኩል መዝገቡ ነው. እና የክወናዎች ብዛት - ሁለተኛው ግራፍ. እና 16 ጊጋባይት በሚሆነው ጊዜ ትንንሽ ቀላል መተንፈስ እንዳለብን ግልጽ ነው።

እና 64 ጊጋባይት ሙሉ በሙሉ የተሻለ ሆኖ ሊታይ በሚችልበት ቦታ. ቀድሞውኑ ጥርሶች ይነገራሉ, ሌሎች ስራዎችን ለመትረፍ እና በዲስክ አንድ ነገር ለማድረግ ብዙ እድሎች አሉ.

ለምን?

ወደ ዝርዝሮቹ በጥቂቱ እገባለሁ ፣ ግን ይህ ርዕስ ፣ የፍተሻ ነጥብ ማስተካከያ እንዴት እንደሚደረግ ፣ አጠቃላይ ዘገባን ሊያስከትል ይችላል ፣ ስለሆነም ብዙ አልጫንም ፣ ግን ምን ችግሮች እንዳሉ በጥቂቱ እዘረዝራለሁ ።

የፍተሻ ነጥቡ ብዙ ጊዜ የሚከሰት ከሆነ እና መስመሮቻችንን በቅደም ተከተል ካዘመንን ፣ ግን በመረጃ ጠቋሚ ፈልገን ፣ ይህም ጥሩ ነው ፣ ምክንያቱም ሙሉውን ጠረጴዛ ስለማንሰርዝ ፣ ከዚያ ምናልባት መጀመሪያ ላይ የመጀመሪያውን ገጽ ፣ ከዚያ ሺህኛውን ነካን ፣ እና ከዚያም ወደ መጀመሪያው ተመለሱ. እና በእነዚህ ጉብኝቶች መካከል ወደ መጀመሪያው ገጽ ፣ የፍተሻ ነጥብ ቀድሞውኑ ወደ ዲስክ አስቀምጦታል ፣ ከዚያ እንደገና ያስቀምጠዋል ፣ ምክንያቱም ለሁለተኛ ጊዜ ስለቆሸሸ።

እና የፍተሻ ቦታን ብዙ ጊዜ እንዲያድነው እናስገድደዋለን። ለእሱ ያልተደጋገሙ ስራዎች እንዴት እንደሚኖሩ።

ግን ያ ብቻ አይደለም። ገፆች በፖስትግሬስ 8 ኪሎባይት እና በሊኑክስ 4 ኪሎባይት ናቸው። እና ሙሉ_ገጽ_ይጽፋል። በነባሪ ነው የነቃው። እና ይሄ ትክክል ነው, ምክንያቱም ካጠፋነው, ከተበላሸ የገጹ ግማሽ ብቻ የሚድንበት አደጋ አለ.

ወደ ፊት ምዝግብ ማስታወሻው WAL የመፃፍ ባህሪው የፍተሻ ቦታ ሲኖረን እና ገጹን ለመጀመሪያ ጊዜ ስንቀይር, ሙሉው ገጽ ማለትም ሁሉም 8 ኪሎባይት ወደ ፊት መዝገብ ውስጥ ይገባል, ምንም እንኳን እኛ ብቻ ቀይረናል. መስመር, እሱም 100 ባይት ይመዝናል. እና ሙሉውን ገጽ መፃፍ አለብን.

በቀጣዮቹ ለውጦች, የተወሰነ tuple ብቻ ይኖራል, ግን ለመጀመሪያ ጊዜ ሁሉንም ነገር እንጽፋለን.

እናም, በዚህ መሠረት, የፍተሻ ነጥቡ እንደገና ከተከሰተ, ሁሉንም ነገር እንደገና ከባዶ መጀመር እና ሙሉውን ገጽ መግፋት አለብን. በተደጋጋሚ የፍተሻ ኬላዎች፣ በተመሳሳዩ ገፆች ውስጥ ስንራመድ ሙሉ_ገጽ_ይፃፋል = በርቷል ከሚችለው በላይ ይሆናል፣ ማለትም ብዙ WAL እናመነጫለን። ተጨማሪ ወደ ቅጂዎች፣ ወደ ማህደር፣ ወደ ዲስክ ይላካል።

እና, በዚህ መሰረት, ሁለት ድጋሚዎች አሉን.

የ max_wal_sizeን ከጨመርን ለሁለቱም የፍተሻ ነጥብ እና የዋል ጸሐፊ ቀላል እናደርገዋለን። እና ያ በጣም ጥሩ ነው።

ቴራባይት አስገብተን እንኑር። ምን መጥፎ ነው? ይህ መጥፎ ነው, ምክንያቱም ውድቀት ቢፈጠር, ለሰዓታት እንወጣለን, ምክንያቱም የፍተሻ ነጥቡ ከረጅም ጊዜ በፊት ስለነበረ እና ብዙ ነገር ተለውጧል. እና ይህን ሁሉ REDO ማድረግ አለብን። እና ስለዚህ ሁለተኛውን ተከታታይ ሙከራዎች እናደርጋለን.

ኦፕሬሽን እንሰራለን እና የፍተሻ ነጥቡ ሊጠናቀቅ ሲል እናያለን -9 Postgresን ሆን ብለን እንገድላለን።

እና ከዚያ በኋላ እንደገና እንጀምራለን, እና በዚህ መሳሪያ ላይ ምን ያህል ጊዜ እንደሚነሳ, ማለትም በዚህ መጥፎ ሁኔታ ውስጥ ምን ያህል እንደሚደግመው ይመልከቱ.

ሁኔታው መጥፎ መሆኑን ሁለት ጊዜ አስተውያለሁ. መጀመሪያ የፍተሻ ነጥቡ ከማለቁ በፊት ተበላሽተናል፣ ስለዚህ ብዙ ያጣናል። ሁለተኛ ደግሞ ትልቅ ቀዶ ጥገና ተደረገልን። እና የፍተሻ ኬላዎች በጊዜ ማብቂያ ላይ ከሆኑ፣ ምናልባት፣ ከመጨረሻው የፍተሻ ነጥብ ጀምሮ ያነሰ WAL ይፈጠር ነበር። ማለትም ድርብ ተሸናፊ ነው።

እንዲህ ዓይነቱን ሁኔታ ለተለያዩ የ max_wal_size መጠኖች እንለካለን እና max_wal_size 64 ጊጋባይት ከሆነ፣ በከፋ ሁኔታ ለ10 ደቂቃ እንደምንወጣ እንረዳለን። እኛ ደግሞ የሚስማማን ወይም አይስማማን ብለን እናስባለን። ይህ የንግድ ጥያቄ ነው። ይህንን ሥዕል ለንግድ ሥራ ውሳኔዎች ተጠያቂ ለሆኑ ሰዎች ማሳየት እና “ችግር ሲፈጠር ለምን ያህል ጊዜ መተኛት እንችላለን? ለ 3-5 ደቂቃዎች በጣም በከፋ ሁኔታ ውስጥ መተኛት እንችላለን? እና እርስዎ ውሳኔ ያደርጋሉ.

እና እዚህ አንድ አስደሳች ነጥብ አለ። በጉባኤው ላይ ስለ Patroni ሁለት ዘገባዎች አሉን። እና ምናልባት እየተጠቀሙበት ሊሆን ይችላል. ይህ ለ Postgres ራስ-ሰር አለመሳካት ነው። GitLab እና Data Egret ስለዚህ ጉዳይ ተናገሩ።

እና በ30 ሰከንድ ውስጥ የሚመጣ አውቶፋይሎቨር ካለህ ምናልባት ለ10 ደቂቃ መተኛት እንችላለን? ምክንያቱም በዚህ ነጥብ ወደ ቅጂው እንቀይራለን, እና ሁሉም ነገር ደህና ይሆናል. ይህ አጉል ነጥብ ነው። ግልፅ መልስ አላውቅም። ይህ ርዕስ በአደጋ ማገገም ላይ ብቻ እንዳልሆነ ይሰማኛል።

ከሽንፈት በኋላ ረጅም ማገገሚያ ካገኘን, በሌሎች ብዙ ሁኔታዎች ውስጥ ምቾት አይሰማንም. ለምሳሌ, በተመሳሳይ ሙከራዎች, አንድ ነገር ስናደርግ እና አንዳንድ ጊዜ ለ 10 ደቂቃዎች መጠበቅ አለብን.

አውቶፋይሎቨር ቢኖረንም አሁንም በጣም ሩቅ አልሄድም። እንደ 64, 100 ጊጋባይት ያሉ እሴቶች ጥሩ እሴቶች ናቸው. አንዳንድ ጊዜ ትንሽ መምረጥ እንኳን ጠቃሚ ነው። በአጠቃላይ ይህ ረቂቅ ሳይንስ ነው።

ድግግሞሾችን ለመስራት ለምሳሌ, max_wal_size =1, 8, የጅምላ ክዋኔውን ብዙ ጊዜ መድገም ያስፈልግዎታል. አደረከው. እና በተመሳሳይ መሰረት እንደገና ማድረግ ይፈልጋሉ, ነገር ግን ሁሉንም ነገር አስቀድመው ሰርዘዋል. ምን ለማድረግ?

በእንደዚህ ዓይነት ሁኔታዎች ውስጥ ለመድገም ምን እንደምናደርግ ስለ መፍትሄችን በኋላ እናገራለሁ ። እና ይህ በጣም ትክክለኛው አቀራረብ ነው።

በዚህ አጋጣሚ ግን እድለኞች ነበርን። እዚህ ላይ "BEGIN, Delete, Rollback" እንደሚለው ከሆነ ሰርዝን መድገም እንችላለን። ማለትም፣ እኛ እራሳችን ከሰረዝነው፣ ልንደግመው እንችላለን። እና በአካል እርስዎ ውሂቡ በተመሳሳይ ቦታ ላይ ይተኛሉ። ምንም እንኳን የሆድ እብጠት እንኳን አይሰማዎትም. እንደዚህ ባሉ DELETEs ላይ መደጋገም ትችላለህ።

ይህ ከROLLBACK ጋር ያለው ሰርዝ ለፍተሻ ነጥብ ማስተካከያ ተስማሚ ነው፣ ምንም እንኳን በትክክል የተዘረጋ የውሂብ ጎታ ቤተሙከራዎች ባይኖሩዎትም።

ከአንድ አምድ "i" ጋር አንድ ሳህን አደረግን. Postgres የመገልገያ አምዶች አሉት። በተለይ ካልተጠየቁ በስተቀር የማይታዩ ናቸው። እነዚህ፡- ctid፣ xmid፣ xmax ናቸው።

Ctid አካላዊ አድራሻ ነው። ዜሮ ገጽ፣ በገጹ ውስጥ የመጀመሪያው tuple።

ከROOLBACK በኋላ ቱፕል በተመሳሳይ ቦታ እንደቆየ ማየት ይቻላል. ማለትም ፣ እንደገና መሞከር እንችላለን ፣ እሱ በተመሳሳይ መንገድ ይሠራል። ዋናው ነገር ይህ ነው።

Xmax የ tuple ሞት ጊዜ ነው። ማህተም ተደርጎበታል፣ነገር ግን ፖስትግሬስ ግብይቱ እንደተመለሰ ያውቃል፣ስለዚህ 0 ከሆነ ወይም የተመለሰ ግብይት ምንም ለውጥ የለውም። ይህ የሚያሳየው በ DELETE ላይ መደጋገም እና የስርዓቱን ባህሪ የጅምላ ስራዎችን ማረጋገጥ እንደሚቻል ነው። ለድሆች የውሂብ ጎታ ቤተ ሙከራ ማድረግ ትችላለህ።

ይህ ስለ ፕሮግራም አውጪዎች ነው። ስለ ዲቢኤም እንዲሁ፣ ሁልጊዜ ፕሮግራመሮችን ለዚህ ይወቅሳሉ፡- “ለምንድን ነው ረጅም እና አስቸጋሪ ስራዎችን የምትሰራው?”። ይህ ሙሉ ለሙሉ የተለየ ቀጥ ያለ ርዕስ ነው። ድሮም አስተዳደር ነበር አሁን ደግሞ ልማት ይኖራል።

እንዳልከፋፈልን ግልጽ ነው። ግልጽ ነው። በሚሊዮን ለሚቆጠሩ መስመሮች እንዲህ ያለውን DELETE እንዳይሰብር ማድረግ አይቻልም። ለ 20 ደቂቃዎች ይከናወናል, እና ሁሉም ነገር ይተኛል. ግን በሚያሳዝን ሁኔታ, ልምድ ያላቸው ገንቢዎች እንኳን በጣም ትልቅ በሆኑ ኩባንያዎች ውስጥ እንኳን ሳይቀር ስህተቶችን ያደርጋሉ.

ለምን መስበር አስፈላጊ ነው?

• ዲስኩ ከባድ መሆኑን ከተመለከትን, እንግዲያውስ ፍጥነት እንቀዘቅዘው. ከተበላሸን ደግሞ ቆም ብለን ልንጨምር እንችላለን፣ ስሮትሊንግን እንቀንሳለን።

• እና ሌሎችን ለረጅም ጊዜ አናግድም። በአንዳንድ ሁኔታዎች ምንም አይደለም፣ ማንም የማይሰራውን እውነተኛ ቆሻሻ እየሰረዙ ከሆነ፣ ምናልባት ከአውቶቫክዩም ስራ በስተቀር ማንንም አያግዱም ፣ ምክንያቱም ግብይቱ እስኪጠናቀቅ ድረስ ይጠብቃል። ነገር ግን ሌላ ሰው ሊጠይቀው የሚችለውን ነገር ካስወገዱ, ከዚያም ይታገዳሉ, የሆነ ዓይነት ሰንሰለት ምላሽ ይኖራል. ረጅም ግብይቶች በድረ-ገጾች እና በሞባይል መተግበሪያዎች ላይ መወገድ አለባቸው.

https://postgres.ai/products/joe/

ይህ አስደሳች ነው። ብዙ ጊዜ ገንቢዎች "ምን ዓይነት ጥቅል መጠን መምረጥ አለብኝ?" ብለው ሲጠይቁ አይቻለሁ።

የጥቅሉ መጠን በትልቁ፣ የግብይቱ መጠን አነስተኛ እንደሚሆን ግልጽ ነው፣ ማለትም፣ ከግብይቶች ተጨማሪ ትርፍ። ግን በተመሳሳይ ጊዜ, ለዚህ ግብይት ጊዜው ይጨምራል.

በጣም ቀላል ህግ አለኝ፡ የምትችለውን ያህል ውሰድ፣ ነገር ግን executables በሰከንድ አትለፍ።

ለምን አንድ ሰከንድ? ማብራሪያው በጣም ቀላል እና ለሁሉም ሰው, ቴክኒካል ያልሆኑ ሰዎች እንኳን ሳይቀር ሊረዳ የሚችል ነው. ምላሽ እናያለን። 50 ሚሊሰከንዶች እንውሰድ. የሆነ ነገር ከተለወጠ ዓይናችን ምላሽ ይሰጣል. ያነሰ ከሆነ ፣ ከዚያ የበለጠ ከባድ። የሆነ ነገር ከ100 ሚሊሰከንዶች በኋላ ምላሽ ከሰጠ፣ ለምሳሌ፣ አይጤውን ጠቅ ካደረግክ፣ እና ከ100 ሚሊሰከንዶች በኋላ መልስ ከሰጠህ፣ ይህ ትንሽ መዘግየት ቀድሞውኑ ይሰማሃል። አንድ ሰከንድ አስቀድሞ እንደ ብሬክስ ነው የሚታወቀው።

በዚህ መሰረት የጅምላ ስራዎቻችንን በ10 ሰከንድ ፍንጣቂ ከሰበርን አንድን ሰው የመከልከል ስጋት አለን። እና ለጥቂት ሰከንዶች ይሰራል, እና ሰዎች አስቀድመው ያስተውላሉ. ስለዚህ, ከአንድ ሰከንድ በላይ ላለማድረግ እመርጣለሁ. ግን በተመሳሳይ ጊዜ, በጣም በጥሩ ሁኔታ አይከፋፍሉት, ምክንያቱም የግብይቱ ትርፍ የሚታይ ይሆናል. መሰረቱ የበለጠ ከባድ ይሆናል, እና ሌሎች የተለያዩ ችግሮች ሊፈጠሩ ይችላሉ.

የማሸጊያውን መጠን እንመርጣለን. በእያንዳንዱ ሁኔታ, በተለየ መንገድ ማድረግ እንችላለን. አውቶማቲክ ማድረግ ይቻላል. እና የአንድ ጥቅል ሂደት ውጤታማነት እርግጠኞች ነን። ማለትም፣ የአንድ ጥቅል ሰርዝ ወይም አፕዴት እናደርጋለን።

በነገራችን ላይ የማወራው ነገር ሁሉ ስለ DELETE ብቻ አይደለም። እንደገመቱት እነዚህ በመረጃ ላይ ያሉ ማንኛቸውም የጅምላ ስራዎች ናቸው።

እና እቅዱ በጣም ጥሩ እንደሆነ እናያለን. የኢንዴክስ ቅኝቱን ማየት ይችላሉ፣ ኢንዴክስ ብቻ ቅኝት እንኳን የተሻለ ነው። እና አነስተኛ መጠን ያለው መረጃ ተካቷል. እና ከአንድ ሰከንድ ያነሰ ጊዜ ይሞላል. ልዕለ

እና አሁንም መበላሸት እንደሌለ ማረጋገጥ አለብን. የመጀመሪያዎቹ እሽጎች በፍጥነት ሲሰሩ ይከሰታል, እና ከዚያ እየባሰ, እየባሰ ይሄዳል. ሂደቱ ብዙ መሞከር ስለሚያስፈልግዎ ነው. የውሂብ ጎታ ቤተ-ሙከራዎች ለዚህ ነው.

እና አሁንም በምርት ውስጥ ይህንን በትክክል ለመከተል የሚያስችለንን አንድ ነገር ማዘጋጀት አለብን. ለምሳሌ, በምዝግብ ማስታወሻው ውስጥ ሰዓቱን እንጽፋለን, አሁን ያለንበትን እና አሁን ማን እንደሰረዝን መጻፍ እንችላለን. እና ይህ በኋላ ምን እየሆነ እንዳለ ለመረዳት ያስችለናል. እና የሆነ ችግር ከተፈጠረ በፍጥነት ችግሩን ያግኙ።

የጥያቄዎችን ቅልጥፍና መፈተሽ ከፈለግን እና ብዙ ጊዜ መደጋገም ከፈለግን እንደ ባልደረባ ቦት ያለ ነገር አለ። እሱ አስቀድሞ ዝግጁ ነው። በየቀኑ በደርዘን የሚቆጠሩ ገንቢዎች ጥቅም ላይ ይውላል. እና በ 30 ሰከንድ ውስጥ ትልቅ የቴራባይት ዳታቤዝ በጥያቄ እንዴት እንደሚሰጥ ያውቃል የእራስዎ ቅጂ። እና እዚያ የሆነ ነገር መሰረዝ እና እንደገና አስጀምር ይበሉ እና እንደገና መሰረዝ ይችላሉ። በዚህ መንገድ ሙከራ ማድረግ ይችላሉ. ለዚህ ነገር ወደፊት አይቻለሁ። እኛ ደግሞ እያደረግን ነው።

https://docs.gitlab.com/ee/development/background_migrations.html

የመከፋፈል ስልቶች ምንድን ናቸው? በጥቅሉ ላይ ያሉ ገንቢዎች እየተጠቀሙባቸው ያሉ 3 የተለያዩ የመከፋፈል ስልቶችን አይቻለሁ።

የመጀመሪያው በጣም ቀላል ነው. የቁጥር መታወቂያ አለን። እና በተለያዩ ክፍተቶች ከፋፍለን በዚያ እንስራ። ጉዳቱ ግልጽ ነው። በመጀመሪያው ክፍል ውስጥ 100 የእውነተኛ ቆሻሻ መስመሮች ሊኖረን ይችላል, በሁለተኛው 5 መስመር ላይ ወይም በጭራሽ አይደለም, ወይም ሁሉም 1 መስመሮች ቆሻሻ ይሆናሉ. በጣም ያልተስተካከለ ስራ, ግን ለመስበር ቀላል ነው. ከፍተኛውን መታወቂያ ወስደው ሰባበሩት። ይህ የዋህነት አካሄድ ነው።

ሁለተኛው ስትራቴጂ ሚዛናዊ አቀራረብ ነው። በ Gitlab ውስጥ ጥቅም ላይ ይውላል. ወስደው ጠረጴዛውን ቃኙት። እያንዳንዱ እሽግ በትክክል 10 መዛግብት እንዲኖረው የመታወቂያ ፓኬጆችን ወሰን አግኝተናል። እና ወረፋ ውስጥ አስቀምጣቸው. እና ከዚያ እንሰራለን. ይህንን በበርካታ ክሮች ውስጥ ማድረግ ይችላሉ.

በመጀመሪያው ስልት, በነገራችን ላይ, ይህንን በበርካታ ክሮች ውስጥ ማድረግ ይችላሉ. አስቸጋሪ አይደለም.

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

ግን ቀዝቃዛ እና የተሻለ አቀራረብ አለ. ይህ ሦስተኛው ስትራቴጂ ነው። እና ከተቻለ, እሱን መምረጥ የተሻለ ነው. ይህንን የምናደርገው በልዩ ኢንዴክስ መሰረት ነው. በዚህ ጉዳይ ላይ እንደ ቆሻሻ ሁኔታችን እና መታወቂያችን ምናልባት ኢንዴክስ ይሆናል። ወደ ክምር እንዳንሄድ ኢንዴክስ ብቻ ስካን እንዲሆን መታወቂያውን እናጨምረዋለን።

በአጠቃላይ የመረጃ ጠቋሚ ብቻ ፍተሻ ከመረጃ ጠቋሚ ፍተሻ የበለጠ ፈጣን ነው።

እና ማስወገድ የምንፈልገውን መታወቂያችንን በፍጥነት እናገኛለን። BATCH_SIZE አስቀድመን እንመርጣለን። እና እነሱን ብቻ ሳይሆን በልዩ መንገድ እናገኛቸዋለን እና ወዲያውኑ እንሰርባቸዋለን። እኛ ግን እየቆለፍን ያለነው ቀድሞውንም ከተቆለፉ ልንቆልፋቸው ሳይሆን ቀጥለን ቀጥለን እንውሰድ። ይህ ለዝማኔ መዝለል ተቆልፏል። ይህ የ Postgres ሱፐር ባህሪ ከፈለግን በበርካታ ክሮች ውስጥ እንድንሰራ ያስችለናል. በአንድ ዥረት ውስጥ ይቻላል. እና እዚህ CTE አለ - ይህ አንድ ጥያቄ ነው። እና በዚህ CTE ሁለተኛ ፎቅ ላይ እውነተኛ ስረዛ አለን - returning *. መታወቂያውን መመለስ ይችላሉ ፣ ግን የተሻለ ነው። *በእያንዳንዱ መስመር ላይ ብዙ ውሂብ ከሌልዎት.

ለምን ያስፈልገናል? መልሰን ሪፖርት ማድረግ ያለብን ይህ ነው። አሁን በእውነቱ ብዙ መስመሮችን ሰርዘናል። እኛ ደግሞ በመታወቂያ ወይም በተፈጠረ_እንዲህ አይነት ድንበር አለን። ደቂቃ፣ ቢበዛ ማድረግ ትችላለህ። ሌላ ነገር ማድረግ ይቻላል. እዚህ ብዙ ነገሮችን ማድረግ ይችላሉ. እና ለክትትል በጣም ምቹ ነው.

ስለ መረጃ ጠቋሚው አንድ ተጨማሪ ማስታወሻ አለ. ለዚህ ተግባር ልዩ መረጃ ጠቋሚ እንደሚያስፈልገን ከወሰንን የ tuples ዝማኔዎችን ብቻ እንዳያበላሽ ማረጋገጥ አለብን። ያም ማለት ፖስትግሬስ እንደዚህ አይነት ስታቲስቲክስ አለው. ይህ ለጠረጴዛዎ በpg_stat_user_tables ላይ ሊታይ ይችላል። ትኩስ ዝመናዎች ጥቅም ላይ እየዋሉ እንደሆነ ወይም እንዳልሆኑ ማየት ይችላሉ።

አዲሱ መረጃ ጠቋሚዎ በቀላሉ ሊቆርጣቸው የሚችልባቸው ሁኔታዎች አሉ። እና አሁን እየሰሩ ያሉ ሌሎች ማሻሻያዎች አሉዎት፣ ፍጥነትዎን ይቀንሱ። መረጃ ጠቋሚው ስለታየ ብቻ አይደለም (እያንዳንዱ ኢንዴክስ ዝመናዎችን ትንሽ ይቀንሳል, ግን ትንሽ), ግን እዚህ አሁንም ያበላሸዋል. እና ለዚህ ጠረጴዛ ልዩ ማመቻቸት የማይቻል ነው. ይህ አንዳንድ ጊዜ ይከሰታል. ይህ ጥቂት ሰዎች የሚያስታውሱት ረቂቅ ነገር ነው። እና ይህ መሰቅሰቂያ ለመርገጥ ቀላል ነው። አንዳንድ ጊዜ ከሌላው ወገን አቀራረብ መፈለግ እና አሁንም ያለዚህ አዲስ መረጃ ጠቋሚ ማድረግ ወይም ሌላ ኢንዴክስ ማድረግ ወይም በሌላ መንገድ ለምሳሌ ሁለተኛውን ዘዴ መጠቀም ሲፈልጉ ይከሰታል።

ነገር ግን ይህ በጣም ጥሩው ስልት ነው፣ እንዴት በቡድን መከፋፈል እና በአንድ ጥያቄ በቡድን መተኮስ ፣ ትንሽ መሰረዝ ፣ ወዘተ.

ረጅም ግብይቶች https://gitlab.com/snippets/1890447

የታገደ አውቶቫክዩም - https://gitlab.com/snippets/1889668

የማገድ ጉዳይ - https://gitlab.com/snippets/1890428

ስህተት #5 ትልቅ ነው። ኒኮላይ ከኦክሜትር ስለ ፖስትግሬስ ክትትል ተናግሯል። Ideal Postgres ክትትል፣ በሚያሳዝን ሁኔታ፣ የለም። አንዳንዶቹ ቅርብ ናቸው፣ አንዳንዶቹ ደግሞ የራቁ ናቸው። ኦክሜትር ፍፁም ለመሆን ቅርብ ነው ፣ ግን ብዙ ጠፍተዋል እና መጨመር አለበት። ለዚህ ዝግጁ መሆን አለብዎት.

ለምሳሌ, የሞቱ ቱፕሎች በተሻለ ሁኔታ ክትትል ይደረግባቸዋል. በጠረጴዛው ውስጥ ብዙ የሞቱ ነገሮች ካሉ, የሆነ ችግር አለ. አሁን ምላሽ መስጠት የተሻለ ነው, አለበለዚያ ውርደት ሊኖር ይችላል, እና መተኛት እንችላለን. ያጋጥማል.

ትልቅ IO ካለ, ይህ ጥሩ እንዳልሆነ ግልጽ ነው.

ረጅም ግብይቶችም. ረጅም ግብይቶች በOLTP ላይ መፍቀድ የለባቸውም። እና ይህን ቅንጣቢ ለመውሰድ እና ረጅም ግብይቶችን ለመከታተል የሚያስችልዎ ወደ ቅንጣቢ የሚወስድ አገናኝ እዚህ አለ።

ረጅም ግብይቶች ለምን መጥፎ ናቸው? ምክንያቱም ሁሉም መቆለፊያዎች መጨረሻ ላይ ብቻ ይለቀቃሉ. እና ሁሉንም እንጨቃጨቃለን። በተጨማሪም፣ ለሁሉም ጠረጴዛዎች አውቶቫክዩምን እናግደዋለን። በፍፁም ጥሩ አይደለም። በቅጂው ላይ ትኩስ ተጠባባቂ የነቃ ቢሆንም፣ አሁንም መጥፎ ነው። በአጠቃላይ ረጅም ግብይቶችን ለማስወገድ የትም የተሻለ አይደለም.

ቫክዩም የሌላቸው ብዙ ጠረጴዛዎች ካሉን ታዲያ ማንቂያ ሊኖረን ይገባል። እዚህ እንዲህ ዓይነቱ ሁኔታ ይቻላል. በተዘዋዋሪ የአውቶቫክዩም ስራን ልንነካ እንችላለን። ይህ ትንሽ ያሻሻልኩት ከአቪቶ የተቀነጨበ ነው። እና በአውቶቫክዩም ያለንን ለማየት አስደሳች መሣሪያ ሆኖ ተገኘ። ለምሳሌ, አንዳንድ ጠረጴዛዎች እዚያ እየጠበቁ ናቸው እና ተራቸውን አይጠብቁም. እንዲሁም በክትትል ውስጥ ማስቀመጥ እና ማንቂያ ሊኖርዎት ይገባል.

እና ብሎኮችን ያወጣል። የማገጃ ዛፎች ጫካ. የሆነ ነገር ከአንድ ሰው ወስጄ ማሻሻል እወዳለሁ። እዚህ የተቆለፉ ዛፎችን ደን የሚያሳይ አሪፍ ተደጋጋሚ CTE ከዳታ ኢግሬት ወሰድኩ። ይህ ጥሩ የመመርመሪያ መሳሪያ ነው. እና በእሱ መሰረት, ክትትልን መገንባት ይችላሉ. ነገር ግን ይህ በጥንቃቄ መደረግ አለበት. ለራስህ ትንሽ መግለጫ_ጊዜ ማብቂያ ማድረግ አለብህ። እና የመቆለፊያ_ጊዜ ማብቂያ ተፈላጊ ነው።

አንዳንድ ጊዜ እነዚህ ሁሉ ስህተቶች በድምሩ ይከሰታሉ.

በእኔ አስተያየት እዚህ ላይ ዋናው ስህተት ድርጅታዊ ነው። ድርጅታዊ ነው, ምክንያቱም ቴክኒኩ አይጎተትም. ይህ ቁጥር 2 ነው - እነሱ በተሳሳተ ቦታ ላይ ምልክት አድርገዋል.

እኛ ትክክለኛ ያልሆነ ቦታ ላይ አረጋግጠናል ፣ ምክንያቱም የምርት ክሎሎን ስላልነበረን ፣ ለመፈተሽ ቀላል ነው። ገንቢ ጨርሶ የማምረት መዳረሻ ላይኖረው ይችላል።

እና እዚያ እንዳልሆነ አረጋገጥን. እዚያ ብናጣራው እራሳችን እናየው ነበር። ገንቢው አንድ አይነት የውሂብ መጠን እና ተመሳሳይ ቦታ ባለበት በጥሩ አካባቢ ላይ ከፈተሸ ያለ DBA እንኳን ሁሉንም አይቷል። ይህን ሁሉ ውርደት አይቶ ያፍር ነበር።

ስለ autovacuum ተጨማሪ። ብዙ ሚሊዮን መስመሮችን ከጠራርን በኋላ፣ አሁንም REPACK ማድረግ አለብን። ይህ በተለይ ለኢንዴክሶች አስፈላጊ ነው. ሁሉንም ነገር እዚያ ካጸዳን በኋላ መጥፎ ስሜት ይኖራቸዋል.

እና የዕለት ተዕለት የጽዳት ስራን መመለስ ከፈለጉ ፣ ከዚያ ብዙ ጊዜ እንዲያደርጉት ሀሳብ አቀርባለሁ ፣ ግን ትንሽ። በደቂቃ አንድ ጊዜ ወይም እንዲያውም ብዙ ጊዜ ትንሽ ሊሆን ይችላል. እና ሁለት ነገሮችን መከታተል ያስፈልግዎታል: ይህ ነገር ምንም ስህተት እንደሌለው እና ወደ ኋላ እንደማይዘገይ. እኔ ያሳየሁት ብልሃት ይህንን ብቻ ይፈታል።

እኛ የምናደርገው ክፍት ምንጭ ነው. በ GitLab ላይ ተለጠፈ። እና ሰዎች ያለ DBA እንኳን ማረጋገጥ እንዲችሉ እናደርጋለን። የውሂብ ጎታ ላብራቶሪ እየሰራን ነው, ማለትም, ጆ በአሁኑ ጊዜ እየሰራ ያለውን የመሠረት አካል ብለን እንጠራዋለን. እና የምርት ቅጂን መውሰድ ይችላሉ. አሁን የጆ ለስላክ አተገባበር አለ, እዚያ ማለት ይችላሉ: "እንዲህ ዓይነቱን እና እንደዚህ ያለ ጥያቄን ያብራሩ" እና ወዲያውኑ የውሂብ ጎታዎን ቅጂ ያግኙ. እዚያም መሰረዝ ትችላለህ፣ እና ማንም አያስተውለውም።

10 ቴራባይት አለህ እንበል፣ ዳታቤዝ ላብራቶሪም 10 ቴራባይት እንሰራለን። እና በአንድ ጊዜ በ10 ቴራባይት ዳታቤዝ፣ 10 ገንቢዎች በአንድ ጊዜ መስራት ይችላሉ። ሁሉም ሰው የፈለገውን ማድረግ ይችላል። መሰረዝ፣ መጣል፣ ወዘተ ይችላል። ያ እንደዚህ ያለ ቅዠት ነው። ስለዚህ ጉዳይ ነገ እንነጋገራለን.

ይህ ቀጭን አቅርቦት ይባላል. ይህ ስውር አቅርቦት ነው። ይህ በእድገት, በሙከራ ላይ መዘግየቶችን የሚያስወግድ እና በዚህ ረገድ ዓለምን የተሻለ ቦታ የሚያደርግ አንድ ዓይነት ቅዠት ነው. ያም ማለት በጅምላ ስራዎች ላይ ችግሮችን ለማስወገድ ብቻ ይፈቅድልዎታል.

ምሳሌ፡- 5 ቴራባይት ዳታቤዝ፣ ከ30 ሰከንድ ባነሰ ጊዜ ቅጂ ማግኘት። እና በመጠኑ ላይ እንኳን አይወሰንም, ማለትም, ስንት ቴራባይት ምንም አይደለም.

ዛሬ መሄድ ይችላሉ postgres.ai እና በመሳሪያዎቻችን ውስጥ ቆፍሩ. ምን እንዳለ ለማየት መመዝገብ ይችላሉ። ይህንን ቦት መጫን ይችላሉ. ነፃ ነው. ጻፍ።

ጥያቄዎች

በጣም ብዙ ጊዜ በእውነተኛ ሁኔታዎች ውስጥ በሰንጠረዡ ውስጥ መቆየት ያለበት መረጃ መሰረዝ ከሚያስፈልገው በጣም ያነሰ ነው. ያም ማለት በእንደዚህ ዓይነት ሁኔታ ውስጥ ብዙውን ጊዜ እንዲህ ዓይነቱን አቀራረብ መተግበር ቀላል ነው, አዲስ ነገር ለመፍጠር ቀላል በሚሆንበት ጊዜ, አስፈላጊውን ውሂብ እዚያ ብቻ ይቅዱ እና የድሮውን ጠረጴዛ ግንድ ያድርጉ. በዚህ ቅጽበት እርስዎ በሚቀይሩበት ጊዜ ፕሮግራማዊ አቀራረብ እንደሚያስፈልግ ግልጽ ነው። ይህ አካሄድ እንዴት ነው?

ይህ በጣም ጥሩ አቀራረብ እና በጣም ጥሩ ስራ ነው. pg_repack ከሚሰራው ጋር በጣም ተመሳሳይ ነው፣ መታወቂያ 4 ባይት ሲያደርጉ ማድረግ ካለቦት ጋር በጣም ተመሳሳይ ነው። ብዙ ማዕቀፎች ከጥቂት አመታት በፊት ይህን ያደርጉ ነበር, እና ሳህኖቹ ብቻ ያደጉ ናቸው, እና ወደ 8 ባይት መቀየር ያስፈልጋቸዋል.

ይህ ተግባር በጣም ከባድ ነው. አደረግነው. እና በጣም መጠንቀቅ አለብዎት. መቆለፊያዎች ወዘተ አሉ ግን እየተሰራ ነው. ማለትም፣ መደበኛው አካሄድ ከpg_repack ጋር መሄድ ነው። እንደዚህ አይነት መለያ ያውጃሉ። እና ቅጽበታዊ ውሂብን ወደ እሱ መስቀል ከመጀመርዎ በፊት ሁሉንም ለውጦች የሚከታተል አንድ ሳህን ያውጃሉ። አንዳንድ ለውጦችን እንኳን መከታተል የማይችሉበት ዘዴ አለ። ረቂቅ ነገሮች አሉ። እና ከዚያ ለውጦችን በማንከባለል ይቀየራሉ። ሁሉንም ሰው ስንዘጋው ለአጭር ጊዜ ቆም ይላል፣ በአጠቃላይ ግን ይህ እየተሰራ ነው።

በ GitHub ላይ pg_repackን ከተመለከቱ፣ እንግዲያውስ መታወቂያን ከ int 4 ወደ int 8 የመቀየር ተግባር በነበረበት ጊዜ pg_repackን በራሱ የመጠቀም ሀሳብ ነበር። ይህ ደግሞ ይቻላል, ነገር ግን ትንሽ መጥለፍ ነው, ነገር ግን ለዚህ ደግሞ ይሰራል. pg_repack በሚጠቀምበት ቀስቅሴ ውስጥ ጣልቃ ገብተህ እዚያ እንዲህ ማለት ትችላለህ፡- "ይህን ውሂብ አንፈልግም" ማለትም የምንፈልገውን ብቻ እናስተላልፋለን። እና ከዚያ ዝም ብሎ ይቀየራል እና ያ ነው።

በዚህ አቀራረብ, አሁንም የሠንጠረዡ ሁለተኛ ቅጂ እናገኛለን, ውሂቡ አስቀድሞ መረጃ ጠቋሚ እና በጣም በሚያምር ኢንዴክሶች የተደረደሩበት.

እብጠት የለም, ጥሩ አቀራረብ ነው. ግን ለዚህ አውቶማቲክን ለማዳበር ሙከራዎች እንዳሉ አውቃለሁ, ማለትም ሁለንተናዊ መፍትሄን ለመፍጠር. ከዚህ አውቶሜትድ ጋር ልገናኝህ እችላለሁ። በፓይዘን ነው የተጻፈው ይህም ጥሩ ነገር ነው።

እኔ ከ MySQL ዓለም ትንሽ ነኝ፣ ስለዚህ ለማዳመጥ መጣሁ። እና ይህን አካሄድ እንጠቀማለን.

ግን 90% ካለን ብቻ ነው። 5% ካለን, እሱን መጠቀም በጣም ጥሩ አይደለም.

ለሪፖርቱ እናመሰግናለን! የተሟላ የፕሮድ ቅጂ ለመስራት ምንም ሀብቶች ከሌሉ ጭነቱን ወይም መጠኑን ለማስላት ስልተ ቀመር ወይም ቀመር አለ?

ጥሩ ጥያቄ. እስካሁን፣ ባለብዙ ቴራባይት ዳታቤዝ ማግኘት ችለናል። ምንም እንኳን እዚያ ያለው ሃርድዌር ተመሳሳይ ባይሆንም ፣ ለምሳሌ ፣ አነስተኛ ማህደረ ትውስታ ፣ አነስተኛ ፕሮሰሰር እና ዲስኮች በትክክል ተመሳሳይ አይደሉም ፣ ግን አሁንም እናደርጋለን። ምንም ቦታ ከሌለ, ማሰብ ያስፈልግዎታል. እስከ ነገ ድረስ ላስብበት፣ መጣህ፣ እናወራለን፣ ይህ ጥሩ ጥያቄ ነው።

ለሪፖርቱ እናመሰግናለን! መጀመሪያ የጀመሩት አሪፍ ፖስትግሬስ እንዳለ ነው፣ እሱም እንደዚህ አይነት እና እንደዚህ ያሉ ገደቦች አሉት፣ ግን እያደገ ነው። እና ይህ ሁሉ በትልቅ እና ትልቅ ክራንች ነው. ይህ ሁሉ ከራሱ ከፖስትግሬስ እድገት ጋር የሚጋጭ አይደለምን ፣ በዚህ ውስጥ አንዳንድ DELETE ተከላካዮች በሚታዩበት ወይም ሌላ ነገር እዚህ በአንዳንድ እንግዳ መንገዶቻችን ለመቀባት እየሞከርን ያለነውን በዝቅተኛ ደረጃ መያዝ አለበት?

በአንድ ግብይት ውስጥ ብዙ መዝገቦችን ለመሰረዝ ወይም ለማዘመን በSQL ካልን፣ ታዲያ ፖስትግሬስ እንዴት እዚያ ሊያከፋፍለው ይችላል? በኦፕራሲዮኖች ውስጥ በአካል ውስን ነን። አሁንም ለረጅም ጊዜ እናደርገዋለን. እና በዚህ ጊዜ እንቆልፋለን, ወዘተ.

በመረጃ ጠቋሚዎች ተከናውኗል።

ተመሳሳዩ የፍተሻ ነጥብ ማስተካከያ በራስ-ሰር ሊሆን እንደሚችል መገመት እችላለሁ። አንድ ቀን ሊሆን ይችላል። ያኔ ግን ጥያቄው በትክክል አልገባኝም።

ጥያቄው እዚህ እና እዚያ የሚሄድ እና እዚህ የእናንተ ትይዩ የሆነ የእድገት ቬክተር አለ ወይ? እነዚያ። እስካሁን አላሰቡትም?

አሁን ጥቅም ላይ ሊውሉ ስለሚችሉት መርሆዎች ተናገርኩ. ሌላ ቦት አለ ናንሲ, በዚህ አማካኝነት አውቶማቲክ የፍተሻ ነጥብ ማስተካከያ ማድረግ ይችላሉ. አንድ ቀን በ Postgres ውስጥ ይሆናል? አላውቅም፣ ገና አልተነጋገረም። አሁንም ከዚያ በጣም ርቀናል. ነገር ግን አዳዲስ ስርዓቶችን የሚሠሩ ሳይንቲስቶች አሉ. እና ወደ አውቶማቲክ ኢንዴክሶች አስገቡን። እድገቶች አሉ። ለምሳሌ, ራስ-ሰር ማስተካከያን መመልከት ይችላሉ. መለኪያዎችን በራስ-ሰር ይመርጣል. ግን የፍተሻ ነጥብ ማስተካከያ አያደርግልህም። ማለትም፣ ለአፈጻጸም፣ ለሼል ቋት ወዘተ ያነሳል።

እና ለፍተሻ ነጥብ ማስተካከያ ይህንን ማድረግ ይችላሉ-ሺህ ክላስተር እና የተለያዩ ሃርድዌር ፣ በደመና ውስጥ የተለያዩ ምናባዊ ማሽኖች ካሉዎት የኛን ቦት መጠቀም ይችላሉ። ናንሲ አውቶማቲክ ማድረግ. እና max_wal_size በእርስዎ ዒላማ ቅንብሮች መሰረት በራስ-ሰር ይመረጣል። ግን እስካሁን ድረስ ይህ በዋናው ውስጥ እንኳን ቅርብ አይደለም ፣ በሚያሳዝን ሁኔታ።

እንደምን አረፈድክ ስለ ረጅም ግብይቶች አደገኛነት ተናግረሃል። ስረዛ ከሆነ አውቶቫክዩም እንደታገደ ተናግረሃል። ሌላስ እንዴት ይጎዳናል? ምክንያቱም የበለጠ እየተነጋገርን ያለነው ቦታን ስለመልቀቅ እና ለመጠቀም ስለመቻል ነው። ሌላ ምን ጎድሎናል?

Autovacuum ምናልባት እዚህ ትልቁ ችግር ላይሆን ይችላል። እና ረጅም ግብይት ሌሎች ግብይቶችን መቆለፍ ስለሚችል, ይህ ዕድል የበለጠ አደገኛ ነው. እሷ ልትገናኝም ላታገኝም ትችላለች። ከተገናኘች, ከዚያም በጣም መጥፎ ሊሆን ይችላል. እና በ autovacuum - ይህ ደግሞ ችግር ነው. በOLTP ውስጥ ከረጅም ግብይቶች ጋር ሁለት ችግሮች አሉ፡ መቆለፊያዎች እና አውቶቫኩም። እና ትኩስ የተጠባባቂ ግብረመልስ በብዜቱ ላይ የነቃ ከሆነ፣ አሁንም በጌታው ላይ አውቶቫክዩም መቆለፊያ ይደርስዎታል፣ ከቅጂው ይመጣል። ግን ቢያንስ መቆለፊያዎች አይኖሩም. እና loks ይሆናል. እየተነጋገርን ያለነው ስለ የውሂብ ለውጦች ነው, ስለዚህ መቆለፊያዎች እዚህ አስፈላጊ ነጥብ ናቸው. እና ይህ ሁሉ ለረጅም እና ለረጅም ጊዜ ከሆነ ከዚያ ብዙ እና ብዙ ግብይቶች ተቆልፈዋል። ሌሎችን ሊሰርቁ ይችላሉ። እና የሎክ ዛፎች ይታያሉ. ወደ ቅንጣቢው አገናኝ አቅርቤ ነበር። እና ይህ ችግር ከአውቶቫኪዩም ጋር ካለው ችግር በበለጠ ፍጥነት ይታያል ፣ ይህም ሊከማች ብቻ ይችላል።

ለሪፖርቱ እናመሰግናለን! ስህተት ሞከርክ በማለት ሪፖርትህን ጀምረሃል። ተመሳሳይ መሳሪያዎችን መውሰድ እንዳለብዎ ሃሳባችንን ቀጠልን, ከመሠረቱ ጋር በተመሳሳይ መንገድ. ለገንቢው መሠረት ሰጥተናል እንበል። እናም ጥያቄውን አሟልቷል. እና እሱ ደህና ይመስላል. ግን እሱ በቀጥታ አይፈትሽም ፣ ግን ለቀጥታ ፣ ለምሳሌ ፣ ከ 60-70% ጭነት አለን ። እና ይህን ማስተካከያ ብንጠቀምም, በጣም ጥሩ አይሰራም.

በቡድኑ ውስጥ ባለሙያ መኖሩ እና በእውነተኛ ዳራ ጭነት ምን እንደሚሆን የሚተነብዩ የ DBA ባለሙያዎችን መጠቀም አስፈላጊ ነው። ንጹህ ለውጦቻችንን ብቻ ስንነዳ, ምስሉን እናያለን. ነገር ግን የበለጠ የላቀ አቀራረብ, እንደገና ተመሳሳይ ነገር ስናደርግ, ነገር ግን በአምራችነት በተመሰለ ጭነት. በጣም አሪፍ ነው። እስከዚያ ድረስ ማደግ አለብህ. እንደ ትልቅ ሰው ነው። ያለንን ብቻ አይተናል እና በቂ ሀብቶች እንዳሉንም አይተናል። ጥሩ ጥያቄ ነው።

አስቀድመን የቆሻሻ ምርጫን በምንሠራበት ጊዜ እና ለምሳሌ የተሰረዘ ባንዲራ አለን

በ Postgres ውስጥ አውቶቫክዩም በራስ-ሰር የሚያደርገው ይህ ነው።

ኦህ፣ ያደርጋል?

አውቶቫክዩም ቆሻሻ ሰብሳቢ ነው።

እናመሰግናለን!

ለሪፖርቱ እናመሰግናለን! ሁሉም ቆሻሻዎች ከዋናው ጠረጴዛ አንድ ቦታ ወደ ጎን እንዲቆሽሹ ወዲያውኑ የውሂብ ጎታውን በመከፋፈል የመንደፍ አማራጭ አለ?

በእርግጥ አላቸው.

ታዲያ ጥቅም ላይ መዋል የሌለበት ጠረጴዛ ከዘጋን እራሳችንን መጠበቅ ይቻላል?

በእርግጥ አላቸው. ግን እንደ ዶሮ እና እንቁላል ጥያቄ ነው። ሁላችንም ወደፊት ምን እንደሚሆን ካወቅን, በእርግጥ, ሁሉንም ነገር አሪፍ እናደርጋለን. ነገር ግን ንግዱ እየተለወጠ ነው, አዲስ ዓምዶች, አዲስ ጥያቄዎች አሉ. እና ከዚያ - ኦው, ልናስወግደው እንፈልጋለን. ግን ይህ ተስማሚ ሁኔታ, በህይወት ውስጥ ይከሰታል, ግን ሁልጊዜ አይደለም. በአጠቃላይ ግን ጥሩ ሀሳብ ነው። ብቻ ይቁረጡ እና ያ ነው።

ምንጭ: hab.com