በ PostgreSQL በንዑስ ብርሃን ላይ እንጽፋለን፡ 1 አስተናጋጅ፣ 1 ቀን፣ 1 ቴባ

በቅርቡ እንዴት እንደነገርኩዎት, መደበኛ የምግብ አዘገጃጀት መመሪያዎችን በመጠቀም የ SQL ንባብ መጠይቆችን አፈፃፀም ያሳድጉ ከ PostgreSQL የውሂብ ጎታ. ዛሬ እንዴት እንደሆነ እንነጋገራለን መቅዳት የበለጠ ውጤታማ በሆነ መንገድ ሊከናወን ይችላል። በማዋቀር ውስጥ ምንም “ጠማማዎች” ሳይጠቀሙ በመረጃ ቋቱ ውስጥ - በቀላሉ የውሂብ ፍሰቶችን በትክክል በማደራጀት።

#1. ክፍል

እንዴት እና ለምን ማደራጀት ጠቃሚ እንደሆነ የሚገልጽ ጽሑፍ የተተገበረ ክፍፍል "በንድፈ ሀሳብ" ቀደም ሲል ነበር ፣ እዚህ በእኛ ውስጥ አንዳንድ አቀራረቦችን የመተግበር ልምድ እንነጋገራለን በመቶዎች ለሚቆጠሩ የ PostgreSQL አገልጋዮች የክትትል አገልግሎት.

"የቀን ነገሮች አልፈዋል..."

መጀመሪያ ላይ፣ ልክ እንደ ማንኛውም ኤምቪፒ፣ ፕሮጀክታችን በቀላል ሸክም ተጀምሯል - ክትትል የተደረገው ለአስር በጣም ወሳኝ አገልጋዮች ብቻ ነበር፣ ሁሉም ጠረጴዛዎች በአንጻራዊ ሁኔታ የታመቁ ነበሩ… , እና እንደገና ከአንዱ ጋር አንድ ነገር ለማድረግ ሞከርን ሰንጠረዦች 1.5TB በመጠንበዚህ መልኩ መኖር ቢቻልም በጣም የማይመች መሆኑን ተረድተናል።

ዘመኑ እንደ ልዩ ጊዜዎች ነበሩ፣ የተለያዩ የ PostgreSQL 9.x ስሪቶች ተዛማጅ ነበሩ፣ ስለዚህ ሁሉም ክፍፍል “በእጅ” መከናወን ነበረበት - በ የጠረጴዛ ውርስ እና ቀስቅሴዎች ከተለዋዋጭ ጋር ማዞር EXECUTE.

የተገኘው መፍትሔ ወደ ሁሉም ጠረጴዛዎች ሊተረጎም የሚችል በቂ የሆነ ሁለንተናዊ ሆነ።

• ባዶ “ራስጌ” የወላጅ ሠንጠረዥ ታውጇል፣ እሱም ሁሉንም የገለፀው። አስፈላጊ ኢንዴክሶች እና ቀስቅሴዎች.
• ከደንበኛው እይታ መዝገብ የተሰራው በ "ሥር" ሠንጠረዥ ውስጥ ነው, እና ከውስጥ ጥቅም ላይ ይውላል የማዞሪያ ቀስቅሴ BEFORE INSERT መዝገቡ "በአካል" ወደ አስፈላጊው ክፍል ገብቷል. እስካሁን እንደዚህ አይነት ነገር ከሌለ ልዩ ሁኔታ አጋጥሞናል እና...
• … በመጠቀም CREATE TABLE ... (LIKE ... INCLUDING ...) የተፈጠረው በወላጅ ጠረጴዛው አብነት ላይ በመመስረት ነው። በተፈለገው ቀን ላይ ገደብ ያለው ክፍልስለዚህ መረጃ ሲወጣ ንባብ በውስጡ ብቻ ይከናወናል.

PG10: የመጀመሪያ ሙከራ

