អ្វី និងមូលហេតុដែលយើងធ្វើនៅក្នុងមូលដ្ឋានទិន្នន័យប្រភពបើកចំហ។ Andrey Borodin (Yandex.Cloud)

ការរួមចំណែករបស់ Yandex ចំពោះមូលដ្ឋានទិន្នន័យខាងក្រោមនឹងត្រូវបានពិនិត្យ។

• ចុចផ្ទះ
• នាវា Odyssey
• ការងើបឡើងវិញដល់ចំណុចទាន់ពេលវេលា (WAL-G)
• PostgreSQL (រួមទាំង logerrors, Amcheck, heapcheck)
• បៃតងផ្លុំ

វីដេអូ:

សួស្តី​ពិភពលោក! ខ្ញុំឈ្មោះ Andrey Borodin ។ ហើយអ្វីដែលខ្ញុំធ្វើនៅ Yandex.Cloud គឺបង្កើតមូលដ្ឋានទិន្នន័យទំនាក់ទំនងបើកចំហជាផលប្រយោជន៍របស់អតិថិជន Yandex.Cloud និង Yandex.Cloud ។

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

ប៉ុន្តែនោះមិនមែនជារឿងសំខាន់ទេ។ រឿងមិនគួរឱ្យជឿកើតឡើង។ រឿងដែលកើតឡើងក្នុងមួយលានករណី។ ហើយនៅក្នុងបរិយាកាសពពក អ្នកត្រូវតែត្រៀមខ្លួនសម្រាប់រឿងនោះ ពីព្រោះរឿងមិនគួរឱ្យជឿក្លាយជាប្រូបាប៊ីលីតេខ្ពស់នៅពេលដែលអ្វីមួយមាននៅក្នុងទំហំ។

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

តើមានវិធីសាស្រ្តអ្វីខ្លះក្នុងការធ្វើការលើកម្មវិធីប្រភពបើកចំហ?

• វិធីសាស្រ្តត្រង់បំផុតគឺការប្រើកម្មវិធី។ ប្រសិនបើអ្នកប្រើពិធីការ ប្រសិនបើអ្នកប្រើស្តង់ដារ ប្រសិនបើអ្នកប្រើទម្រង់ ប្រសិនបើអ្នកសរសេរសំណួរនៅក្នុងកម្មវិធីប្រភពបើកចំហ នោះអ្នកបានគាំទ្រវារួចហើយ។
• អ្នកកំពុងធ្វើឱ្យប្រព័ន្ធអេកូរបស់វាកាន់តែធំ។ អ្នកធ្វើឱ្យលទ្ធភាពនៃការរកឃើញមុននៃបញ្ហាកាន់តែធំ។ អ្នកបង្កើនភាពជឿជាក់នៃប្រព័ន្ធនេះ។ អ្នកបង្កើនភាពអាចរកបាននៃអ្នកអភិវឌ្ឍន៍នៅលើទីផ្សារ។ អ្នកកែលម្អកម្មវិធីនេះ។ អ្នកគឺជាអ្នករួមចំណែករួចហើយ ប្រសិនបើអ្នកទើបតែបង្កើតស្ទីល និងចាប់អារម្មណ៍ជាមួយអ្វីមួយនៅទីនោះ។
• វិធីសាស្រ្តដែលអាចយល់បានមួយទៀតគឺការឧបត្ថម្ភកម្មវិធីប្រភពបើកចំហ។ ឧទាហរណ៍ កម្មវិធី Google Summer of Code ដ៏ល្បីល្បាញ នៅពេលដែល Google បង់លុយឱ្យសិស្សមួយចំនួនធំមកពីជុំវិញពិភពលោក ដើម្បីឱ្យពួកគេបង្កើតគម្រោងកម្មវិធីបើកចំហដែលបំពេញតម្រូវការអាជ្ញាប័ណ្ណជាក់លាក់។
• នេះគឺជាវិធីសាស្រ្តដ៏គួរឱ្យចាប់អារម្មណ៍មួយ ព្រោះវាអនុញ្ញាតឱ្យកម្មវិធីវិវឌ្ឍន៍ដោយមិនផ្លាស់ប្តូរការផ្តោតអារម្មណ៍ចេញពីសហគមន៍។ Google ក្នុងនាមជាក្រុមហ៊ុនបច្ចេកវិទ្យាយក្សមួយ មិនបាននិយាយថាយើងចង់បានមុខងារនេះទេ យើងចង់ជួសជុលកំហុសនេះហើយជាកន្លែងដែលយើងត្រូវជីក។ Google និយាយថា “ធ្វើអ្វីដែលអ្នកធ្វើ។ សូម​បន្ត​ធ្វើ​តាម​របៀប​ដែល​អ្នក​បាន​ធ្វើ ហើយ​អ្វីៗ​នឹង​ល្អ»។
• វិធីសាស្រ្តបន្ទាប់ក្នុងការចូលរួមក្នុងប្រភពបើកចំហគឺការចូលរួម។ នៅពេលអ្នកមានបញ្ហានៅក្នុងកម្មវិធីប្រភពបើកចំហ ហើយមានអ្នកអភិវឌ្ឍន៍ អ្នកអភិវឌ្ឍន៍របស់អ្នកចាប់ផ្តើមដោះស្រាយបញ្ហា។ ពួកគេចាប់ផ្តើមធ្វើឱ្យហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកកាន់តែមានប្រសិទ្ធភាព កម្មវិធីរបស់អ្នកកាន់តែលឿន និងគួរឱ្យទុកចិត្តជាងមុន។

គម្រោង Yandex ដ៏ល្បីល្បាញបំផុតមួយនៅក្នុងវិស័យកម្មវិធីប្រភពបើកចំហគឺ ClickHouse ។ នេះគឺជាមូលដ្ឋានទិន្នន័យដែលកើតមកជាការឆ្លើយតបទៅនឹងបញ្ហាប្រឈមដែលប្រឈមមុខនឹង Yandex.Metrica ។

