21 වන සියවසේ SQL දත්ත සමුදායක් නොනැසී පවතින්නේ කෙසේද: වලාකුළු, Kubernetes සහ PostgreSQL බහුමාස්ටර්

හෙලෝ, Khabrovsk පදිංචිකරුවන්. පාඨමාලාවේ පළමු කණ්ඩායමේ පන්ති අද ආරම්භ වේ "PostgreSQL". මේ සම්බන්ධයෙන්, මෙම පාඨමාලාවේ විවෘත webinar සිදු වූ ආකාරය ගැන අපි ඔබට කියන්නට කැමැත්තෙමු.

В ඊළඟ විවෘත පාඩම අපි වලාකුළු සහ Kubernetes යුගයේ SQL දත්ත සමුදායන් මුහුණ දෙන අභියෝග ගැන කතා කළා. ඒ අතරම, මෙම අභියෝගවල බලපෑම යටතේ SQL දත්ත සමුදායන් අනුවර්තනය වී විකෘති වන ආකාරය අපි සොයා බැලුවෙමු.

webinar පැවැත්විණි වැලරි බෙස්රුකොව්, Google Cloud Practice Delivery Manager at EPAM Systems.

ගස් කුඩා වූ විට ...

පළමුව, DBMS තෝරාගැනීම පසුගිය ශතවර්ෂයේ අවසානයේ ආරම්භ වූ ආකාරය මතක තබා ගනිමු. කෙසේ වෙතත්, මෙය අපහසු නොවනු ඇත, මන්ද ඒ දිනවල DBMS තෝරාගැනීම ආරම්භ වී අවසන් විය ඔරකල්.

90 දශකයේ අගභාගයේ සහ 2 ගණන්වල මුල් භාගයේදී, කාර්මික පරිමාණය කළ හැකි දත්ත සමුදායන් සම්බන්ධයෙන් මූලිකවම තෝරා ගැනීමක් නොතිබුණි. ඔව්, IBM DBXNUMX, Sybase සහ තවත් සමහර දත්ත සමුදායන් පැමිණ ගිය නමුත් සාමාන්‍යයෙන් ඒවා Oracle පසුබිමට එරෙහිව එතරම් කැපී පෙනෙන්නේ නැත. ඒ අනුව, එකල ඉංජිනේරුවන්ගේ කුසලතා කෙසේ හෝ පැවති එකම තේරීම සමඟ බැඳී තිබුණි.

Oracle DBA හට හැකි විය යුත්තේ:

• බෙදාහැරීමේ කට්ටලයෙන් Oracle Server ස්ථාපනය කරන්න;
• Oracle සේවාදායකය වින්‍යාස කරන්න:

• init.ora;
• අසන්නා.ora;

- නිර්මාණය කරන්න:

• මේස අවකාශයන්;
• යෝජනා ක්රම;
• පරිශීලකයන්;

- උපස්ථ කිරීම සහ ප්රතිෂ්ඨාපනය කිරීම;
- අධීක්ෂණය සිදු කරන්න;
- උපප්‍රශස්ත ඉල්ලීම් සමඟ කටයුතු කරන්න.

ඒ අතරම, Oracle DBA වෙතින් විශේෂ අවශ්‍යතාවයක් නොතිබුණි:

• දත්ත ගබඩා කිරීම සහ සැකසීම සඳහා ප්‍රශස්ත DBMS හෝ වෙනත් තාක්ෂණයක් තෝරා ගැනීමට හැකි වීම;
• ඉහළ ලබා ගැනීමේ හැකියාව සහ තිරස් පරිමාණය සැපයීම (මෙය සැමවිටම DBA ගැටළුවක් නොවීය);
• විෂය ක්ෂේත්රය, යටිතල පහසුකම්, යෙදුම් ගෘහ නිර්මාණ ශිල්පය, OS පිළිබඳ හොඳ දැනුමක්;
• දත්ත පැටවීම සහ බෑම, විවිධ DBMS අතර දත්ත සංක්‍රමණය කිරීම.

