កាសាន់ដ្រា។ ធ្វើម៉េចមិនស្លាប់ បើអ្នកស្គាល់តែ Oracle

ហេ ហាប់

ឈ្មោះរបស់ខ្ញុំគឺ Misha Butrimov ខ្ញុំចង់ប្រាប់អ្នកបន្តិចអំពី Cassandra ។ រឿងរបស់ខ្ញុំនឹងមានប្រយោជន៍សម្រាប់អ្នកដែលមិនធ្លាប់ជួបប្រទះនឹងមូលដ្ឋានទិន្នន័យ NoSQL - វាមានមុខងារអនុវត្ត និងបញ្ហាជាច្រើនដែលអ្នកត្រូវដឹង។ ហើយ​ប្រសិន​បើ​អ្នក​មិន​បាន​ឃើញ​អ្វី​ក្រៅ​ពី Oracle ឬ​មូលដ្ឋាន​ទិន្នន័យ​ទំនាក់​ទំនង​ណា​មួយ​ទេ របស់​ទាំង​នេះ​នឹង​ជួយ​សង្គ្រោះ​ជីវិត​អ្នក។

តើ Cassandra ល្អយ៉ាងណា? វាគឺជាមូលដ្ឋានទិន្នន័យ NoSQL ដែលត្រូវបានរចនាឡើងដោយគ្មានចំណុចនៃការបរាជ័យតែមួយដែលធ្វើមាត្រដ្ឋានបានល្អ។ ប្រសិនបើអ្នកត្រូវការបន្ថែមពីរបី terabytes សម្រាប់មូលដ្ឋានទិន្នន័យមួយចំនួន អ្នកគ្រាន់តែបន្ថែមថ្នាំងទៅចិញ្ចៀន។ ពង្រីកវាទៅមជ្ឈមណ្ឌលទិន្នន័យផ្សេងទៀត? បន្ថែមថ្នាំងទៅចង្កោម។ បង្កើន RPS ដំណើរការ? បន្ថែមថ្នាំងទៅចង្កោម។ វាក៏ដំណើរការក្នុងទិសដៅផ្ទុយដែរ។

តើនាងពូកែអ្វីទៀត? វានិយាយអំពីការដោះស្រាយសំណើជាច្រើន។ ប៉ុន្តែតើចំនួនប៉ុន្មាន? សំណើ 10, 20, 30, 40 ពាន់ក្នុងមួយវិនាទីគឺមិនច្រើនទេ។ 100 ពាន់សំណើក្នុងមួយវិនាទីសម្រាប់ការថត - ផងដែរ។ មានក្រុមហ៊ុនដែលបាននិយាយថាពួកគេរក្សាការស្នើសុំ 2 លានក្នុងមួយវិនាទី។ ពួកគេប្រហែលជាត្រូវជឿ។

ហើយជាគោលការណ៍ Cassandra មានភាពខុសគ្នាដ៏ធំមួយពីទិន្នន័យទំនាក់ទំនង - វាមិនស្រដៀងនឹងពួកគេទាល់តែសោះ។ ហើយនេះគឺសំខាន់ណាស់ក្នុងការចងចាំ។

មិនមែនអ្វីៗទាំងអស់ដែលមើលទៅដូចគ្នា ដំណើរការដូចគ្នានោះទេ។

នៅពេលដែលសហសេវិកម្នាក់បានមករកខ្ញុំហើយបានសួរថា: “នេះគឺជាភាសាសំណួរ CQL Cassandra ហើយវាមានសេចក្តីថ្លែងការណ៍ជ្រើសរើស វាមានកន្លែងណា វាមាន និង។ ខ្ញុំសរសេរអក្សរហើយវាមិនដំណើរការទេ។ ហេតុអ្វី?" ការព្យាបាល Cassandra ដូចជាមូលដ្ឋានទិន្នន័យទំនាក់ទំនងគឺជាវិធីដ៏ល្អឥតខ្ចោះដើម្បីធ្វើអត្តឃាតដោយហិង្សា។ ហើយខ្ញុំមិនផ្សព្វផ្សាយវាទេ វាត្រូវបានហាមឃាត់នៅក្នុងប្រទេសរុស្ស៊ី។ អ្នកគ្រាន់តែរចនាអ្វីមួយខុស។

