🥇DBA-bot Joe ។ Anatoly Stansler (Postgres.ai)

តើអ្នកអភិវឌ្ឍន៍ផ្នែកខាងក្រោយយល់យ៉ាងណាថាសំណួរ SQL នឹងដំណើរការល្អលើ "ផលិតផល"? នៅក្នុងក្រុមហ៊ុនធំៗ ឬរីកចម្រើនយ៉ាងឆាប់រហ័ស មិនមែនគ្រប់គ្នាសុទ្ធតែមានសិទ្ធិប្រើប្រាស់ "ផលិតផល" នោះទេ។ ហើយជាមួយនឹងការចូលប្រើ មិនមែនរាល់សំណើទាំងអស់អាចត្រូវបានពិនិត្យដោយគ្មានការឈឺចាប់នោះទេ ហើយការបង្កើតច្បាប់ចម្លងនៃមូលដ្ឋានទិន្នន័យជារឿយៗត្រូវចំណាយពេលរាប់ម៉ោង។ ដើម្បីដោះស្រាយបញ្ហាទាំងនេះ យើងបានបង្កើត DBA សិប្បនិម្មិតមួយ - Joe ។ វាត្រូវបានអនុវត្តដោយជោគជ័យនៅក្នុងក្រុមហ៊ុនជាច្រើន និងជួយអ្នកអភិវឌ្ឍន៍ច្រើនជាងដប់នាក់។

វីដេអូ:

សួស្តីអ្នកទាំងអស់គ្នា! ឈ្មោះរបស់ខ្ញុំគឺ Anatoly Stansler ។ ខ្ញុំធ្វើការឱ្យក្រុមហ៊ុនមួយ។ postgres.ai. យើងប្ដេជ្ញាចិត្តក្នុងការពន្លឿនដំណើរការអភិវឌ្ឍន៍ដោយលុបចោលការពន្យារពេលដែលទាក់ទងនឹងការងាររបស់ Postgres ពីអ្នកអភិវឌ្ឍន៍ DBAs និង QAs។

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

នៅពេលដែលយើងកំពុងអភិវឌ្ឍ និងធ្វើចំណាកស្រុកដែលមានបន្ទុកខ្ពស់ស្មុគ្រស្មាញ យើងសួរខ្លួនយើងនូវសំណួរថា "តើការធ្វើចំណាកស្រុកនេះនឹងរលត់ទៅ?" យើងប្រើការពិនិត្យឡើងវិញ យើងប្រើចំណេះដឹងរបស់សហសេវិកដែលមានបទពិសោធន៍ច្រើនជាង អ្នកជំនាញ DBA ។ ហើយពួកគេអាចនិយាយបានថាតើវានឹងហោះហើរឬអត់។

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

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

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

វាឈឺ វាថ្លៃ។ វាប្រហែលជាល្អបំផុតដែលមិនត្រូវ។

ហើយតើវិធីណាដែលល្អបំផុតដើម្បីធ្វើវា?

ចូរយើងរៀបចំឆាក ហើយជ្រើសរើសផ្នែកខ្លះនៃផលិតផលនៅទីនោះ។ ឬល្អបំផុត ចូរយើងយកផលិតផលពិត ទិន្នន័យទាំងអស់។ ហើយបន្ទាប់ពីយើងបានបង្កើតវានៅក្នុងស្រុក យើងនឹងពិនិត្យមើលបន្ថែមទៀតសម្រាប់ការដាក់បង្ហាញ។

វានឹងអនុញ្ញាតឱ្យយើងលុបចេញនូវកំហុសមួយចំនួន ពោលគឺការពារពួកគេពីការផលិត។

តើមានបញ្ហាអ្វីខ្លះ?

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

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

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

តើអ្វីរារាំងយើងពីការផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍នីមួយៗនូវកៅអីសាកល្បង ដែលជាច្បាប់ចម្លងទំហំពេញ? ខ្ញុំគិតថាវាច្បាស់ណាស់ថាមានអ្វីកើតឡើង។

តើអ្នកណាមានមូលដ្ឋានទិន្នន័យធំជាង តេរ៉ាបៃ? ជាងពាក់កណ្តាលបន្ទប់។

ហើយវាច្បាស់ណាស់ថាការរក្សាម៉ាស៊ីនសម្រាប់អ្នកអភិវឌ្ឍន៍នីមួយៗនៅពេលដែលមានផលិតកម្មធំបែបនេះគឺមានតម្លៃថ្លៃណាស់ ហើយក្រៅពីនេះវាត្រូវចំណាយពេលយូរ។

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

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

ប៉ុន្តែពួកគេប្រើវិធីសាស្រ្តនេះព្រោះវាអនុញ្ញាតឱ្យពួកគេរក្សាផលិតផលដែលអាចទុកចិត្តបាន។