ហើយជាមូលដ្ឋានទិន្នន័យ វាត្រូវបានបង្កើតឡើងនៅក្នុងប្រភពបើកចំហដើម្បីបង្កើតប្រព័ន្ធអេកូឡូស៊ី និងអភិវឌ្ឍវារួមគ្នាជាមួយអ្នកអភិវឌ្ឍន៍ផ្សេងទៀត (មិនត្រឹមតែនៅក្នុង Yandex ប៉ុណ្ណោះទេ)។ ហើយឥឡូវនេះនេះគឺជាគម្រោងដ៏ធំមួយដែលមានក្រុមហ៊ុនផ្សេងៗគ្នាជាច្រើនចូលរួម។

នៅក្នុង Yandex.Cloud យើងបានបង្កើត ClickHouse នៅលើកំពូលនៃ Yandex Object Storage ពោលគឺនៅលើកំពូលនៃ cloud storage។

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

តើវាអាចធ្វើបានដោយរបៀបណា? នេះគឺជាចំណុចសំខាន់នៅក្នុងរបាយការណ៍នេះ។

• យើងអាចអនុវត្ត ClickHouse លើ MDS ។ MDS គឺជាចំណុចប្រទាក់ផ្ទុកពពក Yandex ខាងក្នុង។ វាស្មុគ្រស្មាញជាងពិធីការ S3 ធម្មតា ប៉ុន្តែវាកាន់តែសមស្របសម្រាប់ឧបករណ៍ប្លុក។ វាល្អប្រសើរសម្រាប់ការកត់ត្រាទិន្នន័យ។ វាទាមទារកម្មវិធីបន្ថែម។ អ្នកសរសេរកម្មវិធីនឹងសរសេរកម្មវិធី វាថែមទាំងល្អ វាគួរឱ្យចាប់អារម្មណ៍។
• S3 គឺជាវិធីសាស្រ្តទូទៅមួយដែលធ្វើឱ្យចំណុចប្រទាក់កាន់តែសាមញ្ញក្នុងការចំណាយនៃការសម្របខ្លួនតិចជាងទៅនឹងប្រភេទមួយចំនួននៃបន្ទុកការងារ។

ជាធម្មជាតិ ដោយចង់ផ្តល់មុខងារដល់ប្រព័ន្ធអេកូ ClickHouse ទាំងមូល និងធ្វើកិច្ចការដែលត្រូវការនៅខាងក្នុង Yandex.Cloud យើងបានសម្រេចចិត្តធ្វើឱ្យប្រាកដថាសហគមន៍ ClickHouse ទាំងមូលនឹងទទួលបានអត្ថប្រយោជន៍ពីវា។ យើងបានអនុវត្ត ClickHouse លើ S3 មិនមែន ClickHouse លើ MDS ទេ។ ហើយនេះគឺជាការងារជាច្រើន។

ឯកសារយោង:

https://github.com/ClickHouse/ClickHouse/pull/7946 "ស្រទាប់អរូបីប្រព័ន្ធឯកសារ"
https://github.com/ClickHouse/ClickHouse/pull/8011 "ការរួមបញ្ចូល AWS SDK S3"
https://github.com/ClickHouse/ClickHouse/pull/8649 "ការអនុវត្តមូលដ្ឋាននៃ IDisk interafce សម្រាប់ S3"
https://github.com/ClickHouse/ClickHouse/pull/8356 "ការរួមបញ្ចូលម៉ាស៊ីនផ្ទុកកំណត់ហេតុជាមួយចំណុចប្រទាក់ IDisk"
https://github.com/ClickHouse/ClickHouse/pull/8862 "ការគាំទ្រម៉ាស៊ីនសម្រាប់ S3 និង SeekableReadBuffer"
https://github.com/ClickHouse/ClickHouse/pull/9128 "ការគាំទ្រ Stripe Log S3"
https://github.com/ClickHouse/ClickHouse/pull/9415 "ការគាំទ្រដំបូងការផ្ទុក MergeTree សម្រាប់ S3"
https://github.com/ClickHouse/ClickHouse/pull/9646 "ការ​គាំទ្រ​ពេញលេញ MergeTree សម្រាប់ S3"
https://github.com/ClickHouse/ClickHouse/pull/10126 "គាំទ្រការចម្លងមរតកមែកធាងលើ S3"
https://github.com/ClickHouse/ClickHouse/pull/11134 "បន្ថែមព័ត៌មានសម្ងាត់លំនាំដើម និងបឋមកថាផ្ទាល់ខ្លួនសម្រាប់ការផ្ទុក s3"
https://github.com/ClickHouse/ClickHouse/pull/10576 "S3 ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធប្រូកស៊ីថាមវន្ត"
https://github.com/ClickHouse/ClickHouse/pull/10744 "S3 ជាមួយកម្មវិធីដោះស្រាយប្រូកស៊ី"

នេះគឺជាបញ្ជីសំណើទាញសម្រាប់អនុវត្តប្រព័ន្ធឯកសារនិម្មិតនៅក្នុង ClickHouse ។ នេះគឺជាចំនួនដ៏ច្រើននៃសំណើទាញ។

ឯកសារយោង:

https://github.com/ClickHouse/ClickHouse/pull/9760 "ការអនុវត្តល្អបំផុតនៃតំណភ្ជាប់រឹង DiskS3"
https://github.com/ClickHouse/ClickHouse/pull/11522 "អតិថិជន S3 HTTP - ជៀសវាងការចម្លងស្ទ្រីមឆ្លើយតបទៅក្នុងអង្គចងចាំ"
https://github.com/ClickHouse/ClickHouse/pull/11561 “ជៀសវាងការចម្លងស្ទ្រីមឆ្លើយតបទាំងមូលទៅក្នុងអង្គចងចាំក្នុង S3 HTTP
អតិថិជន"
https://github.com/ClickHouse/ClickHouse/pull/13076 "សមត្ថភាពក្នុងការកំណត់ឃ្លាំងសម្ងាត់និងឯកសារលិបិក្រមសម្រាប់ថាស S3"
https://github.com/ClickHouse/ClickHouse/pull/13459 "ផ្លាស់ទីផ្នែកពី DiskLocal ទៅ DiskS3 ស្របគ្នា"