ជាឧទាហរណ៍ អតិថិជនម្នាក់មករកយើងហើយនិយាយថា៖ “តោះបង្កើតមូលដ្ឋានទិន្នន័យសម្រាប់រឿងភាគទូរទស្សន៍ ឬមូលដ្ឋានទិន្នន័យសម្រាប់បញ្ជីមុខម្ហូប។ យើង​នឹង​មាន​ម្ហូប​អាហារ​នៅ​ទី​នោះ ឬ​បញ្ជី​រឿង​ភាគ​ទូរទស្សន៍ និង​តារា​សម្ដែង​ក្នុង​នោះ»។ យើងនិយាយដោយរីករាយ៖ “តោះ!” គ្រាន់តែផ្ញើពីរបៃ សញ្ញាពីរបី ហើយអ្នករួចរាល់ អ្វីៗនឹងដំណើរការលឿន និងអាចទុកចិត្តបាន។ ហើយអ្វីគ្រប់យ៉ាងគឺល្អរហូតដល់អតិថិជនមកនិយាយថាស្ត្រីមេផ្ទះក៏កំពុងដោះស្រាយបញ្ហាផ្ទុយដែរ: ពួកគេមានបញ្ជីផលិតផលហើយពួកគេចង់ដឹងថាតើពួកគេចង់ចំអិនម្ហូបអ្វី។ អ្នក​គឺ​ស្លាប់។

នេះដោយសារតែ Cassandra គឺជាមូលដ្ឋានទិន្នន័យកូនកាត់៖ វាក្នុងពេលដំណាលគ្នាផ្តល់នូវតម្លៃគន្លឹះ និងរក្សាទុកទិន្នន័យក្នុងជួរឈរធំទូលាយ។ នៅក្នុង Java ឬ Kotlin វាអាចត្រូវបានពិពណ៌នាដូចនេះ៖

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

នោះគឺផែនទីដែលមានផែនទីតម្រៀបផងដែរ។ គ្រាប់ចុចទីមួយនៃផែនទីនេះគឺគ្រាប់ចុចជួរដេក ឬគ្រាប់ចុចបែងចែក - គ្រាប់ចុចបែងចែក។ កូនសោទីពីរ ដែលជាគន្លឹះនៃផែនទីដែលបានតម្រៀបរួចហើយ គឺជាកូនសោរចង្កោម។

ដើម្បីបង្ហាញពីការចែកចាយនៃមូលដ្ឋានទិន្នន័យ ចូរយើងគូរថ្នាំងបី។ ឥឡូវអ្នកត្រូវយល់ពីរបៀបបំបែកទិន្នន័យទៅជាថ្នាំង។ ដោយសារតែប្រសិនបើយើងបង្រួបបង្រួមអ្វីគ្រប់យ៉ាងទៅជាមួយ (ដោយវិធីនេះអាចមានមួយពាន់ពីរពាន់ប្រាំ - ជាច្រើនតាមដែលអ្នកចូលចិត្ត) នេះមិនមែនជាការចែកចាយទេ។ ដូច្នេះ​ហើយ យើង​ត្រូវ​ការ​អនុគមន៍​គណិតវិទ្យា​ដែល​នឹង​ត្រឡប់​លេខ​មួយ។ គ្រាន់តែលេខមួយ int វែងដែលនឹងធ្លាក់ចូលទៅក្នុងជួរមួយចំនួន។ ហើយ​យើង​នឹង​មាន​ថ្នាំង​មួយ​ដែល​ទទួល​ខុស​ត្រូវ​សម្រាប់​ជួរ​មួយ, ទីពីរ​សម្រាប់​ទីពីរ, nth មួយ​សម្រាប់ nth ។

លេខ​នេះ​ត្រូវ​បាន​យក​ដោយ​ប្រើ​មុខងារ hash ដែល​ត្រូវ​បាន​អនុវត្ត​ទៅ​នឹង​អ្វី​ដែល​យើង​ហៅ​ថា Partition key។ នេះ​ជា​ជួរ​ឈរ​ដែល​ត្រូវ​បាន​បញ្ជាក់​ក្នុង​ការ​ណែនាំ​គន្លឹះ​ចម្បង ហើយ​នេះ​ជា​ជួរ​ឈរ​ដែល​នឹង​ជា​គន្លឹះ​ដំបូង​បំផុត​និង​មូលដ្ឋាន​បំផុត​នៃ​ផែនទី។ វាកំណត់ថាថ្នាំងណានឹងទទួលបានទិន្នន័យណាមួយ។ តារាងមួយត្រូវបានបង្កើតនៅក្នុង Cassandra ជាមួយនឹងវាក្យសម្ព័ន្ធស្ទើរតែដូចគ្នានៅក្នុង SQL៖

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