តើយើងអាចធ្វើអ្វីនៅទីនេះ? ចូរធ្វើឱ្យកៅអីសាកល្បងមានតម្លៃថោក ហើយផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍គ្រប់រូបនូវកៅអីសាកល្បងផ្ទាល់ខ្លួនរបស់ពួកគេ។

ហើយនេះអាចទៅរួច។

ហើយនៅក្នុងវិធីសាស្រ្តនេះ នៅពេលដែលយើងបង្កើតក្លូនស្តើងសម្រាប់អ្នកអភិវឌ្ឍន៍នីមួយៗ យើងអាចចែករំលែកវានៅលើម៉ាស៊ីនតែមួយ។ ឧទាហរណ៍ ប្រសិនបើអ្នកមានមូលដ្ឋានទិន្នន័យ 10TB ហើយចង់ផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍ 10 នាក់ អ្នកមិនចាំបាច់មានមូលដ្ឋានទិន្នន័យ XNUMX x XNUMXTB ទេ។ អ្នកត្រូវការម៉ាស៊ីនតែមួយគត់ដើម្បីធ្វើច្បាប់ចម្លងដាច់ដោយឡែកសម្រាប់អ្នកអភិវឌ្ឍន៍នីមួយៗដោយប្រើម៉ាស៊ីនមួយ។ ខ្ញុំនឹងប្រាប់អ្នកពីរបៀបដែលវាដំណើរការបន្តិចក្រោយមក។

ឧទាហរណ៍ជាក់ស្តែង៖

DB - 4,5 តេរ៉ាបៃ។
យើងអាចទទួលបានច្បាប់ចម្លងឯករាជ្យក្នុងរយៈពេល 30 វិនាទី។

អ្នកមិនចាំបាច់រង់ចាំកន្លែងធ្វើតេស្ត ហើយអាស្រ័យលើទំហំប៉ុនណា។ អ្នកអាចទទួលបានវាក្នុងរយៈពេលប៉ុន្មានវិនាទី។ វានឹងក្លាយជាបរិស្ថានដាច់ស្រយាលទាំងស្រុង ប៉ុន្តែដែលចែករំលែកទិន្នន័យក្នុងចំណោមពួកគេ។

នេះគឺអស្ចារ្យណាស់។ នៅទីនេះយើងកំពុងនិយាយអំពីវេទមន្ត និងសកលលោកស្របគ្នា។

ក្នុងករណីរបស់យើង វាដំណើរការដោយប្រើប្រព័ន្ធ OpenZFS ។

OpenZFS គឺជាប្រព័ន្ធឯកសារចម្លងលើការសរសេរ ដែលគាំទ្រការថតរូប និងការក្លូនចេញពីប្រអប់។ វាអាចទុកចិត្តបាន និងអាចធ្វើមាត្រដ្ឋានបាន។ នាងងាយស្រួលគ្រប់គ្រងណាស់។ វាអាចត្រូវបានដាក់ពង្រាយជាពីរក្រុម។

មានជម្រើសផ្សេងទៀត៖

អិលវីអិម,
ការផ្ទុក (ឧទាហរណ៍ Pure Storage) ។

បន្ទប់ពិសោធន៍ទិន្នន័យដែលខ្ញុំកំពុងនិយាយអំពីគឺម៉ូឌុល។ អាចត្រូវបានអនុវត្តដោយប្រើជម្រើសទាំងនេះ។ ប៉ុន្តែសម្រាប់ពេលនេះ យើងបានផ្តោតលើ OpenZFS ដោយសារតែមានបញ្ហាជាមួយ LVM ជាពិសេស។

តើវាដំណើរការយ៉ាងដូចម្តេច? ជំនួសឱ្យការសរសេរជាន់លើទិន្នន័យរាល់ពេលដែលយើងផ្លាស់ប្តូរវា យើងរក្សាទុកវាដោយគ្រាន់តែសម្គាល់ថាទិន្នន័យថ្មីនេះគឺមកពីចំណុចថ្មីនៅក្នុងពេលវេលា ដែលជារូបថតថ្មី។

ហើយនៅពេលអនាគត នៅពេលដែលយើងចង់វិលត្រឡប់មកវិញ ឬយើងចង់បង្កើតក្លូនថ្មីពីកំណែចាស់មួយចំនួន យើងគ្រាន់តែនិយាយថា៖ "យល់ព្រម ផ្តល់ឱ្យយើងនូវប្លុកទិន្នន័យទាំងនេះដែលត្រូវបានសម្គាល់ដូចនេះ។"

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

ហើយយើងនឹងសាខា។ អ្នកអភិវឌ្ឍន៍នីមួយៗនៅក្នុងករណីរបស់យើងនឹងមានឱកាសមានក្លូនផ្ទាល់ខ្លួនរបស់គាត់ដែលគាត់បានកែសម្រួល ហើយទិន្នន័យដែលត្រូវបានចែករំលែកនឹងត្រូវបានចែករំលែករវាងអ្នកគ្រប់គ្នា។

