រឿងនៃការលុបរូបរាងកាយចំនួន 300 លានកំណត់ត្រានៅក្នុង MySQL

សេចក្តីណែនាំ

ជំរាបសួរ។ ខ្ញុំ​គឺ ningenMe អ្នក​បង្កើត​គេហទំព័រ។

ដូចដែលចំណងជើងបាននិយាយថារឿងរបស់ខ្ញុំគឺជារឿងនៃការលុប 300 លានកំណត់ត្រានៅក្នុង MySQL ។

ខ្ញុំ​ចាប់​អារម្មណ៍​នឹង​រឿង​នេះ ដូច្នេះ​ខ្ញុំ​បាន​សម្រេច​ចិត្ត​ធ្វើ​ការ​រំលឹក (សេចក្តី​ណែនាំ)។

ទំព័រដើម - ការជូនដំណឹង

ម៉ាស៊ីនមេបាច់ដែលខ្ញុំប្រើ និងថែទាំមានដំណើរការធម្មតាដែលប្រមូលទិន្នន័យកាលពីខែមុនពី MySQL ម្តងក្នុងមួយថ្ងៃ។

ជាធម្មតាដំណើរការនេះត្រូវបានបញ្ចប់ក្នុងរយៈពេលប្រហែល 1 ម៉ោង ប៉ុន្តែលើកនេះវាមិនបានបញ្ចប់រយៈពេល 7 ឬ 8 ម៉ោងទេ ហើយការជូនដំណឹងមិនបញ្ឈប់ការលេចឡើង ...

ការស្វែងរកមូលហេតុ

ខ្ញុំបានព្យាយាមចាប់ផ្តើមដំណើរការឡើងវិញ ហើយមើលកំណត់ហេតុ ប៉ុន្តែខ្ញុំមិនឃើញអ្វីខុសទេ។
សំណួរត្រូវបានដាក់លិបិក្រមយ៉ាងត្រឹមត្រូវ។ ប៉ុន្តែនៅពេលដែលខ្ញុំគិតអំពីអ្វីដែលកំពុងកើតឡើង ខ្ញុំបានដឹងថាទំហំមូលដ្ឋានទិន្នន័យមានទំហំធំណាស់។

hoge_table | 350'000'000 |

កំណត់ត្រា 350 លាន។ ការធ្វើលិបិក្រមហាក់ដូចជាដំណើរការត្រឹមត្រូវ គ្រាន់តែយឺតណាស់។

ការប្រមូលទិន្នន័យដែលត្រូវការក្នុងមួយខែគឺប្រហែល 12 កំណត់ត្រា។ វាហាក់បីដូចជាពាក្យបញ្ជាជ្រើសរើសចំណាយពេលយូរ ហើយប្រតិបត្តិការមិនត្រូវបានប្រតិបត្តិរយៈពេលយូរទេ។

DB

វាជាតារាងសំខាន់ដែលកើនឡើងប្រហែល 400 ធាតុជារៀងរាល់ថ្ងៃ។ មូលដ្ឋានទិន្នន័យត្រូវបានគេសន្មត់ថាប្រមូលទិន្នន័យសម្រាប់តែខែចុងក្រោយប៉ុណ្ណោះ ដូច្នេះហើយ វាត្រូវបានគេរំពឹងថាវានឹងទប់ទល់នឹងចំនួនទិន្នន័យនេះយ៉ាងពិតប្រាកដ ប៉ុន្តែជាអកុសល ប្រតិបត្តិការបង្វិលមិនត្រូវបានរួមបញ្ចូលទេ។

មូលដ្ឋានទិន្នន័យនេះមិនត្រូវបានបង្កើតឡើងដោយខ្ញុំទេ។ ខ្ញុំបានយកវាពីអ្នកអភិវឌ្ឍន៍ផ្សេងទៀត ដូច្នេះវានៅតែមានអារម្មណ៍ថាដូចជាបំណុលបច្ចេកទេស។

