ផ្ទុកការបង្កើនប្រសិទ្ធភាពលើគម្រោង Highload ជាមួយ ElasticSearch

សួស្តី ហាប! ឈ្មោះរបស់ខ្ញុំគឺ Maxim Vasiliev ខ្ញុំធ្វើការជាអ្នកវិភាគ និងអ្នកគ្រប់គ្រងគម្រោងនៅ FINCH ។ ថ្ងៃនេះខ្ញុំចង់ប្រាប់អ្នកពីរបៀប ដោយប្រើ ElasticSearch យើងអាចដំណើរការសំណួរចំនួន 15 លានក្នុងរយៈពេល 6 នាទី និងបង្កើនប្រសិទ្ធភាពការផ្ទុកប្រចាំថ្ងៃនៅលើគេហទំព័ររបស់អតិថិជនរបស់យើង។ ជាអកុសលយើងនឹងត្រូវធ្វើដោយគ្មានឈ្មោះចាប់តាំងពីយើងមាន NDA យើងសង្ឃឹមថាខ្លឹមសារនៃអត្ថបទនឹងមិនទទួលរងពីរឿងនេះទេ។ តោះ​ទៅ។

របៀបដែលគម្រោងដំណើរការ

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

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

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

ប្រវត្តិសង្ខេប

ដំបូងឡើយ យើងប្រើ PostgreSQL ជាកន្លែងផ្ទុកទិន្នន័យតែមួយគត់របស់យើង។ គុណសម្បត្តិរបស់វាគឺស្តង់ដារសម្រាប់ DBMS៖ វត្តមាននៃប្រតិបត្តិការ ភាសាទាញយកទិន្នន័យដែលបានអភិវឌ្ឍ ជួរដ៏ធំទូលាយនៃឧបករណ៍សម្រាប់ការរួមបញ្ចូល។ គួបផ្សំនឹងដំណើរការល្អ ពួកគេបំពេញតម្រូវការរបស់យើងក្នុងរយៈពេលយូរគួរសម។

យើងបានរក្សាទុកទិន្នន័យទាំងអស់នៅក្នុង Postgres៖ ពីប្រតិបត្តិការទៅព័ត៌មាន។ ប៉ុន្តែចំនួនអ្នកប្រើប្រាស់បានកើនឡើង ហើយជាមួយនឹងវាចំនួនសំណើ។

ដើម្បីយល់ ចំនួនវគ្គប្រចាំឆ្នាំនៅឆ្នាំ 2017 នៅលើគេហទំព័រតែមួយគឺ 131 លាន។ នៅឆ្នាំ 2018 - 125 លាន។ នៅឆ្នាំ 2019 ម្តងទៀត 130 លាន។ បន្ថែម 100-200 លានពីកំណែចល័តរបស់គេហទំព័រ និងកម្មវិធីទូរស័ព្ទ ហើយអ្នក នឹងទទួលបានសំណើយ៉ាងច្រើន។

នៅពេលដែលគម្រោងរីកចម្រើន Postgres មិនអាចទប់ទល់នឹងបន្ទុកបានទៀតទេ យើងមិនអាចបន្តបានទេ - សំណួរផ្សេងៗគ្នាជាច្រើនបានលេចចេញមក ដែលយើងមិនអាចបង្កើតចំនួនសន្ទស្សន៍គ្រប់គ្រាន់បានទេ។

យើងបានដឹងថាមានតម្រូវការសម្រាប់កន្លែងផ្ទុកទិន្នន័យផ្សេងទៀតដែលនឹងបំពេញតម្រូវការរបស់យើង និងដកបន្ទុកចេញពី PostgreSQL ។ Elasticsearch និង MongoDB ត្រូវបានចាត់ទុកថាជាជម្រើសដែលអាចធ្វើបាន។ ចុងក្រោយចាញ់លើចំណុចដូចខាងក្រោម៖

1. ល្បឿនធ្វើលិបិក្រមយឺត ដោយសារបរិមាណទិន្នន័យក្នុងលិបិក្រមកើនឡើង។ ជាមួយនឹង Elastic ល្បឿនមិនអាស្រ័យលើចំនួនទិន្នន័យនោះទេ។
2. មិនមានការស្វែងរកអត្ថបទពេញលេញទេ។

ដូច្នេះយើងជ្រើសរើស Elastic សម្រាប់ខ្លួនយើង ហើយរៀបចំសម្រាប់ការផ្លាស់ប្តូរ។

ប្តូរទៅ Elastic

