21મી સદીમાં SQL ડેટાબેઝ કેવી રીતે ટકી શકાય: ક્લાઉડ્સ, કુબરનેટ્સ અને પોસ્ટગ્રેએસક્યુએલ મલ્ટિમાસ્ટર

હેલો, ખાબ્રોવસ્ક રહેવાસીઓ. કોર્સના પ્રથમ જૂથના વર્ગો આજથી શરૂ થાય છે "PostgreSQL". આ સંદર્ભે, અમે તમને આ કોર્સ પર ઓપન વેબિનાર કેવી રીતે યોજાયો તે વિશે જણાવવા માંગીએ છીએ.

В આગામી ખુલ્લો પાઠ અમે વાદળો અને કુબરનેટસના યુગમાં SQL ડેટાબેસેસનો સામનો કરતા પડકારો વિશે વાત કરી. તે જ સમયે, અમે આ પડકારોના પ્રભાવ હેઠળ SQL ડેટાબેસેસ કેવી રીતે અનુકૂલન અને પરિવર્તિત થાય છે તેના પર જોયું.

વેબિનાર યોજાયો હતો વેલેરી બેઝરુકોવ, EPAM સિસ્ટમ્સમાં Google ક્લાઉડ પ્રેક્ટિસ ડિલિવરી મેનેજર.

જ્યારે વૃક્ષો નાના હતા...

પ્રથમ, ચાલો યાદ કરીએ કે છેલ્લી સદીના અંતમાં ડીબીએમએસની પસંદગી કેવી રીતે શરૂ થઈ. જો કે, આ મુશ્કેલ નહીં હોય, કારણ કે તે દિવસોમાં ડીબીએમએસની પસંદગી શરૂ થઈ અને સમાપ્ત થઈ ઓરેકલ.

90 ના દાયકાના અંતમાં અને 2 ના દાયકાની શરૂઆતમાં, જ્યારે ઔદ્યોગિક સ્કેલેબલ ડેટાબેસેસની વાત આવે ત્યારે આવશ્યકપણે કોઈ વિકલ્પ ન હતો. હા, ત્યાં IBM DBXNUMX, Sybase અને કેટલાક અન્ય ડેટાબેસેસ હતા જે આવ્યા અને ગયા, પરંતુ સામાન્ય રીતે તેઓ ઓરેકલની પૃષ્ઠભૂમિ સામે એટલા ધ્યાનપાત્ર ન હતા. તદનુસાર, તે સમયના એન્જિનિયરોની કુશળતા કોઈક રીતે અસ્તિત્વમાં રહેલી એકમાત્ર પસંદગી સાથે જોડાયેલી હતી.

ઓરેકલ ડીબીએ આ માટે સક્ષમ હોવું જોઈએ:

• વિતરણ કીટમાંથી ઓરેકલ સર્વર ઇન્સ્ટોલ કરો;
• ઓરેકલ સર્વરને ગોઠવો:

• init.ora;
• listener.ora;

- બનાવો:

• ટેબલસ્પેસ;
• યોજનાઓ
• વપરાશકર્તાઓ;

- બેકઅપ અને પુનઃસ્થાપિત કરો;
- દેખરેખ હાથ ધરવા;
- સબઓપ્ટિમલ વિનંતીઓ સાથે વ્યવહાર કરો.

તે જ સમયે, ઓરેકલ ડીબીએ તરફથી કોઈ ખાસ જરૂરિયાત ન હતી:

• ડેટા સ્ટોર કરવા અને પ્રોસેસ કરવા માટે શ્રેષ્ઠ DBMS અથવા અન્ય ટેક્નોલોજી પસંદ કરવામાં સમર્થ થાઓ;
• ઉચ્ચ ઉપલબ્ધતા અને આડી માપનીયતા પ્રદાન કરો (આ હંમેશા DBA સમસ્યા ન હતી);
• વિષય વિસ્તાર, ઈન્ફ્રાસ્ટ્રક્ચર, એપ્લિકેશન આર્કિટેક્ચર, ઓએસનું સારું જ્ઞાન;
• ડેટા લોડ અને અનલોડ કરો, વિવિધ DBMS વચ્ચે ડેટા સ્થાનાંતરિત કરો.