පොදුවේ ගත් කල, අපි ඒ දිනවල තේරීම ගැන කතා කරන්නේ නම්, එය 80 දශකයේ අග භාගයේ සෝවියට් වෙළඳසැලක තේරීමට සමාන ය:

අපේ කාලය

එතැන් සිට, ඇත්ත වශයෙන්ම, ගස් වැඩී ඇත, ලෝකය වෙනස් වී ඇත, එය මේ වගේ දෙයක් බවට පත් විය:

Gartner හි නවතම වාර්තාවෙන් පැහැදිලිව පෙනෙන පරිදි DBMS වෙළඳපොළ ද වෙනස් වී ඇත:

ජනප්‍රියත්වය වැඩිවෙමින් පවතින වලාකුළු ඔවුන්ගේ ස්ථානය අල්ලාගෙන ඇති බව මෙහිදී සටහන් කළ යුතුය. අපි එකම ගාට්නර් වාර්තාව කියවා ඇත්නම්, අපි පහත නිගමන දකිමු:

1. බොහෝ ගනුදෙනුකරුවන් වලාකුළට යෙදුම් ගෙනයාමේ මාවතේ සිටිති.
2. නව තාක්ෂණයන් මුලින්ම වලාකුළෙහි දිස්වන අතර ඒවා කිසිදා වලාකුළු නොවන යටිතල පහසුකම් වෙත ගමන් කරන බව සත්‍යයක් නොවේ.
3. ඔබ යන විට ගෙවීමේ මිල ආකෘතිය සාමාන්‍ය දෙයක් බවට පත්ව ඇත. සෑම කෙනෙකුටම තමන් භාවිතා කරන දේ සඳහා පමණක් ගෙවීමට අවශ්ය වන අතර, මෙය පවා ප්රවණතාවයක් නොවේ, නමුත් හුදෙක් සත්ය ප්රකාශයකි.

දැන් මොකද?

අද අපි හැමෝම ඉන්නේ වලාකුළේ. තවද අපට පැන නගින ප්‍රශ්න තෝරා ගැනීමේ ප්‍රශ්න වේ. තවද අපි පරිශ්‍රයේ ආකෘතියේ DBMS තාක්ෂණයන් තෝරාගැනීම ගැන පමණක් කතා කළත් එය අති විශාලය. අප සතුව සේවා සහ SaaS කළමනාකරණය කර ඇත. මේ අනුව, තේරීම සෑම වසරකම වඩාත් අපහසු වේ.

තෝරා ගැනීමේ ප්රශ්න සමඟ, ද ඇත සීමාකාරී සාධක:

• මිල. බොහෝ තාක්ෂණයන් තවමත් මුදල් වියදම් කරයි;
• නිපුණතා. අපි නිදහස් මෘදුකාංග ගැන කතා කරන්නේ නම්, නිපුණතා පිළිබඳ ප්රශ්නය පැනනගින්නේ, නිදහස් මෘදුකාංග සඳහා එය යොදවන සහ ක්රියාත්මක කරන පුද්ගලයින්ගෙන් ප්රමාණවත් නිපුණතාවයක් අවශ්ය වන බැවිනි;
• ක්රියාකාරී. වලාකුළෙහි ලබා ගත හැකි සහ ගොඩනඟා ඇති සියලුම සේවාවන්, එකම Postgres මත වුවද, Postgres On-premises මෙන් එකම විශේෂාංග නොමැත. මෙය දැනගත යුතු සහ අවබෝධ කරගත යුතු අත්‍යවශ්‍ය සාධකයකි. එපමණක් නොව, මෙම සාධකය තනි DBMS හි සමහර සැඟවුණු හැකියාවන් පිළිබඳ දැනුමට වඩා වැදගත් වේ.

DA/DE වෙතින් දැන් බලාපොරොත්තු වන්නේ කුමක්ද:

• විෂය ක්ෂේත්රය සහ යෙදුම් ගෘහ නිර්මාණ ශිල්පය පිළිබඳ හොඳ අවබෝධයක්;
• කාර්යය සැලකිල්ලට ගනිමින් සුදුසු DBMS තාක්ෂණය නිවැරදිව තෝරා ගැනීමේ හැකියාව;
• පවත්නා සීමාවන්ගේ සන්දර්භය තුළ තෝරාගත් තාක්ෂණය ක්රියාත්මක කිරීම සඳහා ප්රශස්ත ක්රමයක් තෝරාගැනීමේ හැකියාව;
• දත්ත හුවමාරුව සහ සංක්රමණය කිරීමේ හැකියාව;
• තෝරාගත් විසඳුම් ක්රියාත්මක කිරීමට සහ ක්රියාත්මක කිරීමට ඇති හැකියාව.

පහත උදාහරණය GCP මත පදනම්ව දත්ත සමඟ වැඩ කිරීම සඳහා එක් හෝ වෙනත් තාක්ෂණයක් තෝරා ගැනීම එහි ව්‍යුහය අනුව ක්‍රියා කරන ආකාරය නිරූපණය කරයි:

PostgreSQL ක්‍රමලේඛනයට ඇතුළත් නොවන බව කරුණාවෙන් සලකන්න, මෙය පාරිභාෂිතය යටතේ සඟවා ඇති බැවිනි. වලාකුළු SQL. අපි Cloud SQL වෙත ගිය විට, අපි නැවත තේරීමක් කළ යුතුය:

මෙම තේරීම සැමවිටම පැහැදිලි නොවන බව සැලකිල්ලට ගත යුතුය, එබැවින් යෙදුම් සංවර්ධකයින් බොහෝ විට බුද්ධියෙන් මෙහෙයවනු ලැබේ.

එකතුව:

1. ඔබ ඉදිරියට යන තරමට, තේරීම පිළිබඳ ප්‍රශ්නය වඩාත් තද වේ. ඔබ GCP, කළමනාකරණ සේවා සහ SaaS දෙස පමණක් බැලුවද, RDBMS පිළිබඳ යම් සඳහනක් දිස්වන්නේ 4 වන පියවරේදී පමණි (සහ එහි Spanner අසල ඇත). තවද, PostgreSQL තේරීම 5 වන පියවරේදී දිස්වන අතර, ඒ අසල MySQL සහ SQL Server ද ඇත, එනම් සෑම දෙයක්ම ගොඩක් ඇත, නමුත් ඔබ තෝරා ගත යුතුය.
2. පරීක්ෂාවන්ගේ පසුබිමට එරෙහිව සීමා කිරීම් ගැන අප අමතක නොකළ යුතුය. මූලික වශයෙන් සෑම කෙනෙකුටම Spanner අවශ්යයි, නමුත් එය මිල අධිකයි. ප්රතිඵලයක් වශයෙන්, සාමාන්ය ඉල්ලීමක් මේ වගේ දෙයක් පෙනේ: "කරුණාකර අපව ස්පැනර් කරන්න, නමුත් Cloud SQL හි මිලට, ඔබ වෘත්තිකයන්!"

අප කළ යුත්තේ කුමක්ද?

පරම සත්‍යය යැයි නොකියා මෙසේ කියමු.

ඉගෙනීම සඳහා අපගේ ප්‍රවේශය වෙනස් කළ යුතුය:

• DBA වලට කලින් ඉගැන්වූ ආකාරයට ඉගැන්වීමේ තේරුමක් නැත;
• එක් නිෂ්පාදනයක් පිළිබඳ දැනුම තවදුරටත් ප්රමාණවත් නොවේ;
• නමුත් එක මට්ටමින් දුසිම් ගනනක් දැන ගැනීම කළ නොහැක්කකි.

නිෂ්පාදිතය කොපමණ දැයි ඔබ දැනගත යුතු පමණක් නොව, නමුත්:

