TL;DR: កាលពីបួនឆ្នាំមុនខ្ញុំបានចាកចេញពី Google ជាមួយនឹងគំនិតមួយសម្រាប់ឧបករណ៍ត្រួតពិនិត្យម៉ាស៊ីនមេថ្មី។ គំនិតនេះគឺដើម្បីបញ្ចូលគ្នានូវមុខងារដាច់ដោយឡែកជាធម្មតាចូលទៅក្នុងសេវាកម្មមួយ។ ការប្រមូល និងការវិភាគកំណត់ហេតុ, ការប្រមូលម៉ែត្រ, ការជូនដំណឹង និងផ្ទាំងគ្រប់គ្រង។ គោលការណ៍មួយគឺថាសេវាត្រូវតែពិតប្រាកដ លឿនដោយផ្តល់នូវបទពិសោធន៍ដ៏ងាយស្រួល អន្តរកម្ម និងរីករាយជាមួយ devops ។ នេះតម្រូវឱ្យដំណើរការសំណុំទិន្នន័យច្រើនជីហ្គាបៃជាប្រភាគនៃវិនាទី ខណៈស្ថិតក្នុងថវិកា។ ឧបករណ៍គ្រប់គ្រងកំណត់ហេតុដែលមានស្រាប់ជារឿយៗមានភាពយឺតយ៉ាវ និងគាំង ដូច្នេះយើងប្រឈមមុខនឹងបញ្ហាប្រឈមដ៏ល្អមួយ៖ ការរចនាឧបករណ៍យ៉ាងឆ្លាតវៃ ដើម្បីផ្តល់ឱ្យអ្នកប្រើប្រាស់នូវបទពិសោធន៍ថ្មី។

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

ថាមពលសាលាចាស់

ការវិភាគកំណត់ហេតុជាធម្មតាចាប់ផ្តើមដោយការស្វែងរក៖ ស្វែងរកសារទាំងអស់ដែលត្រូវនឹងលំនាំជាក់លាក់មួយ។ នៅក្នុង Scalyr ទាំងនេះគឺជាកំណត់ហេតុរាប់សិប ឬរាប់រយជីហ្គាបៃពីម៉ាស៊ីនមេជាច្រើន។ វិធីសាស្រ្តទំនើប ជាក្បួនពាក់ព័ន្ធនឹងការសាងសង់រចនាសម្ព័ន្ធទិន្នន័យស្មុគស្មាញមួយចំនួនដែលត្រូវបានធ្វើឱ្យប្រសើរឡើងសម្រាប់ការស្វែងរក។ ខ្ញុំពិតជាបានឃើញរឿងនេះនៅលើ Google ដែលពួកគេពិតជាល្អណាស់ចំពោះរឿងបែបនេះ។ ប៉ុន្តែ​យើង​បាន​ដោះស្រាយ​តាម​វិធី​ដែល​មាន​ប្រយោជន៍​ច្រើន​គឺ​ការ​ស្កែន​កំណត់ហេតុ​លីនេអ៊ែរ។ ហើយវាដំណើរការ - យើងផ្តល់នូវចំណុចប្រទាក់ដែលអាចស្វែងរកបាន ដែលជាលំដាប់នៃទំហំលឿនជាងដៃគូប្រកួតប្រជែងរបស់យើង (សូមមើលគំនូរជីវចលនៅចុងបញ្ចប់)។

ការយល់ដឹងសំខាន់គឺថា processors ទំនើបពិតជាលឿនណាស់ក្នុងប្រតិបត្តិការសាមញ្ញ និងត្រង់។ វាងាយនឹងខកខានក្នុងប្រព័ន្ធពហុស្រទាប់ស្មុគស្មាញ ដែលពឹងផ្អែកលើល្បឿន I/O និងប្រតិបត្តិការបណ្តាញ ហើយប្រព័ន្ធបែបនេះគឺជារឿងធម្មតាណាស់សព្វថ្ងៃនេះ។ ដូច្នេះ​យើង​បាន​បង្កើត​ការ​រចនា​ដែល​កាត់​បន្ថយ​ស្រទាប់​និង​កំទេច​កំទី​លើស។ ជាមួយនឹង processor និង servers ជាច្រើនស្របគ្នា ល្បឿនស្វែងរកឈានដល់ 1 TB ក្នុងមួយវិនាទី។

គន្លឹះសំខាន់ៗពីអត្ថបទនេះ៖