ដើម្បីដាក់ពង្រាយប្រព័ន្ធបែបនេះនៅផ្ទះ អ្នកត្រូវដោះស្រាយបញ្ហាពីរ៖

ទីមួយគឺជាប្រភពនៃទិន្នន័យដែលអ្នកនឹងយកវាពី។ អ្នកអាចរៀបចំការចម្លងជាមួយផលិតកម្ម។ អ្នកអាចប្រើការបម្រុងទុកដែលអ្នកបានកំណត់រចនាសម្ព័ន្ធរួចហើយ ខ្ញុំសង្ឃឹមថា។ WAL-E, WAL-G ឬ Barman ។ ហើយទោះបីជាអ្នកកំពុងប្រើដំណោះស្រាយ Cloud មួយចំនួនដូចជា RDS ឬ Cloud SQL ក៏ដោយ អ្នកអាចប្រើការបោះចោលឡូជីខលបាន។ ប៉ុន្តែយើងនៅតែណែនាំអ្នកឱ្យប្រើការបម្រុងទុក ពីព្រោះជាមួយនឹងវិធីសាស្រ្តនេះ អ្នកក៏នឹងរក្សារចនាសម្ព័ន្ធរូបវន្តនៃឯកសារផងដែរ ដែលនឹងអនុញ្ញាតឱ្យអ្នកកាន់តែខិតទៅជិតរង្វាស់ដែលអ្នកនឹងឃើញនៅក្នុងផលិតកម្ម ដើម្បីចាប់យកបញ្ហាទាំងនោះដែលមាន។
ទីពីរគឺជាកន្លែងដែលអ្នកចង់ធ្វើជាម្ចាស់ផ្ទះ Database Lab ។ វាអាចជា Cloud វាអាចជា On-premise។ វាមានសារៈសំខាន់ណាស់ក្នុងការនិយាយនៅទីនេះថា ZFS គាំទ្រការបង្ហាប់ទិន្នន័យ។ ហើយវាធ្វើបានយ៉ាងល្អ។

ស្រមៃថាសម្រាប់ក្លូនបែបនេះនីមួយៗ អាស្រ័យលើប្រតិបត្តិការដែលយើងធ្វើជាមួយមូលដ្ឋាន ប្រភេទនៃ dev មួយចំនួននឹងកើនឡើង។ សម្រាប់បញ្ហានេះ dev ក៏នឹងត្រូវការកន្លែងទំនេរផងដែរ។ ប៉ុន្តែដោយសារតែការពិតដែលថាយើងបានយកមូលដ្ឋាននៃ 4,5 terabytes ZFS នឹងបង្ហាប់វាទៅ 3,5 terabytes ។ វាអាចប្រែប្រួលអាស្រ័យលើការកំណត់។ ហើយយើងនៅតែមានកន្លែងសម្រាប់ dev ។

ប្រព័ន្ធបែបនេះអាចត្រូវបានប្រើសម្រាប់ករណីផ្សេងៗគ្នា។

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

ជាមួយនឹងវិធីសាស្រ្តនេះ:

ប្រូបាប៊ីលីតេទាបនៃកំហុសនៅលើ "ផលិតផល" ពីព្រោះយើងបានសាកល្បងការផ្លាស់ប្តូរទាំងអស់លើទិន្នន័យទំហំពេញ។
យើងមានវប្បធម៌នៃការធ្វើតេស្ត ព្រោះឥឡូវនេះអ្នកមិនចាំបាច់រង់ចាំរាប់ម៉ោងសម្រាប់ការឈររបស់អ្នកទេ។
ហើយគ្មានការរារាំង មិនបាច់រង់ចាំរវាងការធ្វើតេស្ត។ អ្នកពិតជាអាចទៅពិនិត្យ។ ហើយវានឹងកាន់តែប្រសើរឡើងតាមវិធីនេះ នៅពេលដែលយើងបង្កើនល្បឿននៃការអភិវឌ្ឍន៍។

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

នេះមានប្រយោជន៍ព្រោះយើងចែករំលែកធនធាននៃកៅអីសាកល្បង។

រួចរាល់ហើយ ប៉ុន្តែតើមានអ្វីទៀតដែលអាចពន្លឿន?

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

ឥឡូវនេះ មានរង្វង់ដ៏កាចសាហាវមួយ នៅពេលដែលអ្នកអភិវឌ្ឍន៍ ដើម្បីទទួលបានទិន្នន័យពេញលេញពិតប្រាកដ ត្រូវតែក្លាយជាអ្នកជំនាញ។ គាត់ត្រូវតែជឿជាក់ជាមួយនឹងការចូលប្រើបែបនេះ។

ប៉ុន្តែរបៀបលូតលាស់ប្រសិនបើវាមិននៅទីនោះ។ ចុះបើអ្នកមានទិន្នន័យសាកល្បងតិចតួចបំផុតដែលមានសម្រាប់អ្នក? បន្ទាប់មកអ្នកនឹងមិនទទួលបានបទពិសោធន៍ពិតប្រាកដណាមួយឡើយ។

