ផែនទីផ្លូវ Odyssey: តើយើងចង់បានអ្វីទៀតពីឧបករណ៍ភ្ជាប់។ Andrey Borodin (ឆ្នាំ 2019)

នៅក្នុងរបាយការណ៍របស់គាត់ Andrey Borodin នឹងប្រាប់អ្នកពីរបៀបដែលពួកគេបានគិតគូរពីបទពិសោធន៍នៃការធ្វើមាត្រដ្ឋាន PgBouncer នៅពេលរចនាឧបករណ៍ភ្ជាប់ នាវា Odysseyដូចដែលពួកគេបានបញ្ចូលវាទៅក្នុងផលិតកម្ម។ លើសពីនេះទៀត យើងនឹងពិភាក្សាអំពីមុខងាររបស់ឧបករណ៍ទាញដែលយើងចង់ឃើញនៅក្នុងកំណែថ្មី៖ វាមានសារៈសំខាន់សម្រាប់យើងមិនត្រឹមតែបំពេញតម្រូវការរបស់យើងប៉ុណ្ណោះទេ ប៉ុន្តែដើម្បីអភិវឌ្ឍសហគមន៍អ្នកប្រើប្រាស់។ អូឌីសស៊ី.

វីដេអូ:

សួស្តី​អ្នក​ទាំងអស់គ្នា! ខ្ញុំឈ្មោះ Andrew ។

នៅ Yandex ខ្ញុំបង្កើតមូលដ្ឋានទិន្នន័យប្រភពបើកចំហ។ ហើយថ្ងៃនេះ យើងមានប្រធានបទមួយ អំពីការតភ្ជាប់ កុងតឺន័រ។

ប្រសិនបើអ្នកដឹងពីរបៀបហៅ Connect Pooler ជាភាសារុស្សី ប្រាប់ខ្ញុំមក។ ខ្ញុំ​ពិត​ជា​ចង់​រក​ពាក្យ​បច្ចេកទេស​ល្អ​ដែល​គួរ​តែ​បង្កើត​ឡើង​ក្នុង​អក្សរសិល្ប៍​បច្ចេកទេស។

ប្រធានបទគឺស្មុគស្មាញណាស់ ពីព្រោះនៅក្នុងមូលដ្ឋានទិន្នន័យជាច្រើន ឧបករណ៍ភ្ជាប់ការតភ្ជាប់ត្រូវបានភ្ជាប់មកជាមួយ ហើយអ្នកមិនចាំបាច់ដឹងអំពីវាទេ។ ជាការពិតណាស់ មានការកំណត់មួយចំនួននៅគ្រប់ទីកន្លែង ប៉ុន្តែនៅក្នុង Postgres វាមិនដំណើរការដូចនោះទេ។ ហើយស្របគ្នា (នៅ HighLoad++ 2019) មានរបាយការណ៍មួយដោយ Nikolai Samokhvalov អំពីការបង្កើតសំណួរនៅក្នុង Postgres ។ ហើយដូចដែលខ្ញុំយល់ហើយ មនុស្សបានមកទីនេះដែលបានកំណត់រចនាសម្ព័ន្ធសំណួររបស់ពួកគេយ៉ាងល្អឥតខ្ចោះរួចហើយ ហើយទាំងនេះគឺជាមនុស្សដែលប្រឈមមុខនឹងបញ្ហាប្រព័ន្ធដ៏កម្រទាក់ទងនឹងបណ្តាញ និងការប្រើប្រាស់ធនធាន។ ហើយនៅកន្លែងខ្លះ វាអាចមានការលំបាកក្នុងន័យថាបញ្ហាមិនច្បាស់។

Yandex មាន Postgres ។ សេវាកម្ម Yandex ជាច្រើនរស់នៅក្នុង Yandex.Cloud ។ ហើយយើងមានទិន្នន័យចំនួន petabytes ដែលបង្កើតបានយ៉ាងហោចណាស់មួយលានសំណើក្នុងមួយវិនាទីនៅក្នុង Postgres ។

ហើយយើងផ្តល់នូវចង្កោមស្តង់ដារសមរម្យសម្រាប់សេវាកម្មទាំងអស់ - នេះគឺជាថ្នាំងចម្បងចម្បងនៃថ្នាំង ការចម្លងធម្មតាពីរ (សមកាលកម្ម និងអសមកាល) ការបម្រុងទុក ការធ្វើមាត្រដ្ឋាននៃសំណើអាននៅលើការចម្លង។

ថ្នាំងចង្កោមនីមួយៗគឺ Postgres ដែលបន្ថែមពីលើ Postgres និងប្រព័ន្ធត្រួតពិនិត្យ ឧបករណ៍តភ្ជាប់ក៏ត្រូវបានដំឡើងផងដែរ។ ឧបករណ៍ភ្ជាប់ត្រូវបានប្រើប្រាស់សម្រាប់ការហ៊ុមព័ទ្ធ និងសម្រាប់គោលបំណងចម្បងរបស់វា។

តើអ្វីជាគោលបំណងសំខាន់នៃការតភ្ជាប់ឧបករណ៍ភ្ជាប់?

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

លើសពីនេះ កូដ Postgres មានអារេមួយហៅថា procArray។ វាមានទិន្នន័យមូលដ្ឋានអំពីការភ្ជាប់បណ្តាញ។ ហើយស្ទើរតែគ្រប់ក្បួនដោះស្រាយដំណើរការ procArray មានភាពស្មុគស្មាញលីនេអ៊ែរ ពួកគេដំណើរការលើអារេទាំងមូលនៃការតភ្ជាប់បណ្តាញ។ វា​ជា​វដ្ដ​ដ៏​លឿន​មួយ ប៉ុន្តែ​ជាមួយ​នឹង​ការ​តភ្ជាប់​បណ្តាញ​ចូល​កាន់​តែ​ច្រើន អ្វីៗ​នឹង​មាន​តម្លៃ​ថ្លៃ​ជាង​បន្តិច។ ហើយនៅពេលដែលអ្វីៗមានតម្លៃថ្លៃជាងបន្តិច អ្នកអាចបញ្ចប់ការបង់ថ្លៃខ្ពស់សម្រាប់ការតភ្ជាប់បណ្តាញជាច្រើន។

មានវិធីសាស្រ្តចំនួន ៣ ដែលអាចធ្វើទៅបាន៖

