කෙසේ හෝ, ඓතිහාසික වශයෙන්, තොරතුරු තාක්ෂණ කර්මාන්තය ඕනෑම හේතුවක් නිසා කොන්දේසි සහිත කඳවුරු දෙකකට බෙදා ඇත: "සඳහා" සහ "විරුද්ධ" අය. එපමණක් නොව, ආරවුල් විෂය සම්පූර්ණයෙන්ම අත්තනෝමතික විය හැකිය. වඩා හොඳ කුමන මෙහෙයුම් පද්ධතියද: Win හෝ Linux? Android හෝ iOS ස්මාර්ට් ජංගම දුරකතනයකද? ඔබ සෑම දෙයක්ම වලාකුළු තුළ ගබඩා කළ යුතුද නැතහොත් සීතල RAID ගබඩාව මත තබා ඉස්කුරුප්පු ඇණ ආරක්ෂිතව තැබිය යුතුද? PHP පුද්ගලයින්ට ක්‍රමලේඛකයින් ලෙස හැඳින්වීමට අයිතියක් තිබේද? මෙම ආරවුල්, විටෙක, ස්වභාවයෙන්ම තනිකරම පැවැත්මක් වන අතර ක්‍රීඩා උනන්දුව හැර වෙනත් පදනමක් නොමැත.
බහාලුම් පැමිණීමත් සමඟම ඩොකර් සහ කොන්දේසි සහිත k8s සහිත මේ ආදරණීය ආහාර පිසීමත් සමඟ, පසුපෙළේ විවිධ ප්‍රදේශවල නව හැකියාවන් භාවිතා කිරීම සඳහා “සහ” සහ “විරුද්ධව” විවාද ආරම්භ විය. (මෙම සාකච්ඡාවේදී Kubernetes බොහෝ විට වාද්‍ය වෘන්දයක් ලෙස දක්වා ඇතත්, මෙම විශේෂිත මෙවලම තේරීම මූලික වැදගත්කමක් නැති බව කල්තියා වෙන් කරවා ගනිමු. ඒ වෙනුවට, ඔබට වඩාත් පහසු සහ හුරුපුරුදු යැයි පෙනෙන වෙනත් ඕනෑම එකක් ආදේශ කළ හැකිය. .)
තවද, මෙය එකම කාසියේ දෙපැත්තක් අතර සරල ආරවුලක් වනු ඇති බව පෙනේ. වින් එදිරිව ලිනක්ස් අතර සදාකාලික ගැටුම තරම් අඥාන සහ අනුකම්පා විරහිත, ප්‍රමාණවත් පුද්ගලයින් මැද කොතැනක හෝ සිටී. නමුත් බහාලුම්කරණයේදී සෑම දෙයක්ම එතරම් සරල නැත. සාමාන්යයෙන් එවැනි ආරවුල් වලදී දකුණු පැත්තක් නොමැත, නමුත් දත්ත සමුදායන් ගබඩා කිරීම සඳහා බහාලුම් "භාවිතා කරන්න" හෝ "භාවිතා නොකරන්න" නම්, සියල්ල උඩු යටිකුරු වේ. මක්නිසාද යත්, එක්තරා අර්ථයකින්, මෙම ප්‍රවේශයේ ආධාරකරුවන් සහ විරුද්ධවාදීන් යන දෙකම නිවැරදි ය.
හොඳ පැත්ත
සැහැල්ලු පැත්තේ තර්කය එක් වැකියකින් කෙටියෙන් විස්තර කළ හැකිය: "හෙලෝ, 2k19 කවුළුවෙන් පිටත!" එය ජනප්‍රියවාදයක් සේ පෙනේ, නමුත් ඔබ තත්වය විස්තරාත්මකව සොයා බැලුවහොත් එයට එහි වාසි ඇත. අපි දැන් ඒවා නිරාකරණය කරමු.
ඔබට විශාල වෙබ් ව්‍යාපෘතියක් ඇතැයි සිතමු. එය මුලින් ක්ෂුද්ර සේවා ප්‍රවේශයක් මත ගොඩනගා ගත හැකිව තිබුණි, නැතහොත් යම් අවස්ථාවක දී එය පරිණාමීය මාවතක් හරහා එය වෙත පැමිණියේය - ඇත්ත වශයෙන්ම මෙය එතරම් වැදගත් නොවේ. ඔබ අපගේ ව්යාපෘතිය වෙනම ක්ෂුද්ර සේවා, වාද්‍ය වෘන්දය සැකසීම, බර සමතුලිත කිරීම සහ පරිමාණය කිරීම සඳහා විසිරී ඇත. දැන්, පැහැදිලි හෘද සාක්ෂියක් ඇතිව, ඔබ වැටුණු සේවාදායකයන් ඉහළ නැංවීම වෙනුවට හබ්රා බලපෑම් අතරතුර කඩුල්ලක මොජිටෝ එකක් තොල ගෑවේය. නමුත් සෑම ක්රියාවක්ම ඔබ ස්ථාවර විය යුතුය. බොහෝ විට, යෙදුම පමණක් - කේතය - බහාලුම් වේ. කේතය හැර අපට තවත් මොනවාද?
ඒක හරි, දත්ත. ඕනෑම ව්‍යාපෘතියක හදවත එහි දත්ත වේ: මෙය සාමාන්‍ය DBMS එකක් විය හැක - MySQL, Postgre, MongoDB, හෝ සෙවීම සඳහා භාවිතා කරන ගබඩාව (ElasticSearch), හැඹිලිගත කිරීම සඳහා යතුරු අගය ගබඩා කිරීම - උදාහරණයක් ලෙස, redis, ආදිය. දැනට අපි එසේ නොවේ. දුර්වල ලෙස ලියා ඇති විමසුම් හේතුවෙන් දත්ත සමුදාය බිඳ වැටෙන විට අපි වංක පසුබිම ක්රියාත්මක කිරීමේ විකල්ප ගැන කතා කරමු, ඒ වෙනුවට අපි සේවාදායකයා භාරය යටතේ මෙම දත්ත සමුදායේ දෝෂ ඉවසීම සහතික කිරීම ගැන කතා කරමු. සියල්ලට පසු, අපි අපගේ යෙදුම බහාලන විට සහ ලැබෙන ඕනෑම ඉල්ලීම් සංඛ්‍යාවක් සැකසීමට නිදහසේ පරිමාණයට ඉඩ දෙන විට, මෙය ස්වභාවිකවම දත්ත සමුදායේ බර වැඩි කරයි.
ඇත්ත වශයෙන්ම, දත්ත සමුදායට ප්‍රවේශ වීමේ නාලිකාව සහ එය ක්රියාත්මක වන සේවාදායකය අපගේ අලංකාර බහාලුම් කළ පසුපෙළේ ඉඳිකටු ඇස බවට පත්වේ. ඒ අතරම, බහාලුම් අථත්‍යකරණයේ ප්‍රධාන චේතනාව වන්නේ ව්‍යුහයේ සංචලතාව සහ නම්‍යශීලීභාවය වන අතර එමඟින් අපට ලබා ගත හැකි සමස්ත යටිතල පහසුකම් හරහා උපරිම බර බෙදා හැරීම හැකි තරම් කාර්යක්ෂමව සංවිධානය කිරීමට අපට ඉඩ සලසයි. එනම්, අපි පද්ධතියේ පවතින සියලුම මූලද්‍රව්‍ය පොකුර හරහා කන්ටේනරීකරණය කර පෙරළා නොගන්නේ නම්, අපි ඉතා බරපතල වැරැද්දක් කරන්නෙමු.
යෙදුම පමණක් නොව දත්ත ගබඩා කිරීම සඳහා වගකිව යුතු සේවාවන් ද පොකුරු කිරීම වඩා තාර්කික ය. ස්වාධීනව ක්‍රියා කරන සහ k8s තුළ බර බෙදා හරින වෙබ් සේවාදායකයන් පොකුරු කිරීම සහ යෙදවීම මගින්, අපි දැනටමත් දත්ත සමමුහුර්ත කිරීමේ ගැටලුව විසඳමින් සිටිමු - අපි සමහර මාධ්‍ය හෝ බ්ලොග් වේදිකාවක් උදාහරණයක් ලෙස ගතහොත්, පළ කිරීම් පිළිබඳ එකම අදහස්. ඕනෑම අවස්ථාවක, අපට අභ්යන්තර-පොකුරු, අතථ්‍ය පවා, දත්ත සමුදාය බාහිර සේවාවක් ලෙස නියෝජනය කරයි. ප්‍රශ්නය වන්නේ දත්ත සමුදාය තවම පොකුරු කර නොමැති වීමයි - ඝනකයේ යොදවා ඇති වෙබ් සේවාදායකයන් වෙන වෙනම භ්‍රමණය වන අපගේ ස්ථිතික සටන් දත්ත ගබඩාවෙන් වෙනස්කම් පිළිබඳ තොරතුරු ලබා ගනී.
ඔබට අල්ලා ගැනීමක් දැනෙනවාද? අපි පැටවීම බෙදා හැරීමට සහ ප්‍රධාන වෙබ් සේවාදායකය බිඳවැටීම වළක්වා ගැනීමට k8s හෝ Swarm භාවිතා කරයි, නමුත් අපි දත්ත සමුදාය සඳහා මෙය නොකරමු. නමුත් දත්ත සමුදාය බිඳ වැටුනහොත්, අපගේ සමස්ත පොකුරු යටිතල පහසුකම් කිසිදු තේරුමක් නැත - දත්ත සමුදා ප්‍රවේශ දෝෂයක් ලබා දෙන හිස් වෙබ් පිටු මොනවාද?
සාමාන්යයෙන් සිදු කරන පරිදි වෙබ් සේවාදායකයන් පමණක් නොව දත්ත සමුදා යටිතල ව්‍යුහයද පොකුරු කිරීම අවශ්ය වන්නේ එබැවිනි. මේ ආකාරයෙන් පමණක් අපට එක් කණ්ඩායමක් තුළ සම්පූර්ණයෙන්ම ක්‍රියා කරන ව්‍යුහයක් සහතික කළ හැකි නමුත් ඒ සමඟම එකිනෙකාගෙන් ස්වාධීන වේ. එපමනක් නොව, අපගේ පසුපෙළෙන් අඩක් බර යටතේ "බිඳ වැටුණත්", ඉතිරිය නොනැසී පවතිනු ඇති අතර, පොකුරු තුළ දත්ත සමුදායන් එකිනෙක සමමුහුර්ත කිරීමේ පද්ධතිය සහ නව පොකුරු නිමක් නැතිව පරිමාණය කිරීමට සහ යෙදවීමට ඇති හැකියාව අවශ්ය ධාරිතාව ඉක්මනින් ළඟා කර ගැනීමට උපකාරී වේ - දත්ත මධ්යස්ථානයේ රාක්ක තිබුනේ නම් පමණි .
ඊට අමතරව, පොකුරු වශයෙන් බෙදා හරින ලද දත්ත සමුදා ආකෘතිය ඔබට මෙම දත්ත සමුදාය අවශ්ය තැනට ගෙන යාමට ඉඩ සලසයි; අපි ගෝලීය සේවාවක් ගැන කතා කරන්නේ නම්, සැන් ෆ්‍රැන්සිස්කෝ ප්‍රදේශයේ කොතැනක හෝ වෙබ් පොකුරක් කරකවා ගැනීම සහ ඒ සමඟම මොස්කව් කලාපයේ දත්ත සමුදායකට ප්‍රවේශ වීමේදී පැකට් යැවීම තරමක් තාර්කික නොවේ.
එසේම, දත්ත සමුදායේ බහාලුම්කරණය මඟින් පද්ධතියේ සියලුම අංග එකම වියුක්ත මට්ටමකින් ගොඩනැගීමට ඔබට ඉඩ සලසයි. එමඟින්, පරිපාලකයින්ගේ සක්‍රීය මැදිහත්වීමකින් තොරව, සංවර්ධකයින් විසින් කේතයෙන් කෙලින්ම මෙම පද්ධතිය කළමනාකරණය කිරීමට හැකි වේ. නව උප ව්යාපෘතිය සඳහා වෙනම DBMS එකක් අවශ්ය බව සංවර්ධකයින් සිතුවා - පහසුයි! yaml ගොනුවක් ලියා, එය පොකුරට උඩුගත කර ඔබ ඉවරයි.
ඇත්ත වශයෙන්ම, අභ්යන්තර ක්රියාකාරිත්වය බෙහෙවින් සරල කර ඇත. මට කියන්න, නව කණ්ඩායමේ සාමාජිකයෙක් වැඩ සඳහා සටන් දත්ත ගබඩාවට අත තැබූ විට ඔබ කී වතාවක් ඔබේ ඇස් වසාගෙන ඇත්ද? ඇත්ත වශයෙන්ම, ඔබ සතුව ඇති සහ දැන් කැරකෙන එකම එක කුමක්ද? ඇත්ත වශයෙන්ම, අපි සියල්ලෝම මෙහි වැඩිහිටියන් වන අතර, කොතැනක හෝ අපට නැවුම් උපස්ථයක් ඇත, ඊටත් වඩා දුරින් - ආච්චිගේ පිපිඤ්ඤා සහ පැරණි ස්කීස් සහිත රාක්කය පිටුපස - තවත් උපස්ථයක්, සමහර විට සීතල ගබඩාවේ පවා, ඔබේ කාර්යාලය දැනටමත් වරක් ගිනිගෙන ඇති බැවිනි. එහෙත් ඒ සියල්ලටම වඩා, සටන් යටිතල පහසුකම් සඳහා ප්රවේශය ඇති නව කණ්ඩායම් සාමාජිකයෙකුගේ සෑම හඳුන්වාදීමක් සහ, ඇත්ත වශයෙන්ම, සටන් දත්ත ගබඩාවට අවට සිටින සියල්ලන්ටම Validol බාල්දියකි. හොඳයි, ඔහුව හඳුනන්නේ කවුද, නවකයෙක්, සමහරවිට ඔහු හරස් අතට? එය බියජනකයි, ඔබ එකඟ වනු ඇත.
බහාලුම්කරණය සහ ඇත්ත වශයෙන්ම, ඔබේ ව්‍යාපෘතියේ දත්ත සමුදායේ බෙදා හරින ලද භෞතික ස්ථලකය එවැනි වලංගු අවස්ථා වළක්වා ගැනීමට උපකාරී වේ. නවකයෙක් විශ්වාස කරන්නේ නැද්ද? හරි! අනෙක් පොකුරු සමඟ වැඩ කිරීමට සහ දත්ත සමුදාය විසන්ධි කිරීමට ඔහුට ඔහුගේම පොකුරක් ලබා දෙමු - අතින් තල්ලු කිරීම සහ යතුරු දෙකක සමමුහුර්ත කරකැවීමෙන් පමණක් සමමුහුර්ත කිරීම (එකක් කණ්ඩායම් නායකත්වය සඳහා, අනෙක පරිපාලකයා සඳහා). ඒ වගේම හැමෝම සතුටින් ඉන්නවා.
දැන් දත්ත සමුදා පොකුරු වල විරුද්ධවාදීන් බවට වෙනස් වීමට කාලයයි.
අදුරු පැත්ත
දත්ත සමුදාය බහාලුම් කිරීම සහ එය එක මධ්‍යම සේවාදායකයක් මත දිගටම ක්රියාත්මක කිරීම වටින්නේ නැත්තේ මන්දැයි තර්ක කරමින්, අපි ඕතඩොක්ස්වාදයේ වාචාල කතාවලට සහ “සීයා දෘඩාංග මත දත්ත සමුදායන් පවත්වාගෙන ගිය අතර අපිත් එසේ වෙමු!” වැනි ප්‍රකාශවලට නොනැමෙන්නෙමු. ඒ වෙනුවට, බහාලුම්කරණය ඇත්ත වශයෙන්ම ස්පර්ශ කළ හැකි ලාභාංශ ගෙවන තත්වයක් ඇති කිරීමට උත්සාහ කරමු.
එකඟ වන්න, කන්ටේනරයක පදනමක් අවශ්ය වන ව්‍යාපෘති හොඳම ඇඹරුම් යන්ත්‍ර ක්‍රියාකරුට නොව එක් අතක ඇඟිලි මත ගණන් කළ හැකිය. බොහෝ දුරට, k8s හෝ Docker Swarm භාවිතා කිරීම පවා අනවශ්‍යයි - බොහෝ විට මෙම මෙවලම් භාවිතා කරනුයේ තාක්‍ෂණයේ සාමාන්‍ය උද්දීපනය සහ ලිංගභේදයේ පුද්ගලයා තුළ ඇති “සර්වබලධාරී” ආකල්ප නිසා සියල්ල තල්ලු කිරීමට ය. වලාකුළු සහ බහාලුම්. හොඳයි, දැන් එය විලාසිතාවක් වී ඇති අතර සෑම කෙනෙකුම එය කරයි.
අවම වශයෙන් අවස්ථා වලින් අඩක් තුළ, ව්‍යාපෘතියක Kubernetis හෝ Docker භාවිතා කිරීම අතිරික්ත වේ. ගැටළුව වන්නේ සේවාදායකයාගේ යටිතල පහසුකම් නඩත්තු කිරීම සඳහා කුලියට ගත් සියලුම කණ්ඩායම් හෝ බාහිර සේවා සමාගම් මේ පිළිබඳව නොදැන සිටීමයි. කන්ටේනර් පනවන විට එය වඩාත් නරක ය, මන්ද එය සේවාදායකයාට යම් කාසි මුදලක් වැය වේ.
පොදුවේ ගත් කල, ඩොකර්/කියුබ් මාෆියාව මෙම යටිතල පහසුකම් ප්‍රශ්න බාහිරින් ලබා දෙන සේවාදායකයින් මෝඩ ලෙස තලා දමන බවට මතයක් තිබේ. සියල්ලට පසු, පොකුරු සමඟ වැඩ කිරීම සඳහා, අපට මේ සඳහා හැකියාව ඇති ඉංජිනේරුවන් අවශ්ය වන අතර සාමාන්යයෙන් ක්රියාත්මක කරන ලද විසඳුමේ ගෘහ නිර්මාණ ශිල්පය තේරුම් ගනී. අපි වරක් ජනරජ ප්‍රකාශනය සමඟ අපගේ නඩුව විස්තර කර ඇත - එහිදී අපි කුබර්නෙටිස්ගේ යථාර්ථයන් තුළ වැඩ කිරීමට සේවාදායකයාගේ කණ්ඩායම පුහුණු කළ අතර සියලු දෙනා සෑහීමකට පත් විය. සහ එය විනීත විය. බොහෝ විට, k8s “ක්රියාත්මක කරන්නන්” සේවාදායකයාගේ යටිතල පහසුකම් ප්‍රාණ ඇපයට ගනී - මන්ද එහි සෑම දෙයක්ම ක්රියාත්මක වන ආකාරය දැන් ඔවුන්ට පමණක් වැටහෙන බැවිනි; සේවාදායකයාගේ පැත්තේ විශේෂ ists යින් නොමැත.
දැන් හිතන්න අපි මේ විදියට web server part එක විතරක් නෙමේ database නඩත්තුවත් outsource කරනවා කියලා. BD යනු හදවත බවත්, හදවත නැතිවීම ඕනෑම ජීවියෙකුට මාරාන්තික බවත් අපි කීවෙමු. කෙටියෙන් කිවහොත්, අපේක්ෂාවන් හොඳම නොවේ. එබැවින්, කුබර්නෙටිස් ප්‍රබෝධමත් කිරීම වෙනුවට, බොහෝ ව්‍යාපෘති AWS සඳහා සාමාන්‍ය ගාස්තු සමඟ කරදර නොවිය යුතුය, එමඟින් ඔවුන්ගේ වෙබ් අඩවියේ / ව්‍යාපෘතියේ බර සමඟ ඇති සියලුම ගැටළු විසඳනු ඇත. නමුත් AWS තවදුරටත් විලාසිතාවක් නොවන අතර, ප්‍රදර්ශන මුදල්වලට වඩා වටිනවා - අවාසනාවකට, තොරතුරු තාක්ෂණ පරිසරය තුළද.
හරි. සමහර විට ව්‍යාපෘතියට ඇත්තටම පොකුරු අවශ්ය විය හැක, නමුත් අස්ථායී යෙදුම් සමඟ සියල්ල පැහැදිලි නම්, පොකුරු දත්ත සමුදායක් සඳහා යහපත් ජාල සම්බන්ධතාවයක් සංවිධානය කරන්නේ කෙසේද?
අපි කතා කරන්නේ බාධාවකින් තොර ඉංජිනේරු විසඳුමක් ගැන නම්, එනම් k8s වෙත සංක්‍රමණය වන්නේ නම්, අපගේ ප්‍රධාන හිසරදය වන්නේ පොකුරු දත්ත ගබඩාවක දත්ත අනුකරණය කිරීමයි. සමහර DBMS මුලදී ඔවුන්ගේ තනි අවස්ථා අතර දත්ත බෙදා හැරීමට බෙහෙවින් පක්ෂපාතී වේ. තවත් බොහෝ අය එතරම් පිළිගන්නේ නැත. බොහෝ විට අපගේ ව්යාපෘතිය සඳහා DBMS තෝරා ගැනීමේ ප්‍රධාන තර්කය වන්නේ අවම සම්පත් සහ ඉංජිනේරු පිරිවැය සමඟ අනුකරණය කිරීමේ හැකියාව නොවේ. විශේෂයෙන්ම මෙම ව්යාපෘතිය මුලින් ක්ෂුද්ර සේවාවක් ලෙස සැලසුම් නොකළ නමුත් මෙම දිශාවට සරලව පරිණාමය විය.
ජාල ධාවකයන්ගේ වේගය ගැන කතා කිරීමට අවශ්ය නැතැයි අපි සිතමු - ඒවා මන්දගාමී වේ. එම. අපට තවමත් සැබෑ අවස්ථාවක් නැත, යමක් සිදුවුවහොත්, DBMS අවස්ථාවක් වැඩිපුර ඇති තැනක, උදාහරණයක් ලෙස, ප්‍රොසෙසර බලය හෝ නොමිලේ RAM නැවත ආරම්භ කිරීමට. අපි ඉතා ඉක්මනින් අථත්යකරණය කළ තැටි උපපද්ධතියේ කාර්ය සාධනය වෙත පිවිසෙනු ඇත. ඒ අනුව, DBMS සමීපයේ පිහිටා ඇති තමන්ගේම පුද්ගලික යන්ත්‍ර කට්ටලයකට ඇණ ගැසිය යුතුය. එසේත් නැතිනම් එය කෙසේ හෝ වෙන වෙනම සිසිලනය කිරීම අවශ්ය වේ යැයි කියනු ලබන සංචිත සඳහා ප්‍රමාණවත් තරම් වේගවත් දත්ත සමමුහුර්තකරණය.
අතථ්‍ය ගොනු පද්ධති පිළිබඳ මාතෘකාව දිගටම කරගෙන යාම: ඩොකර් වෙළුම්, අවාසනාවකට මෙන්, ගැටළු රහිත නොවේ. පොදුවේ ගත් කල, දිගු කාලීන විශ්වසනීය දත්ත ගබඩා කිරීම වැනි කාරණයකදී, මම වඩාත් තාක්ෂණික වශයෙන් සරල යෝජනා ක්රම සමඟ කටයුතු කිරීමට කැමතියි. තවද කන්ටේනරයේ FS සිට මව් ධාරකයේ FS වෙත නව වියුක්ත ස්ථරයක් එක් කිරීම අවදානමකි. නමුත් බහාලුම් ආධාරක පද්ධතියේ ක්රියාකාරිත්වය මෙම ස්ථර අතර දත්ත සම්ප්‍රේෂණය කිරීමේදී දුෂ්කරතාවන්ට මුහුණ දෙන විට එය සැබවින්ම ව්‍යසනයකි. මේ මොහොතේ, ප්‍රගතිශීලී මනුෂ්‍ය වර්ගයා දන්නා බොහෝ ගැටලු තුරන් වී ඇති බව පෙනේ. නමුත් ඔබට තේරෙනවා, යාන්ත්‍රණය වඩාත් සංකීර්ණ වන තරමට එය කැඩී යාම පහසුය.
මෙම සියලු “වික්‍රමණ” අනුව, දත්ත සමුදාය එක තැනක තබා ගැනීම වඩා ලාභදායී සහ පහසු වන අතර, ඔබට යෙදුම බහාලුම් කිරීමට අවශ්ය වුවද, එය තනිවම ක්රියාත්මක වීමට ඉඩ හරින්න සහ බෙදා හැරීමේ දොරටුව හරහා එකවර සන්නිවේදනය ලබා ගන්න. දත්ත සමුදාය, එය කියවීමට සහ ලිවීමට එක් වරක් පමණක් සහ එක් ස්ථානයක. මෙම ප්රවේශය අවම වශයෙන් දෝෂ සහ desynchronization සම්භාවිතාව අඩු කරයි.
අප යොමු කරන්නේ කුමක් ද? එපමණක් නොව, දත්ත සමුදා බහාලුම්කරණය සඳහා සැබෑ අවශ්‍යතාවයක් ඇති තැන සුදුසු වේ. ඔබට සම්පූර්ණ යෙදුම් දත්ත ගබඩාවක් පුරවා ඔබට ක්ෂුද්ර සේවා දුසිම් දෙකක් ඇති ආකාරයට එය කරකවා ගත නොහැක - එය එසේ ක්‍රියා නොකරයි. තවද මෙය පැහැදිලිව තේරුම් ගත යුතුය.
ප්‍රතිදානය වෙනුවට
ඔබ "දත්ත සමුදාය අථත්යකරණය කිරීමට හෝ නොකිරීමට" පැහැදිලි නිගමනයක් බලා සිටින්නේ නම්, අපි ඔබව කලකිරීමට පත් කරන්නෙමු: එය මෙහි නොවනු ඇත. මක්නිසාද යත් ඕනෑම යටිතල පහසුකම් විසඳුමක් නිර්මාණය කිරීමේදී යමෙකු මඟ පෙන්විය යුත්තේ විලාසිතා සහ ප්‍රගතියෙන් නොව, පළමුව, සාමාන්‍ය බුද්ධියෙන් ය.
Kubernetis සමඟ එන මූලධර්ම සහ මෙවලම් හොඳින් ගැලපෙන ව්‍යාපෘති ඇත, එවැනි ව්‍යාපෘතිවල අවම වශයෙන් පසුපෙළ ප්‍රදේශයේ සාමය ඇත. බහාලුම් අවශ්ය නොවන නමුත් සාමාන්‍ය සේවාදායක යටිතල ව්‍යුහයක් ඇති ව්‍යාපෘති ඇත, මන්ද ඒවාට මූලික වශයෙන් ක්ෂුද්ර සේවා පොකුරු ආකෘතියට නැවත පරිමාණය කළ නොහැකි බැවින් ඒවා වැටෙනු ඇත.
මූලාශ්රය: www.habr.com