• එහි යෙදුම භාවිතා කිරීමේ අවස්ථාව;
• විවිධ යෙදවුම් ක්රම;
• එක් එක් ක්රමයේ වාසි සහ අවාසි;
• දැනුවත් සහ ප්‍රශස්ත තේරීමක් කිරීමට සමාන සහ විකල්ප නිෂ්පාදන සෑම විටම හුරුපුරුදු නිෂ්පාදනයක් සඳහා නොවේ.

ඔබට දත්ත සංක්‍රමණය කිරීමට සහ ETL සමඟ ඒකාබද්ධ වීමේ මූලික මූලධර්ම තේරුම් ගැනීමට ද හැකි විය යුතුය.

සැබෑ නඩුව

මෑත අතීතයේදී, ජංගම යෙදුමක් සඳහා පසුබිමක් නිර්මාණය කිරීම අවශ්ය විය. එය මත වැඩ ආරම්භ කරන විට, පසුබිම දැනටමත් සංවර්ධනය කර ඇති අතර එය ක්රියාත්මක කිරීමට සූදානම්ව සිටි අතර, සංවර්ධන කණ්ඩායම මෙම ව්යාපෘතිය සඳහා වසර දෙකක් පමණ ගත කළේය. පහත සඳහන් කාර්යයන් සකසා ඇත:

• CI/CD ගොඩනැගීම;
• ගෘහ නිර්මාණ ශිල්පය සමාලෝචනය කරන්න;
• ඒ සියල්ල ක්‍රියාත්මක කරන්න.

යෙදුමම microservices වූ අතර, Python/Django කේතය මුල සිටම සහ සෘජුවම GCP තුළ සංවර්ධනය කරන ලදී. ඉලක්කගත ප්‍රේක්ෂකයින් සම්බන්ධයෙන් ගත් කල, එක්සත් ජනපදය සහ යුරෝපා සංගමය යන කලාප දෙකක් පවතිනු ඇතැයි උපකල්පනය කරන ලද අතර, ග්ලෝබල් ලෝඩ් බැලන්සර් හරහා ගමනාගමනය බෙදා හරින ලදී. සියලුම වැඩ බර සහ ගණනය කිරීමේ කාර්ය භාරය Google Kubernetes එන්ජිම මත ධාවනය විය.

දත්ත සඳහා, ව්යුහයන් 3 ක් විය:

• වලාකුළු ගබඩා;
• දත්ත ගබඩාව;
• Cloud SQL (PostgreSQL).

Cloud SQL තෝරා ගත්තේ මන්දැයි කෙනෙකුට සිතිය හැක. සත්‍යය පැවසීම සඳහා, එවැනි ප්‍රශ්නයක් මෑත වසරවලදී යම් ආකාරයක අමුතු විරාමයක් ඇති කර ඇත - මිනිසුන් සම්බන්ධතා දත්ත සමුදායන් ගැන ලැජ්ජාවට පත් වී ඇති බවට හැඟීමක් ඇත, නමුත් එසේ වුවද ඔවුන් ඒවා ක්‍රියාකාරීව භාවිතා කරයි ;-).

අපගේ නඩුව සම්බන්ධයෙන්, Cloud SQL පහත සඳහන් හේතු නිසා තෝරාගෙන ඇත:

1. සඳහන් කර ඇති පරිදි, යෙදුම Django භාවිතයෙන් සංවර්ධනය කරන ලද අතර, SQL දත්ත ගබඩාවක සිට Python වස්තූන් (Django ORM) වෙත අඛණ්ඩ දත්ත සිතියම්ගත කිරීම සඳහා ආකෘතියක් ඇත.
2. රාමුව විසින්ම DBMS හි තරමක් සීමිත ලැයිස්තුවක් සඳහා සහය විය:

• PostgreSQL;
• MariaDB;
• MySQL;
• ඔරකල්;
• SQLite.

ඒ අනුව, PostgreSQL මෙම ලැයිස්තුවෙන් තෝරාගනු ලැබුවේ ඉතා බුද්ධිමත්ව (හොඳයි, එය තෝරා ගැනීමට Oracle නොවේ, ඇත්තෙන්ම).