• នៅផ្នែកខាងកម្មវិធី។
• នៅលើផ្នែកមូលដ្ឋានទិន្នន័យ។
• ហើយរវាង, នោះគឺ, គ្រប់ប្រភេទនៃបន្សំ។

ជាអកុសល អាងទឹកដែលភ្ជាប់មកជាមួយបច្ចុប្បន្នកំពុងស្ថិតក្រោមការអភិវឌ្ឍន៍។ មិត្តភក្តិរបស់យើងនៅ PostgreSQL Professional ធ្វើរឿងនេះភាគច្រើន។ ពេល​ដែល​វា​នឹង​លេច​ឡើង​គឺ​ពិបាក​នឹង​ទស្សន៍ទាយ។ ហើយការពិតយើងមានដំណោះស្រាយពីរសម្រាប់ស្ថាបត្យករដើម្បីជ្រើសរើស។ ទាំងនេះគឺជាក្រុមផ្នែកខាងកម្មវិធី និងអាងប្រូកស៊ី។

អាងចំហៀងកម្មវិធីគឺជាវិធីងាយស្រួលបំផុត។ ហើយស្ទើរតែគ្រប់កម្មវិធីបញ្ជាអតិថិជនទាំងអស់ផ្តល់ឱ្យអ្នកនូវវិធីមួយ: បង្ហាញការតភ្ជាប់រាប់លានរបស់អ្នកនៅក្នុងកូដក្នុងទម្រង់នៃការតភ្ជាប់រាប់សិបទៅមូលដ្ឋានទិន្នន័យ។

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

បន្ទាប់មក អ្នកដឹងថាអ្នកមានតំបន់ដែលអាចរកបានជាច្រើនទៀត មជ្ឈមណ្ឌលទិន្នន័យជាច្រើន។ ហើយវិធីសាស្រ្តបូកបញ្ចូលគ្នារបស់ភាគីអតិថិជននាំទៅរកចំនួនដ៏ច្រើន។ ធំ ៗ មានការតភ្ជាប់ប្រហែល 10 ។ នេះគឺជាគែមដែលអាចដំណើរការធម្មតា។

ប្រសិនបើយើងនិយាយអំពី proxy poolers នោះមាន poolers ពីរដែលអាចធ្វើរឿងជាច្រើន។ ពួកគេមិនត្រឹមតែជាអ្នកហែលទឹកប៉ុណ្ណោះទេ។ ពួកគេគឺជាអាងហែលទឹក + មុខងារត្រជាក់ជាង។ នេះ។ Pgpool и Crunchy-ប្រូកស៊ី.

ប៉ុន្តែជាអកុសល មិនមែនគ្រប់គ្នាត្រូវការមុខងារបន្ថែមនេះទេ។ ហើយវានាំឱ្យការពិតដែលថា poolers គាំទ្រតែ session pooling ពោលគឺ client incoming client មួយ outgoing client ទៅកាន់ database។

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

ហើយនៅក្នុងបន្ទុកការងាររបស់យើងនេះជាការពិត។ ប៉ុន្តែមានបញ្ហាមួយចំនួន.

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

ជាការពិតណាស់អ្នកអាចប្រើ application_name_add_host ។ នេះគឺជាវិធីមួយនៅខាង Bouncer ដើម្បីបន្ថែមអាសយដ្ឋាន IP ទៅ application_name ។ ប៉ុន្តែ application_name ត្រូវបានកំណត់ដោយការតភ្ជាប់បន្ថែម។

នៅលើក្រាហ្វនេះ កន្លែងដែលបន្ទាត់ពណ៌លឿងគឺជាសំណើពិតប្រាកដ និងកន្លែងដែលបន្ទាត់ពណ៌ខៀវគឺជាសំណើដែលហោះហើរចូលទៅក្នុងមូលដ្ឋានទិន្នន័យ។ ហើយភាពខុសគ្នានេះគឺច្បាស់ណាស់ការដំឡើង application_name ដែលត្រូវការសម្រាប់តែការតាមដានប៉ុណ្ណោះ ប៉ុន្តែវាមិនឥតគិតថ្លៃទាល់តែសោះ។

លើសពីនេះទៀតនៅក្នុង Bouncer អ្នកមិនអាចកំណត់អាងមួយបានទេ ពោលគឺចំនួននៃការភ្ជាប់មូលដ្ឋានទិន្នន័យសម្រាប់អ្នកប្រើប្រាស់ជាក់លាក់ ក្នុងមួយមូលដ្ឋានទិន្នន័យជាក់លាក់។

តើនេះនាំទៅរកអ្វី? អ្នក​មាន​សេវា​ដែល​បាន​ផ្ទុក​ដែល​សរសេរ​ជា C++ និង​កន្លែង​មួយ​នៅ​ក្បែរ​សេវា​តូច​មួយ​នៅ​លើ​ថ្នាំង​ដែល​មិន​ធ្វើ​អ្វី​ដែល​គួរ​ឱ្យ​ភ័យខ្លាច​ជាមួយ​នឹង​មូលដ្ឋាន​ទិន្នន័យ ប៉ុន្តែ​កម្មវិធី​បញ្ជា​របស់​វា​ឆ្កួត។ វាបើកការតភ្ជាប់ 20 ហើយអ្វីៗផ្សេងទៀតនឹងរង់ចាំ។ សូម្បីតែលេខកូដរបស់អ្នកក៏ធម្មតាដែរ។

ជាការពិតណាស់ យើងបានសរសេរបំណះតូចមួយសម្រាប់ Bouncer ដែលបន្ថែមការកំណត់នេះ ពោលគឺកំណត់អតិថិជនទៅអាង។

វាអាចទៅរួចក្នុងការធ្វើបែបនេះនៅផ្នែក Postgres ពោលគឺកំណត់តួនាទីនៅក្នុងមូលដ្ឋានទិន្នន័យដោយចំនួននៃការតភ្ជាប់។

