🥇យើងសរសេរទៅ PostgreSQL លើ sublight: 1 host, 1 day, 1TB

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

#1. ការបែងចែក

អត្ថបទអំពីរបៀប និងមូលហេតុដែលវាមានតម្លៃរៀបចំ អនុវត្តការបែងចែក "តាមទ្រឹស្តី" បានរួចមកហើយ នៅទីនេះ យើងនឹងនិយាយអំពីការអនុវត្តនៃការអនុវត្តវិធីសាស្រ្តមួយចំនួននៅក្នុងរបស់យើង។ សេវាត្រួតពិនិត្យសម្រាប់ម៉ាស៊ីនមេ PostgreSQL រាប់រយ.

"អ្វីៗជាច្រើនថ្ងៃកន្លងផុតទៅ ... "

ដំបូងឡើយ ដូចជា MVP ណាមួយ គម្រោងរបស់យើងបានចាប់ផ្តើមនៅក្រោមបន្ទុកដ៏ស្រាលមួយ - ការត្រួតពិនិត្យត្រូវបានអនុវត្តសម្រាប់តែម៉ាស៊ីនមេសំខាន់ៗចំនួន 10 ប៉ុណ្ណោះ តារាងទាំងអស់មានលក្ខណៈតូចចង្អៀត... ប៉ុន្តែយូរៗទៅចំនួនម៉ាស៊ីនដែលបានត្រួតពិនិត្យកាន់តែមានកាន់តែច្រើនឡើងៗ។ ហើយជាថ្មីម្តងទៀតយើងបានព្យាយាមធ្វើអ្វីមួយជាមួយមួយ។ តារាងទំហំ 1.5TBយើងបានដឹងថា ទោះបីជាវាអាចទៅរួចក្នុងការបន្តរស់នៅបែបនេះក៏ដោយ វាពិតជាពិបាកខ្លាំងណាស់។

ពេលវេលាគឺស្ទើរតែដូចជាសម័យវីរភាព កំណែផ្សេងគ្នានៃ PostgreSQL 9.x គឺពាក់ព័ន្ធ ដូច្នេះការបែងចែកទាំងអស់ត្រូវធ្វើ "ដោយដៃ" - តាមរយៈ តារាងមរតក និងកេះ ដឹកនាំជាមួយថាមវន្ត EXECUTE.

ដំណោះស្រាយជាលទ្ធផលបានប្រែក្លាយជាសកលគ្រប់គ្រាន់ដែលវាអាចត្រូវបានបកប្រែទៅគ្រប់តារាង៖

តារាងមេ "បឋមកថា" ទទេត្រូវបានប្រកាស ដែលពិពណ៌នាទាំងអស់។ លិបិក្រម និងគន្លឹះចាំបាច់.
កំណត់ត្រាតាមទស្សនៈរបស់អតិថិជនត្រូវបានធ្វើឡើងនៅក្នុងតារាង "ឫស" និងការប្រើប្រាស់ខាងក្នុង គន្លឹះនាំផ្លូវ BEFORE INSERT កំណត់ត្រាត្រូវបានបញ្ចូល "រាងកាយ" ទៅក្នុងផ្នែកដែលត្រូវការ។ បើមិនទាន់មានរឿងបែបនេះទេ យើងចាប់បានករណីលើកលែងហើយ...
… ដោយប្រើ CREATE TABLE ... (LIKE ... INCLUDING ...) ត្រូវបានបង្កើតឡើងដោយផ្អែកលើគំរូនៃតារាងមេ ផ្នែកជាមួយនឹងការរឹតបន្តឹងលើកាលបរិច្ឆេទដែលចង់បានដូច្នេះនៅពេលដែលទិន្នន័យត្រូវបានទាញយក ការអានត្រូវបានអនុវត្តតែនៅក្នុងវាប៉ុណ្ណោះ។

PG10: ការប៉ុនប៉ងដំបូង

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

នៅក្នុង PG10 ស្ថានភាពនេះត្រូវបានធ្វើឱ្យប្រសើរឡើងយ៉ាងខ្លាំងដោយការអនុវត្តការគាំទ្រ ការបែងចែកដើម. ដូច្នេះហើយ យើងបានព្យាយាមអនុវត្តភ្លាមៗបន្ទាប់ពីផ្ទេរកន្លែងផ្ទុក ប៉ុន្តែ...

ដូចដែលវាបានប្រែក្លាយបន្ទាប់ពីជីកតាមរយៈសៀវភៅដៃ តារាងបែងចែកដើមនៅក្នុងកំណែនេះគឺ៖