સામાન્ય રીતે, જો આપણે તે દિવસોમાં પસંદગી વિશે વાત કરીએ, તો તે 80 ના દાયકાના અંતમાં સોવિયત સ્ટોરની પસંદગી જેવું લાગે છે:

અમારો સમય

ત્યારથી, અલબત્ત, વૃક્ષો ઉગાડ્યા છે, વિશ્વ બદલાઈ ગયું છે, અને તે કંઈક આના જેવું બન્યું:

ડીબીએમએસ માર્કેટ પણ બદલાઈ ગયું છે, જે ગાર્ટનરના નવીનતમ અહેવાલમાંથી સ્પષ્ટપણે જોઈ શકાય છે:

અને અહીં એ નોંધવું જોઇએ કે વાદળો, જેની લોકપ્રિયતા વધી રહી છે, તેમના વિશિષ્ટ સ્થાન પર કબજો મેળવ્યો છે. જો આપણે સમાન ગાર્ટનર અહેવાલ વાંચીએ, તો આપણે નીચેના તારણો જોશું:

1. ઘણા ગ્રાહકો એપ્લિકેશનને ક્લાઉડ પર ખસેડવાના માર્ગ પર છે.
2. નવી તકનીકો પ્રથમ ક્લાઉડમાં દેખાય છે અને તે હકીકત નથી કે તેઓ ક્યારેય બિન-ક્લાઉડ ઇન્ફ્રાસ્ટ્રક્ચર તરફ જશે.
3. પે-એઝ-યુ-ગો પ્રાઇસિંગ મોડલ સામાન્ય બની ગયું છે. દરેક વ્યક્તિ જે ઉપયોગ કરે છે તેના માટે જ ચૂકવણી કરવા માંગે છે, અને આ એક વલણ પણ નથી, પરંતુ ફક્ત હકીકતનું નિવેદન છે.

હવે શું?

આજે આપણે બધા વાદળમાં છીએ. અને આપણા માટે જે પ્રશ્નો ઉભા થાય છે તે પસંદગીના પ્રશ્નો છે. અને જો આપણે ફક્ત ઓન-પ્રિમીસીસ ફોર્મેટમાં DBMS તકનીકોની પસંદગી વિશે વાત કરીએ તો પણ તે વિશાળ છે. અમે સેવાઓ અને SaaS નું સંચાલન પણ કર્યું છે. આમ, પસંદગી દર વર્ષે માત્ર વધુ મુશ્કેલ બની જાય છે.

પસંદગીના પ્રશ્નોની સાથે, ત્યાં પણ છે મર્યાદિત પરિબળો:

• ભાવ. ઘણી તકનીકો હજુ પણ પૈસા ખર્ચે છે;
• કુશળતા. જો આપણે ફ્રી સૉફ્ટવેર વિશે વાત કરી રહ્યા છીએ, તો પછી કૌશલ્યનો પ્રશ્ન ઊભો થાય છે, કારણ કે મફત સૉફ્ટવેરને તે લોકો પાસેથી પર્યાપ્ત યોગ્યતાની જરૂર છે જે તેને જમાવતા અને ચલાવે છે;
• કાર્યાત્મક. બધી સેવાઓ કે જે ક્લાઉડમાં ઉપલબ્ધ છે અને બિલ્ટ છે, કહો કે, સમાન પોસ્ટગ્રેસ પર પણ, પોસ્ટગ્રેસ ઓન-પ્રિમિસીસ જેવી જ સુવિધાઓ ધરાવતી નથી. આ એક આવશ્યક પરિબળ છે જેને જાણવાની અને સમજવાની જરૂર છે. તદુપરાંત, આ પરિબળ એક DBMS ની કેટલીક છુપી ક્ષમતાઓના જ્ઞાન કરતાં વધુ મહત્વપૂર્ણ બની જાય છે.