ነገር ግን በውርስ መከፋፈል በታሪካዊ ንቁ የሆነ የፅሁፍ ዥረት ወይም ብዙ ቁጥር ያላቸውን የልጆች ክፍልፋዮችን ለመቋቋም ተስማሚ አይደለም። ለምሳሌ, አስፈላጊውን ክፍል ለመምረጥ ስልተ ቀመር እንደነበረው ማስታወስ ይችላሉ ኳድራቲክ ውስብስብነትከ100+ ክፍሎች ጋር እንደሚሰራ፣ እርስዎ እራስዎ እንዴት እንደሆነ ተረድተዋል።

በPG10 ይህ ሁኔታ ድጋፍን በመተግበር በጣም ተሻሽሏል። ቤተኛ ክፍፍል. ስለዚህ፣ ማከማቻውን ከተሸጋገርን በኋላ ወዲያውኑ ተግባራዊ ለማድረግ ሞከርን ነገር ግን...

በመመሪያው ውስጥ ከተቆፈረ በኋላ እንደታየው በዚህ ሥሪት ውስጥ ያለው ቤተኛ የተከፋፈለው ሰንጠረዥ የሚከተለው ነው-

• የመረጃ ጠቋሚ መግለጫዎችን አይደግፍም።
• በላዩ ላይ ቀስቅሴዎችን አይደግፍም
• የማንም “ዘር” ሊሆን አይችልም
• አትደግፉ INSERT ... ON CONFLICT
• ክፍል በራስ ሰር ማመንጨት አይችልም።

በግንባሩ ላይ በሬክ ላይ የሚያሰቃይ ድብደባ ከደረሰብን አፕሊኬሽኑን ሳናስተካክል ማድረግ እንደማይቻል ተረድተን ተጨማሪ ምርምር ለስድስት ወራት አራዝመናል።

PG10: ሁለተኛ ዕድል

ስለዚህ የተነሱትን ችግሮች አንድ በአንድ መፍታት ጀመርን።

1. ምክንያቱም ቀስቅሴዎች እና ON CONFLICT አሁንም እዚህም እዚያም እንደምናስፈልጋቸው ስላወቅን እነሱን ለመሥራት መካከለኛ መድረክ አዘጋጅተናል ተኪ ሰንጠረዥ.
2. ከ "ራውት" ተወግዷል ቀስቅሴዎች ውስጥ - ማለትም ከ EXECUTE.
3. ለየብቻ አወጡት። የአብነት ሰንጠረዥ ከሁሉም ኢንዴክሶች ጋርበፕሮክሲ ሠንጠረዥ ውስጥ እንኳን እንዳይገኙ.

በመጨረሻም, ከዚህ ሁሉ በኋላ, ዋናውን ጠረጴዛ በአገር ውስጥ ተከፋፍለን. አዲስ ክፍል መፍጠር አሁንም ለመተግበሪያው ህሊና የተተወ ነው።

"መጋዝ" መዝገበ ቃላት

እንደ ማንኛውም የትንታኔ ሥርዓት እኛ ደግሞ ነበረን። "እውነታዎች" እና "መቁረጥ" (መዝገበ ቃላት)። በእኛ ሁኔታ፣ በዚህ ተግባር ሠርተዋል፣ ለምሳሌ፣ አብነት አካል ተመሳሳይ ቀርፋፋ መጠይቆች ወይም የጥያቄው ጽሑፍ ራሱ።

"እውነታዎች" በቀን ለረጅም ጊዜ ተከፋፍለዋል, ስለዚህ በእርጋታ ጊዜ ያለፈባቸውን ክፍሎችን ሰርዘናል, እና አያስቸግሩንም (ምዝግብ ማስታወሻዎች!). ግን መዝገበ ቃላት ላይ ችግር ነበር...

ብዙዎቹ ነበሩ ለማለት ሳይሆን በግምት 100 ቴባ “እውነታዎች” 2.5TB መዝገበ ቃላትን አስገኝቷል።. ከእንደዚህ አይነት ጠረጴዛ ላይ ማንኛውንም ነገር በአመቺነት መሰረዝ አይችሉም, በበቂ ጊዜ መጭመቅ አይችሉም, እና ለእሱ መጻፍ ቀስ በቀስ ቀርፋፋ ሆነ.