ប៉ុន្តែការងារមិនបានបញ្ចប់នៅទីនោះទេ។ បន្ទាប់​ពី​មុខងារ​នេះ​ត្រូវ​បាន​បង្កើត​ឡើង ការងារ​មួយ​ចំនួន​ទៀត​ត្រូវ​បាន​ទាមទារ​ដើម្បី​បង្កើន​ប្រសិទ្ធភាព​មុខងារ​នេះ។

ឯកសារយោង:

https://github.com/ClickHouse/ClickHouse/pull/12638 "បន្ថែមព្រឹត្តិការណ៍ SelectedRows និង SelectedBytes"
https://github.com/ClickHouse/ClickHouse/pull/12464 "បន្ថែមព្រឹត្តិការណ៍ប្រវត្តិរូបពីសំណើ S3 ទៅ system.events"
https://github.com/ClickHouse/ClickHouse/pull/13028 "បន្ថែម QueryTimeMicroseconds, SelectQueryTimeMicroseconds និង InsertQueryTimeMicroseconds"

ហើយបន្ទាប់មកវាចាំបាច់ក្នុងការធ្វើឱ្យវាអាចធ្វើរោគវិនិច្ឆ័យបាន រៀបចំការត្រួតពិនិត្យ និងធ្វើឱ្យវាអាចគ្រប់គ្រងបាន។

ហើយអ្វីៗទាំងអស់នេះត្រូវបានធ្វើឡើងដើម្បីឱ្យសហគមន៍ទាំងមូល ប្រព័ន្ធអេកូ ClickHouse ទាំងមូលបានទទួលលទ្ធផលនៃការងារនេះ។

ចូរបន្តទៅមូលដ្ឋានទិន្នន័យប្រតិបត្តិការ ទៅកាន់មូលដ្ឋានទិន្នន័យ OLTP ដែលនៅជិតខ្ញុំផ្ទាល់។

នេះគឺជាផ្នែកអភិវឌ្ឍន៍ DBMS ប្រភពបើកចំហ។ បុរសទាំងនេះកំពុងធ្វើវេទមន្តតាមដងផ្លូវ ដើម្បីកែលម្អមូលដ្ឋានទិន្នន័យបើកចំហប្រតិបត្តិការ។

គម្រោងមួយក្នុងចំណោមគម្រោង ដោយប្រើឧទាហរណ៍ដែលយើងអាចនិយាយអំពីរបៀប និងអ្វីដែលយើងធ្វើគឺ Connection Pooler នៅក្នុង Postgres។

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

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

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

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

https://pgconf.ru/2017/92899

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

https://pgconf.ru/media/2017/04/03/20170316H1_V.Borodin.pdf

ហើយយើងបានធ្វើការ។ យើងបានជួសជុលបញ្ហាដែលយើងជួបប្រទះ យើងបានជួសជុល Bouncer និងព្យាយាមជំរុញសំណើរឡើង។ ប៉ុន្តែការភ្ជាប់ខ្សែតែមួយជាមូលដ្ឋានគឺពិបាកក្នុងការធ្វើការជាមួយ។

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

យើងឈានដល់ការសន្និដ្ឋានថាយើងបានបង្កើតឧបករណ៍ភ្ជាប់ទំនាក់ទំនងផ្ទាល់ខ្លួនរបស់យើងដែលត្រូវបានគេហៅថា Odyssey ។ យើងសរសេរវាតាំងពីដំបូង។

https://www.pgcon.org/2019/schedule/events/1312.en.html

នៅឆ្នាំ 2019 នៅក្នុងសន្និសិទ PgCon ខ្ញុំបានធ្វើបទបង្ហាញអំពីឧបករណ៍នេះដល់សហគមន៍អ្នកអភិវឌ្ឍន៍។ ឥឡូវនេះយើងមានផ្កាយតិចជាង 2 នៅលើ GitHub ពោលគឺគម្រោងនេះនៅរស់ គម្រោងនេះមានប្រជាប្រិយភាព។

ហើយប្រសិនបើអ្នកបង្កើតចង្កោម Postgres នៅក្នុង Yandex.Cloud នោះវានឹងជាចង្កោមដែលមាន Odyssey ដែលភ្ជាប់មកជាមួយ ដែលត្រូវបានកំណត់រចនាសម្ព័ន្ធឡើងវិញនៅពេលធ្វើមាត្រដ្ឋានចង្កោមថយក្រោយឬទៅមុខ។

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

PgBouncer ចាប់ផ្តើមអភិវឌ្ឍលឿនជាងមុន។

ហើយឥឡូវនេះគម្រោងផ្សេងទៀតបានបង្ហាញខ្លួន។ ឧទាហរណ៍ pgagroal ដែលត្រូវបានបង្កើតឡើងដោយអ្នកអភិវឌ្ឍន៍ Red Hat ។ ពួកគេដេញតាមគោលដៅស្រដៀងគ្នា និងអនុវត្តគំនិតស្រដៀងគ្នា ប៉ុន្តែជាការពិតណាស់ ជាមួយនឹងភាពជាក់លាក់របស់ពួកគេផ្ទាល់ ដែលខិតទៅជិតអ្នកអភិវឌ្ឍន៍ pgagroal ។

ករណីមួយទៀតនៃការធ្វើការជាមួយសហគមន៍ postgres កំពុងស្ដារឡើងវិញនូវពេលវេលា។ នេះគឺជាការងើបឡើងវិញបន្ទាប់ពីការបរាជ័យ នេះគឺជាការសង្គ្រោះពីការបម្រុងទុក។

មានការបម្រុងទុកជាច្រើន ហើយពួកវាទាំងអស់គឺខុសគ្នា។ ស្ទើរតែគ្រប់អ្នកលក់ Postgres មានដំណោះស្រាយបម្រុងទុកផ្ទាល់ខ្លួន។

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

https://www.citusdata.com/blog/2017/08/18/introducing-wal-g-faster-restores-for-postgres/