DA/DE પાસેથી હવે શું અપેક્ષિત છે:

• વિષય વિસ્તાર અને એપ્લિકેશન આર્કિટેક્ચરની સારી સમજ;
• હાથ પરના કાર્યને ધ્યાનમાં લેતા, યોગ્ય DBMS તકનીકને યોગ્ય રીતે પસંદ કરવાની ક્ષમતા;
• હાલની મર્યાદાઓના સંદર્ભમાં પસંદ કરેલ તકનીકના અમલીકરણ માટે શ્રેષ્ઠ પદ્ધતિ પસંદ કરવાની ક્ષમતા;
• ડેટા ટ્રાન્સફર અને સ્થળાંતર કરવાની ક્ષમતા;
• પસંદ કરેલા ઉકેલોને અમલમાં મૂકવા અને ચલાવવાની ક્ષમતા.

ઉદાહરણ નીચે GCP પર આધારિત ડેટા સાથે કામ કરવા માટે એક અથવા બીજી તકનીકની પસંદગી તેની રચનાના આધારે કેવી રીતે કાર્ય કરે છે તે દર્શાવે છે:

મહેરબાની કરીને નોંધ કરો કે PostgreSQL સ્કીમામાં સમાવેલ નથી, અને આ એટલા માટે છે કારણ કે તે પરિભાષા હેઠળ છુપાયેલ છે. મેઘ એસક્યુએલ. અને જ્યારે આપણે ક્લાઉડ એસક્યુએલ પર પહોંચીએ, ત્યારે આપણે ફરીથી પસંદગી કરવાની જરૂર છે:

એ નોંધવું જોઇએ કે આ પસંદગી હંમેશા સ્પષ્ટ હોતી નથી, તેથી એપ્લિકેશન વિકાસકર્તાઓ ઘણીવાર અંતર્જ્ઞાન દ્વારા માર્ગદર્શન આપે છે.

કુલ:

1. તમે જેટલા આગળ વધો છો, પસંદગીનો પ્રશ્ન વધુ દબાવતો જાય છે. અને જો તમે માત્ર GCP, વ્યવસ્થાપિત સેવાઓ અને SaaS જુઓ, તો RDBMS નો અમુક ઉલ્લેખ ફક્ત 4થા પગલા પર જ દેખાય છે (અને ત્યાં સ્પેનર નજીકમાં છે). ઉપરાંત, PostgreSQL ની પસંદગી 5મા પગલામાં દેખાય છે, અને તેની બાજુમાં MySQL અને SQL સર્વર પણ છે, એટલે કે ત્યાં બધું ઘણું છે, પરંતુ તમારે પસંદ કરવું પડશે.
2. આપણે લાલચની પૃષ્ઠભૂમિ સામેના પ્રતિબંધો વિશે ભૂલવું જોઈએ નહીં. મૂળભૂત રીતે દરેકને સ્પેનર જોઈએ છે, પરંતુ તે ખર્ચાળ છે. પરિણામે, સામાન્ય વિનંતી કંઈક આના જેવી દેખાય છે: "કૃપા કરીને અમને સ્પેનર બનાવો પરંતુ Cloud SQL ની કિંમત માટે, તમે વ્યાવસાયિકો છો!"

આપણે શું કરવું જોઈએ?

અંતિમ સત્ય હોવાનો દાવો કર્યા વિના, ચાલો નીચે મુજબ કહીએ:

અમારે શીખવા માટેનો અમારો અભિગમ બદલવાની જરૂર છે:

• પહેલા જે રીતે ડીબીએ શીખવવામાં આવતું હતું તે રીતે શીખવવાનો કોઈ અર્થ નથી;
• એક ઉત્પાદનનું જ્ઞાન હવે પૂરતું નથી;
• પરંતુ એકના સ્તરે ડઝનેક જાણવું અશક્ય છે.