እንደ መዝገበ ቃላት ... በውስጡ እያንዳንዱ ግቤት በትክክል አንድ ጊዜ መቅረብ አለበት ... ይህ ደግሞ ትክክል ነው, ግን! ለእያንዳንዱ ቀን የተለየ መዝገበ ቃላት! አዎ፣ ይህ የተወሰነ ድግግሞሽን ያመጣል፣ ግን ይፈቅዳል፡-

• በፍጥነት መጻፍ/አንብብ በትንሽ ክፍል መጠን ምክንያት
• ያነሰ የማስታወስ ፍጆታ ከታመቁ ኢንዴክሶች ጋር በመስራት
• ያነሰ ውሂብ ማከማቸት ጊዜው ያለፈበትን በፍጥነት የማስወገድ ችሎታ ምክንያት

በጠቅላላው ውስብስብ እርምጃዎች ምክንያት የሲፒዩ ጭነት በ ~ 30% ፣ የዲስክ ጭነት በ ~ 50% ቀንሷል:

በተመሳሳይ ጊዜ, በትንሽ ጭነት ብቻ ወደ የውሂብ ጎታ ውስጥ በትክክል ተመሳሳይ ነገር መፃፍ ቀጠልን.

#2. የውሂብ ጎታ ዝግመተ ለውጥ እና እንደገና መፈጠር

ስለዚህ ባለን ነገር ላይ ተረጋጋን። እያንዳንዱ ቀን የራሱ ክፍል አለው ከመረጃ ጋር። በእውነቱ፣ CHECK (dt = '2018-10-12'::date) - እና የመከፋፈያ ቁልፍ እና መዝገብ በአንድ የተወሰነ ክፍል ውስጥ እንዲወድቅ ቅድመ ሁኔታ አለ.

በአገልግሎታችን ውስጥ ያሉት ሁሉም ሪፖርቶች በአንድ የተወሰነ ቀን አውድ ውስጥ የተገነቡ እንደመሆናቸው መጠን ከ "ያልተከፋፈሉ ጊዜያት" ጀምሮ ለእነርሱ ያሉት ጠቋሚዎች ሁሉም ዓይነት ናቸው. (አገልጋይ፣ ቀን፣ የፕላን አብነት), (አገልጋይ፣ ቀን፣ የእቅድ አንጓ), (ቀንየስህተት ክፍል፣ አገልጋይ)...

አሁን ግን በእያንዳንዱ ክፍል ላይ ይኖራሉ የእርስዎ ቅጂዎች እያንዳንዱ እንደዚህ ያለ ኢንዴክስ ... እና በእያንዳንዱ ክፍል ውስጥ ቀን ቋሚ ነው... አሁን እኛ በእያንዳንዱ እንደዚህ ኢንዴክስ ውስጥ እንዳለን ተገለጠ በቀላሉ ቋሚ አስገባ እንደ አንዱ መስክ, ይህም ድምጹን እና ለእሱ የፍለጋ ጊዜን ይጨምራል, ነገር ግን ምንም ውጤት አያመጣም. ሬኩሱን ለራሳቸው ትተውት ውይ...

የማመቻቸት አቅጣጫ ግልጽ ነው - ቀላል የቀን መስኩን ከሁሉም ኢንዴክሶች ያስወግዱ በተከፋፈሉ ጠረጴዛዎች ላይ. ጥራዞችን ከሰጠን, ትርፉ ስለ ነው 1 ቴባ/ሳምንት!

አሁን ይህ ቴራባይት አሁንም በሆነ መንገድ መቅዳት እንዳለበት እናስተውል። ማለትም እኛ ደግሞ ዲስኩ አሁን ያነሰ መጫን አለበት! ይህ ሥዕል ለአንድ ሳምንት ያዋልነውን ከጽዳት የተገኘውን ውጤት በግልፅ ያሳያል፡-

