ស្ថិរភាពនៃការប្រមូលទិន្នន័យខ្នាតធំ៖ បញ្ហាដែលលេចចេញក្រោយពេលពង្រីកមាត្រដ្ឋាន

ស្គ្រីបប្រមូលទិន្នន័យមួយអាចដំណើរការល្អលើគោលដៅដប់ ប៉ុន្តែពេលពង្រីកទៅរាប់ពាន់ អត្រាជោគជ័យអាចចាប់ផ្តើមធ្លាក់ចុះ។ អ្នកបានបន្ថែម retry ប្តូរ proxy និងកែ concurrency ប៉ុន្តែបញ្ហានៅតែត្រឡប់មកវិញ។ ពេលស៊ើបអង្កេតជ្រៅជាងនេះ ចំណុចជាប់គាំងជាញឹកញាប់មិនមែន parsing logic ទេ ប៉ុន្តែជាស្រទាប់វិស្វកម្មមួយចំនួនដែលមិនទាន់បានរៀបចំ។ នៅខ្នាតតូច បញ្ហាទាំងនេះអាចមិនលេចឡើងសោះ។

ចាត់ប្រភេទកំហុសជាមុន ទើប retry មានន័យ

ការប្រមូលទិន្នន័យតែងមានការបរាជ័យ។ ចំណុចសំខាន់គឺត្រូវបែងចែកប្រភេទ៖ បញ្ហាបណ្តាញរអាក់រអួល និង connection reset អាច retry ភ្លាមៗបាន; rate limit បណ្តោះអាសន្នគួរធ្វើ backoff មុន retry; បើរចនាសម្ព័ន្ធទំព័រប្រែប្រួលធ្វើឱ្យ parsing result ទទេ ទោះ retry មួយម៉ឺនដងក៏មិនជួយទេ ដូច្នេះត្រូវកត់ត្រា និងជូនដំណឹង; បើគោលដៅមិនមានស្រាប់ អាចសម្គាល់ថាបានបញ្ចប់; បើ environment ឬ network egress មិនអាចចាប់ផ្តើមបាន ត្រូវប្តូរទៅមួយផ្សេងហើយសាកល្បងម្តងទៀត។

ការធ្វើ retry គ្រប់ករណីដោយមិនបែងចែកគឺជាកំហុសដែលងាយកើត។ វាលាក់បញ្ហាដែលត្រូវការមនុស្សចូលជួយក្នុង loop ហើយក៏ខ្ជះខ្ជាយ quota និង egress resources ផងដែរ។ Backoff ក៏ចាំបាច់៖ ចន្លោះពេល retry គួរតែកើនឡើង បើមិនដូច្នោះទេ task ជាច្រើននឹងត្រឡប់ទៅគោលដៅក្នុងពេលតែមួយ ហើយធ្វើឱ្យ rate limiting កាន់តែខ្លាំង។

Retries នាំទៅរកបញ្ហា deduplication ដោយផ្ទាល់។ Task មួយអាចត្រូវបានប្រតិបត្តិច្រើនដងដោយសារ retry ដូច្នេះ task នីមួយៗត្រូវមាន unique identifier ដែលមានស្ថិរភាព ដូចជា value បន្ទាប់ពី URL normalization ហើយការសរសេរទៅ database គួរតែ idempotent តាម identifier នោះ។ បើមិនដូច្នោះទេ retry កាន់តែច្រើន ទិន្នន័យកខ្វក់កាន់តែច្រើន។

Rate limiting និង concurrency ជារឿងពីរផ្សេងគ្នា

ការបង្កើន concurrency មិនធានាថា throughput នឹងកើនតាមទេ។ មានកម្រិតបីកំពុងដំណើរការពេលតែមួយ៖ គេហទំព័រគោលដៅអាចទ្រាំទ្របានប៉ុន្មានមុន rate limiting ធ្វើឱ្យ throughput សរុបធ្លាក់ចុះ, memory និង CPU របស់ម៉ាស៊ីនក្នុងតំបន់, និងថាតើ environment ឬ session មួយអាចរត់ task ច្រើនពេលតែមួយបានឬអត់។