1. យើងបានចាប់ផ្តើមការផ្លាស់ប្តូរជាមួយនឹងសេវាកម្មស្វែងរកចំណុចលក់។ អតិថិជនរបស់យើងមានចំណុចលក់សរុបប្រហែល 70 ហើយក្នុងពេលតែមួយ ប្រភេទនៃការស្វែងរកជាច្រើនត្រូវបានទាមទារនៅលើគេហទំព័រ និងក្នុងកម្មវិធី៖

• អត្ថបទស្វែងរកតាមឈ្មោះតំបន់
• Geosearch ក្នុងកាំដែលបានផ្តល់ឱ្យពីចំណុចជាក់លាក់មួយ។ ជាឧទាហរណ៍ ប្រសិនបើអ្នកប្រើចង់ឃើញចំណុចលក់ណាដែលនៅជិតផ្ទះរបស់គាត់។
• ស្វែងរកដោយការ៉េដែលបានផ្តល់ឱ្យ - អ្នកប្រើប្រាស់គូសបញ្ជាក់ការ៉េនៅលើផែនទី ហើយចំណុចទាំងអស់នៅក្នុងកាំនេះត្រូវបានបង្ហាញដល់គាត់។
• ស្វែងរកដោយតម្រងបន្ថែម។ ពិន្ទុលក់ខុសគ្នាពីគ្នាទៅវិញទៅមកក្នុងការចាត់ថ្នាក់

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

2. ជួរបន្ទាប់គឺផ្នែកព័ត៌មាន។ ការបោះពុម្ពផ្សាយលេចឡើងនៅលើគេហទំព័រជារៀងរាល់ថ្ងៃដើម្បីកុំឱ្យអ្នកប្រើប្រាស់បាត់បង់លំហូរព័ត៌មានទិន្នន័យត្រូវតែតម្រៀបមុនពេលចេញ។ នេះគឺជាអ្វីដែលការស្វែងរកគឺសម្រាប់៖ នៅលើគេហទំព័រ អ្នកអាចស្វែងរកដោយការផ្គូផ្គងអត្ថបទ ហើយក្នុងពេលតែមួយភ្ជាប់តម្រងបន្ថែម ចាប់តាំងពីពួកវាក៏ត្រូវបានធ្វើឡើងតាមរយៈ Elastic ផងដែរ។

3. បន្ទាប់មកយើងបានផ្លាស់ប្តូរដំណើរការប្រតិបត្តិការ។ អ្នកប្រើប្រាស់អាចទិញផលិតផលជាក់លាក់មួយនៅលើគេហទំព័រ និងចូលរួមក្នុងការចាប់រង្វាន់។ បន្ទាប់ពីការទិញបែបនេះ យើងដំណើរការទិន្នន័យមួយចំនួនធំ ជាពិសេសនៅថ្ងៃចុងសប្តាហ៍ និងថ្ងៃឈប់សម្រាក។ សម្រាប់ការប្រៀបធៀបប្រសិនបើនៅថ្ងៃធម្មតាចំនួននៃការទិញគឺនៅកន្លែងណាមួយប្រហែល 1,5-2 លានបន្ទាប់មកនៅថ្ងៃឈប់សម្រាកតួលេខអាចឈានដល់ 53 លាន។

ក្នុងពេលជាមួយគ្នានេះ ទិន្នន័យត្រូវតែដំណើរការក្នុងរយៈពេលអប្បបរមា អ្នកប្រើប្រាស់មិនចូលចិត្តរង់ចាំច្រើនថ្ងៃសម្រាប់លទ្ធផលនោះទេ។ មិនមានវិធីដើម្បីសម្រេចបាននូវពេលវេលាកំណត់បែបនេះតាមរយៈ Postgres នោះទេ ជារឿយៗយើងបានទទួលប្លុក ហើយខណៈពេលដែលយើងកំពុងដំណើរការសំណើទាំងអស់ អ្នកប្រើប្រាស់មិនអាចពិនិត្យមើលថាតើពួកគេបានទទួលរង្វាន់ឬអត់នោះទេ។ នេះ​មិន​សូវ​រីករាយ​សម្រាប់​អាជីវកម្ម​ទេ ដូច្នេះ​យើង​បាន​ប្តូរ​ដំណើរការ​ទៅ Elasticsearch។

រយៈពេល

ឥឡូវនេះការអាប់ដេតត្រូវបានកំណត់រចនាសម្ព័ន្ធផ្អែកលើព្រឹត្តិការណ៍ យោងទៅតាមលក្ខខណ្ឌខាងក្រោម៖