ខណៈពេលដែលយើងកំពុងធ្វើការលើបញ្ហានេះ CitusData បានចាប់ផ្តើមគម្រោង WAL-G ។ នេះគឺជាប្រព័ន្ធបម្រុងទុកដែលត្រូវបានធ្វើឡើងដោយសម្លឹងមើលបរិយាកាសពពក។ ឥឡូវនេះ CitusData គឺជាផ្នែកមួយនៃ Microsoft រួចហើយ។ ហើយនៅពេលនោះ យើងពិតជាចូលចិត្តគំនិតដែលត្រូវបានដាក់នៅក្នុងការចេញផ្សាយដំបូងនៃ WAL-G ។ ហើយ​យើង​បាន​ចាប់​ផ្តើម​ចូល​រួម​ចំណែក​ក្នុង​គម្រោង​នេះ។

https://github.com/wal-g/wal-g/graphs/contributors

ឥឡូវនេះមានអ្នកអភិវឌ្ឍន៍រាប់សិបនាក់នៅក្នុងគម្រោងនេះ ប៉ុន្តែអ្នករួមចំណែកកំពូលទាំង 10 ដល់ WAL-G រួមមាន 6 Yandexoids ។ យើងបាននាំយកគំនិតជាច្រើនរបស់យើងនៅទីនោះ។ ហើយជាការពិតណាស់ យើងបានអនុវត្តវាដោយខ្លួនឯង សាកល្បងវាដោយខ្លួនឯង បញ្ចូលវាទៅក្នុងផលិតកម្មខ្លួនយើង យើងប្រើប្រាស់វាដោយខ្លួនឯង យើងខ្លួនឯងស្វែងរកកន្លែងដែលត្រូវផ្លាស់ទីបន្ទាប់ ខណៈពេលដែលធ្វើអន្តរកម្មជាមួយសហគមន៍ WAL-G ដ៏ធំ។

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

តើ​វា​មានន័យ​យ៉ាង​ដូចម្តេច? យើងកំពុងផ្សព្វផ្សាយគំនិតធំមួយ៖ ការបម្រុងទុកគួរតែមានសុវត្ថិភាព ថោកដើម្បីដំណើរការ និងលឿនតាមដែលអាចធ្វើទៅបានដើម្បីស្តារឡើងវិញ។

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

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

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

ប៉ុន្តែនោះមិនមែនទាំងអស់ទេ។ យើងចង់បានរឿងតូចមួយទៀត។ យើងចង់បានមូលដ្ឋានទិន្នន័យផ្សេងៗគ្នាជាច្រើន។ មិនមែនអតិថិជនទាំងអស់របស់យើងប្រើ Postgres ទេ។ អ្នកខ្លះប្រើ MySQL, MongoDB ។ នៅក្នុងសហគមន៍ អ្នកអភិវឌ្ឍន៍ផ្សេងទៀតបានគាំទ្រ FoundationDB ។ ហើយបញ្ជីនេះកំពុងពង្រីកឥតឈប់ឈរ។

សហគមន៍ចូលចិត្តគំនិតនៃមូលដ្ឋានទិន្នន័យដែលកំពុងដំណើរការនៅក្នុងបរិយាកាសដែលបានគ្រប់គ្រងនៅក្នុងពពក។ និងអ្នកអភិវឌ្ឍន៍រក្សានូវមូលដ្ឋានទិន្នន័យរបស់ពួកគេ ដែលអាចត្រូវបានបម្រុងទុកស្មើៗគ្នាជាមួយនឹង Postgres ជាមួយនឹងប្រព័ន្ធបម្រុងទុករបស់យើង។

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

មានមូលដ្ឋានទិន្នន័យដូចជា Postgres ។ ខ្ញុំចូលចិត្តស្នូល Postgres បំផុត។ ខ្ញុំចំណាយពេលច្រើនក្នុងការអភិវឌ្ឍន៍ស្នូល Postgres ជាមួយសហគមន៍។

ប៉ុន្តែនៅទីនេះវាត្រូវតែនិយាយថា Yandex.Cloud មានការដំឡើងខាងក្នុងនៃមូលដ្ឋានទិន្នន័យដែលបានគ្រប់គ្រង។ ហើយវាបានចាប់ផ្តើមជាយូរមកហើយនៅក្នុង Yandex.Mail ។ ជំនាញដែលឥឡូវនេះបាននាំឱ្យមានការគ្រប់គ្រង Postgres ត្រូវបានប្រមូលផ្តុំនៅពេលដែលសំបុត្រចង់ផ្លាស់ទីទៅ Postgres ។

សំបុត្រមានតម្រូវការស្រដៀងនឹងពពក។ វាត្រូវការឱ្យអ្នកអាចធ្វើមាត្រដ្ឋានដល់កំណើនអិចស្ប៉ូណង់ស្យែលដែលមិនរំពឹងទុកនៅចំណុចណាមួយនៅក្នុងទិន្នន័យរបស់អ្នក។ ហើយសំបុត្រមានផ្ទុករួចហើយជាមួយនឹងប្រអប់សំបុត្ររាប់រយលាននៃអ្នកប្រើប្រាស់មួយចំនួនធំ ដែលតែងតែធ្វើសំណើជាច្រើន។

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

ឥឡូវនេះការដំឡើងខាងក្នុងនៃ Postgres គឺជាទិន្នន័យមួយចំនួន petabytes ។ ទាំងនេះគឺជាសំណើរាប់លានក្នុងមួយវិនាទី។ ទាំងនេះគឺជាចង្កោមរាប់ពាន់។ វាមានទ្រង់ទ្រាយធំណាស់។

ប៉ុន្តែមាន nuance មួយ។ វា​មិន​ស្ថិត​នៅ​លើ​ដ្រាយ​បណ្ដាញ​ដ៏​ស្រស់​ស្អាត​នោះ​ទេ ប៉ុន្តែ​នៅ​លើ​ផ្នែក​រឹង​សាមញ្ញ​គួរ​សម។ ហើយមានបរិយាកាសសាកល្បងជាពិសេសសម្រាប់អ្វីដែលថ្មីគួរឱ្យចាប់អារម្មណ៍។