វិធីមានស្ថិរភាពជាងគឺចាប់ផ្តើមពី concurrency ទាប ហើយបន្ថែម load បន្តិចម្តងៗ ខណៈពេលមើល success rate និង response time ជាមួយគ្នា ដើម្បីរកចំណុចដែល performance ចាប់ផ្តើមអាក្រក់ច្បាស់។ Rate limiting គឺជារឿងផ្សេង៖ វាគ្រប់គ្រងល្បឿនចូលប្រើគោលដៅដូចគ្នា ហើយមិនដូច global concurrency ទេ។ បើ task មួយ batch ចែកទៅគេហទំព័រច្រើន គេហទំព័រនីមួយៗគួរមាន pacing ផ្ទាល់ខ្លួន។

ការបន្តពីចំណុចផ្អាកអាស្រ័យលើ state persistence

សម្រាប់ task ដែលរត់ជាច្រើនម៉ោង ការផ្អាកម្តងគឺជារឿងធម្មតា ហើយការចាប់ផ្តើមពីដើមឡើងវិញអាចមានតម្លៃខ្ពស់ពេក។ ដូច្នេះត្រូវរក្សាទុក state ជាអចិន្ត្រៃយ៍៖ pending, running, completed ព្រមទាំង retry count, ពេលបន្ទាប់ដែលអាចរត់បាន និង error type។ ពេល process ចាប់ផ្តើម គួរទាញ queue មកពី storage មិនមែនបង្កើតឡើងវិញពី memory ទេ។

ការរក្សា queue តែក្នុង memory គឺជាវិធីធម្មតាដែលមើលទៅដំណើរការ។ ប៉ុន្តែពេល process ដួល task ដែលកំពុងរង់ចាំទាំងអស់នឹងបាត់ ហើយការរាប់នឹងមិនត្រូវគ្នាទៀត។

ដោះស្រាយ proxy និង network egress failures ដាច់ដោយឡែក

ការដែលគោលដៅ block egress, proxy offline ឬ regional node មានការប្រែប្រួល នឹងកើតឡើងជាបន្តបន្ទាប់នៅខ្នាតធំ។ វាមិនមែនជាករណីកម្រទេ ប៉ុន្តែជាស្ថានភាពធម្មតា។ ចាត់ទុក egress ជា resource ដែលអាចប្តូរបាន៖ ពេល task បរាជ័យ សូមកំណត់ជាមុនថាជា rate limiting ពីគោលដៅ ឬ egress មិនអាចប្រើបាន; ករណីទីមួយធ្វើ backoff ករណីទីពីរប្តូរ egress ហើយ retry។ ក៏គួរកត់ត្រា failure rate របស់ egress នីមួយៗ និងដកក្រុមដែលអាក្រក់ច្បាស់ចេញ។

ផ្ទុយទៅវិញ បើ task ទាំងអស់ប្រើ egress តែមួយ task មួយអាចធ្វើឱ្យផ្លូវបណ្តាញមានបញ្ហា ហើយប៉ះពាល់ទាំងអស់ដែលនៅខាងក្រោយ។ ពេល troubleshooting ត្រូវតាម logs ថយក្រោយដើម្បីរក task ដែលបង្កបញ្ហា។

ពិនិត្យសមភាពទិន្នន័យ

Run បានជោគជ័យមិនមានន័យថាទិន្នន័យត្រឹមត្រូវទេ។ បន្ទាប់ពីសរសេរចូល storage គួរអាចឆ្លើយសំណួរមួយចំនួន៖ ចំនួន task ដែលបានបញ្ចប់ត្រូវគ្នានឹងចំនួន rows ដែលបានរក្សាទុកឬអត់, parsing result ទទេមានភាគរយប៉ុន្មាន, missing rate របស់ critical fields កើនឡើងខុសប្រក្រតីឬអត់, និងមាន duplicate rows ប៉ុន្មាន?