មិនគាំទ្រការពិពណ៌នាសន្ទស្សន៍
មិនគាំទ្រការកេះនៅលើវា។
មិនអាចជា "កូនចៅ" របស់នរណាម្នាក់ឡើយ
មិនគាំទ្រ INSERT ... ON CONFLICT
មិនអាចបង្កើតផ្នែកដោយស្វ័យប្រវត្តិបានទេ។

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

PG10: ឱកាសទីពីរ

ដូច្នេះ យើងចាប់ផ្តើមដោះស្រាយបញ្ហាដែលកើតឡើងម្តងមួយៗ៖

ព្រោះកេះ និង ON CONFLICT យើងបានរកឃើញថាយើងនៅតែត្រូវការពួកគេនៅទីនេះ និងទីនោះ ដូច្នេះហើយយើងបានបង្កើតដំណាក់កាលកម្រិតមធ្យមដើម្បីដោះស្រាយពួកគេ។ តារាងប្រូកស៊ី.
កម្ចាត់ "ផ្លូវ" នៅក្នុងគន្លឹះ - នោះគឺពី EXECUTE.
ពួកគេបានយកវាចេញដោយឡែកពីគ្នា។ តារាងគំរូជាមួយសន្ទស្សន៍ទាំងអស់។ដូច្នេះពួកគេមិនមានសូម្បីតែនៅក្នុងតារាងប្រូកស៊ី។

ជាចុងក្រោយ បន្ទាប់ពីអ្វីៗទាំងអស់នេះ យើងបានបែងចែកតារាងមេ។ ការបង្កើតផ្នែកថ្មីនៅតែបន្សល់ទុកនូវមនសិការរបស់កម្មវិធី។

វចនានុក្រម "Sawing"

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

"ការពិត" ត្រូវបានបែងចែកដោយថ្ងៃជាយូរណាស់មកហើយ ដូច្នេះយើងបានលុបផ្នែកដែលហួសសម័យដោយស្ងប់ស្ងាត់ ហើយពួកគេមិនរំខានយើងទេ (កំណត់ហេតុ!) ប៉ុន្តែមានបញ្ហាជាមួយវចនានុក្រម ...

មិនមែននិយាយថាមានច្រើនទេ ប៉ុន្តែប្រហែល 100TB នៃ "ការពិត" បណ្តាលឱ្យមានវចនានុក្រម 2.5TB. អ្នកមិនអាចលុបអ្វីបានយ៉ាងងាយស្រួលពីតារាងបែបនេះ អ្នកមិនអាចបង្ហាប់វាក្នុងពេលគ្រប់គ្រាន់បានទេ ហើយការសរសេរទៅវាយឺតបន្តិចម្ដងៗ។

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

សរសេរ / អានលឿនជាងមុន ដោយសារតែទំហំផ្នែកតូចជាង
ប្រើប្រាស់ការចងចាំតិច ដោយធ្វើការជាមួយសន្ទស្សន៍បង្រួមកាន់តែច្រើន
រក្សាទុកទិន្នន័យតិច ដោយសារតែសមត្ថភាពក្នុងការយកចេញហួសសម័យយ៉ាងឆាប់រហ័ស

ជាលទ្ធផលនៃភាពស្មុគស្មាញទាំងមូលនៃវិធានការ ការផ្ទុកស៊ីភីយូថយចុះ ~ 30%, ការផ្ទុកថាស ~ 50%:

ក្នុងពេលជាមួយគ្នានេះ យើងបានបន្តសរសេរដូចគ្នាយ៉ាងពិតប្រាកដទៅក្នុងមូលដ្ឋានទិន្នន័យ ដោយគ្រាន់តែផ្ទុកតិច។

#២. ការវិវត្តនៃមូលដ្ឋានទិន្នន័យ និងការកែលម្អឡើងវិញ

ដូច្នេះយើងបានតាំងចិត្តលើអ្វីដែលយើងមាន ជារៀងរាល់ថ្ងៃមានផ្នែកផ្ទាល់ខ្លួន ជាមួយទិន្នន័យ។ តាមពិតទៅ CHECK (dt = '2018-10-12'::date) — ហើយមានសោចែកភាគនិងលក្ខខណ្ឌសម្រាប់កំណត់ត្រាធ្លាក់ចូលទៅក្នុងផ្នែកជាក់លាក់។

ដោយសាររបាយការណ៍ទាំងអស់នៅក្នុងសេវាកម្មរបស់យើងត្រូវបានបង្កើតឡើងក្នុងបរិបទនៃកាលបរិច្ឆេទជាក់លាក់មួយ សន្ទស្សន៍សម្រាប់ពួកគេចាប់តាំងពី "ពេលវេលាមិនបែងចែក" មានគ្រប់ប្រភេទ។ (ម៉ាស៊ីនមេ, កាលបរិច្ឆេទ, គំរូផែនការ), (ម៉ាស៊ីនមេ, កាលបរិច្ឆេទ, ថ្នាំងផែនការ), (កាលបរិច្ឆេទថ្នាក់កំហុស ម៉ាស៊ីនមេ)...

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