તમારે માત્ર એ જાણવાની જરૂર નથી કે ઉત્પાદન કેટલું છે, પરંતુ:

• તેની એપ્લિકેશનનો ઉપયોગ કેસ;
• વિવિધ જમાવટ પદ્ધતિઓ;
• દરેક પદ્ધતિના ફાયદા અને ગેરફાયદા;
• સમાન અને વૈકલ્પિક ઉત્પાદનો જાણકાર અને શ્રેષ્ઠ પસંદગી કરવા માટે અને હંમેશા પરિચિત ઉત્પાદનની તરફેણમાં નથી.

તમારે ડેટાને સ્થાનાંતરિત કરવામાં અને ETL સાથે એકીકરણના મૂળભૂત સિદ્ધાંતોને સમજવામાં પણ સક્ષમ હોવું જરૂરી છે.

વાસ્તવિક કેસ

તાજેતરના ભૂતકાળમાં, મોબાઇલ એપ્લિકેશન માટે બેકએન્ડ બનાવવું જરૂરી હતું. તેના પર કામ શરૂ થયું ત્યાં સુધીમાં, બેકએન્ડ પહેલેથી જ વિકસિત થઈ ચૂક્યું હતું અને અમલીકરણ માટે તૈયાર હતું, અને વિકાસ ટીમે આ પ્રોજેક્ટ પર લગભગ બે વર્ષ ગાળ્યા હતા. નીચેના કાર્યો સેટ કરવામાં આવ્યા હતા:

• CI/CD બિલ્ડ કરો;
• આર્કિટેક્ચરની સમીક્ષા કરો;
• તે બધું ઓપરેશનમાં મૂકો.

એપ્લિકેશન પોતે માઇક્રોસર્વિસીસ હતી, અને પાયથોન/જેંગો કોડ શરૂઆતથી અને સીધો જીસીપીમાં વિકસાવવામાં આવ્યો હતો. લક્ષ્ય પ્રેક્ષકો માટે, એવું માનવામાં આવતું હતું કે ત્યાં બે પ્રદેશો હશે - યુએસ અને ઇયુ, અને ટ્રાફિકનું વિતરણ વૈશ્વિક લોડ બેલેન્સર દ્વારા કરવામાં આવ્યું હતું. બધા વર્કલોડ અને ગણતરી વર્કલોડ Google Kubernetes Engine પર ચાલે છે.

ડેટા માટે, ત્યાં 3 માળખાં હતા:

• મેઘ સંગ્રહ;
• ડેટાસ્ટોર;
• મેઘ SQL (PostgreSQL).

કોઈને આશ્ચર્ય થશે કે ક્લાઉડ એસક્યુએલ શા માટે પસંદ કરવામાં આવ્યું હતું? સાચું કહું તો, આવા પ્રશ્ને તાજેતરના વર્ષોમાં એક પ્રકારનો બેડોળ વિરામ આપ્યો છે - એવી લાગણી છે કે લોકો રિલેશનલ ડેટાબેસેસ વિશે શરમાળ બની ગયા છે, પરંતુ તેમ છતાં તેઓ તેનો સક્રિયપણે ઉપયોગ કરવાનું ચાલુ રાખે છે ;-).

અમારા કિસ્સામાં, ક્લાઉડ એસક્યુએલ નીચેના કારણોસર પસંદ કરવામાં આવ્યું હતું:

1. ઉલ્લેખ કર્યો છે તેમ, એપ્લિકેશન Django નો ઉપયોગ કરીને વિકસાવવામાં આવી હતી, અને તેમાં એક SQL ડેટાબેઝથી Python ઑબ્જેક્ટ્સ (Django ORM) પર સતત ડેટા મેપ કરવા માટે એક મોડેલ છે.
2. ફ્રેમવર્ક પોતે DBMS ની એકદમ મર્યાદિત સૂચિને સમર્થન આપે છે:

• PostgreSQL;
• મારિયાડીબી;
• MySQL;
• ઓરેકલ;
• SQLite.