• ការស្វែងរក Brute-force គឺជាវិធីសាស្រ្តដែលអាចសម្រេចបានសម្រាប់ការដោះស្រាយបញ្ហាក្នុងពិភពពិត និងទ្រង់ទ្រាយធំ។
• Brute force គឺជាបច្ចេកទេសរចនា មិនមែនជាដំណោះស្រាយការងារទេ។ ដូចបច្ចេកទេសណាមួយដែរ វាស័ក្តិសមទៅនឹងបញ្ហាមួយចំនួនជាងបញ្ហាផ្សេងទៀត ហើយអាចអនុវត្តមិនបានល្អ ឬល្អ។
• កម្លាំង Brute គឺល្អជាពិសេសសម្រាប់ការសម្រេចបាន។ ស្ថិរភាព ផលិតភាព។
• ការ​ប្រើ​កម្លាំង​ដ៏​មាន​ប្រសិទ្ធភាព​តម្រូវ​ឱ្យ​មាន​ការ​បង្កើន​ប្រសិទ្ធភាព​កូដ និង​ការ​ប្រើ​ធនធាន​គ្រប់គ្រាន់​នៅ​ពេល​ត្រឹមត្រូវ។ វាសមស្របប្រសិនបើម៉ាស៊ីនមេរបស់អ្នកស្ថិតនៅក្រោមបន្ទុកធ្ងន់ដែលមិនប្រើអ្នកប្រើប្រាស់ ហើយប្រតិបត្តិការរបស់អ្នកប្រើនៅតែជាអាទិភាព។
• ការអនុវត្តគឺអាស្រ័យលើការរចនានៃប្រព័ន្ធទាំងមូល មិនត្រឹមតែក្បួនដោះស្រាយរង្វិលជុំខាងក្នុងប៉ុណ្ណោះទេ។

(អត្ថបទនេះពិពណ៌នាអំពីការស្វែងរកទិន្នន័យនៅក្នុងអង្គចងចាំ។ ក្នុងករណីភាគច្រើន នៅពេលដែលអ្នកប្រើប្រាស់ធ្វើការស្វែងរកកំណត់ហេតុ នោះម៉ាស៊ីនមេ Scalyr បានរក្សាទុកវារួចហើយ។ អត្ថបទបន្ទាប់នឹងពិភាក្សាអំពីការស្វែងរកកំណត់ហេតុដែលមិនបានលាក់ទុក។ គោលការណ៍ដូចគ្នាត្រូវបានអនុវត្ត៖ កូដមានប្រសិទ្ធភាព កម្លាំង brute ជាមួយនឹងធនធានគណនាដ៏ធំ) ។

វិធីសាស្ត្របង្ខំ

ជាប្រពៃណី សំណុំទិន្នន័យដ៏ធំមួយត្រូវបានស្វែងរកដោយប្រើលិបិក្រមពាក្យគន្លឹះ។ នៅពេលអនុវត្តទៅកំណត់ហេតុម៉ាស៊ីនមេ នេះមានន័យថាស្វែងរករាល់ពាក្យតែមួយគត់នៅក្នុងកំណត់ហេតុ។ សម្រាប់ពាក្យនីមួយៗ អ្នកត្រូវបង្កើតបញ្ជីនៃការរួមបញ្ចូលទាំងអស់។ វាធ្វើឱ្យមានភាពងាយស្រួលក្នុងការស្វែងរកសារទាំងអស់ដោយប្រើពាក្យនេះ ឧទាហរណ៍ 'error', 'firefox' ឬ "transaction_16851951" - គ្រាន់តែមើលក្នុងលិបិក្រម។

ខ្ញុំបានប្រើវិធីសាស្រ្តនេះនៅ Google ហើយវាដំណើរការល្អ។ ប៉ុន្តែនៅក្នុង Scalyr យើងស្វែងរកកំណត់ហេតុដោយបៃ។

ហេតុអ្វី? តាមទស្សនៈនៃក្បួនដោះស្រាយអរូបី លិបិក្រមពាក្យគន្លឹះមានប្រសិទ្ធភាពជាងការស្វែងរកដោយបង្ខំ។ ទោះយ៉ាងណាក៏ដោយ យើងមិនលក់ក្បួនដោះស្រាយទេ យើងលក់ការអនុវត្ត។ ហើយ​ការ​អនុវត្ត​គឺ​មិន​ត្រឹម​តែ​អំពី​ក្បួន​ដោះស្រាយ​ប៉ុណ្ណោះ​ទេ ប៉ុន្តែ​ក៏​អំពី​វិស្វកម្ម​ប្រព័ន្ធ​ផង​ដែរ។ យើងត្រូវតែពិចារណាគ្រប់យ៉ាង៖ បរិមាណទិន្នន័យ ប្រភេទនៃការស្វែងរក បរិបទផ្នែករឹង និងផ្នែកទន់ដែលមាន។ យើងបានសម្រេចចិត្តថាសម្រាប់បញ្ហាជាក់លាក់របស់យើង អ្វីមួយដូចជា 'grep' គឺសមស្របជាងសន្ទស្សន៍។