ទិសដៅនៃការបង្កើនប្រសិទ្ធភាពគឺជាក់ស្តែង - សាមញ្ញ យកវាលកាលបរិច្ឆេទចេញពីសន្ទស្សន៍ទាំងអស់។ នៅលើតារាងបែងចែក។ ដោយគិតពីបរិមាណរបស់យើង ការកើនឡើងគឺប្រហែល 1TB/សប្តាហ៍!

ឥឡូវនេះសូមកត់សម្គាល់ថា terabyte នេះនៅតែត្រូវកត់ត្រាតាមរបៀបណាមួយ។ នោះគឺយើងផងដែរ។ ឥឡូវនេះថាសគួរតែផ្ទុកតិច! រូបភាពនេះបង្ហាញយ៉ាងច្បាស់ពីប្រសិទ្ធភាពដែលទទួលបានពីការសម្អាត ដែលយើងលះបង់ក្នុងមួយសប្តាហ៍៖

#៣. "ការរីករាលដាល" បន្ទុកខ្ពស់បំផុត

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

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

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

setInterval(sendToDB, interval)

បញ្ហានៅទីនេះគឺច្បាស់ណាស់នៅក្នុងការពិតនោះ។ ខ្សែទាំងអស់ចាប់ផ្តើមនៅពេលដូចគ្នាដូច្នេះពេលវេលាបញ្ជូនរបស់ពួកគេស្ទើរតែតែងតែស្របគ្នា "ដល់ចំណុច" ។ អូ៎ #2...

ជាសំណាងល្អ នេះពិតជាងាយស្រួលក្នុងការជួសជុល បន្ថែមការរត់ "ចៃដន្យ" តាមពេលវេលា៖

setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))

#៤. យើងទុកអ្វីដែលយើងត្រូវការ

បញ្ហាផ្ទុកខ្ពស់បែបប្រពៃណីទីបីគឺ គ្មានឃ្លាំងសម្ងាត់ តើគាត់នៅឯណា អាច ក្លាយជា។

ឧទាហរណ៍ យើងបានធ្វើឱ្យវាអាចធ្វើការវិភាគទាក់ទងនឹងថ្នាំងផែនការ (ទាំងអស់នេះ Seq Scan on users) ប៉ុន្តែគិតភ្លាមៗថាពួកគេភាគច្រើនដូចគ្នា - ពួកគេភ្លេច។

ទេជាការពិតណាស់គ្មានអ្វីត្រូវបានសរសេរទៅមូលដ្ឋានទិន្នន័យម្តងទៀតទេ នេះកាត់ផ្តាច់គន្លឹះជាមួយ INSERT ... ON CONFLICT DO NOTHING. ប៉ុន្តែទិន្នន័យនេះនៅតែទៅដល់មូលដ្ឋានទិន្នន័យ ហើយវាមិនចាំបាច់ទេ។ ការអានដើម្បីពិនិត្យមើលជម្លោះ ត្រូវតែធ្វើ។ អូ៎ #3...

ភាពខុសគ្នានៃចំនួនកំណត់ត្រាដែលបានផ្ញើទៅមូលដ្ឋានទិន្នន័យមុន/បន្ទាប់ពីការបើកឃ្លាំងសម្ងាត់គឺជាក់ស្តែង៖

ហើយនេះជាការធ្លាក់ចុះនៃការផ្ទុកដែលអមមកជាមួយ៖

សរុប

"Terabyte-ក្នុងមួយថ្ងៃ" គ្រាន់តែស្តាប់ទៅគួរឱ្យខ្លាច។ ប្រសិនបើអ្នកធ្វើអ្វីគ្រប់យ៉ាងត្រឹមត្រូវ នោះគ្រាន់តែជាការប៉ុណ្ណោះ។ 2^40 បៃ / 86400 វិនាទី = ~12.5MB/sដែលសូម្បីតែវីស IDE ផ្ទៃតុត្រូវបានកាន់។ 🙂

ប៉ុន្តែធ្ងន់ធ្ងរ សូម្បីតែជាមួយនឹងបន្ទុកដប់ដងនៅពេលថ្ងៃ អ្នកអាចបំពេញតាមសមត្ថភាពរបស់ SSDs ទំនើបបានយ៉ាងងាយស្រួល។

ប្រភព: www.habr.com

យើងសរសេរក្នុង PostgreSQL នៅលើ sublight: 1 host, 1 day, 1TB