កូនសោចម្បងក្នុងករណីនេះមានជួរឈរមួយ ហើយវាក៏ជាសោបែងចែកផងដែរ។

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

ជ្រើសរើស៖ នៅពេលអនុញ្ញាតការត្រង ប្រែទៅជាការស្កេនពេញលេញ ឬអ្វីដែលមិនគួរធ្វើ

តោះសរសេរសេចក្តីថ្លែងការណ៍ជ្រើសរើសមួយចំនួន៖ select * from users where, userid = . វាប្រែចេញដូចជានៅក្នុង Oracle៖ យើងសរសេរជ្រើសរើស បញ្ជាក់លក្ខខណ្ឌ ហើយអ្វីៗដំណើរការ អ្នកប្រើប្រាស់ទទួលបានវា។ ប៉ុន្តែប្រសិនបើអ្នកជ្រើសរើសឧទាហរណ៍ អ្នកប្រើប្រាស់ដែលមានឆ្នាំកំណើតជាក់លាក់ Cassandra ត្អូញត្អែរថាវាមិនអាចបំពេញតាមសំណើបានទេ។ ដោយសារតែនាងមិនដឹងអ្វីទាំងអស់អំពីរបៀបដែលយើងចែកចាយទិន្នន័យអំពីឆ្នាំកំណើត - នាងមានជួរឈរតែមួយគត់ដែលចង្អុលបង្ហាញជាគន្លឹះ។ បន្ទាប់មកនាងនិយាយថា “មិនអីទេ ខ្ញុំនៅតែអាចបំពេញសំណើនេះ។ បន្ថែមការអនុញ្ញាតតម្រង។" យើងបន្ថែមការណែនាំ អ្វីៗដំណើរការ។ ហើយនៅពេលនេះមានអ្វីដ៏គួរឱ្យភ័យខ្លាចកើតឡើង។

នៅពេលដែលយើងដំណើរការលើទិន្នន័យសាកល្បង អ្វីគ្រប់យ៉ាងគឺល្អ។ ហើយនៅពេលដែលអ្នកអនុវត្តសំណួរនៅក្នុងផលិតកម្ម ដែលជាកន្លែងដែលយើងមានឧទាហរណ៍ 4 លានកំណត់ត្រា នោះអ្វីៗគឺមិនល្អសម្រាប់យើងទេ។ ដោយសារតែអនុញ្ញាតឱ្យតម្រងគឺជាការណែនាំដែលអនុញ្ញាតឱ្យ Cassandra ប្រមូលទិន្នន័យទាំងអស់ពីតារាងនេះពីគ្រប់ថ្នាំងទាំងអស់ មជ្ឈមណ្ឌលទិន្នន័យទាំងអស់ (ប្រសិនបើមានពួកវាច្រើននៅក្នុងចង្កោមនេះ) ហើយមានតែបន្ទាប់មកត្រងវា។ នេះគឺជា analogue នៃ Full Scan ហើយស្ទើរតែគ្មាននរណាម្នាក់រីករាយនឹងវាទេ។

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

ហើយនាងក៏មានកូនសោមួយផងដែរ ដែលយើងហៅថា Clustering Key។ កូនសោនេះ រួម​មាន​ជួរ​ឈរ​ដែល​យើង​ជ្រើសរើស ដោយ​មាន​ជំនួយ​ដែល Cassandra យល់​ពី​របៀប​ដែល​ទិន្នន័យ​របស់​វា​ត្រូវ​បាន​តម្រៀប​តាម​លក្ខណៈ​រូបវិទ្យា ហើយ​នឹង​មាន​ទីតាំង​នៅ​លើ​ថ្នាំង​នីមួយៗ។ នោះគឺសម្រាប់ Partition key មួយចំនួន Clustering key នឹងប្រាប់អ្នកយ៉ាងច្បាស់លាស់ពីរបៀបរុញទិន្នន័យចូលទៅក្នុងដើមឈើនេះ តើកន្លែងណាដែលវានឹងយកនៅទីនោះ។

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

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

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

យើងកំណត់ការតម្រៀប និងដាក់កម្រិត

