መግቢያ
ሀሎ. እኔ ningenMe ነኝ፣ የድር ገንቢ።
ርዕሱ እንደሚለው የኔ ታሪክ በ MySQL ውስጥ 300 ሚሊዮን መዝገቦችን በአካል የመሰረዝ ታሪክ ነው።
በዚህ ላይ ፍላጎት አደረብኝ, ስለዚህ ማስታወሻ (መመሪያዎችን) ለማድረግ ወሰንኩ.
ቤት - ማንቂያ
እኔ የምጠቀምበት እና የምይዘው ባች አገልጋይ ያለፈውን ወር መረጃ ከ MySQL በቀን አንድ ጊዜ የሚሰበስብ መደበኛ ሂደት አለው።
ብዙውን ጊዜ ይህ ሂደት በ 1 ሰዓት ውስጥ ይጠናቀቃል, ነገር ግን በዚህ ጊዜ ለ 7 እና ለ 8 ሰዓታት አልተጠናቀቀም, እና ማንቂያው ብቅ ማለት አላቆመም ...
ምክንያት መፈለግ
ሂደቱን እንደገና ለማስጀመር ሞከርኩ እና ምዝግቦቹን ለመመልከት ሞከርኩ, ነገር ግን ምንም ስህተት አላየሁም.
መጠይቁ በትክክል ተጠቁሟል። ነገር ግን ምን እየተከሰተ እንዳለ ሳስብ የመረጃ ቋቱ መጠን በጣም ትልቅ እንደሆነ ተረዳሁ።
hoge_table | 350'000'000 |350 ሚሊዮን መዝገቦች. መረጃ ጠቋሚ በትክክል የሚሰራ ይመስላል፣ በጣም ቀርፋፋ።
የሚፈለገው መረጃ መሰብሰብ በወር ወደ 12 መዛግብት ነበር። የመረጡት ትዕዛዝ ረጅም ጊዜ የወሰደ እና ግብይቱ ለረጅም ጊዜ ያልተፈጸመ ይመስላል።
DB
በመሰረቱ በየቀኑ ወደ 400 የሚጠጉ ምዝግቦች የሚያድግ ጠረጴዛ ነው። የመረጃ ቋቱ መረጃ መሰብሰብ የነበረበት ለመጨረሻው ወር ብቻ ነው፣ ስለዚህ ይህንን መጠን በትክክል ይቋቋማል ተብሎ ይጠበቃል፣ ግን በሚያሳዝን ሁኔታ የማሽከርከር ክዋኔው አልተካተተም።
ይህ ዳታቤዝ በእኔ አልተዘጋጀም። ከሌላ ገንቢ ተረክቤዋለሁ፣ ስለዚህ አሁንም እንደ ቴክኒካል ዕዳ ተሰማኝ።
በየቀኑ የሚያስገባው የውሂብ መጠን ትልቅ ሲሆን በመጨረሻም ገደቡ ላይ ሲደርስ አንድ ነጥብ መጣ። ከእንደዚህ አይነት ከፍተኛ መጠን ያለው መረጃ ጋር ሲሰራ እነሱን መለየት አስፈላጊ እንደሆነ ይገመታል, ግን ይህ, በሚያሳዝን ሁኔታ, አልተደረገም.
እና ከዚያ ወደ ተግባር ገባሁ።
እርማት
የመረጃ ቋቱን መጠን መቀነስ እና እሱን ለማስኬድ ጊዜን መቀነስ አመክንዮውን እራሱ ከመቀየር የበለጠ ምክንያታዊ ነበር።
300 ሚሊዮን መዝገቦችን ከሰረዙ ሁኔታው በከፍተኛ ሁኔታ መለወጥ አለበት, ስለዚህ ይህን ለማድረግ ወሰንኩ ... ኧረ ይህ በእርግጠኝነት ይሰራል ብዬ አስቤ ነበር.
ተግባር 1
አስተማማኝ ምትኬን በማዘጋጀት በመጨረሻ ጥያቄዎችን መላክ ጀመርኩ።
"ጥያቄ በመላክ ላይ"
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';"..."
"..."
“እም... መልስ የለም። ምናልባት ሂደቱ ረጅም ጊዜ ይወስዳል? ” - አሰብኩ ፣ ግን እንደዚያ ከሆነ ፣ ግራፋናን ተመለከትኩ እና የዲስክ ጭነት በጣም በፍጥነት እያደገ መሆኑን አየሁ።
“አደገኛ” ብዬ እንደገና አሰብኩ እና ወዲያውኑ ጥያቄውን አቆምኩ።
ተግባር 2
ሁሉንም ነገር ከመረመርኩ በኋላ, ሁሉንም ነገር በአንድ ጊዜ ለመሰረዝ የውሂብ መጠን በጣም ትልቅ እንደሆነ ተገነዘብኩ.
ወደ 1 የሚጠጉ መዝገቦችን ሊሰርዝ የሚችል ስክሪፕት ለመጻፍ ወሰንኩ እና ጀመርኩት።
"ስክሪፕቱን ተግባራዊ አደርጋለሁ"
"አሁን ይህ በእርግጠኝነት ይሰራል" ብዬ አሰብኩ።
ተግባር 3
ሁለተኛው ዘዴ ሠርቷል, ነገር ግን በጣም ጉልበት የሚጠይቅ ሆኖ ተገኝቷል.
ሁሉንም ነገር በጥንቃቄ ለማድረግ, ያለ አላስፈላጊ ነርቮች, ሁለት ሳምንታት ይወስዳል. ግን አሁንም ይህ ሁኔታ የአገልግሎት መስፈርቶቹን አያሟላም, ስለዚህ ከእሱ መውጣት ነበረብን.
ስለዚህ ለማድረግ የወሰንኩት ነገር ይኸውና፡-
ሠንጠረዡን ይቅዱ እና እንደገና ይሰይሙት
ካለፈው እርምጃ፣ ይህን ያህል መጠን ያለው ውሂብ መሰረዝ እኩል የሆነ ትልቅ ጭነት እንደሚፈጥር ተገነዘብኩ። ስለዚህ አስገባን ተጠቅሜ ከባዶ አዲስ ሠንጠረዥ ለመፍጠር ወሰንኩ እና የምሰርዘውን ውሂብ ወደ እሱ አንቀሳቅስ።
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|አዲሱን ሠንጠረዥ ከላይ ካለው ተመሳሳይ መጠን ካደረጉት ፣ የውሂብ ሂደት ፍጥነት እንዲሁ በ1/7 ፈጣን መሆን አለበት።
ሠንጠረዡን ከፈጠርኩ በኋላ ስሙን ከቀየርኩ በኋላ እንደ ዋና ጠረጴዛ መጠቀም ጀመርኩ. አሁን ጠረጴዛውን በ 300 ሚሊዮን መዝገቦች ከጣልኩ ሁሉም ነገር ጥሩ መሆን አለበት.
መቆራረጥ ወይም መጣል ከመሰረዝ ያነሰ ትርፍ እንደሚፈጥር ተረድቼ ይህን ዘዴ ለመጠቀም ወሰንኩ።
መገደል።
"ጥያቄ በመላክ ላይ"
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
"..."
"..."
"እም…?"
ተግባር 4
የቀደመው ሀሳብ ይሰራል ብዬ አስቤ ነበር፣ ነገር ግን የማስገባት ጥያቄውን ከላኩ በኋላ፣ በርካታ ስህተቶች ታዩ። MySQL ይቅር ባይ አይደለም።
አስቀድሜ በጣም ደክሞኝ ስለነበር ከአሁን በኋላ ይህን ማድረግ እንደማልፈልግ ማሰብ ጀመርኩ.
ተቀምጬ አሰብኩ እና ምናልባት ለአንድ ጊዜ ብዙ የማስገቢያ መጠይቆች እንዳሉ ተረዳሁ...
የመረጃ ቋቱ በ1 ቀን ውስጥ ሊያስኬደው የሚገባውን የውሂብ መጠን የማስገባት ጥያቄ ለመላክ ሞከርኩ። ተከሰተ!
ደህና፣ ከዚያ በኋላ ለተመሳሳይ የውሂብ መጠን ጥያቄዎችን መላክ እንቀጥላለን። የአንድ ወር ዋጋ ያለው መረጃን ማስወገድ ስለሚያስፈልገን ይህንን ክዋኔ ወደ 35 ጊዜ ያህል እንደግመዋለን.
ጠረጴዛን እንደገና በመሰየም ላይ
እዚህ ዕድል ከጎኔ ነበር፡ ሁሉም ነገር ያለችግር ሄደ።
ማንቂያ ጠፍቷል
ባች ማቀነባበሪያ ፍጥነት ጨምሯል።
ከዚህ ቀደም ይህ ሂደት አንድ ሰዓት ያህል ወስዷል, አሁን 2 ደቂቃ ያህል ይወስዳል.
ሁሉም ችግሮች እንደተፈቱ እርግጠኛ ከሆንኩ በኋላ 300 ሚሊዮን መዝገቦችን ጣልኩ። ጠረጴዛውን ሰረዝኩ እና እንደገና መወለድ ተሰማኝ።
ማጠቃለያ
በቡድን ሂደት ውስጥ የማሽከርከር ሂደት እንደጠፋ ተገነዘብኩ, እና ያ ዋናው ችግር ነበር. የዚህ ዓይነቱ የስነ-ህንፃ ስህተት ጊዜን ወደ ማጣት ያመራል.
ከመረጃ ቋቱ መዝገቦችን በሚሰርዙበት ጊዜ በመረጃ ማባዛት ወቅት ስለ ጭነቱ ያስባሉ? MySQL ከመጠን በላይ አንጫን።
በመረጃ ቋቶች ውስጥ ጠንቅቀው የሚያውቁ ሰዎች በእርግጠኝነት እንደዚህ አይነት ችግር አይገጥማቸውም. ለቀሪዎቻችሁ, ይህ ጽሑፍ ጠቃሚ ነበር ብዬ ተስፋ አደርጋለሁ.
ስላነበቡ እናመሰግናለን!
ይህን ጽሑፍ እንደወደዱት፣ ትርጉሙ ግልጽ እንደሆነ፣ ለእርስዎ ጠቃሚ እንደሆነ ከነገሩን በጣም ደስ ይለናል?
ምንጭ: hab.com