សន្ទស្សន៍គឺអស្ចារ្យ ប៉ុន្តែពួកគេមានដែនកំណត់។ ពាក្យមួយគឺងាយស្រួលរក។ ប៉ុន្តែការស្វែងរកសារដែលមានពាក្យច្រើនដូចជា 'googlebot' និង '404' គឺពិបាកជាង។ ការស្វែងរកឃ្លាដូចជា 'uncaught exception' តម្រូវឱ្យមានលិបិក្រមដែលស្មុគស្មាញជាងនេះ ដែលកត់ត្រាមិនត្រឹមតែសារទាំងអស់ជាមួយនឹងពាក្យនោះទេ ប៉ុន្តែក៏មានទីតាំងជាក់លាក់នៃពាក្យផងដែរ។

ការលំបាកពិតប្រាកដកើតឡើងនៅពេលដែលអ្នកមិនស្វែងរកពាក្យ។ ឧបមាថាអ្នកចង់ឃើញចំនួនចរាចរដែលមកពីរូបយន្ត។ គំនិតដំបូងគឺស្វែងរកកំណត់ហេតុសម្រាប់ពាក្យ 'bot' ។ នេះជារបៀបដែលអ្នកនឹងរកឃើញរូបយន្តមួយចំនួន៖ Googlebot, Bingbot និងជាច្រើនទៀត។ ប៉ុន្តែនៅទីនេះ 'bot' មិនមែនជាពាក្យទេ ប៉ុន្តែជាផ្នែកមួយនៃវា។ ប្រសិនបើយើងស្វែងរក 'bot' នៅក្នុងលិបិក្រម យើងនឹងមិនឃើញប្រកាសណាមួយដែលមានពាក្យ 'Googlebot' ទេ។ ប្រសិនបើអ្នកពិនិត្យរាល់ពាក្យនៅក្នុងលិបិក្រម ហើយបន្ទាប់មកស្កេនលិបិក្រមសម្រាប់ពាក្យគន្លឹះដែលបានរកឃើញនោះ ការស្វែងរកនឹងថយចុះយ៉ាងខ្លាំង។ ជាលទ្ធផល កម្មវិធីកំណត់ហេតុមួយចំនួនមិនអនុញ្ញាតឱ្យស្វែងរកពាក្យជាផ្នែក ឬ (ល្អបំផុត) អនុញ្ញាតឱ្យវាក្យសម្ព័ន្ធពិសេសជាមួយនឹងការអនុវត្តទាបជាង។ យើង​ចង់​ជៀស​វាង​រឿង​នេះ។

បញ្ហាមួយទៀតគឺសញ្ញាវណ្ណយុត្តិ។ តើអ្នកចង់ស្វែងរកសំណើទាំងអស់ពី 50.168.29.7? តើមានអ្វីអំពីការបំបាត់កំហុសដែលមានកំណត់ហេតុ [error]? អក្សរកាត់ជាធម្មតារំលងសញ្ញាវណ្ណយុត្តិ។

ទីបំផុត វិស្វករស្រឡាញ់ឧបករណ៍ដ៏មានអានុភាព ហើយជួនកាលបញ្ហាអាចដោះស្រាយបានតែជាមួយនឹងការបញ្ចេញមតិធម្មតាប៉ុណ្ណោះ។ លិបិក្រមពាក្យគន្លឹះគឺមិនសូវសមរម្យសម្រាប់រឿងនេះទេ។