ប៉ុន្តែបន្ទាប់មកអ្នកបាត់បង់សមត្ថភាពក្នុងការយល់ពីមូលហេតុដែលអ្នកមិនមានការតភ្ជាប់ទៅម៉ាស៊ីនមេ។ PgBouncer មិនបោះកំហុសក្នុងការតភ្ជាប់ទេ វាតែងតែត្រឡប់ព័ត៌មានដដែល។ ហើយអ្នកមិនអាចយល់បានទេ៖ ប្រហែលជាពាក្យសម្ងាត់របស់អ្នកបានផ្លាស់ប្តូរ ប្រហែលជាមូលដ្ឋានទិន្នន័យទើបតែបាត់ ប្រហែលជាមានអ្វីមួយខុសហើយ។ ប៉ុន្តែមិនមានរោគវិនិច្ឆ័យទេ។ ប្រសិនបើសម័យមិនអាចបង្កើតបាន អ្នកនឹងមិនដឹងថាហេតុអ្វីបានជាវាមិនអាចបង្កើតវាបានទេ។

នៅចំណុចជាក់លាក់មួយ អ្នកមើលក្រាហ្វកម្មវិធី ហើយឃើញថាកម្មវិធីមិនដំណើរការទេ។

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

យើងបានឈានដល់ការសន្និដ្ឋានថាយើងត្រូវការ PgBouncers បន្ថែមទៀត។

https://lwn.net/Articles/542629/

Bouncer ត្រូវបាន patched បន្តិច។

ហើយពួកគេបានធ្វើវាដើម្បីឱ្យ Bouncers ជាច្រើនអាចត្រូវបានលើកឡើងដោយប្រើប្រាស់ច្រក TCP ឡើងវិញ។ ហើយប្រព័ន្ធប្រតិបត្តិការនឹងផ្ទេរការភ្ជាប់ TCP ចូលដោយស្វ័យប្រវត្តិរវាងពួកវាដោយប្រើ round-robin ។

វាមានតម្លាភាពចំពោះអតិថិជន មានន័យថាវាហាក់ដូចជាអ្នកមាន Bouncer មួយ ប៉ុន្តែអ្នកមានការបែងចែកនៃការតភ្ជាប់ទំនេររវាង Bouncers កំពុងដំណើរការ។

ហើយនៅពេលជាក់លាក់មួយ អ្នកអាចកត់សំគាល់ថា Bouncers ទាំង 3 នេះម្នាក់ៗស៊ីស្នូលរបស់ពួកគេ 100% ។ អ្នកត្រូវការ Bouncers មួយចំនួន។ ហេតុអ្វី?

ដោយសារតែអ្នកមាន TLS ។ អ្នកមានការតភ្ជាប់ដែលបានអ៊ិនគ្រីប។ ហើយប្រសិនបើអ្នកសម្គាល់ Postgres ដោយមាន និងគ្មាន TLS អ្នកនឹងឃើញថាចំនួននៃការតភ្ជាប់ដែលបានបង្កើតឡើងធ្លាក់ចុះស្ទើរតែពីរលំដាប់នៃទំហំជាមួយនឹងការបើកការអ៊ិនគ្រីប ពីព្រោះការចាប់ដៃ TLS ប្រើប្រាស់ធនធាន CPU ។

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

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

នេះគឺជាឧទាហរណ៍នៃ 16 PgBouncers ដែលផ្ទុក 16 cores នៅ 100% ។

យើងបានមកដល់ល្បាក់ PgBouncer ។ នេះគឺជាការកំណត់រចនាសម្ព័ន្ធដ៏ល្អបំផុតដែលអាចសម្រេចបាននៅលើបន្ទុករបស់យើងជាមួយ Bouncer ។ Bouncers ខាងក្រៅរបស់យើងត្រូវបានប្រើសម្រាប់ការចាប់ដៃ TCP ហើយ Bouncers ខាងក្នុងត្រូវបានប្រើសម្រាប់ការរួមបញ្ចូលពិតប្រាកដ ដូច្នេះដើម្បីកុំឱ្យបែកខ្ញែកការតភ្ជាប់ខាងក្រៅច្រើនពេក។

នៅក្នុងការកំណត់រចនាសម្ព័ន្ធនេះ ការចាប់ផ្តើមឡើងវិញដោយរលូនគឺអាចធ្វើទៅបាន។ អ្នកអាចចាប់ផ្តើម Bouncers ទាំង 18 នេះឡើងវិញម្តងមួយៗ។ ប៉ុន្តែការរក្សាការកំណត់បែបនេះគឺពិបាកណាស់។ Sysadmins, DevOps និងមនុស្សដែលទទួលខុសត្រូវពិតប្រាកដសម្រាប់ម៉ាស៊ីនមេនេះនឹងមិនសប្បាយចិត្តខ្លាំងជាមួយនឹងការរៀបចំនេះទេ។

វាហាក់ដូចជាថាការកែលម្អរបស់យើងទាំងអស់អាចត្រូវបានផ្សព្វផ្សាយទៅជាប្រភពបើកចំហ ប៉ុន្តែ Bouncer មិនត្រូវបានគាំទ្រយ៉ាងល្អនោះទេ។ ជាឧទាហរណ៍ សមត្ថភាពក្នុងការដំណើរការ PgBouncers ជាច្រើននៅលើច្រកមួយត្រូវបានប្រព្រឹត្តកាលពីមួយខែមុន។ មានសំណើទាញជាមួយលក្ខណៈពិសេសនេះជាច្រើនឆ្នាំមុន។

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

ឬឧទាហរណ៍មួយទៀត។ នៅក្នុង Postgres អ្នកអាចលុបចោលសំណើដែលកំពុងដំណើរការដោយផ្ញើការសម្ងាត់ទៅកាន់ការតភ្ជាប់ផ្សេងដោយមិនចាំបាច់មានការផ្ទៀងផ្ទាត់មិនចាំបាច់។ ប៉ុន្តែអតិថិជនមួយចំនួនគ្រាន់តែផ្ញើការកំណត់ TCP ឡើងវិញ ពោលគឺពួកគេបំបែកការភ្ជាប់បណ្តាញ។ តើ Bouncer នឹងធ្វើអ្វី? គាត់នឹងមិនធ្វើអ្វីទេ។ វានឹងបន្តអនុវត្តសំណើ។ ប្រសិនបើអ្នកបានទទួលការភ្ជាប់ជាច្រើនដែលបានបង្កើតមូលដ្ឋានទិន្នន័យជាមួយនឹងសំណើតូចៗ នោះគ្រាន់តែផ្តាច់ការតភ្ជាប់ពី Bouncer នឹងមិនគ្រប់គ្រាន់ទេ អ្នកក៏ត្រូវបំពេញសំណើទាំងនោះដែលកំពុងដំណើរការនៅក្នុងមូលដ្ឋានទិន្នន័យផងដែរ។