តើធ្វើដូចម្តេចដើម្បីចេញពីរង្វង់នេះ? ជាចំណុចប្រទាក់ទីមួយ ដែលងាយស្រួលសម្រាប់អ្នកអភិវឌ្ឍន៍កម្រិតណាមួយ យើងបានជ្រើសរើស Slack bot ។ ប៉ុន្តែវាអាចជាចំណុចប្រទាក់ផ្សេងទៀត។

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

ហើយ Slack ក៏ផ្តល់ឱ្យយើងនូវឱកាសសម្រាប់ការសហការក្រៅប្រអប់។ ដោយសារនេះគ្រាន់តែជាឆានែលមួយ អ្នកអាចចាប់ផ្តើមពិភាក្សាអំពីសំណើនេះនៅទីនោះនៅក្នុងខ្សែស្រលាយសម្រាប់សំណើបែបនេះ ping មិត្តរួមការងាររបស់អ្នក DBAs ដែលនៅខាងក្នុងក្រុមហ៊ុន។

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

ប៉ុន្តែដើម្បីឱ្យការធ្វើតេស្តទាំងនេះអាចជឿទុកចិត្តបាន អ្នកត្រូវដោះស្រាយបញ្ហានេះដោយរបៀបណា។

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

វាពិតជាល្អណាស់ដែលមានផ្នែករឹងដូចនៅក្នុងការផលិត ប៉ុន្តែវាអាចខុសគ្នា។

ចូរយើងចងចាំពីរបៀបដែល Postgres ដំណើរការជាមួយការចងចាំ។ យើងមានឃ្លាំងសម្ងាត់ពីរ។ មួយមកពីប្រព័ន្ធឯកសារ និង Postgres ដើមមួយ ពោលគឺបានចែករំលែក Buffer Cache ។

វាជារឿងសំខាន់ក្នុងការកត់សម្គាល់ថា Shared Buffer Cache ត្រូវបានបែងចែកនៅពេលដែល Postgres ចាប់ផ្តើម អាស្រ័យលើទំហំដែលអ្នកបញ្ជាក់នៅក្នុងការកំណត់។

ហើយឃ្លាំងសម្ងាត់ទីពីរប្រើកន្លែងទំនេរទាំងអស់។

ហើយនៅពេលដែលយើងបង្កើតក្លូនជាច្រើននៅលើម៉ាស៊ីនមួយ វាបង្ហាញថាយើងបំពេញអង្គចងចាំបន្តិចម្តងៗ។ ហើយតាមរបៀបដ៏ល្អ Shared Buffer Cache គឺ 25% នៃចំនួនអង្គចងចាំសរុបដែលមាននៅលើម៉ាស៊ីន។

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

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

ឧទាហរណ៍ប្រសិនបើយើងមានឃ្លាំងសម្ងាត់ធំនៅលើផលិតផលនោះ Postgres នឹងចូលចិត្តប្រើលិបិក្រម។ ហើយប្រសិនបើមិនមានទេនោះនឹងមាន SeqScan ។ ហើយតើផែនការរបស់យើងមិនស្របគ្នានឹងអ្វីទៅ?

ប៉ុន្តែនៅទីនេះយើងឈានដល់ការសន្និដ្ឋានថាតាមពិតផែនការនៅក្នុង Postgres មិនអាស្រ័យលើទំហំជាក់លាក់ដែលបានបញ្ជាក់នៅក្នុង Shared Buffer នៅក្នុងផែនការនោះទេ វាអាស្រ័យលើ effective_cache_size ។

Effective_cache_size គឺជាចំនួនប៉ាន់ស្មាននៃឃ្លាំងសម្ងាត់ដែលមានសម្រាប់យើង ពោលគឺផលបូកនៃឃ្លាំងសម្ងាត់ Buffer និងឃ្លាំងសម្ងាត់ប្រព័ន្ធឯកសារ។ នេះត្រូវបានកំណត់ដោយការកំណត់។ ហើយការចងចាំនេះមិនត្រូវបានបែងចែកទេ។

ហើយដោយសារតែប៉ារ៉ាម៉ែត្រនេះ យើងអាចបញ្ឆោត Postgres ដោយនិយាយថា យើងមានទិន្នន័យជាច្រើនដែលអាចប្រើបាន ទោះបីជាយើងមិនមានទិន្នន័យនេះក៏ដោយ។ ដូច្នេះហើយ ផែនការនឹងស្របគ្នានឹងផលិតកម្ម។

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

វាអាស្រ័យលើបន្ទុកដែលបច្ចុប្បន្ននៅលើផលិតផល។
វាអាស្រ័យលើលក្ខណៈរបស់ម៉ាស៊ីនខ្លួនឯង។