ហើយនៅពេលជាក់លាក់មួយនៅក្នុងបរិយាកាសសាកល្បង យើងបានទទួលសារដែលបង្ហាញថា invariants ខាងក្នុងនៃលិបិក្រមមូលដ្ឋានទិន្នន័យត្រូវបានបំពាន។

វិចារណញាណ គឺជាទំនាក់ទំនងប្រភេទមួយចំនួន ដែលយើងរំពឹងថានឹងមានជានិច្ច។

ស្ថានភាព​ធ្ងន់ធ្ងរ​ណាស់​សម្រាប់​យើង។ វាបង្ហាញថាទិន្នន័យមួយចំនួនអាចនឹងត្រូវបាត់បង់។ ហើយ​ការ​បាត់​បង់​ទិន្នន័យ​គឺ​ជា​អ្វី​មួយ​ដ៏​មហន្តរាយ។

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

ហើយនៅទីនេះ ស្ថានភាពមួយកើតឡើងដែលបង្ហាញថា ប្រហែលជាមានស្ថានភាពមួយដែលយើងប្រហែលជាមិនបានត្រៀមខ្លួន។ ហើយយើងបានចាប់ផ្តើមរៀបចំសម្រាប់ស្ថានភាពនេះ។

https://commitfest.postgresql.org/23/2171/

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

បំណះនេះត្រូវបានទទួលយកដោយសហគមន៍ដោយមិនមានការពិភាក្សាច្រើនទេ ព្រោះក្នុងករណីជាក់លាក់នីមួយៗ វាច្បាស់ណាស់ថាមានរឿងអាក្រក់បានកើតឡើង ហើយចាំបាច់ត្រូវរាយការណ៍ទៅកំណត់ហេតុ។

បន្ទាប់​ពី​នេះ យើង​បាន​មក​ដល់​ចំណុច​ដែល​យើង​មាន​ការ​ត្រួត​ពិនិត្យ​ដែល​ស្កែន​កំណត់​ហេតុ។ ហើយ​ក្នុង​ករណី​មាន​សារ​គួរ​ឱ្យ​សង្ស័យ គាត់​ដាស់​មន្ត្រី​កាតព្វកិច្ច ហើយ​មន្ត្រី​កាតព្វកិច្ច​ជួយ​ជួសជុល​។

តែ! ការស្កេនកំណត់ហេតុគឺជាប្រតិបត្តិការថោកមួយនៅលើចង្កោមមួយ ហើយមានតម្លៃថ្លៃយ៉ាងមហន្តរាយសម្រាប់ចង្កោមមួយពាន់។

យើងបានសរសេរផ្នែកបន្ថែមហៅថា អ្នកកាប់ឈើ. វាបង្កើតទិដ្ឋភាពនៃមូលដ្ឋានទិន្នន័យដែលអ្នកអាចជ្រើសរើសស្ថិតិដោយថោក និងរហ័សលើកំហុសកន្លងមក។ ហើយប្រសិនបើយើងត្រូវការដាស់មន្រ្តីកាតព្វកិច្ចនោះ យើងនឹងស្វែងយល់អំពីបញ្ហានេះដោយមិនស្កេនឯកសារ gigabyte ប៉ុន្តែដោយការស្រង់ចេញពីរបីបៃពីតារាង hash ។

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

https://www.postgresql.org/message-id/flat/[អ៊ីមែលការពារ]

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

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

https://www.postgresql.org/message-id/flat/[អ៊ីមែលការពារ]

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

https://commitfest.postgresql.org/29/2667/

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

យើង​បាន​សរសេរ​កូដ​ដែល​គួរ​ធ្វើ​តាម​ទាំង​អស់​ can... protocols។ យើងបានពិភាក្សាអំពីបំណះនេះមួយរយៈជាមួយ Peter Gaghan ពី Crunchy Data ។ គាត់ត្រូវកែប្រែដើមឈើ B ដែលមានស្រាប់នៅក្នុង Postgres បន្តិច ដើម្បីទទួលយកបំណះនេះ។ គាត់ត្រូវបានទទួលយក។ ហើយឥឡូវនេះ ការពិនិត្យមើលលិបិក្រមលើការចម្លងក៏មានប្រសិទ្ធភាពគ្រប់គ្រាន់ដើម្បីរកមើលការបំពានដែលយើងបានជួបប្រទះ។ នោះគឺទាំងនេះគឺជាការរំលោភបំពានដែលអាចបណ្តាលមកពីកំហុសនៅក្នុងកម្មវិធីបង្កប់ថាស កំហុសនៅក្នុង Postgres កំហុសនៅក្នុងខឺណែលលីនុច និងបញ្ហាផ្នែករឹង។ បញ្ជីយ៉ាងទូលំទូលាយនៃប្រភពនៃបញ្ហាដែលយើងកំពុងរៀបចំ។

https://www.postgresql.org/message-id/flat/38AF687F-8F6B-48B4-AB9E-A60CFD6CC261%40enterprisedb.com#0e86a12c01d967bac04a9bf83cd337cb

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

យើងមានផ្នែកបន្ថែមមួយហៅថា Heapcheck ។ យើងបានចាប់ផ្តើមអភិវឌ្ឍវា។ ហើយស្របគ្នាជាមួយយើង ក្រុមហ៊ុន EnterpriseDB ក៏ចាប់ផ្តើមសរសេរម៉ូឌុលមួយ ដែលពួកគេហៅថា Heapcheck តាមរបៀបដូចគ្នា។ មានតែយើងទេដែលហៅវាថា PgHeapcheck ហើយពួកគេគ្រាន់តែហៅវាថា Heapcheck ។ ពួកវាមានមុខងារស្រដៀងគ្នា ហត្ថលេខាខុសគ្នាបន្តិច ប៉ុន្តែមានគំនិតដូចគ្នា។ ពួកគេបានអនុវត្តវាប្រសើរជាងមុនបន្តិចនៅកន្លែងខ្លះ។ ហើយពួកគេបានបង្ហោះវានៅក្នុងប្រភពបើកចំហពីមុន។

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

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