તદનુસાર, PostgreSQL આ સૂચિમાંથી સાહજિક રીતે પસંદ કરવામાં આવ્યું હતું (સારું, તે પસંદ કરવા માટે ઓરેકલ નથી, ખરેખર).

શું ખૂટતું હતું:

• એપ્લિકેશન ફક્ત 2 પ્રદેશોમાં જ તૈનાત કરવામાં આવી હતી, અને 3જી યોજનાઓ (એશિયા);
• ડેટાબેઝ ઉત્તર અમેરિકન પ્રદેશ (આયોવા) માં સ્થિત હતો;
• ગ્રાહક તરફથી શક્ય વિશે ચિંતાઓ હતી ઍક્સેસ વિલંબ યુરોપ અને એશિયામાંથી અને વિક્ષેપો સેવા માં DBMS ડાઉનટાઇમના કિસ્સામાં.

એ હકીકત હોવા છતાં કે જેંગો પોતે ઘણા ડેટાબેસેસ સાથે સમાંતરમાં કામ કરી શકે છે અને તેમને વાંચન અને લેખનમાં વિભાજિત કરી શકે છે, એપ્લિકેશનમાં આટલું લખાણ નહોતું (90% થી વધુ વાંચે છે). અને સામાન્ય રીતે, અને સામાન્ય રીતે, જો તે કરવું શક્ય હતું યુરોપ અને એશિયામાં મુખ્ય આધારની વાંચન-પ્રતિકૃતિ, આ એક સમાધાનકારી ઉકેલ હશે. સારું, તે વિશે શું જટિલ છે?

મુશ્કેલી એ હતી કે ગ્રાહક વ્યવસ્થાપિત સેવાઓ અને ક્લાઉડ એસક્યુએલનો ઉપયોગ છોડવા માંગતો ન હતો. અને Cloud SQL ની ક્ષમતાઓ હાલમાં મર્યાદિત છે. ક્લાઉડ એસક્યુએલ ઉચ્ચ ઉપલબ્ધતા (HA) અને રીડ રેપ્લિકા (RR) ને સપોર્ટ કરે છે, પરંતુ સમાન RR માત્ર એક પ્રદેશમાં જ સમર્થિત છે. અમેરિકન પ્રદેશમાં ડેટાબેઝ બનાવ્યા પછી, તમે ક્લાઉડ એસક્યુએલનો ઉપયોગ કરીને યુરોપિયન પ્રદેશમાં રીડ રેપ્લિકા બનાવી શકતા નથી, જો કે પોસ્ટગ્રેસ પોતે તમને આ કરવાથી રોકતું નથી. Google કર્મચારીઓ સાથેનો પત્રવ્યવહાર ક્યાંય ન હતો અને "અમે સમસ્યા જાણીએ છીએ અને તેના પર કામ કરી રહ્યા છીએ, એક દિવસ આ સમસ્યા ઉકેલાઈ જશે" ની શૈલીમાં વચનો સાથે સમાપ્ત થઈ.

જો આપણે Cloud SQL ની ક્ષમતાઓને સંક્ષિપ્તમાં સૂચિબદ્ધ કરીએ, તો તે કંઈક આના જેવું દેખાશે:

1. ઉચ્ચ ઉપલબ્ધતા (HA):

• એક પ્રદેશની અંદર;
• ડિસ્ક પ્રતિકૃતિ દ્વારા;
• PostgreSQL એન્જિનનો ઉપયોગ થતો નથી;
• સ્વચાલિત અને મેન્યુઅલ નિયંત્રણ શક્ય - ફેલઓવર/ફેલબેક;
• સ્વિચ કરતી વખતે, DBMS ઘણી મિનિટો માટે અનુપલબ્ધ હોય છે.

2. પ્રતિકૃતિ (RR) વાંચો:

• એક પ્રદેશની અંદર;
• ગરમ સ્ટેન્ડબાય;
• PostgreSQL સ્ટ્રીમિંગ પ્રતિકૃતિ.