វា​ត្រូវ​បាន​ជួសជុល​ហើយ​បញ្ហា​នេះ​មិន​ទាន់​ត្រូវ​បាន​បញ្ចូល​ចូល​ទៅ​ក្នុង​ចរន្ត​របស់ Bouncer ទេ។

ដូច្នេះហើយ យើងបានឈានដល់ការសន្និដ្ឋានថា យើងត្រូវការឧបករណ៍ភ្ជាប់ទំនាក់ទំនងផ្ទាល់ខ្លួនរបស់យើង ដែលនឹងត្រូវបានបង្កើតឡើង បំណះ ដែលបញ្ហាអាចត្រូវបានកែដំរូវបានយ៉ាងឆាប់រហ័ស ហើយដែលជាការពិតណាស់ ត្រូវតែមានខ្សែពហុខ្សែ។

យើងកំណត់ multithreading ជាកិច្ចការចម្បង។ យើងត្រូវតែអាចដោះស្រាយរលកនៃការតភ្ជាប់ TLS ចូលបានល្អ។

ដើម្បីធ្វើដូច្នេះ យើងត្រូវបង្កើតបណ្ណាល័យដាច់ដោយឡែកមួយហៅថា Machinarium ដែលត្រូវបានរចនាឡើងដើម្បីពិពណ៌នាអំពីស្ថានភាពម៉ាស៊ីននៃការតភ្ជាប់បណ្តាញជាកូដតាមលំដាប់លំដោយ។ ប្រសិនបើអ្នកក្រឡេកមើលកូដប្រភព libpq អ្នកនឹងឃើញការហៅដ៏ស្មុគស្មាញមួយចំនួនដែលអាចផ្តល់លទ្ធផលឱ្យអ្នកវិញ ហើយនិយាយថា “ហៅខ្ញុំពេលក្រោយ។ ឥឡូវនេះ ខ្ញុំមាន IO សម្រាប់ពេលនេះ ប៉ុន្តែនៅពេលដែល IO បាត់ទៅ ខ្ញុំនឹងមានបន្ទុកលើ processor”។ ហើយនេះគឺជាគ្រោងការណ៍ពហុកម្រិត។ ការទំនាក់ទំនងបណ្តាញជាធម្មតាត្រូវបានពិពណ៌នាដោយម៉ាស៊ីនរដ្ឋ។ ច្បាប់ជាច្រើនដូចជា "ប្រសិនបើពីមុនខ្ញុំបានទទួលបឋមកថានៃទំហំ N ឥឡូវនេះខ្ញុំកំពុងរង់ចាំ N bytes" "ប្រសិនបើខ្ញុំបានផ្ញើកញ្ចប់ព័ត៌មាន SYNC ឥឡូវនេះខ្ញុំកំពុងរង់ចាំកញ្ចប់ព័ត៌មានដែលមានទិន្នន័យមេតាលទ្ធផល។" លទ្ធផល​គឺ​ជា​កូដ​ដែល​ពិបាក​ឆ្លើយ​តប​នឹង​ការ​យល់​ឃើញ​ដូច​ជា​ផ្ទាំង​ថ្ម​ត្រូវ​បាន​បំប្លែង​ទៅ​ជា​ការ​ស្កេន​បន្ទាត់។ យើងបង្កើតវាដូច្នេះជំនួសឱ្យម៉ាស៊ីនរដ្ឋ អ្នកសរសេរកម្មវិធីពិពណ៌នាផ្លូវសំខាន់នៃអន្តរកម្មក្នុងទម្រង់នៃកូដចាំបាច់ធម្មតា។ វាគ្រាន់តែថានៅក្នុងកូដចាំបាច់នេះ អ្នកត្រូវបញ្ចូលកន្លែងដែលលំដាប់ប្រតិបត្តិត្រូវរំខានដោយរង់ចាំទិន្នន័យពីបណ្តាញ ឆ្លងកាត់បរិបទប្រតិបត្តិទៅកាន់ coroutine ផ្សេងទៀត (ខ្សែស្រឡាយពណ៌បៃតង)។ វិធីសាស្រ្តនេះគឺស្រដៀងគ្នាទៅនឹងការពិតដែលថាយើងសរសេរផ្លូវដែលរំពឹងទុកបំផុតនៅក្នុង maze ជាប់ៗគ្នាហើយបន្ទាប់មកបន្ថែមសាខាទៅវា។

ជាលទ្ធផល យើងមានខ្សែស្រឡាយមួយដែល TCP ទទួលយក ហើយ round-robin ឆ្លងកាត់ការតភ្ជាប់ TPC ទៅកម្មករជាច្រើន។

ក្នុងករណីនេះ ការភ្ជាប់ម៉ាស៊ីនភ្ញៀវនីមួយៗតែងតែដំណើរការលើខួរក្បាលតែមួយ។ ហើយនេះអនុញ្ញាតឱ្យអ្នកធ្វើឱ្យវាងាយស្រួលក្នុងឃ្លាំងសម្ងាត់។

ហើយលើសពីនេះទៀត យើងបានធ្វើឱ្យប្រសើរឡើងបន្តិចនូវការប្រមូលកញ្ចប់តូចទៅក្នុងកញ្ចប់ធំមួយ ដើម្បីបន្ធូរបន្ថយជង់ TCP ប្រព័ន្ធ។

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

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

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

នេះគឺជាឧទាហរណ៍នៃការដំឡើងការចម្លងឡូជីខល។

លើសពីនេះទៀត យើងមានការគាំទ្រសម្រាប់ការចម្លងរូបវ័ន្តខាងក្រៅ។ ជាការពិតណាស់ នៅក្នុង Cloud នេះគឺមិនអាចទៅរួចនោះទេ ពីព្រោះបន្ទាប់មក ចង្កោមនឹងផ្តល់ឱ្យអ្នកនូវព័ត៌មានច្រើនពេកអំពីខ្លួនវា។ ប៉ុន្តែនៅក្នុងការដំឡើងរបស់អ្នក ប្រសិនបើអ្នកត្រូវការការចម្លងរូបវន្តតាមរយៈឧបករណ៍ភ្ជាប់នៅក្នុង Odyssey វាអាចទៅរួច។