លើសពីនេះទៀតសន្ទស្សន៍ ស្មុគស្មាញ. សារនីមួយៗត្រូវបន្ថែមទៅក្នុងបញ្ជីពាក្យគន្លឹះជាច្រើន។ បញ្ជីទាំងនេះគួរតែត្រូវបានរក្សាទុកជាទម្រង់ដែលអាចស្វែងរកបានយ៉ាងងាយស្រួលគ្រប់ពេលវេលា។ សំណួរដែលមានឃ្លា បំណែកពាក្យ ឬកន្សោមធម្មតាចាំបាច់ត្រូវបកប្រែទៅជាប្រតិបត្តិការពហុបញ្ជី ហើយលទ្ធផលត្រូវបានស្កេន និងបញ្ចូលគ្នាដើម្បីបង្កើតសំណុំលទ្ធផល។ នៅក្នុងបរិបទនៃសេវាកម្មពហុភតិកៈដែលមានទំហំធំ ភាពស្មុគស្មាញនេះបង្កើតបញ្ហានៃការអនុវត្តដែលមិនអាចមើលឃើញនៅពេលវិភាគក្បួនដោះស្រាយ។

លិបិក្រមពាក្យគន្លឹះក៏ប្រើកន្លែងច្រើនដែរ ហើយការផ្ទុកគឺជាការចំណាយដ៏សំខាន់នៅក្នុងប្រព័ន្ធគ្រប់គ្រងកំណត់ហេតុ។

ម្យ៉ាងវិញទៀត ការស្វែងរកនីមួយៗអាចប្រើប្រាស់ថាមពលកុំព្យូទ័រយ៉ាងច្រើន។ អ្នកប្រើប្រាស់របស់យើងពេញចិត្តក្នុងការស្វែងរកល្បឿនលឿនសម្រាប់សំណួរប្លែកៗ ប៉ុន្តែសំណួរបែបនេះត្រូវបានធ្វើឡើងកម្រណាស់។ សម្រាប់សំណួរស្វែងរកធម្មតា ឧទាហរណ៍ សម្រាប់ផ្ទាំងគ្រប់គ្រង យើងប្រើបច្ចេកទេសពិសេស (យើងនឹងពណ៌នាពួកវាក្នុងអត្ថបទបន្ទាប់)។ សំណើផ្សេងទៀតគឺកម្រគ្រប់គ្រាន់ ដែលអ្នកកម្រត្រូវដំណើរការច្រើនជាងមួយក្នុងពេលតែមួយ។ ប៉ុន្តែនេះមិនមែនមានន័យថាម៉ាស៊ីនមេរបស់យើងមិនរវល់នោះទេ៖ ពួកគេរវល់ជាមួយការងារទទួល វិភាគ និងបង្ហាប់សារថ្មី វាយតម្លៃការជូនដំណឹង ការបង្ហាប់ទិន្នន័យចាស់ជាដើម។ ដូច្នេះ យើង​មាន​ការ​ផ្គត់ផ្គង់​យ៉ាង​សំខាន់​នៃ​ដំណើរការ​ដែល​អាច​ត្រូវ​បាន​ប្រើ​ដើម្បី​ប្រតិបត្តិ​សំណួរ។

Brute force ដំណើរការប្រសិនបើអ្នកមានបញ្ហា brute (និងកម្លាំងច្រើន)

កម្លាំង Brute ដំណើរការល្អបំផុតលើបញ្ហាសាមញ្ញជាមួយរង្វិលជុំខាងក្នុងតូចៗ។ ជាញឹកញាប់អ្នកអាចបង្កើនប្រសិទ្ធភាពរង្វិលជុំខាងក្នុងដើម្បីដំណើរការក្នុងល្បឿនលឿនបំផុត។ ប្រសិនបើ​កូដ​មាន​ភាព​ស្មុគ​ស្មាញ នោះ​វា​កាន់តែ​លំបាក​ក្នុង​ការ​បង្កើន​ប្រសិទ្ធភាព​វា។

កូដស្វែងរករបស់យើងដំបូងឡើយមានរង្វិលជុំខាងក្នុងធំល្មម។ យើងរក្សាទុកសារនៅលើទំព័រនៅកម្រិត 4K; ទំព័រនីមួយៗមានសារមួយចំនួន (ក្នុង UTF-8) និងទិន្នន័យមេតាសម្រាប់សារនីមួយៗ។ ទិន្នន័យមេតាគឺជារចនាសម្ព័ន្ធដែលអ៊ិនកូដប្រវែងនៃតម្លៃ លេខសម្គាល់សារខាងក្នុង និងវាលផ្សេងទៀត។ វដ្តស្វែងរកមើលទៅដូចនេះ៖

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