ហើយនេះគឺជាប៉ារ៉ាម៉ែត្រដោយប្រយោល ប៉ុន្តែតាមពិតយើងអាចបង្កើនប្រសិទ្ធភាពយ៉ាងពិតប្រាកដដោយចំនួនទិន្នន័យដែលសំណួរនេះនឹងអានដើម្បីទទួលបានលទ្ធផល។

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

សូមក្រឡេកមើលពីរបៀបដែល Joe ត្រូវបានធ្វើឱ្យប្រសើរជាពិសេស។

ចូរយើងទទួលយកសំណើពីប្រព័ន្ធពិតប្រាកដ។ ក្នុងករណីនេះមូលដ្ឋានទិន្នន័យគឺ 1 តេរ៉ាបៃ។ ហើយយើងចង់រាប់ចំនួនប្រកាសថ្មីៗដែលមានច្រើនជាង 10 Likes

យើងកំពុងសរសេរសារទៅឆានែល ក្លូនមួយត្រូវបានគេប្រើសម្រាប់យើង។ ហើយយើងនឹងឃើញថាសំណើបែបនេះនឹងបញ្ចប់ក្នុងរយៈពេល 2,5 នាទី។ នេះជារឿងដំបូងដែលយើងកត់សម្គាល់។

B Joe នឹងបង្ហាញអ្នកនូវការណែនាំដោយស្វ័យប្រវត្តិដោយផ្អែកលើផែនការ និងម៉ែត្រ។

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

ចូរយើងពិនិត្យមើលឱ្យបានដិតដល់នូវអ្វីដែលបានកើតឡើង។ ជាការពិតណាស់ យើងឃើញថាយើងបានអានទិន្នន័យស្ទើរតែមួយ និងកន្លះជីហ្គាបៃពីឃ្លាំងសម្ងាត់ឯកសារ ឬសូម្បីតែពីថាស។ ហើយនេះមិនល្អទេ ព្រោះយើងទទួលបានតែ ១៤២ ជួរប៉ុណ្ណោះ។

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

ហើយរឿងនេះបានកើតឡើងនៅក្នុងផែនការដោយសារតែការពិតដែលថាលក្ខខណ្ឌនៅក្នុងសំណួរនិងលក្ខខណ្ឌនៅក្នុងលិបិក្រមមួយផ្នែកមិនត្រូវគ្នាទេ។

តោះព្យាយាមធ្វើឱ្យលិបិក្រមកាន់តែច្បាស់លាស់ ហើយមើលពីរបៀបដែលការប្រតិបត្តិសំណួរផ្លាស់ប្តូរបន្ទាប់ពីនោះ។

ការបង្កើតលិបិក្រមចំណាយពេលយូរណាស់មកហើយ ប៉ុន្តែឥឡូវនេះយើងពិនិត្យមើលសំណួរ ហើយឃើញថាពេលវេលាជំនួសឱ្យ 2,5 នាទីគឺត្រឹមតែ 156 មិល្លីវិនាទី ដែលល្អគ្រប់គ្រាន់ហើយ។ ហើយយើងអានទិន្នន័យត្រឹមតែ 6 មេកាបៃប៉ុណ្ណោះ។

ហើយឥឡូវនេះយើងប្រើលិបិក្រមស្កែនតែប៉ុណ្ណោះ។

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

នេះគឺជាសំណើខុសគ្នាខ្លាំងជាងមុន។ ហើយយើងបង្កើត Flame Graphs យោងទៅតាមប៉ារ៉ាម៉ែត្រពីរ៖ នេះគឺជាចំនួនទិន្នន័យដែលថ្នាំងជាក់លាក់មួយត្រូវបានរាប់ក្នុងផែនការ និងពេលវេលា ពោលគឺពេលវេលាប្រតិបត្តិរបស់ថ្នាំង។

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

ជាការពិតណាស់អ្នករាល់គ្នាដឹងថាexplain.depesz.com។ លក្ខណៈពិសេសដ៏ល្អនៃការមើលឃើញនេះគឺថាយើងរក្សាទុកផែនការអត្ថបទ ហើយថែមទាំងដាក់ប៉ារ៉ាម៉ែត្រមូលដ្ឋានមួយចំនួនទៅក្នុងតារាងដើម្បីឱ្យយើងអាចតម្រៀបបាន។

ហើយអ្នកអភិវឌ្ឍន៍ដែលមិនទាន់បានយល់ដឹងអំពីប្រធានបទនេះក៏ប្រើគេហទំព័រ description.depesz.com ដែរ ព្រោះវាងាយស្រួលសម្រាប់ពួកគេក្នុងការស្វែងយល់ថាតើម៉ែត្រមួយណាសំខាន់ និងមួយណាមិនសំខាន់។

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

កិច្ចសហប្រតិបត្តិការ

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