អ្នកត្រូវចាំថា លំដាប់តម្រៀប (ចុះឡើង ឡើងចុះ អ្វីក៏ដោយ) ត្រូវបានកំណត់នៅពេលតែមួយ នៅពេលដែលសោត្រូវបានបង្កើត ហើយវាមិនអាចផ្លាស់ប្តូរនៅពេលក្រោយបានទេ។ វាកំណត់ជាលក្ខណៈរូបវ័ន្តពីរបៀបដែលទិន្នន័យនឹងត្រូវបានតម្រៀប និងរបៀបដែលវានឹងត្រូវបានរក្សាទុក។ ប្រសិនបើអ្នកត្រូវការផ្លាស់ប្តូរ Clustering key ឬ sort order អ្នកនឹងត្រូវបង្កើតតារាងថ្មី ហើយផ្ទេរទិន្នន័យទៅក្នុងវា។ វានឹងមិនដំណើរការជាមួយឧបករណ៍ដែលមានស្រាប់ទេ។

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

កន្លែងធ្វើការរបស់យើងលេចឡើងម្តងទៀត where, andហើយយើងទទួលបានអ្នកប្រើប្រាស់ ហើយអ្វីៗគឺល្អម្តងទៀត។ ប៉ុន្តែប្រសិនបើយើងព្យាយាមប្រើតែផ្នែកនៃ Clustering key ហើយមួយផ្នែកដែលមិនសូវសំខាន់នោះ Cassandra នឹងត្អូញត្អែរភ្លាមៗថាវាមិនអាចរកកន្លែងនៅក្នុងផែនទីរបស់យើងបានទេ ដែលវត្ថុនេះមានវាលទាំងនេះសម្រាប់ null comparator និងមួយនេះ។ ដែលទើបតែត្រូវបានកំណត់ - កន្លែងដែលគាត់កុហក។ ខ្ញុំនឹងត្រូវទាញទិន្នន័យទាំងអស់ចេញពីថ្នាំងនេះម្តងទៀត ហើយត្រងវា។ ហើយនេះគឺជា analogue នៃ Full Scan នៅក្នុង node នេះគឺមិនល្អទេ។

ក្នុងស្ថានភាពមិនច្បាស់លាស់ណាមួយ បង្កើតតារាងថ្មីមួយ

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

យើងធ្វើពាណិជ្ជកម្មទំហំដែលមិនចាំបាច់ និងទិន្នន័យដែលមិនប្រក្រតីសម្រាប់សមត្ថភាពក្នុងការធ្វើមាត្រដ្ឋានបានល្អ និងដំណើរការប្រកបដោយភាពជឿជាក់។ តាមពិតទៅ ចង្កោមដែលមានមជ្ឈមណ្ឌលទិន្នន័យចំនួនបី ដែលនីមួយៗមានថ្នាំងចំនួន 5 ជាមួយនឹងកម្រិតដែលអាចទទួលយកបាននៃការរក្សាទុកទិន្នន័យ (នៅពេលដែលគ្មានអ្វីត្រូវបានបាត់បង់) អាចរស់រានមានជីវិតពីមជ្ឈមណ្ឌលទិន្នន័យមួយទាំងស្រុង។ និង​ថ្នាំង​ពីរ​ទៀត​ក្នុង​នីមួយៗ​នៃ​ពីរ​ដែល​នៅ​សេសសល់។ ហើយមានតែបន្ទាប់ពីនេះបញ្ហាចាប់ផ្តើម។ នេះ​គឺ​ជា​ការ​ប្រើ​ប្រាស់​ដដែលៗ​ដ៏​ល្អ វា​មាន​តម្លៃ​ពីរ​បី​នៃ​ការ​បន្ថែម SSD drives និង processor ។ ដូច្នេះដើម្បីប្រើ Cassandra ដែលមិនមែនជា SQL ដែលមិនមានទំនាក់ទំនង សោរបរទេស អ្នកត្រូវដឹងពីច្បាប់សាមញ្ញ។

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

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

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

ការ​តម្រៀប​ត្រូវ​បាន​ជ្រើសរើស​ម្តង​នៅ​ដំណាក់កាល​បង្កើត​កូនសោ​ចង្កោម។ ប្រសិនបើចាំបាច់ត្រូវផ្លាស់ប្តូរ យើងនឹងត្រូវធ្វើបច្ចុប្បន្នភាពតារាងរបស់យើងដោយប្រើសោផ្សេង។

ហើយអ្វីដែលសំខាន់បំផុត: ប្រសិនបើយើងត្រូវការទាញយកទិន្នន័យដូចគ្នាក្នុង 100 វិធីផ្សេងគ្នា នោះយើងនឹងមានតារាង 100 ផ្សេងគ្នា។

ប្រភព: www.habr.com