Odyssey មានការត្រួតពិនិត្យដែលឆបគ្នាយ៉ាងពេញលេញជាមួយ PgBouncer ។ យើងមានកុងសូលដូចគ្នាដែលដំណើរការស្ទើរតែគ្រប់ពាក្យបញ្ជាដូចគ្នា។ ប្រសិនបើមានអ្វីមួយបាត់ សូមផ្ញើសំណើរទាញ ឬយ៉ាងហោចណាស់មានបញ្ហានៅលើ GitHub ហើយយើងនឹងបំពេញពាក្យបញ្ជាចាំបាច់។ ប៉ុន្តែយើងមានមុខងារចម្បងរបស់កុងសូល PgBouncer រួចហើយ។

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

មុខងារនេះត្រូវបានបិទក្នុងករណីដែលអ្នកត្រូវការភាពឆបគ្នា 100% ជាមួយ PgBouncer។ យើង​អាច​មាន​ឥរិយាបទ​ដូច​នឹង Bouncer គឺ​គ្រាន់តែ​នៅ​ខាង​សុវត្ថិភាព។

ការអភិវឌ្ឍន៍

ពាក្យពីរបីអំពីកូដប្រភព Odyssey ។

https://github.com/yandex/odyssey/pull/66

ឧទាហរណ៍មានពាក្យបញ្ជា "ផ្អាក / បន្ត" ។ ជាធម្មតាពួកវាត្រូវបានប្រើដើម្បីធ្វើបច្ចុប្បន្នភាពមូលដ្ឋានទិន្នន័យ។ ប្រសិនបើអ្នកត្រូវការអាប់ដេត Postgres បន្ទាប់មកអ្នកអាចផ្អាកវានៅក្នុងឧបករណ៍ភ្ជាប់ ធ្វើ pg_upgrade បន្ទាប់មកធ្វើបន្ត។ ហើយពីខាងអតិថិជន វានឹងមើលទៅហាក់ដូចជាមូលដ្ឋានទិន្នន័យកំពុងដំណើរការយឺត។ មុខងារនេះត្រូវបាននាំមកជូនយើងដោយមនុស្សមកពីសហគមន៍។ នាង​មិន​ទាន់​កក​នៅ​ឡើយ​ទេ ប៉ុន្តែ​មិន​យូរ​មិន​ឆាប់​អ្វី​គ្រប់​យ៉ាង​នឹង​ក្លាយ​ជា។ (កកហើយ)

https://github.com/yandex/odyssey/pull/73 - កករួចហើយ

លើសពីនេះទៀត លក្ខណៈពិសេសថ្មីមួយនៅក្នុង PgBouncer គឺការគាំទ្រសម្រាប់ SCRAM Authentication ដែលត្រូវបាននាំយកមកឱ្យយើងដោយមនុស្សម្នាក់ដែលមិនដំណើរការនៅក្នុង Yandex.Cloud ផងដែរ។ ទាំងពីរមានមុខងារស្មុគស្មាញ និងសំខាន់។

ដូច្នេះហើយ ខ្ញុំចង់ប្រាប់អ្នកថា Odyssey ធ្វើពីអ្វី ក្នុងករណីដែលអ្នកចង់សរសេរកូដបន្តិចឥឡូវនេះ។

អ្នកមានមូលដ្ឋានប្រភព Odyssey ដែលពឹងផ្អែកលើបណ្ណាល័យសំខាន់ពីរ។ បណ្ណាល័យ Kiwi គឺជាការអនុវត្តនៃពិធីសារ Postgres ។ នោះគឺប្រូតូ 3 ដើមរបស់ Postgres គឺជាសារស្តង់ដារដែលផ្នែកខាងមុខ និងផ្នែកខាងក្រោយអាចផ្លាស់ប្តូរបាន។ ពួកវាត្រូវបានអនុវត្តនៅក្នុងបណ្ណាល័យគីវី។

បណ្ណាល័យ Machinarium គឺជាបណ្ណាល័យការអនុវត្តខ្សែស្រឡាយ។ បំណែកតូចមួយនៃ Machinarium នេះត្រូវបានសរសេរជាភាសាជួបប្រជុំគ្នា។ ប៉ុន្តែ​កុំ​ភ័យ​ខ្លាច​មាន​តែ ១៥ ខ្សែ​ប៉ុណ្ណោះ។

ស្ថាបត្យកម្ម Odyssey ។ មានម៉ាស៊ីនសំខាន់ដែល coroutines កំពុងដំណើរការ។ ម៉ាស៊ីននេះអនុវត្តការទទួលយកការតភ្ជាប់ TCP ចូល និងចែកចាយពួកវាក្នុងចំណោមកម្មករ។

អ្នកដោះស្រាយសម្រាប់អតិថិជនជាច្រើនអាចធ្វើការក្នុងកម្មករម្នាក់។ ខ្សែស្រឡាយសំខាន់ក៏ដំណើរការកុងសូល និងដំណើរការកិច្ចការក្រូន ដើម្បីលុបការតភ្ជាប់ដែលលែងត្រូវការនៅក្នុងអាង។

Odyssey ត្រូវបានសាកល្បងដោយប្រើឈុតតេស្ត Postgres ស្តង់ដារ។ យើងគ្រាន់តែដំណើរការ install-check តាមរយៈ Bouncer ហើយតាមរយៈ Odyssey យើងទទួលបាន null div ។ មានការធ្វើតេស្តជាច្រើនដែលទាក់ទងនឹងការធ្វើទ្រង់ទ្រាយកាលបរិច្ឆេទដែលមិនឆ្លងកាត់ពិតប្រាកដដូចគ្នានៅក្នុង Bouncer និងនៅក្នុង Odyssey ។

លើសពីនេះទៀតមានអ្នកបើកបរជាច្រើនដែលមានការធ្វើតេស្តផ្ទាល់ខ្លួនរបស់ពួកគេ។ ហើយយើងប្រើការធ្វើតេស្តរបស់ពួកគេដើម្បីសាកល្បង Odyssey ។

លើសពីនេះទៀត ដោយសារតែការកំណត់រចនាសម្ព័ន្ធល្បាក់របស់យើង យើងត្រូវសាកល្បងបណ្តុំផ្សេងៗ៖ Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey ដើម្បីប្រាកដថា ប្រសិនបើ Odyssey បញ្ចប់ផ្នែកណាមួយនៅក្នុងល្បាក់នោះ វាក៏នៅតែដំណើរការផងដែរ។ ដូចដែលយើងរំពឹងទុក។