(អ្នកអាចសួរថាហេតុអ្វីបានជាយើងរក្សាទុកសារក្នុងទម្រង់នេះជាមួយនឹងទំព័រ 4K អត្ថបទ និងទិន្នន័យមេតា ជាជាងការធ្វើការជាមួយកំណត់ហេតុដោយផ្ទាល់។ មានហេតុផលជាច្រើនដែលធ្វើឱ្យម៉ាស៊ីន Scalyr នៅខាងក្នុងគឺដូចជាមូលដ្ឋានទិន្នន័យចែកចាយជាង ប្រព័ន្ធឯកសារ។ ការស្វែងរកអត្ថបទត្រូវបានរួមបញ្ចូលគ្នាជាញឹកញាប់ជាមួយតម្រងរចនាប័ទ្ម DBMS នៅក្នុងរឹមបន្ទាប់ពីការវិភាគកំណត់ហេតុ។ យើងអាចស្វែងរកកំណត់ហេតុរាប់ពាន់ក្នុងពេលតែមួយ ហើយឯកសារអត្ថបទសាមញ្ញមិនស័ក្តិសមសម្រាប់ការគ្រប់គ្រងទិន្នន័យដែលបានចែកចាយ ប្រតិបត្តិការ ចម្លង និងចែកចាយរបស់យើងទេ)។

ដំបូង វាហាក់បីដូចជាកូដបែបនេះមិនស័ក្តិសមបំផុតសម្រាប់ការបង្កើនប្រសិទ្ធភាពកម្លាំង brute ។ "ការងារពិត" នៅក្នុង String.indexOf() មិន​បាន​គ្រប​ដណ្ដប់​លើ​ទម្រង់ CPU ទេ។ នោះគឺការបង្កើនប្រសិទ្ធភាពវិធីសាស្ត្រនេះតែឯងនឹងមិននាំមកនូវឥទ្ធិពលគួរឱ្យកត់សម្គាល់នោះទេ។

វាកើតឡើងដូច្នេះថាយើងរក្សាទុកទិន្នន័យមេតានៅដើមទំព័រនីមួយៗ ហើយអត្ថបទនៃសារទាំងអស់នៅក្នុង UTF-8 ត្រូវបានខ្ចប់នៅចុងម្ខាងទៀត។ ទាញយកប្រយោជន៍ពីវា យើងសរសេររង្វិលជុំឡើងវិញ ដើម្បីស្វែងរកទំព័រទាំងមូលក្នុងពេលតែមួយ៖

កំណែនេះដំណើរការដោយផ្ទាល់លើទិដ្ឋភាព raw byte[] ហើយស្វែងរកសារទាំងអស់ក្នុងពេលតែមួយនៅលើទំព័រ 4K ទាំងមូល។

នេះ​គឺ​ជា​ការ​ងាយស្រួល​ជាង​ក្នុង​ការ​បង្កើន​ប្រសិទ្ធភាព​សម្រាប់​វិធីសាស្ត្រ brute force ។ រង្វិលជុំស្វែងរកខាងក្នុងត្រូវបានគេហៅថាក្នុងពេលដំណាលគ្នាសម្រាប់ទំព័រ 4K ទាំងមូល ជាជាងដាច់ដោយឡែកនៅលើប្រកាសនីមួយៗ។ មិនមានការចម្លងទិន្នន័យ គ្មានការបែងចែកវត្ថុ។ ហើយ​ប្រតិបត្តិការ​ទិន្នន័យ​មេតា​ដែល​ស្មុគស្មាញ​ច្រើន​ត្រូវ​បាន​ហៅ​តែ​នៅ​ពេល​ដែល​លទ្ធផល​វិជ្ជមាន​ប៉ុណ្ណោះ ហើយ​មិនមែន​នៅ​លើ​រាល់​សារ​ទេ។ វិធីនេះ​យើង​បាន​លុប​ចោល​បន្ទុក​លើស​មួយ​តោន ហើយ​បន្ទុក​ដែល​នៅ​សល់​ត្រូវ​បាន​ប្រមូល​ផ្ដុំ​ក្នុង​រង្វង់​ស្វែងរក​ខាងក្នុង​តូចមួយ ដែល​ស័ក្តិសម​សម្រាប់​ការ​បង្កើន​ប្រសិទ្ធភាព​បន្ថែម​ទៀត។

ក្បួនដោះស្រាយការស្វែងរកពិតប្រាកដរបស់យើងគឺផ្អែកលើ គំនិតដ៏អស្ចារ្យរបស់ Leonid Volnitsky. វាស្រដៀងទៅនឹងក្បួនដោះស្រាយ Boyer-Moore ដោយរំលងប្រមាណប្រវែងនៃខ្សែអក្សរស្វែងរកនៅជំហាននីមួយៗ។ ភាពខុសគ្នាសំខាន់គឺថាវាពិនិត្យពីរបៃក្នុងពេលតែមួយ ដើម្បីកាត់បន្ថយការផ្គូផ្គងមិនពិត។