1. ចំណុចលក់។ នៅពេលដែលយើងទទួលបានទិន្នន័យពីប្រភពខាងក្រៅ យើងចាប់ផ្តើមការអាប់ដេតភ្លាមៗ។
2. ព័ត៌មាន។ ដរាបណាព័ត៌មានណាមួយត្រូវបានកែសម្រួលនៅលើគេហទំព័រ វាត្រូវបានផ្ញើដោយស្វ័យប្រវត្តិទៅ Elastic ។

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

វិធីសាស្រ្តរួមបញ្ចូលគ្នា

មាន 2 វិធីក្នុងការរួមបញ្ចូលជាមួយ Elastic:

1. តាមរយៈអតិថិជនដើមតាមរយៈ TCP ។ អ្នកបើកបរជនជាតិដើមកំពុងស្លាប់ជាបណ្តើរៗ៖ វាលែងត្រូវបានគាំទ្រហើយ វាក្យសម្ព័ន្ធរបស់វាមានការរអាក់រអួលខ្លាំង។ ដូច្នេះហើយ យើងអនុវត្តមិនប្រើវា ហើយព្យាយាមបោះបង់វាចោលទាំងស្រុង។
2. តាមរយៈចំណុចប្រទាក់ HTTP ដែលអ្នកអាចប្រើទាំងសំណើ JSON និងវាក្យសម្ព័ន្ធ Lucene ។ ចុងក្រោយគឺម៉ាស៊ីនអត្ថបទដែល Elastic ប្រើ។ នៅក្នុងជម្រើសនេះ យើងទទួលបានសមត្ថភាពក្នុងការ Batch តាមរយៈសំណើ JSON តាមរយៈ HTTP ។ នេះគឺជាជម្រើសដែលយើងកំពុងព្យាយាមប្រើ។

សូមអរគុណចំពោះចំណុចប្រទាក់ HTTP យើងអាចប្រើបណ្ណាល័យដែលផ្តល់នូវការអនុវត្តអសមកាលនៃម៉ាស៊ីនភ្ញៀវ HTTP ។ យើងអាចទាញយកអត្ថប្រយោជន៍ពី Batch និង Asynchronous API ដែលនៅទីបំផុតផ្តល់នូវដំណើរការខ្ពស់ ដែលបានជួយយ៉ាងច្រើនក្នុងអំឡុងពេលថ្ងៃនៃការផ្សព្វផ្សាយដ៏ធំមួយ (បន្ថែមលើវាខាងក្រោម)

លេខមួយចំនួនសម្រាប់ប្រៀបធៀប៖

• រក្សាទុកអ្នកប្រើប្រាស់ដែលបានទទួលរង្វាន់នៅក្នុង Postgres ក្នុង 20 ខ្សែដោយមិនដាក់ក្រុម: 460713 កត់ត្រាក្នុងរយៈពេល 42 វិនាទី
• Elastic + reactive client សម្រាប់ 10 threads + batch សម្រាប់ 1000 ធាតុ: 596749 records ក្នុងរយៈពេល 11 វិនាទី
• Elastic + reactive client សម្រាប់ 10 threads + batch សម្រាប់ 1000 ធាតុ៖ 23801684 កត់ត្រាក្នុងរយៈពេល 4 នាទី។

ឥឡូវនេះយើងបានសរសេរកម្មវិធីគ្រប់គ្រងសំណើ HTTP ដែលបង្កើត JSON ជា Batch/non-Batch ហើយផ្ញើវាតាមរយៈម៉ាស៊ីនភ្ញៀវ HTTP ណាមួយដោយមិនគិតពីបណ្ណាល័យ។ អ្នកក៏អាចជ្រើសរើសផ្ញើសំណើដោយសមកាលកម្ម ឬអសមកាលផងដែរ។

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

ការផ្សព្វផ្សាយធំ

មួយឆ្នាំម្តង គម្រោងនេះរៀបចំការផ្សព្វផ្សាយដ៏ធំមួយសម្រាប់អ្នកប្រើប្រាស់ - នេះគឺជា Highload ដូចគ្នា ព្រោះនៅពេលនេះយើងធ្វើការជាមួយអ្នកប្រើប្រាស់រាប់សិបលាននាក់ក្នុងពេលដំណាលគ្នា។