តុង

យើងប្រើ Odyssey ក្នុងការផលិត។ ហើយវាមិនយុត្តិធម៌ទេប្រសិនបើខ្ញុំនិយាយថាអ្វីៗទាំងអស់ដំណើរការ។ ទេ នោះគឺបាទ ប៉ុន្តែមិនមែនជានិច្ចទេ។ ជាឧទាហរណ៍ នៅក្នុងការផលិតអ្វីៗគ្រប់យ៉ាងទើបតែដំណើរការ ពេលនោះមិត្តភ័ក្តិរបស់យើងមកពី PostgreSQL Professional បានមកនិយាយថាយើងមានការលេចធ្លាយអង្គចងចាំ។ ពួកគេពិតជាមែន យើងបានកែពួកគេ។ ប៉ុន្តែវាមានលក្ខណៈសាមញ្ញ។

បន្ទាប់មកយើងបានរកឃើញថាឧបករណ៍ភ្ជាប់ទំនាក់ទំនងមានការតភ្ជាប់ TLS ចូល និងការតភ្ជាប់ TLS ចេញ។ ហើយការតភ្ជាប់តម្រូវឱ្យមានវិញ្ញាបនបត្រអតិថិជន និងវិញ្ញាបនបត្រម៉ាស៊ីនមេ។

វិញ្ញាបនបត្រម៉ាស៊ីនមេ Bouncer និង Odyssey ត្រូវបានអានឡើងវិញដោយ pcache របស់ពួកគេ ប៉ុន្តែវិញ្ញាបនបត្រអតិថិជនមិនចាំបាច់ត្រូវអានឡើងវិញពី pcache ទេ ព្រោះ Odyssey ដែលអាចធ្វើមាត្រដ្ឋានបានរបស់យើងនៅទីបំផុតដំណើរការទៅក្នុងដំណើរការប្រព័ន្ធនៃការអានវិញ្ញាបនបត្រនេះ។ នេះ​បាន​ធ្វើ​ឱ្យ​យើង​ភ្ញាក់​ផ្អើល ព្រោះ​វា​មិន​ចំណាយ​ពេល​យូរ​ដើម្បី​ទប់ទល់។ ដំបូងវាធ្វើមាត្រដ្ឋានតាមលីនេអ៊ែរ ប៉ុន្តែបន្ទាប់ពី 20 ការតភ្ជាប់ចូលក្នុងពេលដំណាលគ្នាបញ្ហានេះបានបង្ហាញខ្លួនឯង។

Pluggable Authentication Method គឺជាសមត្ថភាពក្នុងការផ្ទៀងផ្ទាត់ដោយប្រើឧបករណ៍ Lunux ដែលមានស្រាប់។ នៅក្នុង PgBouncer វាត្រូវបានអនុវត្តតាមរបៀបដែលមានខ្សែស្រឡាយដាច់ដោយឡែកមួយដើម្បីរង់ចាំការឆ្លើយតបពី PAM ហើយមានខ្សែស្រឡាយ PgBouncer សំខាន់ដែលផ្តល់សេវាការតភ្ជាប់បច្ចុប្បន្ន ហើយអាចស្នើសុំឱ្យពួកគេរស់នៅក្នុងខ្សែស្រឡាយ PAM ។

យើងមិនបានអនុវត្តវាសម្រាប់ហេតុផលសាមញ្ញមួយ។ យើងមានខ្សែជាច្រើន។ ហេតុអ្វីបានជាយើងត្រូវការវា?

ទីបំផុតវាអាចបង្កើតបញ្ហានៅក្នុងនោះ ប្រសិនបើអ្នកមានការផ្ទៀងផ្ទាត់ PAM និងការផ្ទៀងផ្ទាត់មិនមែនជា PAM នោះរលកដ៏ធំនៃការផ្ទៀងផ្ទាត់ PAM អាចពន្យារពេលយ៉ាងសំខាន់នូវការផ្ទៀងផ្ទាត់ដែលមិនមែនជា PAM ។ នេះជារឿងមួយដែលយើងមិនបានជួសជុល។ ប៉ុន្តែប្រសិនបើអ្នកចង់ជួសជុលវា អ្នកអាចធ្វើដូចនេះបាន។

តុងរួចមួយទៀតគឺថាយើងមានខ្សែស្រឡាយមួយដែលទទួលយករាល់ការភ្ជាប់ចូល។ ហើយបន្ទាប់មកពួកគេត្រូវបានផ្ទេរទៅអាងកម្មករដែលជាកន្លែងដែលការចាប់ដៃ TLS នឹងប្រព្រឹត្តទៅ។

បន្ទាត់ខាងក្រោម ប្រសិនបើអ្នកមានរលកស៊ីសង្វាក់នៃការតភ្ជាប់បណ្តាញ 20 នោះពួកវាទាំងអស់នឹងត្រូវបានទទួលយក។ ហើយនៅលើផ្នែកអតិថិជន libpq នឹងចាប់ផ្តើមរាយការណ៍អំពីពេលវេលាអស់។ តាមលំនាំដើមវាហាក់ដូចជា 000 វិនាទី។

ប្រសិនបើពួកគេទាំងអស់មិនអាចបញ្ចូលមូលដ្ឋានទិន្នន័យក្នុងពេលតែមួយបានទេនោះ ពួកគេមិនអាចបញ្ចូលមូលដ្ឋានទិន្នន័យបានទេ ព្រោះអ្វីៗទាំងអស់នេះអាចត្រូវបានគ្របដណ្តប់ដោយការព្យាយាមម្តងទៀតដែលមិនមែនជានិទស្សន្ត។

យើងឈានដល់ការសន្និដ្ឋានថាយើងបានចម្លងគ្រោងការណ៍ពី PgBouncer នៅទីនេះដោយការពិតដែលថាយើងបានបិទចំនួននៃការតភ្ជាប់ TCP ដែលយើងទទួលយក។

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

ផែនទីបង្ហាញផ្លូវ

តើអ្នកចង់ឃើញអ្វីនាពេលអនាគតនៅ Odyssey? តើ​យើង​ត្រៀម​ខ្លួន​ដើម្បី​អភិវឌ្ឍ​ខ្លួន​យើង​អ្វី ហើយ​តើ​យើង​រំពឹង​អ្វី​ពី​សហគមន៍?