අතුරුදහන් වූ දේ:

• යෙදුම යොදවා ඇත්තේ කලාප 2 ක පමණක් වන අතර 3 වන එකක් සැලසුම් (ආසියාව) තුළ දර්ශනය විය;
• දත්ත සමුදාය උතුරු ඇමරිකානු කලාපයේ (අයෝවා) පිහිටා ඇත;
• පාරිභෝගිකයාගේ පැත්තෙන් විය හැකි දේ ගැන කනස්සල්ලක් ඇති විය ප්රවේශ ප්රමාදයන් යුරෝපයෙන් සහ ආසියාවෙන් සහ බාධා කිරීම් ක්රියාත්මකයි DBMS අක්‍රිය අවස්ථාවකදී.

ජැන්ගෝට දත්ත සමුදා කිහිපයක් සමඟ සමාන්තරව ක්‍රියා කළ හැකි අතර ඒවා කියවීමට හා ලිවීමට බෙදිය හැකි වුවද, යෙදුමේ එතරම් ලිවීමක් නොතිබුණි (90% කට වඩා කියවීම). සහ පොදුවේ, සහ පොදුවේ, එය කළ හැකි නම් යුරෝපයේ සහ ආසියාවේ ප්‍රධාන පදනමේ කියවීමේ අනුරුව, මෙය සම්මුති විසඳුමක් වනු ඇත. හොඳයි, එහි ඇති සංකීර්ණත්වය කුමක්ද?

දුෂ්කරතාවය වූයේ කළමනාකරණය කළ සේවාවන් සහ Cloud SQL භාවිතය අත්හැරීමට පාරිභෝගිකයාට අවශ්‍ය නොවීමයි. තවද Cloud SQL හි හැකියාවන් දැනට සීමිතය. Cloud SQL, High availability (HA) සහ Read Replica (RR) සඳහා සහය දක්වයි, නමුත් එකම RR එක කලාපයක පමණක් සහය දක්වයි. ඇමරිකානු කලාපයේ දත්ත සමුදායක් නිර්මාණය කිරීමෙන් පසු, ඔබට Cloud SQL භාවිතයෙන් යුරෝපීය කලාපයේ කියවීමේ අනුරුවක් සෑදිය නොහැක, නමුත් Postgres විසින්ම මෙය කිරීමෙන් ඔබව වළක්වන්නේ නැත. ගූගල් සේවකයින් සමඟ ලිපි හුවමාරුව කොතැනකවත් නොපැමිණි අතර "අපි ගැටලුව දන්නා අතර එය මත වැඩ කරමින් සිටිමු, කවදා හෝ ගැටලුව විසඳනු ඇත" යන විලාසයෙන් පොරොන්දුවකින් අවසන් විය.

අපි Cloud SQL හි හැකියාවන් කෙටියෙන් ලැයිස්තුගත කළහොත්, එය මේ වගේ දෙයක් පෙනෙනු ඇත:

1. ඉහළ ලබා ගැනීමේ හැකියාව (HA):

• එක් කලාපයක් තුළ;
• තැටි අනුකරණය හරහා;
• PostgreSQL එන්ජින් භාවිතා නොකෙරේ;
• ස්වයංක්‍රීය සහ අතින් පාලනය කළ හැකි - අසාර්ථක / අසාර්ථක වීම;
• මාරු කරන විට, DBMS මිනිත්තු කිහිපයක් සඳහා ලබා ගත නොහැක.

2. අනුරුව (RR) කියවන්න:

• එක් කලාපයක් තුළ;
• උණුසුම් පොරොත්තු;
• PostgreSQL streaming replication.

ඊට අමතරව, පුරුද්දක් ලෙස, තාක්ෂණයක් තෝරාගැනීමේදී ඔබ සැමවිටම සමහරක් මුහුණ දෙයි සීමා:

• GKE හරහා හැර, ආයතන නිර්මාණය කිරීමට සහ IaaS භාවිතා කිරීමට පාරිභෝගිකයාට අවශ්‍ය නොවීය;
• ස්වයං සේවා PostgreSQL/MySQL යෙදවීමට පාරිභෝගිකයා කැමති නැත;
• හොඳයි, පොදුවේ ගත් කල, Google Spanner එහි මිල සඳහා නොවේ නම් එය බෙහෙවින් සුදුසු වනු ඇත, කෙසේ වෙතත්, Django ORM හට එය සමඟ වැඩ කළ නොහැක, නමුත් එය හොඳ දෙයකි.

තත්වය සැලකිල්ලට ගනිමින්, පාරිභෝගිකයාට පසු විපරම් ප්රශ්නයක් ලැබුණි: "ඔබට Google Spanner වැනි, නමුත් Django ORM සමඟද ක්‍රියා කිරීමට සමාන දෙයක් කළ හැකිද?"

විසඳුම් විකල්පය අංක 0

මතකයට නැඟුණු පළමු දෙය:

• CloudSQL තුළ රැඳී සිටින්න;
• කිසිදු ආකාරයකින් කලාප අතර ගොඩනඟන ලද අනුකරණයක් නොමැත;
• PostgreSQL මගින් පවතින Cloud SQL එකකට අනුරුවක් ඇමිණීමට උත්සාහ කරන්න;
• කොතැනක හෝ කෙසේ හෝ PostgreSQL අවස්ථාවක් දියත් කරන්න, නමුත් අවම වශයෙන් මාස්ටර් ස්පර්ශ නොකරන්න.

අහෝ, මෙය සිදු කළ නොහැකි බව පෙනී ගියේය, මන්ද ධාරකයට ප්‍රවේශයක් නොමැති නිසා (එය සම්පූර්ණයෙන්ම වෙනස් ව්‍යාපෘතියක ඇත) - pg_hba සහ යනාදිය, සහ සුපිරි පරිශීලක යටතේ ප්‍රවේශයක් ද නොමැත.

විසඳුම් විකල්පය අංක 1

තවදුරටත් පරාවර්තනය කිරීමෙන් සහ පෙර තත්වයන් සැලකිල්ලට ගැනීමෙන් පසු, චින්තන මාර්ගය තරමක් වෙනස් විය:

• අපි තවමත් CloudSQL තුළ රැඳී සිටීමට උත්සාහ කරමින් සිටිමු, නමුත් අපි MySQL වෙත මාරු වන්නෙමු, මන්ද MySQL මගින් Cloud SQL හට බාහිර ප්‍රධානයක් ඇත, එනම්:

- බාහිර MySQL සඳහා ප්‍රොක්සියකි;
- MySQL උදාහරණයක් ලෙස පෙනේ;
- වෙනත් වලාකුළුවලින් හෝ පරිශ්‍රයෙන් දත්ත සංක්‍රමණය කිරීම සඳහා නිර්මාණය කර ඇත.

MySQL අනුවර්තනය පිහිටුවීමට සත්කාරක වෙත ප්‍රවේශය අවශ්‍ය නොවන බැවින්, ප්‍රතිපත්තිමය වශයෙන් සෑම දෙයක්ම ක්‍රියාත්මක විය, නමුත් එය ඉතා අස්ථායී සහ අපහසු විය. අපි තවත් ඉදිරියට ගිය විට, එය සම්පූර්ණයෙන්ම බියජනක විය, මන්ද අපි සම්පූර්ණ ව්‍යුහයම ටෙරාෆෝම් සමඟ යෙදවූ අතර, හදිසියේම පෙනී ගියේ බාහිර ස්වාමියාට ටෙරාෆෝම් මගින් සහය නොදක්වන බවයි. ඔව්, Google සතුව CLI එකක් ඇත, නමුත් යම් හේතුවක් නිසා සෑම දෙයක්ම මෙහි සෑම විටම ක්‍රියාත්මක විය - සමහර විට එය නිර්මාණය කර ඇත, සමහර විට එය නිර්මාණය නොවේ. සමහර විට CLI සොයාගනු ලැබුවේ බාහිර දත්ත සංක්‍රමණය සඳහා මිස අනුපිටපත් සඳහා නොවේ.