នៅកន្លែងខ្លះ យើងថែមទាំងបានសន្និដ្ឋានថាយើងមានចំណុចវិជ្ជមានមិនពិតនៅក្នុងប្រព័ន្ធត្រួតពិនិត្យរបស់យើង។ ឧទាហរណ៍ប្រព័ន្ធ 1C ។ នៅពេលប្រើមូលដ្ឋានទិន្នន័យ ពេលខ្លះ Postgres សរសេរទិន្នន័យទៅក្នុងវា ដែលវាអាចអានបាន ប៉ុន្តែ pg_dump មិនអាចអានបានទេ។

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

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

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

សហគមន៍​បាន​ឆ្លើយ​តប​ថា "អូ យើង​ពិត​ជា​ត្រូវ​ការ​ជួសជុល​វា"។

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

តើយើងបានរៀនអ្វីខ្លះនៅទីនេះ? យើងបានរៀនរឿងសាមញ្ញមួយ៖ អ្វីដែលសំខាន់បំផុតគឺត្រូវពន្យល់សហគមន៍ថាមានបញ្ហា។ ប្រសិនបើសហគមន៍បានទទួលស្គាល់បញ្ហានោះ ការប្រកួតប្រជែងធម្មជាតិកើតឡើងដើម្បីដោះស្រាយបញ្ហា។ ដោយសារតែមនុស្សគ្រប់គ្នាចង់ដោះស្រាយបញ្ហាសំខាន់មួយ។ អ្នកលក់ទាំងអស់ ពួក Hacker ទាំងអស់យល់ថាខ្លួនគេអាចឈានជើងលើតុងរួចនេះ ដូច្នេះពួកគេចង់លុបបំបាត់ពួកគេ។

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

មូលដ្ឋានទិន្នន័យគួរឱ្យចាប់អារម្មណ៍គឺ Greenplum ។ វា​គឺ​ជា​មូលដ្ឋាន​ទិន្នន័យ​ស្រប​គ្នា​យ៉ាង​ខ្លាំង​ដែល​ផ្អែក​លើ​មូលដ្ឋាន​កូដ Postgres ដែល​ខ្ញុំ​ស្គាល់​យ៉ាង​ខ្លាំង។

https://greenplum.org/greenplum-database-tables-compression/

ហើយ Greenplum មានមុខងារគួរឱ្យចាប់អារម្មណ៍ - បន្ថែមតារាងដែលប្រសើរឡើង។ ទាំងនេះគឺជាតារាងដែលអ្នកអាចបន្ថែមបានយ៉ាងឆាប់រហ័ស។ ពួកវាអាចជាជួរឈរឬជួរដេក។

ប៉ុន្តែមិនមានការចង្កោមទេ ពោលគឺមិនមានមុខងារដែលអ្នកអាចរៀបចំទិន្នន័យដែលមានទីតាំងក្នុងតារាងស្របតាមលំដាប់ដែលមាននៅក្នុងសន្ទស្សន៍មួយ។

បុរស​ជិះ​តាក់ស៊ី​មក​រក​ខ្ញុំ ហើយ​និយាយ​ថា ៖ « Andrey អ្នក​ស្គាល់ Postgres ។ ហើយនៅទីនេះវាស្ទើរតែដូចគ្នា។ ប្តូរទៅ 20 នាទី។ អ្នកយកវាហើយធ្វើវា។ ខ្ញុំគិតថា បាទ ខ្ញុំស្គាល់ Postgres ដោយប្តូររយៈពេល 20 នាទី - ខ្ញុំត្រូវធ្វើរឿងនេះ។

https://github.com/greenplum-db/gpdb/commit/179feb77a034c2547021d675082aae0911be40f7

ប៉ុន្តែមិនមែន 20 នាទីទេ ខ្ញុំសរសេរវាច្រើនខែ។ នៅក្នុងសន្និសិទ PgConf.Russia ខ្ញុំបានទៅជួប Heikki Linakangas ពី Pivotal ហើយបានសួរថា “តើមានបញ្ហាជាមួយនេះទេ? ហេតុ​អ្វី​បាន​ជា​មិន​មាន​ឧបសម្ព័ន្ធ​តារាង​ដែល​បាន​ធ្វើ​ឱ្យ​ប្រសើរ​ឡើង​? គាត់និយាយថា“ អ្នកយកទិន្នន័យ។ អ្នកតម្រៀប អ្នករៀបចំឡើងវិញ។ វា​គ្រាន់​តែ​ជា​ការងារ»។ ខ្ញុំ៖ "អូ បាទ អ្នកគ្រាន់តែត្រូវការវា ហើយធ្វើវា" ។ គាត់​និយាយ​ថា​៖ ​«​បាទ យើង​ត្រូវ​ការ​ដៃ​ទំនេរ​ដើម្បី​ធ្វើ​កិច្ចការ​នេះ​»។ ខ្ញុំ​គិត​ថា​ខ្ញុំ​ច្បាស់​ជា​ត្រូវ​ធ្វើ​រឿង​នេះ។

ហើយពីរបីខែក្រោយមកខ្ញុំបានដាក់សំណើរទាញដែលអនុវត្តមុខងារនេះ។ សំណើទាញនេះត្រូវបានពិនិត្យដោយ Pivotal រួមគ្នាជាមួយសហគមន៍។ ជាការពិតណាស់មានកំហុស។

https://github.com/greenplum-db/gpdb/issues/10150

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

https://github.com/greenplum-db/gpdb/pull/10290

ខ្ញុំបានជួសជុលកំហុសនេះ។ បានផ្ញើសំណើទាញទៅកាន់អ្នកជួសជុល។ គាត់ត្រូវបានគេសម្លាប់។

https://github.com/greenplum-db/gpdb-postgres-merge/pull/53