ការអនុវត្តរបស់យើងតម្រូវឱ្យបង្កើតតារាងរកមើល 64K សម្រាប់ការស្វែងរកនីមួយៗ ប៉ុន្តែវាមិនមានអ្វីប្រៀបធៀបទៅនឹងទិន្នន័យជីហ្គាបៃដែលយើងកំពុងស្វែងរកនោះទេ។ រង្វិលជុំខាងក្នុងដំណើរការជាច្រើនជីហ្គាបៃក្នុងមួយវិនាទីនៅលើស្នូលតែមួយ។ នៅក្នុងការអនុវត្តជាក់ស្តែង ដំណើរការមានស្ថេរភាពគឺប្រហែល 1,25 GB ក្នុងមួយវិនាទីនៅលើស្នូលនីមួយៗ ហើយវាមានកន្លែងសម្រាប់ធ្វើឱ្យប្រសើរឡើង។ វាគឺអាចធ្វើទៅបានដើម្បីលុបបំបាត់ផ្នែកខ្លះនៃផ្នែកខាងក្រៅនៃរង្វិលជុំខាងក្នុង ហើយយើងគ្រោងនឹងពិសោធន៍ជាមួយរង្វិលជុំខាងក្នុងនៅក្នុង C ជំនួសឱ្យ Java ។

យើងប្រើកម្លាំង

យើងបានពិភាក្សាថាការស្វែងរកកំណត់ហេតុអាចត្រូវបានអនុវត្ត "ប្រហែល" ប៉ុន្តែតើយើងមាន "ថាមពល" ប៉ុន្មាន? ច្រើន​គួរសម។

1 ស្នូល៖ នៅពេលប្រើបានត្រឹមត្រូវ ស្នូលតែមួយនៃខួរក្បាលទំនើបមានថាមពលខ្លាំងនៅក្នុងសិទ្ធិរបស់វា។

8 ស្នូល៖ បច្ចុប្បន្នយើងកំពុងដំណើរការនៅលើ Amazon hi1.4xlarge និង i2.4xlarge SSD servers ដែលនីមួយៗមាន 8 cores (16 threads)។ ដូចដែលបានរៀបរាប់ខាងលើ ស្នូលទាំងនេះជាធម្មតារវល់ជាមួយប្រតិបត្តិការផ្ទៃខាងក្រោយ។ នៅពេលដែលអ្នកប្រើប្រាស់ធ្វើការស្វែងរក ប្រតិបត្តិការផ្ទៃខាងក្រោយត្រូវបានផ្អាក ដោយធ្វើឱ្យមានស្នូលទាំង 8 សម្រាប់ការស្វែងរក។ ការស្វែងរកជាធម្មតាបញ្ចប់ក្នុងវិនាទីបំបែក បន្ទាប់ពីនោះការងារផ្ទៃខាងក្រោយបន្ត (កម្មវិធីបិទបើកធានាថារបាំងនៃសំណួរស្វែងរកមិនរំខានដល់ការងារផ្ទៃខាងក្រោយសំខាន់ៗទេ)។

16 ស្នូល៖ សម្រាប់ភាពអាចជឿជាក់បាន យើងរៀបចំ servers ទៅជា master/slave group។ មេនីមួយៗមាន SSD មួយ និងម៉ាស៊ីនមេ EBS មួយនៅក្រោមពាក្យបញ្ជារបស់គាត់។ ប្រសិនបើម៉ាស៊ីនមេគាំង នោះម៉ាស៊ីនមេ SSD ជំនួសកន្លែងរបស់វាភ្លាមៗ។ ស្ទើរតែគ្រប់ពេលវេលា មេ និងទាសករដំណើរការបានល្អ ដូច្នេះប្លុកទិន្នន័យនីមួយៗអាចស្វែងរកបាននៅលើម៉ាស៊ីនមេពីរផ្សេងគ្នា (ម៉ាស៊ីនមេ EBS slave មានដំណើរការខ្សោយ ដូច្នេះយើងមិនពិចារណាវាទេ)។ យើងបែងចែកភារកិច្ចរវាងពួកគេ ដូច្នេះយើងមានស្នូលសរុបចំនួន 16 ។