ការត្រួតពិនិត្យទាំងនេះមិនចាំបាច់ស្មុគស្មាញទេ។ ការយក sample តាម batch គ្រប់គ្រាន់ ប៉ុន្តែត្រូវមានអ្នកពិនិត្យលទ្ធផល។ នៅខ្នាតធំ ទិន្នន័យខុសអាចបង្កបញ្ហាច្រើនជាងការមិនមានទិន្នន័យ។

ត្រូវមើល metric អ្វីខ្លះ

មិនចាំបាច់ប្រមូល metric ច្រើនពេកទេ។ គ្រាន់តែ metric មួយចំនួនដែលបង្ហាញសុខភាពប្រព័ន្ធក៏គ្រប់គ្រាន់។

• Success rate និងការចែកចាយ failure types ដើម្បីមើលថាកំហុសប្រភេទណាកំពុងកើនឡើង
• ប្រវែង task queue និង average wait time; backlog ដែលកើនជាបន្តបន្ទាប់បង្ហាញថា intake និង processing capacity មិនសមគ្នា
• ចំនួន active environments និង processes ពាក់ព័ន្ធ; ការកើនតែមួយទិសយូរមានន័យជាញឹកញាប់ថាមាន leak ក្នុង resource cleanup
• Output ក្នុងមួយឯកតាពេល ដើម្បីដឹងថា throughput ត្រូវ rate limiting ចុចទាបឬអត់
• Egress failure rate ដើម្បីសម្រេចថាត្រូវប្តូរក្រុម nodes ឬអត់

បើ metric ណាមួយផ្លាស់ប្តូរតែមួយទិសជាយូរ សូមពិនិត្យ resource cleanup និង retry logic ជាមុន។

បំបែក environment layer ឱ្យឯករាជ្យ

ពេលមើលបញ្ហាទាំងនេះរួមគ្នា នឹងឃើញសេចក្តីសន្និដ្ឋានដូចគ្នា៖ environment layer ត្រូវគ្រប់គ្រងដាច់ពី scripts។ Environment pooling តម្រូវឱ្យ environments អាច schedule កណ្តាល មិនមែនបែកចែកនៅក្នុង scripts នីមួយៗ; resource cleanup តម្រូវឱ្យ state អាច query បាន មិនមែនពឹងឱ្យ script នីមួយៗដោះស្រាយដោយខ្លួនឯង; ការប្តូរ environment ឬ egress ហើយ retry អាចធ្វើបានតែពេល environments អាច schedule ឯករាជ្យ។

Scripts គ្រប់គ្រង logic ខណៈ environment layer គ្រប់គ្រង resources និង identity។ ក្នុង architecture បែបនេះ PurpleMark គឺជាស្រទាប់នេះ ដោយផ្តល់ environment resources ដែលអាចបង្កើតជាបាច់ ចងភ្ជាប់នឹង network egress ឯករាជ្យ និង query status បាន។

ព្រំដែននៃការអនុលោម

សមត្ថភាពពង្រីកមាត្រដ្ឋានមិនមានន័យថាអាចប្រមូលទិន្នន័យតាមចិត្តបានទេ។ ត្រូវគោរព robots rules និងលក្ខខណ្ឌសេវាកម្មរបស់គេហទំព័រគោលដៅ មិនប្រមូលព័ត៌មានផ្ទាល់ខ្លួន មិនឆ្លងកាត់វិធានការការពារបច្ចេកទេស និងគ្រប់គ្រង request frequency ដើម្បីកុំឱ្យប៉ះពាល់ដល់ការដំណើរការធម្មតារបស់សេវា។ Stability ជាបញ្ហាបច្ចេកទេស ខណៈការអនុញ្ញាតឱ្យប្រមូលគឺជាបញ្ហាផ្សេងទៀត។ ទាំងពីរត្រូវតែបំពេញលក្ខខណ្ឌ។