#3. ከፍተኛውን ጭነት "በማሰራጨት" ላይ

ከተጫኑ ስርዓቶች ውስጥ አንዱ ትልቅ ችግር ነው ተደጋጋሚ ማመሳሰል አንዳንድ የማያስፈልጋቸው ክወናዎች. አንዳንድ ጊዜ "ምክንያቱም አላስተዋሉም", አንዳንድ ጊዜ "በዚያ መንገድ ቀላል ነበር", ነገር ግን ፈጥኖም ሆነ ዘግይቶ ማስወገድ አለብዎት.

የቀደመውን ምስል እናሳድግ እና ዲስክ እንዳለን እንይ ከጭነቱ በታች "ፓምፖች" በድርብ ስፋት በአጎራባች ናሙናዎች መካከል ፣ በግልጽ “በስታቲስቲክስ” እንደዚህ ባሉ በርካታ ኦፕሬሽኖች መከሰት የለበትም ።

ይህን ለማግኘት በጣም ቀላል ነው። መከታተል ጀምረናል ወደ 1000 የሚጠጉ አገልጋዮች, እያንዳንዱ በተለየ ሎጂካዊ ክር ነው የሚሰራው እና እያንዳንዱ ክር የተከማቸ መረጃን በተወሰነ ድግግሞሽ ወደ ዳታቤዝ እንዲላክ ያደርገዋል።

setInterval(sendToDB, interval)

እዚህ ያለው ችግር በትክክል በእውነታው ላይ ነው ሁሉም ክሮች በግምት በተመሳሳይ ጊዜ ይጀምራሉስለዚህ የመላኪያ ጊዜያቸው ሁልጊዜ ማለት ይቻላል “እስከ ነጥቡ” ጋር ይገጣጠማል። ውይ #2...

እንደ እድል ሆኖ, ይህ ለማስተካከል በጣም ቀላል ነው, "በዘፈቀደ" ሩጫ መጨመር በሰዓት

setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))

#4. የምንፈልገውን እናስቀምጣለን።

ሦስተኛው ባህላዊ የከፍተኛ ጭነት ችግር ነው። ምንም መሸጎጫ የለም የት ነው ያለው ይችላል መ ሆ ን.

ለምሳሌ፣ ከዕቅድ አንጓዎች አንፃር ለመተንተን አስችሎናል (እነዚህ ሁሉ Seq Scan on users), ግን ወዲያውኑ እነሱ በአብዛኛው ተመሳሳይ ናቸው ብለው ያስቡ - ረስተዋል.

አይ ፣ በእርግጥ ፣ እንደገና ወደ ዳታቤዝ ምንም ነገር አልተጻፈም ፣ ይህ ቀስቅሴውን ያቋርጣል INSERT ... ON CONFLICT DO NOTHING. ነገር ግን ይህ ውሂብ አሁንም የውሂብ ጎታ ላይ ይደርሳል, እና አላስፈላጊ ነው ግጭትን ለማጣራት ማንበብ ማድረግ አለበት. ውይ #3...

መሸጎጫ ከመሰራቱ በፊት/በኋላ ወደ ዳታቤዝ የተላኩት መዛግብት ብዛት ያለው ልዩነት ግልፅ ነው።

እና ይህ አብሮ የሚሄድ የማከማቻ ጭነት ጠብታ ነው።

ԸՆԴՀԱՆՈՒՐ ԳԻՆ

"ቴራባይት-በቀን" አስፈሪ ይመስላል። ሁሉንም ነገር በትክክል ካደረጉ, ይህ ብቻ ነው 2 ^ 40 ባይት / 86400 ሰከንድ = ~ 12.5 ሜባ / ሰእንኳን የዴስክቶፕ IDE ብሎኖች ተይዘዋል. 🙂

ግን በቁም ነገር ፣ በቀን ውስጥ በአስር እጥፍ “skew” ጭነት እንኳን ፣ የዘመናዊ ኤስኤስዲዎችን ችሎታዎች በቀላሉ ማሟላት ይችላሉ።

ምንጭ: hab.com