គិតត្រឹមខែសីហា ឆ្នាំ 2019 ។

នេះជាអ្វីដែលផែនទីបង្ហាញផ្លូវ Odyssey មើលទៅក្នុងខែសីហា៖

• យើងចង់បានការផ្ទៀងផ្ទាត់ SCRAM និង PAM ។
• យើងចង់បញ្ជូនសំណើអានទៅរង់ចាំ។
• ខ្ញុំចង់ចាប់ផ្តើមឡើងវិញតាមអ៊ីនធឺណិត។
• និងសមត្ថភាពក្នុងការផ្អាកនៅលើម៉ាស៊ីនមេ។

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

ទាក់ទង​នឹង​សំណួរ​ដែល​បាន​តែ​អាន​ទៅ​មុខ​ដើម្បី​រង់ចាំ? យើងមានឧបករណ៍ចម្លងដែលនឹងកម្តៅខ្យល់ដោយមិនចាំបាច់អនុវត្តសំណើ។ យើងត្រូវការពួកគេដើម្បីផ្តល់ការបរាជ័យ និងការប្តូរ។ ក្នុងករណីមានបញ្ហានៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យមួយ ខ្ញុំចង់កាន់កាប់ពួកវាជាមួយនឹងការងារមានប្រយោជន៍មួយចំនួន។ ដោយសារតែយើងមិនអាចកំណត់រចនាសម្ព័ន្ធដំណើរការកណ្តាលដូចគ្នា អង្គចងចាំដូចគ្នាខុសគ្នា ពីព្រោះបើមិនដូច្នេះទេការចម្លងនឹងមិនដំណើរការទេ។

ជាគោលការណ៍នៅក្នុង Postgres ចាប់ផ្តើមពី 10 វាអាចបញ្ជាក់ session_attrs នៅពេលភ្ជាប់។ អ្នក​អាច​រាយ​បញ្ជី​ម៉ាស៊ីន​មូលដ្ឋាន​ទិន្នន័យ​ទាំងអស់​ក្នុង​ការ​តភ្ជាប់ ហើយ​និយាយ​ថា​ហេតុ​អ្វី​បាន​ជា​អ្នក​ទៅ​កាន់​មូលដ្ឋាន​ទិន្នន័យ៖ សរសេរ ឬ​អាន​តែ​ប៉ុណ្ណោះ។ ហើយអ្នកបើកបរខ្លួនឯងនឹងជ្រើសរើសម៉ាស៊ីនដំបូងនៅក្នុងបញ្ជីដែលគាត់ចូលចិត្តបំផុតដែលបំពេញតម្រូវការរបស់ session_attrs ។

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

Odyssey ត្រូវតែទៅមូលដ្ឋានទិន្នន័យពីពេលមួយទៅពេលមួយហើយសុំចម្ងាយចម្លងពីបឋម។ ហើយប្រសិនបើវាឈានដល់តម្លៃកំណត់ សូមកុំអនុញ្ញាតឱ្យសំណើថ្មីចូលទៅក្នុងមូលដ្ឋានទិន្នន័យ ប្រាប់អតិថិជនថាវាត្រូវចាប់ផ្តើមការតភ្ជាប់ឡើងវិញ ហើយអាចជ្រើសរើសម៉ាស៊ីនផ្សេងទៀតដើម្បីប្រតិបត្តិសំណើ។ វា​នឹង​អនុញ្ញាត​ឱ្យ​មូលដ្ឋាន​ទិន្នន័យ​ស្ដារ​ភាពយឺតយ៉ាវ​នៃ​ការ​ចម្លង​ឡើង​វិញ​យ៉ាង​ឆាប់​រហ័ស ហើយ​ត្រឡប់​មក​វិញ​ម្ដង​ទៀត​ដើម្បី​ឆ្លើយ​តប​នឹង​សំណើ។

វាពិបាកក្នុងការផ្តល់ពេលវេលាសម្រាប់ការអនុវត្តព្រោះវាជាប្រភពបើកចំហ។ ប៉ុន្តែខ្ញុំសង្ឃឹមថាមិនមែន 2,5 ឆ្នាំដូចមិត្តរួមការងាររបស់ខ្ញុំពី PgBouncer ទេ។ នេះគឺជាលក្ខណៈពិសេសដែលខ្ញុំចង់ឃើញនៅក្នុង Odyssey ។

នៅក្នុងសហគមន៍ មនុស្សបានសួរអំពីការគាំទ្រសម្រាប់សេចក្តីថ្លែងការណ៍ដែលបានរៀបចំ. ឥឡូវអ្នកអាចបង្កើតសេចក្តីថ្លែងការណ៍ដែលបានរៀបចំតាមពីរវិធី។ ដំបូងអ្នកអាចប្រតិបត្តិពាក្យបញ្ជា SQL ដែលមានឈ្មោះថា "រៀបចំ" ។ ដើម្បីយល់ពីពាក្យបញ្ជា SQL នេះ យើងត្រូវរៀនយល់ពី SQL នៅខាង Bouncer ។ នេះ​នឹង​ជា​ការ​សម្លាប់​លើស​ពី​នេះ ព្រោះ​វា​លើស​ពី​ព្រោះ​យើង​ត្រូវ​ការ​ធាតុ​ញែក​ទាំងមូល។ យើងមិនអាចញែករាល់ពាក្យបញ្ជា SQL បានទេ។

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

ប៉ុន្តែនៅទីនេះ ភាពមិនស្របគ្នាក្នុងការសន្ទនាកើតឡើង ពីព្រោះនរណាម្នាក់និយាយថា អ្នកត្រូវយល់ពីប្រភេទនៃសេចក្តីថ្លែងការដែលបានរៀបចំដែលម៉ាស៊ីនភ្ញៀវបានបង្កើត និងចែករំលែកការតភ្ជាប់ម៉ាស៊ីនមេរវាងអតិថិជនទាំងអស់ដែលបង្កើតការតភ្ជាប់ម៉ាស៊ីនមេនេះ ពោលគឺអ្នកដែលបានបង្កើតសេចក្តីថ្លែងការណ៍ដែលបានរៀបចំបែបនេះ។