ជាធម្មតា ការផ្ទុកខ្ពស់បំផុតកើតឡើងក្នុងអំឡុងពេលវិស្សមកាល ប៉ុន្តែការផ្សព្វផ្សាយនេះគឺមានកម្រិតខុសគ្នាទាំងស្រុង។ កាល​ពី​ឆ្នាំ​មុន នៅ​ថ្ងៃ​ផ្សព្វផ្សាយ​នេះ យើង​លក់​ទំនិញ​បាន ២៧ ៥៨០ ៨៩០ គ្រឿង។ ទិន្នន័យ​នេះ​ត្រូវ​ចំណាយ​ពេល​ជាង​កន្លះ​ម៉ោង​ដើម្បី​ដំណើរការ ដែល​បង្ក​ឱ្យ​មាន​ការ​រអាក់រអួល​ដល់​អ្នក​ប្រើ​ប្រាស់។ អ្នកប្រើប្រាស់បានទទួលរង្វាន់សម្រាប់ការចូលរួម ប៉ុន្តែវាច្បាស់ណាស់ថាដំណើរការចាំបាច់ត្រូវពន្លឿន។

នៅដើមឆ្នាំ 2019 យើងបានសម្រេចចិត្តថា ElasticSearch គឺចាំបាច់។ ពេញមួយឆ្នាំ យើងបានរៀបចំដំណើរការទិន្នន័យដែលទទួលបាននៅក្នុង Elastic និងលទ្ធផលរបស់វាទៅកាន់ API នៃកម្មវិធីទូរស័ព្ទ និងគេហទំព័រ។ ជាលទ្ធផល នៅឆ្នាំបន្ទាប់ក្នុងអំឡុងពេលផ្សព្វផ្សាយ យើងបានដំណើរការ 15 ធាតុក្នុងរយៈពេល 131 នាទី។

ដោយសារយើងមានមនុស្សជាច្រើនដែលចង់ទិញផលិតផល និងចូលរួមក្នុងការចាប់រង្វាន់នៅក្នុងការផ្សព្វផ្សាយរបស់យើង នេះជាវិធានការបណ្តោះអាសន្ន។ ឥឡូវនេះ យើងផ្ញើព័ត៌មានបច្ចុប្បន្នទៅ Elastic ប៉ុន្តែនៅពេលអនាគត យើងមានគម្រោងផ្ទេរព័ត៌មានដែលបានរក្សាទុកសម្រាប់ខែកន្លងមកទៅ Postgres ជាកន្លែងផ្ទុកអចិន្ត្រៃយ៍។ ដើម្បីកុំឱ្យស្ទះសន្ទស្សន៍ Elastic ដែលមានដែនកំណត់របស់វាផងដែរ។

សេចក្តីសន្និដ្ឋាន/សេចក្តីសន្និដ្ឋាន

នៅពេលនេះ យើងបានផ្ទេរសេវាកម្មទាំងអស់ដែលយើងចង់ទៅ Elastic ហើយបានផ្អាកនៅពេលនេះ។ ឥឡូវនេះយើងកំពុងបង្កើតលិបិក្រមមួយនៅក្នុង Elastic នៅលើកំពូលនៃការផ្ទុកជាប់លាប់សំខាន់នៅក្នុង Postgres ដែលចំណាយពេលលើបន្ទុកអ្នកប្រើប្រាស់។

នៅពេលអនាគត យើងមានគម្រោងផ្ទេរសេវាកម្ម ប្រសិនបើយើងយល់ថាសំណើទិន្នន័យមានភាពចម្រុះពេក ហើយកំពុងត្រូវបានស្វែងរកចំនួនជួរឈរដែលគ្មានដែនកំណត់។ នេះមិនមែនជាកិច្ចការសម្រាប់ Postgres ទៀតទេ។

ប្រសិនបើយើងត្រូវការការស្វែងរកអត្ថបទពេញលេញនៅក្នុងមុខងារ ឬប្រសិនបើយើងមានលក្ខខណ្ឌស្វែងរកផ្សេងគ្នាជាច្រើន នោះយើងដឹងរួចហើយថាវាត្រូវការបកប្រែទៅជា Elastic។

⌘⌘⌘

អរគុណសម្រាប់ការអាន។ ប្រសិនបើក្រុមហ៊ុនរបស់អ្នកក៏ប្រើ ElasticSearch ហើយមានករណីអនុវត្តផ្ទាល់របស់អ្នកដែរ សូមប្រាប់ពួកយើង។ វានឹងគួរឱ្យចាប់អារម្មណ៍ក្នុងការដឹងពីរបៀបដែលអ្នកដទៃធ្វើ :)

ប្រភព: www.habr.com