បន្ទាប់ពីនោះវាបានប្រែក្លាយថាមុខងារនេះចាំបាច់ត្រូវទទួលបាននៅក្នុងកំណែ Greenplum សម្រាប់ PostgreSQL 12។ នោះគឺជាដំណើរផ្សងព្រេងរយៈពេល 20 នាទីបន្តជាមួយនឹងដំណើរផ្សងព្រេងដ៏គួរឱ្យចាប់អារម្មណ៍ថ្មីៗ។ វាគួរឱ្យចាប់អារម្មណ៍ក្នុងការប៉ះការអភិវឌ្ឍន៍បច្ចុប្បន្ន ដែលសហគមន៍កំពុងកាត់បន្ថយលក្ខណៈពិសេសថ្មីៗ និងសំខាន់បំផុត។ វាកក។

https://github.com/greenplum-db/gpdb/pull/10565

ប៉ុន្តែវាមិនបានបញ្ចប់នៅទីនោះទេ។ បន្ទាប់ពីអ្វីៗគ្រប់យ៉ាងវាប្រែថាយើងត្រូវសរសេរឯកសារសម្រាប់អ្វីៗទាំងអស់នេះ។

ខ្ញុំចាប់ផ្តើមសរសេរឯកសារ។ ជាសំណាងល្អ អ្នកឯកសារមកពី Pivotal បានមកជាមួយ។ ភាសាអង់គ្លេសគឺជាភាសាកំណើតរបស់ពួកគេ។ ពួកគេបានជួយខ្ញុំជាមួយឯកសារ។ តាមពិត ពួកគេ​ខ្លួនឯង​បាន​សរសេរ​ឡើងវិញ​នូវ​អ្វីដែល​ខ្ញុំ​បាន​ស្នើ​ទៅជា​ភាសាអង់គ្លេស​ពិតប្រាកដ។

ហើយនៅទីនេះ វាហាក់ដូចជា ការផ្សងព្រេងបានបញ្ចប់។ ហើយ​តើ​អ្នក​ដឹង​ថា​មាន​អ្វី​កើត​ឡើង​នៅ​ពេល​នោះ? បុរស​ជិះ​តាក់ស៊ី​មក​រក​ខ្ញុំ​ហើយ​និយាយ​ថា​៖ «​នៅ​មាន​ដំណើរ​ផ្សងព្រេង​ពីរ​ទៀត​គឺ​រយៈពេល​ ១០ នាទី​»​។ ហើយតើខ្ញុំគួរប្រាប់ពួកគេអំពីអ្វី? ខ្ញុំ​បាន​និយាយ​ថា​ឥឡូវ​នេះ​ខ្ញុំ​នឹង​ផ្តល់​របាយការណ៍​ជា​ខ្នាត​បន្ទាប់​មក​យើង​នឹង​ឃើញ​ដំណើរ​ផ្សងព្រេង​របស់​អ្នក​ព្រោះ​នេះ​ជា​ការងារ​គួរ​ឱ្យ​ចាប់​អារម្មណ៍​។

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

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

អស់ហើយ។ ចូរយើងបន្តទៅសំណួរ។

វគ្គសំណួរ

សួស្តី! យើងមានវគ្គសំណួរ និងចម្លើយមួយទៀត។ ហើយនៅក្នុងស្ទូឌីយោ Andrei Borodin ។ នេះគឺជាមនុស្សដែលទើបតែប្រាប់អ្នកអំពីការរួមចំណែករបស់ Yandex.Cloud និង Yandex ទៅកាន់ប្រភពបើកចំហ។ របាយការណ៍របស់យើងឥឡូវនេះគឺមិនមែនទាំងស្រុងអំពី Cloud ទេ ប៉ុន្តែនៅពេលជាមួយគ្នានេះដែរ យើងផ្អែកលើបច្ចេកវិទ្យាបែបនេះ។ បើគ្មានអ្វីដែលអ្នកបានធ្វើនៅក្នុង Yandex នោះវានឹងមិនមានសេវាកម្មនៅក្នុង Yandex.Cloud ទេ ដូច្នេះសូមអរគុណពីខ្ញុំផ្ទាល់។ ហើយសំណួរដំបូងពីការផ្សាយ៖ "តើគម្រោងនីមួយៗដែលអ្នកបានលើកឡើងនោះសរសេរលើអ្វី?"

ប្រព័ន្ធបម្រុងទុកនៅក្នុង WAL-G ត្រូវបានសរសេរនៅក្នុង Go ។ នេះ​ជា​គម្រោង​ថ្មី​មួយ​ក្នុង​ចំណោម​គម្រោង​ថ្មី​ជាង​នេះ​ដែល​យើង​បាន​ធ្វើ។ គាត់មានអាយុត្រឹមតែ 3 ឆ្នាំប៉ុណ្ណោះ។ ហើយមូលដ្ឋានទិន្នន័យជារឿយៗនិយាយអំពីភាពអាចជឿជាក់បាន។ ហើយនេះមានន័យថា មូលដ្ឋានទិន្នន័យគឺចាស់ណាស់ ហើយជាធម្មតាវាត្រូវបានសរសេរនៅក្នុង C. គម្រោង Postgres បានចាប់ផ្តើមប្រហែល 30 ឆ្នាំមុន។ បន្ទាប់មក C89 គឺជាជម្រើសដ៏ត្រឹមត្រូវ។ ហើយ Postgres ត្រូវបានសរសេរនៅលើវា។ មូលដ្ឋានទិន្នន័យទំនើបជាច្រើនទៀតដូចជា ClickHouse ជាធម្មតាត្រូវបានសរសេរនៅក្នុង C++ ។ ការអភិវឌ្ឍន៍ប្រព័ន្ធទាំងអស់គឺផ្អែកលើ C និង C ++ ។

សំណួរមួយពីអ្នកគ្រប់គ្រងហិរញ្ញវត្ថុរបស់យើង ដែលជាអ្នកទទួលខុសត្រូវលើការចំណាយនៅ Cloud៖ "ហេតុអ្វីបានជា Cloud ចំណាយលុយលើការគាំទ្រប្រភពបើកចំហ?"

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