មានចំនុចមួយនៅពេលដែលបរិមាណនៃទិន្នន័យដែលបានបញ្ចូលប្រចាំថ្ងៃបានក្លាយជាធំ ហើយទីបំផុតឈានដល់ដែនកំណត់របស់វា។ វាត្រូវបានសន្មត់ថានៅពេលធ្វើការជាមួយទិន្នន័យដ៏ច្រើនបែបនេះ វានឹងចាំបាច់ក្នុងការបែងចែកពួកវា ប៉ុន្តែជាអកុសលវាមិនត្រូវបានធ្វើទេ។

ហើយបន្ទាប់មកខ្ញុំបានចូលទៅក្នុងសកម្មភាព។

ការកែតម្រូវ

វាសមហេតុផលជាងក្នុងការកាត់បន្ថយទំហំនៃមូលដ្ឋានទិន្នន័យខ្លួនឯង និងកាត់បន្ថយពេលវេលាសម្រាប់ដំណើរការវា ជាជាងការផ្លាស់ប្តូរតក្កវិជ្ជាខ្លួនឯង។

ស្ថានភាពគួរតែផ្លាស់ប្តូរយ៉ាងខ្លាំង ប្រសិនបើអ្នកលុបកំណត់ត្រាចំនួន 300 លាន ដូច្នេះខ្ញុំបានសម្រេចចិត្តធ្វើដូច្នេះ... អេ ខ្ញុំគិតថាវាប្រាកដជាដំណើរការ។

សកម្មភាព ១

ដោយបានរៀបចំការបម្រុងទុកដែលអាចទុកចិត្តបាន ទីបំផុតខ្ញុំបានចាប់ផ្តើមផ្ញើសំណើ។

"ផ្ញើសំណើរ"

DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';

「…」

「…」

“ហ៊ឺ… គ្មានចម្លើយទេ។ ប្រហែលជាដំណើរការនេះចំណាយពេលយូរ? - ខ្ញុំបានគិត ប៉ុន្តែគ្រាន់តែក្នុងករណី ខ្ញុំបានក្រឡេកមើល grafana ហើយឃើញថាការផ្ទុកថាសកំពុងកើនឡើងយ៉ាងឆាប់រហ័ស។
“គ្រោះថ្នាក់” ខ្ញុំបានគិតម្តងទៀត ហើយបញ្ឈប់សំណើរភ្លាមៗ។

សកម្មភាព ១

បន្ទាប់​ពី​វិភាគ​គ្រប់​យ៉ាង ខ្ញុំ​បាន​ដឹង​ថា​ទំហំ​ទិន្នន័យ​ធំ​ពេក​ក្នុង​ការ​លុប​អ្វីៗ​ទាំង​អស់​ក្នុង​ពេល​តែ​មួយ។

ខ្ញុំបានសម្រេចចិត្តសរសេរស្គ្រីបដែលអាចលុបកំណត់ត្រាប្រហែល 1 ហើយបើកដំណើរការវា។

"ខ្ញុំអនុវត្តស្គ្រីប"

ខ្ញុំ​បាន​គិត​ថា​៖ «​ឥឡូវ​នេះ​វា​ប្រាកដ​ជា​ដំណើរការ​ហើយ​»។

សកម្មភាព ១

វិធីសាស្រ្តទីពីរបានដំណើរការ ប៉ុន្តែបានប្រែក្លាយថាប្រើកម្លាំងពលកម្មខ្លាំង។
ដើម្បីធ្វើអ្វីៗគ្រប់យ៉ាងដោយប្រុងប្រយ័ត្នដោយគ្មានសរសៃប្រសាទដែលមិនចាំបាច់នឹងចំណាយពេលប្រហែលពីរសប្តាហ៍។ ប៉ុន្តែនៅតែ សេណារីយ៉ូនេះមិនបានបំពេញតាមតម្រូវការនៃសេវាកម្ម ដូច្នេះយើងត្រូវផ្លាស់ទីឆ្ងាយពីវា។

ដូច្នេះ នេះជាអ្វីដែលខ្ញុំបានសម្រេចចិត្តធ្វើ៖

ចម្លងតារាងហើយប្តូរឈ្មោះវា។

ពីជំហានមុន ខ្ញុំបានដឹងថាការលុបទិន្នន័យដ៏ច្រើនបែបនេះបង្កើតបន្ទុកធំស្មើៗគ្នា។ ដូច្នេះខ្ញុំបានសម្រេចចិត្តបង្កើតតារាងថ្មីមួយពីដំបូងដោយប្រើបញ្ចូល និងផ្លាស់ទីទិន្នន័យដែលខ្ញុំនឹងលុបទៅក្នុងវា។