વધુમાં, જેમ કે પ્રચલિત છે, જ્યારે ટેક્નૉલૉજી પસંદ કરતી વખતે તમને કેટલીક સમસ્યાઓનો સામનો કરવો પડે છે પ્રતિબંધો:

• ગ્રાહક GKE મારફતે સિવાય એન્ટિટી બનાવવા અને IaaS નો ઉપયોગ કરવા માંગતા ન હતા;
• ગ્રાહક સ્વયં સેવા PostgreSQL/MySQL જમાવવાનું પસંદ કરશે નહીં;
• ઠીક છે, સામાન્ય રીતે, Google સ્પેનર તેની કિંમત માટે ન હોત તો તે એકદમ યોગ્ય હશે, જો કે, Django ORM તેની સાથે કામ કરી શકતું નથી, પરંતુ તે સારી બાબત છે.

પરિસ્થિતિને ધ્યાનમાં લેતા, ગ્રાહકને ફોલો-અપ પ્રશ્ન મળ્યો: "શું તમે કંઈક એવું કરી શકો છો કે જેથી તે Google Spanner જેવું હોય, પણ Django ORM સાથે પણ કામ કરે?"

ઉકેલ વિકલ્પ નંબર 0

પ્રથમ વસ્તુ જે ધ્યાનમાં આવી:

• CloudSQL ની અંદર રહો;
• કોઈપણ સ્વરૂપમાં પ્રદેશો વચ્ચે કોઈ બિલ્ટ-ઇન પ્રતિકૃતિ હશે નહીં;
• PostgreSQL દ્વારા હાલની ક્લાઉડ SQL સાથે પ્રતિકૃતિ જોડવાનો પ્રયાસ કરો;
• ક્યાંક અને કોઈક રીતે પોસ્ટગ્રેએસક્યુએલ દાખલો લોંચ કરો, પરંતુ ઓછામાં ઓછું માસ્ટરને સ્પર્શ કરશો નહીં.

અરે, તે બહાર આવ્યું કે આ કરી શકાતું નથી, કારણ કે હોસ્ટની કોઈ ઍક્સેસ નથી (તે એકસાથે અલગ પ્રોજેક્ટમાં છે) - pg_hba અને તેથી વધુ, અને સુપરયુઝર હેઠળ પણ કોઈ ઍક્સેસ નથી.

ઉકેલ વિકલ્પ નંબર 1

વધુ ચિંતન કર્યા પછી અને અગાઉના સંજોગોને ધ્યાનમાં લીધા પછી, વિચારની ટ્રેન કંઈક અંશે બદલાઈ ગઈ:

• અમે હજી પણ CloudSQL માં રહેવાનો પ્રયાસ કરી રહ્યા છીએ, પરંતુ અમે MySQL પર સ્વિચ કરી રહ્યા છીએ, કારણ કે MySQL દ્વારા ક્લાઉડ SQL પાસે બાહ્ય માસ્ટર છે, જે:

- બાહ્ય MySQL માટે પ્રોક્સી છે;
- MySQL ઉદાહરણ જેવું લાગે છે;
- અન્ય વાદળો અથવા ઓન-પ્રિમિસીસમાંથી ડેટા સ્થાનાંતરિત કરવા માટે શોધ કરવામાં આવી હતી.

MySQL પ્રતિકૃતિને સેટ કરવા માટે હોસ્ટની ઍક્સેસની જરૂર નથી, સૈદ્ધાંતિક રીતે બધું કામ કરતું હતું, પરંતુ તે ખૂબ જ અસ્થિર અને અસુવિધાજનક હતું. અને જ્યારે અમે આગળ ગયા, ત્યારે તે સંપૂર્ણપણે ડરામણી બની ગયું, કારણ કે અમે સમગ્ર માળખું ટેરાફોર્મ સાથે જમાવ્યું, અને અચાનક તે બહાર આવ્યું કે બાહ્ય માસ્ટર ટેરાફોર્મ દ્વારા સપોર્ટેડ નથી. હા, Google પાસે CLI છે, પરંતુ કેટલાક કારણોસર અહીં દરેક વસ્તુ સમયાંતરે કામ કરે છે - ક્યારેક તે બનાવવામાં આવે છે, ક્યારેક તે બનાવવામાં આવતું નથી. કદાચ કારણ કે CLI ની શોધ બાહ્ય ડેટા સ્થળાંતર માટે કરવામાં આવી હતી, પ્રતિકૃતિઓ માટે નહીં.