Andres Freund បាននិយាយថាប្រសិនបើអតិថិជនមករកអ្នកដែលបានបង្កើតសេចក្តីថ្លែងការណ៍ដែលបានរៀបចំរួចហើយនៅក្នុងការតភ្ជាប់ម៉ាស៊ីនមេផ្សេងទៀតបន្ទាប់មកបង្កើតវាសម្រាប់គាត់។ ប៉ុន្តែវាហាក់បីដូចជាខុសបន្តិចក្នុងការប្រតិបត្តិសំណើនៅក្នុងមូលដ្ឋានទិន្នន័យជំនួសឱ្យអតិថិជន ប៉ុន្តែតាមទស្សនៈរបស់អ្នកអភិវឌ្ឍន៍ដែលសរសេរពិធីការសម្រាប់អន្តរកម្មជាមួយមូលដ្ឋានទិន្នន័យ វានឹងមានភាពងាយស្រួលប្រសិនបើគាត់ត្រូវបានផ្តល់ការតភ្ជាប់បណ្តាញដោយសាមញ្ញ។ មានសំណើដែលបានរៀបចំបែបនេះ។

និងលក្ខណៈពិសេសមួយទៀតដែលយើងត្រូវអនុវត្ត។ ឥឡូវនេះយើងមានការត្រួតពិនិត្យដែលត្រូវគ្នាជាមួយ PgBouncer ។ យើងអាចត្រឡប់ពេលវេលាប្រតិបត្តិសំណួរជាមធ្យម។ ប៉ុន្តែពេលវេលាជាមធ្យមគឺសីតុណ្ហភាពជាមធ្យមនៅក្នុងមន្ទីរពេទ្យ: ខ្លះត្រជាក់ ខ្លះក្តៅ - ជាមធ្យម មនុស្សគ្រប់គ្នាមានសុខភាពល្អ។ វា​មិន​ពិត​ទេ។

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

អ្វីដែលសំខាន់បំផុតនោះគឺថាខ្ញុំចង់បានកំណែ 1.0 (កំណែ 1.1 ត្រូវបានចេញផ្សាយរួចហើយ) ។ ការពិតគឺថា Odyssey ឥឡូវនេះស្ថិតនៅក្នុងកំណែ 1.0rc ពោលគឺ បេក្ខជនចេញផ្សាយ។ ហើយបញ្ហាទាំងអស់ដែលខ្ញុំបានរាយបញ្ជីត្រូវបានជួសជុលជាមួយនឹងកំណែដូចគ្នាទាំងស្រុង លើកលែងតែការលេចធ្លាយអង្គចងចាំ។

តើកំណែ 1.0 នឹងមានន័យយ៉ាងណាសម្រាប់យើង? យើងកំពុងដាក់ Odyssey ទៅកាន់មូលដ្ឋានរបស់យើង។ វាត្រូវបានដំណើរការនៅលើមូលដ្ឋានទិន្នន័យរបស់យើងរួចហើយ ប៉ុន្តែនៅពេលដែលវាឈានដល់ 1 សំណើក្នុងមួយវិនាទី នោះយើងអាចនិយាយបានថា នេះគឺជាកំណែចេញផ្សាយ ហើយនេះគឺជាកំណែដែលអាចត្រូវបានគេហៅថា 000 ។

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

ខ្ញុំកំពុងរង់ចាំសំណើររបស់អ្នក។ ខ្ញុំ​ក៏​ចង់​ដឹង​ដែរ​ថា​អ្នក​មាន​បញ្ហា​អ្វី​ជាមួយ Bouncer។ តោះពិភាក្សាពួកគេ។ ប្រហែលជាយើងអាចអនុវត្តមុខងារមួយចំនួនដែលអ្នកត្រូវការ។

នេះជាភាគបញ្ចប់របស់ខ្ញុំ ខ្ញុំចង់ស្តាប់អ្នក សូមអរគុណ!

សំណួរ

ប្រសិនបើខ្ញុំកំណត់ application_name ផ្ទាល់ខ្លួនរបស់ខ្ញុំ តើវានឹងត្រូវបានបញ្ជូនបន្តយ៉ាងត្រឹមត្រូវ រួមទាំងការបញ្ចូលប្រតិបត្តិការនៅក្នុង Odyssey ដែរឬទេ?

Odyssey ឬ Bouncer?

នៅ Odyssey ។ នៅក្នុង Bouncer វាត្រូវបានបោះចោល។

យើងនឹងធ្វើឈុតមួយ។

ហើយប្រសិនបើការតភ្ជាប់ពិតប្រាកដរបស់ខ្ញុំលោតលើការតភ្ជាប់ផ្សេងទៀត តើវានឹងត្រូវបានបញ្ជូនដែរឬទេ?

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

អរគុណ Andrey សម្រាប់របាយការណ៍! របាយការណ៍ល្អ! ខ្ញុំ​រីករាយ​ដែល Odyssey កំពុង​អភិវឌ្ឍ​លឿន​ជាង​មុន​រាល់​នាទី។ ខ្ញុំចង់បន្តដូចនេះ។ យើងបានស្នើឱ្យអ្នកមានការតភ្ជាប់ប្រភពទិន្នន័យច្រើនរួចហើយ ដូច្នេះ Odyssey អាចភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យផ្សេងៗគ្នាក្នុងពេលដំណាលគ្នា ពោលគឺទាសករមេ ហើយបន្ទាប់មកភ្ជាប់ដោយស្វ័យប្រវត្តិទៅមេថ្មីបន្ទាប់ពីការបរាជ័យ។

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

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

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

បាទ​វា​ជា​រឿង​ពិត។ pcache នឹងមិនមានប្លុកទិន្នន័យដែលអ្នកចង់បានទេ ឃ្លាំងសម្ងាត់ពិតនឹងមិនមានព័ត៌មានអំពីតារាងដែលអ្នកចង់បាន គម្រោងនឹងមិនមានសំណួរដែលបានញែកទេ វានឹងមិនមានអ្វីទាំងអស់។

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

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

បាទ បង្កើនទម្ងន់។

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

Nginx មានជម្រើសនេះ។ slowly start នៅក្នុងចង្កោមសម្រាប់ម៉ាស៊ីនមេ។ ហើយគាត់បង្កើនបន្ទុកបន្តិចម្តង ៗ ។

បាទ គំនិតដ៏អស្ចារ្យ យើងនឹងសាកល្បងវានៅពេលយើងទៅដល់ទីនោះ។

ប្រភព: www.habr.com