| 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';

「…」
「…」
"អេម...?"

សកម្មភាព ១

ខ្ញុំគិតថាគំនិតពីមុននឹងដំណើរការ ប៉ុន្តែបន្ទាប់ពីផ្ញើសំណើបញ្ចូល កំហុសជាច្រើនបានលេចចេញមក។ MySQL មិនអត់ទោសទេ។

ខ្ញុំ​ហត់​ហើយ​គិត​ថា​ខ្ញុំ​មិន​ចង់​ធ្វើ​បែប​នេះ​ទៀត​ទេ។

ខ្ញុំ​អង្គុយ​គិត​ហើយ​ដឹង​ថា​ប្រហែល​ជា​មាន​សំណួរ​បញ្ចូល​ច្រើន​ពេក​ក្នុង​ពេល​តែ​មួយ…
ខ្ញុំបានព្យាយាមផ្ញើសំណើបញ្ចូលសម្រាប់បរិមាណទិន្នន័យដែលមូលដ្ឋានទិន្នន័យគួរតែដំណើរការក្នុងរយៈពេល 1 ថ្ងៃ។ បានកើតឡើង!

ជាការប្រសើរណាស់, បន្ទាប់ពីនោះយើងបន្តផ្ញើសំណើសម្រាប់បរិមាណដូចគ្នានៃទិន្នន័យ។ ដោយសារ​យើង​ត្រូវ​លុប​ទិន្នន័យ​ដែល​មាន​តម្លៃ​ក្នុង​មួយ​ខែ យើង​ធ្វើ​ប្រតិបត្តិការ​នេះ​ឡើងវិញ​ប្រហែល 35 ដង។

ការប្តូរឈ្មោះតារាង

សំណាងគឺនៅខាងខ្ញុំ៖ អ្វីៗដំណើរការដោយរលូន។

បាត់​ដំណឹង

ល្បឿនដំណើរការបណ្តុំបានកើនឡើង។

កាលពីមុនដំណើរការនេះចំណាយពេលប្រហែលមួយម៉ោង ឥឡូវនេះវាចំណាយពេលប្រហែល 2 នាទី។

បន្ទាប់ពីខ្ញុំប្រាកដថាបញ្ហាទាំងអស់ត្រូវបានដោះស្រាយ ខ្ញុំបានទម្លាក់កំណត់ត្រាចំនួន 300 លាន។ ខ្ញុំបានលុបតុហើយមានអារម្មណ៍ថាកើតជាថ្មី។

សង្ខេប

ខ្ញុំបានដឹងថាដំណើរការបង្វិលត្រូវបានបាត់នៅក្នុងដំណើរការជាបាច់ ហើយនោះគឺជាបញ្ហាចម្បង។ ប្រភេទនៃកំហុសស្ថាបត្យកម្មនេះនាំឱ្យមានការខ្ជះខ្ជាយពេលវេលា។

តើ​អ្នក​គិត​អំពី​បន្ទុក​ក្នុង​អំឡុង​ពេល​ចម្លង​ទិន្នន័យ​ពេល​លុប​កំណត់ត្រា​ពី​មូលដ្ឋាន​ទិន្នន័យ​ដែរ​ឬ​ទេ? កុំផ្ទុក MySQL ច្រើនពេក។

អ្នកទាំងឡាយណាដែលមានជំនាញក្នុងមូលដ្ឋានទិន្នន័យច្បាស់ជាមិនជួបប្រទះបញ្ហាបែបនេះទេ។ សម្រាប់អ្នកទាំងអស់គ្នា ខ្ញុំសង្ឃឹមថាអត្ថបទនេះមានប្រយោជន៍។

អរគុណសម្រាប់ការអាន!

យើងនឹងរីករាយណាស់ប្រសិនបើអ្នកប្រាប់យើងថាតើអ្នកចូលចិត្តអត្ថបទនេះ ថាតើការបកប្រែច្បាស់លាស់ ថាតើវាមានប្រយោជន៍សម្រាប់អ្នកដែរឬទេ?

ប្រភព: www.habr.com