ખરેખર, આ બિંદુએ તે સ્પષ્ટ થઈ ગયું છે કે ક્લાઉડ એસક્યુએલ બિલકુલ યોગ્ય નથી. જેમ તેઓ કહે છે, અમે અમારાથી બનતું બધું કર્યું.

ઉકેલ વિકલ્પ નંબર 2

ક્લાઉડ SQL ફ્રેમવર્કમાં રહેવું શક્ય ન હોવાથી, અમે સમાધાન ઉકેલ માટે જરૂરિયાતો ઘડવાનો પ્રયાસ કર્યો. આવશ્યકતાઓ નીચેની હોવાનું બહાર આવ્યું:

• કુબરનેટ્સમાં કામ, કુબરનેટ્સ (ડીસીએસ, ...) અને જીસીપી (એલબી, ...) ની સંસાધનોનો મહત્તમ ઉપયોગ અને ક્ષમતાઓ;
• HA પ્રોક્સી જેવા ક્લાઉડમાં બિનજરૂરી વસ્તુઓના સમૂહમાંથી બાલાસ્ટનો અભાવ;
• મુખ્ય HA પ્રદેશમાં PostgreSQL અથવા MySQL ચલાવવાની ક્ષમતા; અન્ય પ્રદેશોમાં - મુખ્ય પ્રદેશના RR માંથી HA વત્તા તેની નકલ (વિશ્વસનીયતા માટે);
• મલ્ટી માસ્ટર (હું તેનો સંપર્ક કરવા માંગતો ન હતો, પરંતુ તે ખૂબ મહત્વનું ન હતું)

.
આ માંગણીઓના પરિણામે પીયોગ્ય DBMS અને બંધનકર્તા વિકલ્પો:

• MySQL ગેલેરા;
• કોકરોચડીબી;
• PostgreSQL સાધનો

:
- pgpool-II;
- આશ્રયદાતા.

MySQL ગેલેરા

MySQL ગેલેરા ટેક્નોલોજી કોડરશિપ દ્વારા વિકસાવવામાં આવી હતી અને તે InnoDB માટે પ્લગઇન છે. વિશિષ્ટતાઓ:

• મલ્ટી માસ્ટર;
• સિંક્રનસ પ્રતિકૃતિ;
• કોઈપણ નોડમાંથી વાંચન;
• કોઈપણ નોડ પર રેકોર્ડિંગ;
• બિલ્ટ-ઇન HA મિકેનિઝમ;
• બિટનામી તરફથી એક હેલ્મ ચાર્ટ છે.

કોકરોચડીબી

વર્ણન અનુસાર, વસ્તુ એકદમ બોમ્બ છે અને ગોમાં લખાયેલ ઓપન સોર્સ પ્રોજેક્ટ છે. મુખ્ય સહભાગી કોકરોચ લેબ્સ છે (Google ના લોકો દ્વારા સ્થાપિત). આ રિલેશનલ ડીબીએમએસ મૂળરૂપે વિતરિત કરવા માટે બનાવવામાં આવ્યું હતું (બૉક્સની બહાર આડી સ્કેલિંગ સાથે) અને ખામી-સહિષ્ણુ. કંપનીના તેના લેખકોએ "NoSQL સોલ્યુશન્સથી પરિચિત આડી સુલભતા સાથે SQL કાર્યક્ષમતાની સમૃદ્ધિને સંયોજિત કરવાનો" ધ્યેય દર્શાવ્યો હતો.