វាហាក់ដូចជាយើងថាវាមានសារៈសំខាន់ក្នុងការធ្វើតេស្តលើទិន្នន័យទំហំពេញ។ ដើម្បីធ្វើដូច្នេះ យើងបានបង្កើតឧបករណ៍ Update Database Lab ដែលមាននៅក្នុងប្រភពបើកចំហ។ អ្នកក៏អាចប្រើ Joe bot ផងដែរ។ អ្នកអាចយកវាឥឡូវនេះ ហើយអនុវត្តវានៅកន្លែងរបស់អ្នក។ មគ្គុទ្ទេសក៍ទាំងអស់អាចរកបាននៅទីនោះ។

វាក៏សំខាន់ផងដែរក្នុងការកត់សម្គាល់ថាដំណោះស្រាយខ្លួនឯងមិនមែនជាបដិវត្តន៍ទេព្រោះវាមាន Delphix ប៉ុន្តែវាគឺជាដំណោះស្រាយសហគ្រាស។ វាត្រូវបានបិទទាំងស្រុងវាថ្លៃណាស់។ យើងមានជំនាញជាពិសេសនៅក្នុង Postgres ។ ទាំងនេះគឺជាផលិតផលប្រភពបើកចំហទាំងអស់។ ចូលរួមជាមួយយើង!

នេះជាកន្លែងដែលខ្ញុំបញ្ចប់។ សូមអរគុណ!

សំណួរ

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

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

សំណួរល្អ។ វាជាការសំខាន់ក្នុងការតាមដានក្លូនជាក់លាក់នៅទីនេះ។ ហើយប្រសិនបើក្លូនមានការផ្លាស់ប្តូរធំពេក វាចាប់ផ្តើមកើនឡើង នោះដំបូងយើងអាចចេញការព្រមានដល់អ្នកប្រើប្រាស់អំពីបញ្ហានេះ ឬបញ្ឈប់ការក្លូននេះភ្លាមៗ ដើម្បីកុំឱ្យយើងជួបស្ថានភាពបរាជ័យ។

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

មាន ttl មួយចំនួនសម្រាប់ក្លូននីមួយៗ។ ជាទូទៅយើងមាន ttl ថេរ។

ចុះបើមិនមែនជាអាថ៌កំបាំង?

1 ម៉ោង ឧ. ទំនេរ - 1 ម៉ោង។ បើមិនប្រើទេ យើងវាយវាទៅ។ ប៉ុន្តែគ្មានអ្វីគួរឱ្យភ្ញាក់ផ្អើលទេនៅទីនេះ ព្រោះយើងអាចលើកក្លូនក្នុងរយៈពេលប៉ុន្មានវិនាទី។ ហើយប្រសិនបើអ្នកត្រូវការវាម្តងទៀតបន្ទាប់មកសូម។

ខ្ញុំក៏ចាប់អារម្មណ៍លើជម្រើសនៃបច្ចេកវិទ្យាដែរ ព្រោះជាឧទាហរណ៍ យើងប្រើវិធីសាស្រ្តជាច្រើនស្របគ្នាសម្រាប់ហេតុផលមួយ ឬមួយផ្សេងទៀត។ ហេតុអ្វី ZFS? ហេតុអ្វីបានជាអ្នកមិនប្រើ LVM? អ្នកបានរៀបរាប់ថាមានបញ្ហាជាមួយ LVM។ តើមានបញ្ហាអ្វីខ្លះ? នៅក្នុងគំនិតរបស់ខ្ញុំ ជម្រើសដ៏ប្រសើរបំផុតគឺជាមួយនឹងការផ្ទុកនៅក្នុងលក្ខខណ្ឌនៃការអនុវត្ត។

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

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

Nikolai Samokhvalov៖ តើខ្ញុំអាចធ្វើអត្ថាធិប្បាយបន្ថែមបានទេ? ឈ្មោះរបស់ខ្ញុំគឺ Nikolay យើងធ្វើការជាមួយ Anatoly ។ ខ្ញុំយល់ស្របថាការផ្ទុកគឺអស្ចារ្យណាស់។ ហើយអតិថិជនរបស់យើងខ្លះមាន Pure Storage ជាដើម។

Anatoly បានកត់សម្គាល់យ៉ាងត្រឹមត្រូវថាយើងផ្តោតលើម៉ូឌុល។ ហើយនៅពេលអនាគត អ្នកអាចអនុវត្តចំណុចប្រទាក់មួយ - ថតរូប បង្កើតក្លូន បំផ្លាញក្លូន។ វាងាយស្រួលទាំងអស់។ ហើយការផ្ទុកគឺត្រជាក់ប្រសិនបើវាជា។