ඇත්ත වශයෙන්ම, මෙම අවස්ථාවේදී Cloud SQL කිසිසේත්ම සුදුසු නොවන බව පැහැදිලි විය. ඔවුන් පවසන පරිදි, අපි හැකි සෑම දෙයක්ම කළා.

විසඳුම් විකල්පය අංක 2

Cloud SQL රාමුව තුළ රැඳී සිටීමට නොහැකි වූ නිසා, අපි සම්මුති විසඳුමක් සඳහා අවශ්‍යතා සකස් කිරීමට උත්සාහ කළෙමු. අවශ්‍යතා පහත පරිදි විය:

• Kubernetes හි වැඩ කිරීම, Kubernetes (DCS, ...) සහ GCP (LB, ...) හි සම්පත් සහ හැකියාවන් උපරිම ලෙස භාවිතා කිරීම;
• HA ප්‍රොක්සි වැනි වලාකුළේ ඇති අනවශ්‍ය දේවල් සමූහයකින් බැලස්ට් නොමැතිකම;
• ප්‍රධාන HA කලාපය තුළ PostgreSQL හෝ MySQL ධාවනය කිරීමේ හැකියාව; අනෙකුත් කලාපවල - ප්රධාන කලාපයේ RR සිට HA සහ එහි පිටපත (විශ්වසනීයත්වය සඳහා);
• බහු මාස්ටර් (මට ඔහුව සම්බන්ධ කර ගැනීමට අවශ්‍ය නොවීය, නමුත් එය එතරම් වැදගත් නොවීය)

.
මෙම ඉල්ලීම් හේතුවෙන් පීසුදුසු DBMS සහ බන්ධන විකල්ප:

• MySQL Galera;
• CockroachDB;
• PostgreSQL මෙවලම්

:
- pgpool-II;
- පැට්රෝනි.

MySQL Galera

MySQL Galera තාක්ෂණය Codership විසින් සංවර්ධනය කරන ලද අතර එය InnoDB සඳහා ප්ලගිනයකි. සුවිශේෂතා:

• බහු මාස්ටර්;
• සමමුහුර්ත පිටපත් කිරීම;
• ඕනෑම නෝඩයකින් කියවීම;
• ඕනෑම නෝඩයකට පටිගත කිරීම;
• බිල්ට් HA යාන්ත්රණය;
• බිට්නාමිගෙන් හෙල්ම් ප්‍රස්ථාරයක් ඇත.

කුකුළා ඩී.බී.

විස්තරයට අනුව, එය සම්පූර්ණයෙන්ම බෝම්බයක් වන අතර එය Go හි ලියා ඇති විවෘත මූලාශ්‍ර ව්‍යාපෘතියකි. ප්‍රධාන සහභාගිකයා වන්නේ Cockroach Labs (Google හි පුද්ගලයින් විසින් ආරම්භ කරන ලද) ය. මෙම සම්බන්ධිත DBMS මුලින් නිර්මාණය කර ඇත්තේ බෙදා හැරීමට (පෙට්ටියෙන් පිටත තිරස් පරිමාණය සහිතව) සහ දෝෂ ඉවසීමටය. සමාගමේ කතුවරුන් "SQL ක්‍රියාකාරීත්වයේ පොහොසත්කම NoSQL විසඳුම්වලට හුරුපුරුදු තිරස් ප්‍රවේශ්‍යතාවය සමඟ ඒකාබද්ධ කිරීමේ" ඉලක්කය ගෙනහැර දැක්වීය.

හොඳ ප්‍රසාද දීමනාවක් වන්නේ පශ්චාත්-ග්‍රහස් සම්බන්ධතා ප්‍රොටෝකෝලය සඳහා සහාය වීමයි.