એક સરસ બોનસ પોસ્ટ-ગ્રેસ કનેક્શન પ્રોટોકોલ માટે સપોર્ટ છે.

પીજીપૂલ

આ PostgreSQL માં એડ-ઓન છે, હકીકતમાં, એક નવી એન્ટિટી છે જે તમામ કનેક્શન્સ લે છે અને તેમની પ્રક્રિયા કરે છે. તેની પાસે તેનું પોતાનું લોડ બેલેન્સર અને પાર્સર છે, જે BSD લાયસન્સ હેઠળ લાઇસન્સ ધરાવે છે. તે પૂરતી તકો પૂરી પાડે છે, પરંતુ કંઈક અંશે ડરામણી લાગે છે, કારણ કે નવી એન્ટિટીની હાજરી કેટલાક વધારાના સાહસોનું સ્ત્રોત બની શકે છે.

પટ્રોની

આ છેલ્લી વસ્તુ છે જેના પર મારી નજર પડી, અને, જેમ તે બહાર આવ્યું, નિરર્થક નથી. Patroni એ એક ઓપન સોર્સ યુટિલિટી છે, જે અનિવાર્યપણે પાયથોન ડિમન છે જે તમને પોસ્ટગ્રેએસક્યુએલ ક્લસ્ટરોને વિવિધ પ્રકારની પ્રતિકૃતિ અને ઓટોમેટિક રોલ સ્વિચિંગ સાથે આપમેળે જાળવવા માટે પરવાનગી આપે છે. વસ્તુ ખૂબ જ રસપ્રદ બની, કારણ કે તે ક્યુબર સાથે સારી રીતે સંકલિત થાય છે અને કોઈ નવી એન્ટિટી રજૂ કરતી નથી.

તમે અંતે શું પસંદ કર્યું?

પસંદગી સરળ ન હતી:

1. કોકરોચડીબી - આગ, પરંતુ શ્યામ;
2. MySQL ગેલેરા - ખરાબ પણ નથી, તેનો ઉપયોગ ઘણી જગ્યાએ થાય છે, પરંતુ MySQL;
3. પીજીપૂલ — ઘણી બધી બિનજરૂરી સંસ્થાઓ, ક્લાઉડ અને K8s સાથે આમ એકીકરણ;
4. પટ્રોની - K8s સાથે ઉત્તમ સંકલન, કોઈ બિનજરૂરી સંસ્થાઓ, GCP LB સાથે સારી રીતે સંકલિત થાય છે.

આમ, પસંદગી પટ્રોની પર પડી.

તારણો

ટૂંકમાં સારાંશ આપવાનો આ સમય છે. હા, આઈટી ઈન્ફ્રાસ્ટ્રક્ચરની દુનિયા નોંધપાત્ર રીતે બદલાઈ ગઈ છે, અને આ માત્ર શરૂઆત છે. અને જો પહેલા વાદળો માત્ર અન્ય પ્રકારનું ઇન્ફ્રાસ્ટ્રક્ચર હતું, તો હવે બધું અલગ છે. તદુપરાંત, વાદળોમાં નવીનતાઓ સતત દેખાઈ રહી છે, તે દેખાશે અને, કદાચ, તે ફક્ત વાદળોમાં જ દેખાશે અને માત્ર ત્યારે જ, સ્ટાર્ટઅપ્સના પ્રયત્નો દ્વારા, તેને ઓન-પ્રિમિસીસમાં સ્થાનાંતરિત કરવામાં આવશે.

SQL માટે, SQL જીવંત રહેશે. આનો અર્થ એ છે કે તમારે PostgreSQL અને MySQL ને જાણવાની જરૂર છે અને તેમની સાથે કામ કરવા માટે સક્ષમ બનવાની જરૂર છે, પરંતુ તેનાથી પણ વધુ મહત્વપૂર્ણ છે કે તેનો યોગ્ય રીતે ઉપયોગ કરવામાં સક્ષમ બનવું.

સોર્સ: www.habr.com