ស្នូលជាច្រើន។៖ នាពេលខាងមុខនេះ យើងនឹងចែកចាយទិន្នន័យឆ្លងកាត់ម៉ាស៊ីនមេ តាមរបៀបដែលពួកវាទាំងអស់ចូលរួមក្នុងដំណើរការរាល់សំណើដែលមិនសំខាន់។ ស្នូលនីមួយៗនឹងដំណើរការ។ [ចំណាំ៖ យើងបានអនុវត្តផែនការនេះ និងបង្កើនល្បឿនស្វែងរកដល់ 1 TB/s សូមមើលចំណាំនៅចុងបញ្ចប់នៃអត្ថបទ].

ភាពសាមញ្ញធានានូវភាពជឿជាក់

អត្ថប្រយោជន៍មួយទៀតនៃវិធីសាស្ត្រ brute force គឺដំណើរការស្របគ្នាដោយស្មើភាពរបស់វា។ ជាធម្មតា ការស្វែងរកមិនមានភាពរសើបខ្លាំងចំពោះព័ត៌មានលម្អិតនៃបញ្ហា និងសំណុំទិន្នន័យទេ (ខ្ញុំគិតថានោះហើយជាមូលហេតុដែលវាត្រូវបានគេហៅថា "រដុប")។

ពេលខ្លះសន្ទស្សន៍ពាក្យគន្លឹះបង្កើតលទ្ធផលលឿនមិនគួរឱ្យជឿ ហើយពេលខ្លះវាមិនមាន។ ចូរនិយាយថាអ្នកមានកំណត់ហេតុ 50 GB ដែលពាក្យ 'customer_5987235982' លេចឡើងយ៉ាងពិតប្រាកដបីដង។ ការស្វែងរកពាក្យនេះរាប់ទីតាំងចំនួនបីដោយផ្ទាល់ពីលិបិក្រម ហើយនឹងបញ្ចប់ភ្លាមៗ។ ប៉ុន្តែការស្វែងរកអក្សរជំនួសដ៏ស្មុគស្មាញអាចស្កេនពាក្យគន្លឹះរាប់ពាន់ ហើយចំណាយពេលយូរ។

ម៉្យាងវិញទៀត ការស្វែងរកដោយកម្លាំង brute force ដំណើរការក្នុងល្បឿនដូចគ្នា ឬតិចជាងសម្រាប់សំណួរណាមួយ។ ការ​ស្វែងរក​ពាក្យ​វែង​គឺ​ល្អ​ជាង ប៉ុន្តែ​សូម្បី​តែ​ការ​ស្វែងរក​តួអក្សរ​មួយ​ក៏​លឿន​ណាស់​ដែរ។

ភាពសាមញ្ញនៃវិធីសាស្រ្តកម្លាំង brute មានន័យថាការអនុវត្តរបស់វាគឺជិតដល់អតិបរមាទ្រឹស្តីរបស់វា។ មានជម្រើសតិចជាងមុនសម្រាប់ការផ្ទុកលើសចំណុះនៃថាសដែលមិនរំពឹងទុក ការប៉ះទង្គិចការចាក់សោ ការដេញតាមទ្រនិច និងហេតុផលរាប់ពាន់ផ្សេងទៀតសម្រាប់ការបរាជ័យ។ ខ្ញុំទើបតែមើលសំណើដែលធ្វើឡើងដោយអ្នកប្រើប្រាស់ Scalyr កាលពីសប្តាហ៍មុននៅលើម៉ាស៊ីនមេដែលមមាញឹកបំផុតរបស់យើង។ មានសំណើចំនួន 14 ។ ពិតប្រាកដប្រាំបីនៃពួកគេបានចំណាយពេលច្រើនជាងមួយវិនាទី; 000% បានបញ្ចប់ក្នុងរយៈពេល 99 មិល្លីវិនាទី (ប្រសិនបើអ្នកមិនទាន់បានប្រើឧបករណ៍វិភាគកំណត់ហេតុទេ សូមទុកចិត្តខ្ញុំ៖ វាលឿនណាស់។).

ដំណើរការប្រកបដោយស្ថេរភាព និងគួរឱ្យទុកចិត្តមានសារៈសំខាន់សម្រាប់ភាពងាយស្រួលនៃការប្រើប្រាស់សេវាកម្ម។ ប្រសិនបើវាយឺតយ៉ាវតាមកាលកំណត់ អ្នកប្រើប្រាស់នឹងយល់ថាវាមិនគួរឱ្យទុកចិត្ត និងស្ទាក់ស្ទើរក្នុងការប្រើប្រាស់វា។