pgpool

මෙය PostgreSQL වෙත ඇඩෝනයකි, ඇත්ත වශයෙන්ම, සියලු සම්බන්ධතා භාරගෙන ඒවා ක්‍රියාවට නංවන නව ආයතනයකි. එයට BSD බලපත්‍රය යටතේ බලපත්‍ර ලබා ඇති එහිම load balancer සහ parser ඇත. එය ප්‍රමාණවත් අවස්ථාවන් ලබා දෙයි, නමුත් එය තරමක් බියජනක ලෙස පෙනේ, මන්ද නව ආයතනයක් තිබීම අමතර වික්‍රමාන්විතයන් සඳහා මූලාශ්‍රය විය හැකි බැවිනි.

පැට්රෝනි

මෙය මගේ ඇස් යොමු වූ අවසාන දෙය වන අතර, එය නිෂ්ඵල නොවේ. Patroni යනු විවෘත මූලාශ්‍ර උපයෝගිතාවකි, එය අත්‍යවශ්‍යයෙන්ම Python ඩීමන් එකක් වන අතර එමඟින් විවිධ ආකාරයේ අනුකරණයන් සහ ස්වයංක්‍රීය භූමිකාව මාරු කිරීම සමඟ PostgreSQL පොකුරු ස්වයංක්‍රීයව පවත්වා ගැනීමට ඔබට ඉඩ සලසයි. එය කියුබර් සමඟ හොඳින් ඒකාබද්ධ වන අතර නව ආයතන කිසිවක් හඳුන්වා නොදෙන බැවින් කාරණය ඉතා සිත්ගන්නා සුළු විය.

අවසානයේ ඔබ තෝරාගත්තේ කුමක්ද?

තේරීම පහසු නොවීය:

1. කුකුළා ඩී.බී. - ගින්න, නමුත් අඳුරු;
2. MySQL Galera - ද නරක නැත, එය බොහෝ ස්ථානවල භාවිතා වේ, නමුත් MySQL;
3. pgpool - අනවශ්‍ය ආයතන රාශියක්, එබැවින් වලාකුළු සහ K8s සමඟ ඒකාබද්ධ වීම;
4. පැට්රෝනි - K8s සමඟ විශිෂ්ට ඒකාබද්ධතාවයක්, අනවශ්‍ය ආයතන නොමැත, GCP LB සමඟ හොඳින් ඒකාබද්ධ වේ.

මේ අනුව, තේරීම Patroni මත වැටුණි.

සොයා ගැනීම්

කෙටියෙන් සාරාංශ කිරීමට කාලයයි. ඔව්, තොරතුරු තාක්ෂණ යටිතල පහසුකම් ලෝකය සැලකිය යුතු ලෙස වෙනස් වී ඇති අතර, මෙය ආරම්භය පමණි. මීට පෙර වලාකුළු තවත් යටිතල පහසුකම් පමණක් නම්, දැන් සියල්ල වෙනස් ය. එපමණක්ද නොව, වලාකුළු වල නවෝත්පාදනයන් නිරන්තරයෙන් පෙනෙන අතර, ඒවා දිස්වනු ඇති අතර, සමහර විට, ඒවා වලාකුළු තුළ පමණක් දිස්වනු ඇති අතර පසුව පමණක්, ආරම්භකයින්ගේ ප්රයත්නයන් මගින්, පරිශ්රය වෙත මාරු කරනු ලැබේ.

SQL සඳහා, SQL ජීවත් වනු ඇත. මෙයින් අදහස් කරන්නේ ඔබ PostgreSQL සහ MySQL දැනගෙන ඒවා සමඟ වැඩ කිරීමට හැකි විය යුතු බවයි, නමුත් ඊටත් වඩා වැදගත් වන්නේ ඒවා නිවැරදිව භාවිතා කිරීමට හැකි වීමයි.

මූලාශ්රය: www.habr.com