ប៉ុន្តែ ZFS មានសម្រាប់មនុស្សគ្រប់គ្នា។ DelPhix គឺគ្រប់គ្រាន់ហើយ ពួកគេមានអតិថិជន 300 នាក់។ ក្នុងចំណោមនោះ សំណាង 100 មានអតិថិជន 50 នាក់ ពោលគឺ ពួកគេមានគោលដៅនៅ NASA ។ល។ វាដល់ពេលហើយសម្រាប់មនុស្សគ្រប់គ្នាដើម្បីទទួលបានបច្ចេកវិទ្យានេះ។ នោះហើយជាមូលហេតុដែលយើងមាន Open Source Core។ យើងមានផ្នែកចំណុចប្រទាក់ដែលមិនមែនជាប្រភពបើកចំហ។ នេះគឺជាវេទិកាដែលយើងនឹងបង្ហាញ។ ប៉ុន្តែយើងចង់ឱ្យវាអាចប្រើបានសម្រាប់អ្នកគ្រប់គ្នា។ យើងចង់ធ្វើបដិវត្តន៍មួយ ដើម្បីឱ្យអ្នកសាកល្បងទាំងអស់ឈប់ទាយលើកុំព្យូទ័រយួរដៃ។ យើងត្រូវសរសេរ SELECT ហើយឃើញភ្លាមថាយឺត។ ឈប់រង់ចាំ DBA ប្រាប់អ្នកអំពីវា។ នេះគឺជាគោលដៅចម្បង។ ហើយខ្ញុំគិតថាយើងទាំងអស់គ្នានឹងមកនេះ។ ហើយយើងធ្វើរឿងនេះសម្រាប់អ្នករាល់គ្នាមាន។ ដូច្នេះ ZFS ព្រោះវានឹងមាននៅគ្រប់ទីកន្លែង។ សូមអរគុណដល់សហគមន៍សម្រាប់ការដោះស្រាយបញ្ហា និងសម្រាប់ការមានអាជ្ញាប័ណ្ណប្រភពបើកចំហ។ល។*

ស្វាគមន៍! អរគុណសម្រាប់របាយការណ៍! ខ្ញុំឈ្មោះ Maxim ។ យើងបានដោះស្រាយបញ្ហាដូចគ្នា។ ពួកគេបានសម្រេចចិត្តដោយខ្លួនឯង។ តើអ្នកចែករំលែកធនធានរវាងក្លូនទាំងនេះដោយរបៀបណា? ក្លូននីមួយៗអាចធ្វើរឿងដោយខ្លួនឯងបានគ្រប់ពេលវេលា៖ មួយសាកល្បងរឿងមួយ មួយទៀត នរណាម្នាក់បង្កើតលិបិក្រម នរណាម្នាក់មានការងារធ្ងន់។ ហើយប្រសិនបើអ្នកនៅតែអាចបែងចែកដោយ CPU បន្ទាប់មកដោយ IO តើអ្នកបែងចែកដោយរបៀបណា? នេះជាសំណួរដំបូង។

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

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

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

ខ្ញុំមានសំណួរពីរ។ នេះជាវត្ថុឡូយណាស់។ តើមានករណីដែលទិន្នន័យផលិតកម្មមានសារៈសំខាន់ ដូចជាលេខកាតឥណទានដែរឬទេ? តើមានអ្វីដែលត្រៀមខ្លួនរួចហើយឬក៏ជាកិច្ចការដាច់ដោយឡែក? ហើយសំណួរទីពីរ - តើមានអ្វីដូចនេះសម្រាប់ MySQL ទេ?

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

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

ប៉ុន្តែដោយសារប្រព័ន្ធអាចពង្រីកបាន វាក៏អាចប្រើសម្រាប់ MySQL ផងដែរ។ ហើយមានឧទាហរណ៍បែបនេះ។ Yandex មានរឿងស្រដៀងគ្នា ប៉ុន្តែពួកគេមិនបោះផ្សាយវាគ្រប់ទីកន្លែងទេ។ ពួកគេប្រើវានៅខាងក្នុង Yandex.Metrica ។ ហើយមានតែរឿងរ៉ាវអំពី MySQL ប៉ុណ្ណោះ។ ប៉ុន្តែបច្ចេកវិទ្យាគឺដូចគ្នា ZFS ។

អរគុណសម្រាប់របាយការណ៍! ខ្ញុំក៏មានសំណួរពីរបីដែរ។ អ្នកបាននិយាយថាការក្លូនអាចត្រូវបានប្រើសម្រាប់ការវិភាគ ឧទាហរណ៍ដើម្បីបង្កើតលិបិក្រមបន្ថែមនៅទីនោះ។ តើអ្នកអាចប្រាប់បន្តិចទៀតអំពីរបៀបដែលវាដំណើរការបានទេ?

ហើយខ្ញុំនឹងសួរសំណួរទីពីរភ្លាមៗអំពីភាពស្រដៀងគ្នានៃជំហរ ភាពស្រដៀងគ្នានៃផែនការ។ ផែនការនេះក៏អាស្រ័យលើស្ថិតិដែលប្រមូលបានដោយ Postgres ។ តើអ្នកដោះស្រាយបញ្ហានេះដោយរបៀបណា?

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

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