ចូលដំណើរការស្វែងរក

នេះ​ជា​ចលនា​ខ្លី​មួយ​ដែល​បង្ហាញ​ការ​ស្វែងរក Scalyr ក្នុង​សកម្មភាព។ យើងមានគណនីសាកល្បង ដែលយើងនាំចូលរាល់ព្រឹត្តិការណ៍នៅក្នុងគ្រប់ឃ្លាំង Github សាធារណៈ។ នៅក្នុងការបង្ហាញនេះ ខ្ញុំពិនិត្យមើលទិន្នន័យដែលមានតម្លៃក្នុងមួយសប្តាហ៍៖ ប្រហែល 600 MB នៃកំណត់ហេតុឆៅ។

វីដេអូ​នេះ​ត្រូវ​បាន​ថត​បន្ត​ផ្ទាល់ ដោយ​គ្មាន​ការ​រៀបចំ​ពិសេស​នៅ​លើ​កុំព្យូទ័រ​របស់​ខ្ញុំ (ប្រហែល 5000 គីឡូម៉ែត្រ​ពី​ម៉ាស៊ីន​មេ)។ ការសម្តែងដែលអ្នកនឹងឃើញគឺភាគច្រើនដោយសារតែ ការបង្កើនប្រសិទ្ធភាពម៉ាស៊ីនភ្ញៀវគេហទំព័រក៏ដូចជាផ្នែកខាងក្រោយលឿន និងអាចទុកចិត្តបាន។ រាល់ពេលដែលមានការផ្អាកដោយគ្មានសូចនាករ 'កំពុងផ្ទុក' គឺខ្ញុំផ្អាក ដូច្នេះអ្នកអាចអានអ្វីដែលខ្ញុំហៀបនឹងចុច។

នៅក្នុងសេចក្តីសន្និដ្ឋាន

នៅពេលដំណើរការទិន្នន័យក្នុងបរិមាណច្រើន វាជារឿងសំខាន់ក្នុងការជ្រើសរើសក្បួនដោះស្រាយដ៏ល្អ ប៉ុន្តែ "ល្អ" មិនមានន័យថា "ប្រឌិត" នោះទេ។ គិតអំពីរបៀបដែលលេខកូដរបស់អ្នកនឹងដំណើរការក្នុងការអនុវត្ត។ ការវិភាគទ្រឹស្តីនៃក្បួនដោះស្រាយបានបន្សល់ទុកនូវកត្តាមួយចំនួនដែលអាចមានសារៈសំខាន់ខ្លាំងនៅក្នុងពិភពពិត។ ក្បួនដោះស្រាយសាមញ្ញគឺមានភាពងាយស្រួលក្នុងការបង្កើនប្រសិទ្ធភាព និងមានស្ថេរភាពជាងមុននៅក្នុងស្ថានភាពគែម។

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

ដោយប្រើវិធីសាស្ត្រ brute force យើងបានអនុវត្តការស្វែងរកលឿន គួរឱ្យទុកចិត្ត និងអាចបត់បែនបានតាមសំណុំនៃកំណត់ហេតុមួយ។ យើងសង្ឃឹមថាគំនិតទាំងនេះមានប្រយោជន៍សម្រាប់គម្រោងរបស់អ្នក។

កែសម្រួល៖ ចំណងជើង និងអត្ថបទបានផ្លាស់ប្តូរពី "Search at 20 GB per second" ទៅ "Search at 1 TB per second" ដើម្បីឆ្លុះបញ្ចាំងពីការកើនឡើងនៃដំណើរការក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ។ ការកើនឡើងនៃល្បឿននេះគឺជាចម្បងដោយសារតែការផ្លាស់ប្តូរនៅក្នុងប្រភេទ និងចំនួននៃម៉ាស៊ីនមេ EC2 ដែលយើងកំពុងដាក់នៅថ្ងៃនេះ ដើម្បីបម្រើអតិថិជនដែលកើនឡើងរបស់យើង។ មានការផ្លាស់ប្តូរនាពេលឆាប់ៗនេះដែលនឹងផ្តល់នូវការបង្កើនប្រសិទ្ធភាពប្រតិបត្តិការយ៉ាងខ្លាំង ហើយយើងមិនអាចរង់ចាំក្នុងការចែករំលែកវាបានទេ។

ប្រភព: www.habr.com