សំណួរមួយទៀត៖ "តើតម្រូវការរបស់អ្នកប្រើប្រាស់ខាងក្រៅដែលរស់នៅក្នុង Yandex.Cloud ខុសពីអ្នកប្រើប្រាស់ខាងក្នុងដែលរស់នៅក្នុង Cloud ខាងក្នុងឬ?"

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

សំណួរបន្ទាប់៖ "តើអ្នកមានអារម្មណ៍យ៉ាងណាចំពោះការពិតដែលថាអ្វីដែលអ្នកធ្វើត្រូវបានប្រើប្រាស់ដោយ Clouds ផ្សេងទៀត?" យើងនឹងមិនដាក់ឈ្មោះជាក់លាក់នោះទេ ប៉ុន្តែគម្រោងជាច្រើនដែលត្រូវបានធ្វើនៅក្នុង Yandex.Cloud ត្រូវបានប្រើនៅក្នុងពពករបស់អ្នកដទៃ។

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

អ្នកបាននិយាយច្រើនអំពីការរត់ម៉ារ៉ាតុង។ ខ្ញុំដឹងថាអ្នករត់ម៉ារ៉ាតុងនៅទីក្រុងម៉ូស្គូ។ ជា​លទ្ធផល? វ៉ាដាច់បុរសពី PostgreSQL?

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

តើអ្នកនិយាយថាគ្មានអ្នករត់នៅ ClickHouse ទេ?

ខ្ញុំដឹងច្បាស់ថាពួកគេនៅទីនោះ។ ClickHouse ក៏ជាមូលដ្ឋានទិន្នន័យផងដែរ។ និយាយអីញ្ចឹង Oleg ឥឡូវនេះកំពុងសរសេរមកខ្ញុំថា "តើយើងនឹងរត់តាមរបាយការណ៍ទេ?" នេះគឺជាគំនិតដ៏អស្ចារ្យមួយ។

សំណួរមួយទៀតពីការផ្សាយពី Nikita: "ហេតុអ្វីបានជាអ្នកជួសជុលកំហុសនៅក្នុង Greenplum ដោយខ្លួនឯងហើយមិនផ្តល់ឱ្យវាដល់យុវជន?" ពិតហើយ វាមិនច្បាស់ទេថាអ្វីជាកំហុស និងនៅក្នុងសេវាកម្មមួយណា ប៉ុន្តែវាប្រហែលជាមានន័យថាជាកំហុសដែលអ្នកបាននិយាយ។

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

ដោយសារ​យើង​កំពុង​និយាយ​អំពី​ក្មេង​តូចៗ នេះ​ជា​សំណួរ។ បុគ្គលនោះបានសម្រេចចិត្តបង្កើតការប្តេជ្ញាចិត្តដំបូងនៅ Postgres ។ តើ​គាត់​ត្រូវ​ធ្វើ​អ្វី​ដើម្បី​ធ្វើ​ការ​តាំង​ចិត្ត​ដំបូង?

នេះគឺជាសំណួរគួរឱ្យចាប់អារម្មណ៍មួយ: "កន្លែងដែលត្រូវចាប់ផ្តើម?" ជាធម្មតាវាពិបាកណាស់ក្នុងការចាប់ផ្តើមជាមួយអ្វីមួយនៅក្នុងខឺណែល។ ជាឧទាហរណ៍ នៅក្នុង Postgres មានបញ្ជីដែលត្រូវធ្វើ។ ប៉ុន្តែ​តាម​ពិត នេះ​ជា​សន្លឹក​នៃ​អ្វី​ដែល​គេ​ព្យាយាម​ធ្វើ​តែ​មិន​បាន​ជោគជ័យ។ ទាំងនេះគឺជារឿងស្មុគស្មាញ។ ហើយជាធម្មតាអ្នកអាចរកឃើញឧបករណ៍ប្រើប្រាស់មួយចំនួននៅក្នុងប្រព័ន្ធអេកូ ផ្នែកបន្ថែមមួយចំនួនដែលអាចត្រូវបានកែលម្អ ដែលទាក់ទាញការយកចិត្តទុកដាក់តិចពីអ្នកអភិវឌ្ឍន៍ខឺណែល។ ហើយតាមនោះ មានចំណុចជាច្រើនទៀតសម្រាប់កំណើននៅទីនោះ។ នៅឯកម្មវិធី Google Summer of code ជារៀងរាល់ឆ្នាំសហគមន៍ postgres បង្ហាញប្រធានបទផ្សេងៗគ្នាជាច្រើនដែលអាចដោះស្រាយបាន។ ខ្ញុំគិតថាឆ្នាំនេះយើងមានសិស្សបីនាក់។ មនុស្សម្នាក់ថែមទាំងបានសរសេរនៅក្នុង WAL-G លើប្រធានបទដែលមានសារៈសំខាន់សម្រាប់ Yandex ។ នៅក្នុង Greenplum អ្វីគ្រប់យ៉ាងគឺសាមញ្ញជាងនៅក្នុងសហគមន៍ Postgres ពីព្រោះពួក Hacker Greenplum ព្យាបាលសំណើរទាញបានយ៉ាងល្អ ហើយចាប់ផ្តើមពិនិត្យមើលភ្លាមៗ។ ការផ្ញើបំណះទៅ Postgres គឺជាបញ្ហាជាច្រើនខែ ប៉ុន្តែ Greenplum នឹងមកក្នុងមួយថ្ងៃ ហើយមើលអ្វីដែលអ្នកបានធ្វើ។ រឿងមួយទៀតគឺថា Greenplum ត្រូវការដោះស្រាយបញ្ហាបច្ចុប្បន្ន។ Greenplum មិនត្រូវបានគេប្រើយ៉ាងទូលំទូលាយទេ ដូច្នេះការស្វែងរកបញ្ហារបស់អ្នកគឺពិបាកណាស់។ ហើយជាដំបូង យើងត្រូវដោះស្រាយបញ្ហា។

ប្រភព: www.habr.com