សន្ទស្សន៍នឹងត្រូវបានបង្កើតរាល់ពេល?

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

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

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

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

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

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

វាប្រែថាការអាប់ដេតនឹងប្រព្រឹត្តទៅជាស្រទាប់បន្ថែម ហើយរូបភាពថ្មីទាំងអស់នឹងដំណើរការរួចហើយ ដោយផ្អែកលើស្រទាប់នេះមែនទេ?

ពីស្រទាប់មុនដែលមកពីការចម្លងពីមុន។

ស្រទាប់មុននឹងធ្លាក់ចុះ ប៉ុន្តែពួកគេនឹងសំដៅទៅលើស្រទាប់ចាស់ ហើយតើពួកគេនឹងយករូបភាពថ្មីពីស្រទាប់ចុងក្រោយដែលបានទទួលនៅក្នុងការអាប់ដេតដែរឬទេ?

ជាទូទៅបាទ។

បន្ទាប់មកជាលទ្ធផលយើងនឹងមានរហូតដល់ផ្លែល្វានៃស្រទាប់មួយ។ ហើយយូរ ៗ ទៅពួកគេនឹងត្រូវការបង្ហាប់?

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

សួស្តី អរគុណសម្រាប់របាយការណ៍! សំណួរអំពី Joe ។ អ្នកបាននិយាយថាអតិថិជនមិនចង់ផ្តល់ឱ្យអ្នកគ្រប់គ្នាចូលប្រើទិន្នន័យនោះទេ។ និយាយយ៉ាងតឹងរឹងប្រសិនបើមនុស្សម្នាក់ទទួលបានលទ្ធផលនៃការវិភាគការវិភាគនោះគាត់អាចមើលទិន្នន័យបាន។

វាដូចនោះ។ ឧទាហរណ៍ យើងអាចសរសេរថា "SELECT FROM WHERE email = to that"។ នោះគឺយើងនឹងមិនឃើញទិន្នន័យដោយខ្លួនឯងទេ ប៉ុន្តែយើងអាចឃើញសញ្ញាប្រយោលមួយចំនួន។ នេះត្រូវតែយល់។ ប៉ុន្តែម្យ៉ាងវិញទៀត វានៅទីនោះទាំងអស់។ យើងមានសវនកម្មកំណត់ហេតុ យើងមានការគ្រប់គ្រងលើសហសេវិកផ្សេងទៀតដែលមើលឃើញផងដែរនូវអ្វីដែលអ្នកអភិវឌ្ឍន៍កំពុងធ្វើ។ ហើយប្រសិនបើនរណាម្នាក់ព្យាយាមធ្វើបែបនេះ នោះសេវាកម្មសន្តិសុខនឹងមករកពួកគេ ហើយធ្វើការលើបញ្ហានេះ។

អរុណសួស្តី អរគុណសម្រាប់របាយការណ៍! ខ្ញុំមានសំណួរខ្លីមួយ។ ប្រសិនបើក្រុមហ៊ុនមិនប្រើ Slack តើមានការចងភ្ជាប់ជាមួយវាឥឡូវនេះទេ ឬតើវាអាចទៅរួចទេសម្រាប់អ្នកអភិវឌ្ឍន៍ដើម្បីដាក់ពង្រាយ instances ដើម្បីភ្ជាប់កម្មវិធីសាកល្បងទៅមូលដ្ឋានទិន្នន័យ?

ឥឡូវនេះមានតំណភ្ជាប់ទៅកាន់ Slack ពោលគឺមិនមានអ្នកនាំសារផ្សេងទៀតទេ ប៉ុន្តែខ្ញុំពិតជាចង់ផ្តល់ការគាំទ្រដល់អ្នកនាំសារផ្សេងទៀតផងដែរ។ តើអ្នកអាចធ្វើអ្វីបាន? អ្នកអាចដាក់ពង្រាយ DB Lab ដោយគ្មាន Joe សូមទៅដោយជំនួយពី REST API ឬដោយមានជំនួយពីវេទិការបស់យើង ហើយបង្កើតក្លូន និងភ្ជាប់ជាមួយ PSQL ។ ប៉ុន្តែនេះអាចត្រូវបានធ្វើ ប្រសិនបើអ្នកត្រៀមខ្លួនរួចរាល់ហើយដើម្បីផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍របស់អ្នកចូលប្រើទិន្នន័យ ពីព្រោះវានឹងមិនមានអេក្រង់ទៀតទេ។

ខ្ញុំមិនត្រូវការស្រទាប់នេះទេ ប៉ុន្តែខ្ញុំត្រូវការឱកាសបែបនេះ។

បន្ទាប់មក បាទ វាអាចធ្វើបាន។

ប្រភព: www.habr.com

DBA bot Joe ។ Anatoly Stansler (Postgres.ai)

កិច្ចសហប្រតិបត្តិការ

សំណួរ

បន្ថែមមតិយោបល់ ответОтменить