በ 21 ኛው ክፍለ ዘመን ከ SQL ዳታቤዝ እንዴት እንደሚተርፉ: ደመናዎች ፣ ኩበርኔትስ እና PostgreSQL መልቲማስተር

ጤና ይስጥልኝ የካብሮቭስክ ነዋሪዎች። በኮርሱ የመጀመሪያ ቡድን ውስጥ ያሉ ክፍሎች ዛሬ ይጀምራሉ "PostgreSQL". በዚህ ረገድ, በዚህ ኮርስ ላይ ክፍት ዌቢናር እንዴት እንደተከናወነ ልንነግርዎ እንፈልጋለን.

В ቀጣዩ ክፍት ትምህርት በደመና እና በኩበርኔትስ ዘመን የ SQL የውሂብ ጎታዎች የሚያጋጥሟቸውን ተግዳሮቶች ተነጋግረናል። በተመሳሳይ ጊዜ፣ የ SQL የውሂብ ጎታዎች በእነዚህ ተግዳሮቶች ተጽእኖ ስር እንዴት እንደሚለዋወጡ እና እንደሚለዋወጡ ተመልክተናል።

ዌቢናር ተካሄደ Valery BezrukovበEPAM ሲስተምስ የጉግል ክላውድ ልምምድ ማድረሻ ስራ አስኪያጅ።

ዛፎቹ ትንሽ ሲሆኑ ...

በመጀመሪያ ፣ የ DBMS ምርጫ ባለፈው ክፍለ ዘመን መጨረሻ ላይ እንዴት እንደጀመረ እናስታውስ። ሆኖም፣ ይህ አስቸጋሪ አይሆንም፣ ምክንያቱም በእነዚያ ቀናት የ DBMS ምርጫ ተጀምሯል እና አብቅቷል። Oracle.

በ90ዎቹ መገባደጃ እና በ2ዎቹ መጀመሪያ ላይ፣ በኢንዱስትሪ ሊለወጡ የሚችሉ የውሂብ ጎታዎችን በተመለከተ ምንም ምርጫ አልነበረም። አዎ፣ IBM DBXNUMX፣ Sybase እና አንዳንድ ሌሎች መጥተው የሄዱ የውሂብ ጎታዎች ነበሩ፣ ነገር ግን በአጠቃላይ በOracle ዳራ ላይ ያን ያህል የሚታዩ አልነበሩም። በዚህ መሠረት የዚያን ጊዜ መሐንዲሶች ችሎታ ከነበረው ብቸኛው ምርጫ ጋር የተቆራኘ ነበር።

Oracle DBA የሚከተሉትን ማድረግ መቻል ነበረበት፦

• ከስርጭት ኪት ውስጥ Oracle Server ን ይጫኑ;
• Oracle አገልጋይን ያዋቅሩ

• init.ora;
• አድማጭ.ኦራ;

- መፍጠር;

• የጠረጴዛ ቦታዎች;
• መርሃግብሮች;
• ተጠቃሚዎች;

- ምትኬን ማከናወን እና መመለስ;
- ክትትል ማካሄድ;
- ከተሻሻሉ ጥያቄዎች ጋር መገናኘት።

በተመሳሳይ ጊዜ፣ ከOracle DBA ምንም ልዩ መስፈርት አልነበረም፡-

• መረጃን ለማከማቸት እና ለማስኬድ ጥሩውን DBMS ወይም ሌላ ቴክኖሎጂ መምረጥ መቻል ፤
• ከፍተኛ ተደራሽነት እና አግድም ልኬት መስጠት (ይህ ሁልጊዜ የ DBA ጉዳይ አልነበረም)።
• ስለ ርዕሰ ጉዳዩ አካባቢ ጥሩ እውቀት, መሠረተ ልማት, የመተግበሪያ አርክቴክቸር, ስርዓተ ክወና;
• ውሂብን ይጫኑ እና ያራግፉ፣ ውሂብን በተለያዩ ዲቢኤምኤስ መካከል ያዛውሩ።

በአጠቃላይ ፣ በእነዚያ ቀናት ስለ ምርጫው ከተነጋገርን ፣ በ 80 ዎቹ መገባደጃ ላይ በሶቪየት ሱቅ ውስጥ ካለው ምርጫ ጋር ይመሳሰላል ።

የእኛ ጊዜ።

ከዚያን ጊዜ ጀምሮ, በእርግጥ, ዛፎቹ አድገዋል, ዓለም ተለውጧል, እና እንደዚህ ያለ ነገር ሆነ.

ከቅርብ ጊዜ የጋርትነር ዘገባ በግልፅ እንደሚታየው የዲቢኤምኤስ ገበያም ተቀይሯል።

እና እዚህ ታዋቂነታቸው እየጨመረ የመጣ ደመናዎች ቦታቸውን እንደያዙ ልብ ሊባል ይገባል። ተመሳሳይ የጋርትነር ዘገባ ካነበብን የሚከተሉትን መደምደሚያዎች እናያለን፡-

1. ብዙ ደንበኞች መተግበሪያዎችን ወደ ደመና ለማንቀሳቀስ መንገድ ላይ ናቸው።
2. አዳዲስ ቴክኖሎጂዎች በመጀመሪያ በደመና ውስጥ ይገለጣሉ እና ወደ ደመና ያልሆኑ መሠረተ ልማቶች የሚሄዱ መሆናቸው እውነት አይደለም።
3. ሲሄዱ ክፍያ የዋጋ አሰጣጥ ሞዴል የተለመደ ሆኗል። ሁሉም ሰው ለሚጠቀሙበት ብቻ መክፈል ይፈልጋል, እና ይህ አዝማሚያ እንኳን አይደለም, ነገር ግን በቀላሉ የእውነታ መግለጫ ነው.

አሁንስ?

ዛሬ ሁላችንም በደመና ውስጥ ነን። ለእኛ የሚነሱት ጥያቄዎች ደግሞ የምርጫ ጥያቄዎች ናቸው። እና ስለ DBMS ቴክኖሎጂዎች ምርጫ በግቢው ውስጥ ብቻ ብንነጋገርም በጣም ትልቅ ነው። እንዲሁም የሚተዳደሩ አገልግሎቶች እና SaaS አሉን። ስለዚህ ምርጫው በየዓመቱ የበለጠ አስቸጋሪ ይሆናል.

ከምርጫ ጥያቄዎች ጋር, እንዲሁ አሉ መገደብ ምክንያቶች:

• ዋጋ. ብዙ ቴክኖሎጂዎች አሁንም ገንዘብ ያስወጣሉ;
• ክህሎቶች. ስለ ነፃ ሶፍትዌሮች እየተነጋገርን ከሆነ፣ ነፃ ሶፍትዌር ከሚያሰማሩት እና ከሚያንቀሳቅሱት ሰዎች በቂ ብቃት ስለሚያስፈልገው የችሎታ ጥያቄ ይነሳል።
• ተግባራዊ. ሁሉም በደመና ውስጥ የሚገኙ እና የተገነቡ ሁሉም አገልግሎቶች አይደሉም፣ በላቸው፣ በተመሳሳይ Postgres ላይ እንኳን፣ ከ Postgres On-premises ጋር አንድ አይነት ባህሪ አላቸው። ይህ ሊታወቅ እና ሊታወቅ የሚገባው አስፈላጊ ነገር ነው. በተጨማሪም፣ ይህ ሁኔታ የአንድ ዲቢኤምኤስ አንዳንድ ድብቅ ችሎታዎች ከማወቅ የበለጠ አስፈላጊ ይሆናል።

አሁን ከDA/DE ምን ይጠበቃል፡-

• ስለ ርዕሰ ጉዳዩ አካባቢ እና የመተግበሪያ ስነ-ህንፃ ጥሩ ግንዛቤ;
• ተገቢውን የዲቢኤምኤስ ቴክኖሎጂ በትክክል የመምረጥ ችሎታ, የተያዘውን ተግባር ግምት ውስጥ በማስገባት;
• አሁን ባለው ውስንነት ውስጥ የተመረጠውን ቴክኖሎጂ ተግባራዊ ለማድረግ በጣም ጥሩውን ዘዴ የመምረጥ ችሎታ;
• የውሂብ ማስተላለፍ እና ፍልሰት የማከናወን ችሎታ;
• የተመረጡ መፍትሄዎችን የመተግበር እና የመተግበር ችሎታ.

ከዚህ በታች ምሳሌ በ GCP ላይ የተመሠረተ ከመረጃ ጋር ለመስራት የአንድ ወይም የሌላ ቴክኖሎጂ ምርጫ እንደ አወቃቀሩ እንዴት እንደሚሰራ ያሳያል።

እባክዎን PostgreSQL በስርዓተ-ፆታ ውስጥ ያልተካተተ መሆኑን ልብ ይበሉ፣ እና ይህ የሆነው በቃላት ስር ስለተደበቀ ነው። ደመና SQL. እና ወደ Cloud SQL ስንደርስ እንደገና ምርጫ ማድረግ አለብን፡-

ይህ ምርጫ ሁልጊዜ ግልጽ እንዳልሆነ ልብ ሊባል የሚገባው ነው, ስለዚህ የመተግበሪያ ገንቢዎች ብዙውን ጊዜ በእውቀት ይመራሉ.

ጠቅላላ:

1. በሄድክ ቁጥር የመምረጥ ጥያቄው እየጨመረ ይሄዳል። እና GCP፣ የሚተዳደሩ አገልግሎቶች እና SaaS ብቻ ቢመለከቱም፣ አንዳንድ የ RDBMS መጠቀስ በ 4 ኛ ደረጃ ላይ ብቻ ይታያል (እና እዚያ Spanner በአቅራቢያ አለ)። በተጨማሪም ፣ የ PostgreSQL ምርጫ በ 5 ኛ ደረጃ ላይ ይታያል ፣ እና ከእሱ ቀጥሎ MySQL እና SQL አገልጋይም አሉ ፣ ማለትም ሁሉም ነገር በጣም ብዙ ነው, ግን መምረጥ አለብዎት.
2. በፈተናዎች ዳራ ላይ ስለ እገዳዎች መርሳት የለብንም. በመሠረቱ ሁሉም ሰው ስፓነር ይፈልጋል፣ ግን ውድ ነው። በውጤቱም, የተለመደው ጥያቄ ይህን ይመስላል: "እባክዎ ስፓነር ያድርገን ግን ለ Cloud SQL ዋጋ እርስዎ ባለሙያዎች ናችሁ!"

ምን እናድርግ?

የመጨረሻው እውነት ነን ሳንል የሚከተለውን እንበል።

የመማር አካሄዳችንን መቀየር አለብን፡-

• ከዚህ በፊት ዲቢኤዎች የተማሩበትን መንገድ ማስተማር ምንም ፋይዳ የለውም።
• የአንድ ምርት እውቀት ከአሁን በኋላ በቂ አይደለም;
• ግን በደርዘን የሚቆጠሩ ሰዎችን በአንድ ደረጃ ማወቅ የማይቻል ነው።

ምርቱ ምን ያህል እንደሆነ ማወቅ ብቻ ሳይሆን ነገር ግን:

• የአጠቃቀም ጉዳይ;
• የተለያዩ የማሰማራት ዘዴዎች;
• የእያንዳንዱ ዘዴ ጥቅሞች እና ጉዳቶች;
• ተመሳሳይ እና አማራጭ ምርቶች በመረጃ ላይ የተመሰረተ እና ጥሩ ምርጫ ለማድረግ እና ሁልጊዜ ለሚታወቀው ምርት አይደግፉም.

እንዲሁም መረጃን ማዛወር እና ከኢቲኤል ጋር የመዋሃድ መሰረታዊ መርሆችን መረዳት መቻል አለቦት።

እውነተኛ ጉዳይ

በቅርብ ጊዜ ውስጥ ለሞባይል አፕሊኬሽን ጀርባ መፍጠር አስፈላጊ ነበር። በእሱ ላይ ሥራ በጀመረበት ጊዜ, የጀርባው አካል ቀድሞውኑ ተዘጋጅቷል እና ለትግበራ ዝግጁ ነበር, እና የልማት ቡድኑ በዚህ ፕሮጀክት ላይ ለሁለት ዓመታት ያህል አሳልፏል. የሚከተሉት ተግባራት ተዘጋጅተዋል፡-

• CI / ሲዲ ይገንቡ;
• የሕንፃውን አሠራር መገምገም;
• ሁሉንም ወደ ሥራ አስገባ።

አፕሊኬሽኑ ራሱ ማይክሮ ሰርቪስ ነበር፣ እና የ Python/Django ኮድ ከባዶ እና በቀጥታ በጂ.ሲ.ፒ. የተሰራ ነው። የታለመውን ታዳሚ በተመለከተ፣ ሁለት ክልሎች - ዩኤስ እና የአውሮፓ ህብረት እንደሚኖሩ ታሳቢ ተደርጎ ነበር፣ እና ትራፊክ የተከፋፈለው በግሎባል ሎድ ሚዛን ነው። ሁሉም የስራ ጫናዎች እና የስራ ጫናዎች በGoogle Kubernetes ሞተር ላይ ሄደዋል።

እንደ መረጃው, 3 መዋቅሮች ነበሩ.

• የደመና ማከማቻ;
• የውሂብ ማከማቻ;
• ደመና SQL (PostgreSQL)።

አንድ ሰው Cloud SQL ለምን እንደተመረጠ ሊያስገርም ይችላል? እውነቱን ለመናገር ፣ እንዲህ ዓይነቱ ጥያቄ በቅርብ ዓመታት ውስጥ አንድ ዓይነት አሰቃቂ ቆም እንዲል አድርጓል - ሰዎች ስለ ተዛማጅ የውሂብ ጎታዎች ዓይናፋር ሆነዋል የሚል ስሜት አለ ፣ ግን እነሱ በንቃት መጠቀማቸውን ቀጥለዋል ;-).

የእኛን ጉዳይ በተመለከተ፣ Cloud SQL የተመረጠው በሚከተሉት ምክንያቶች ነው።

1. እንደተጠቀሰው፣ አፕሊኬሽኑ የተገነባው Djangoን በመጠቀም ነው፣ እና ከSQL ዳታቤዝ ወደ ፓይዘን ነገሮች (ጃንጎ ORM) ቀጣይነት ያለው መረጃን የማዘጋጀት ሞዴል አለው።
2. ማዕቀፉ ራሱ በትክክል የተገደበ የዲቢኤምኤስ ዝርዝርን ይደግፋል፡-

• PostgreSQL;
• ማሪያዲቢ;
• MySQL;
• ኦራክል;
• SQLite።

በዚህ መሠረት PostgreSQL ከዚህ ዝርዝር ውስጥ በማስተዋል ተመርጧል (በእርግጥም Oracleን መምረጥ አይደለም)።

የጎደለው ነገር፡-

• ማመልከቻው በ 2 ክልሎች ውስጥ ብቻ ተዘርግቷል, እና 3 ኛ በእቅዶች (እስያ) ውስጥ ታየ;
• የመረጃ ቋቱ በሰሜን አሜሪካ ክልል (አዮዋ) ውስጥ ይገኝ ነበር;
• በደንበኛው በኩል ሊኖሩ ስለሚችሉ ስጋቶች ነበሩ የመዳረሻ መዘግየቶች ከአውሮፓ እና እስያ እና ማቋረጦች በአገልግሎት ላይ የዲቢኤምኤስ የእረፍት ጊዜ ካለ.

ምንም እንኳን Django እራሱ ከበርካታ የውሂብ ጎታዎች ጋር በትይዩ መስራት እና በንባብ እና በመፃፍ መከፋፈል ቢችልም, በመተግበሪያው ውስጥ ብዙ ጽሁፍ አልነበረም (ከ 90% በላይ ማንበብ ነው). እና በአጠቃላይ, እና በአጠቃላይ, ማድረግ ቢቻል በአውሮፓ እና በእስያ ውስጥ ዋናው መሠረት የተነበበ-ቅጅይህ የመስማማት መፍትሄ ይሆናል። ደህና፣ በዚህ ጉዳይ ምን የተወሳሰበ ነገር አለ?

ችግሩ ደንበኛው የሚተዳደሩ አገልግሎቶችን እና Cloud SQL በመጠቀም መተው አለመፈለጉ ነበር። እና የ Cloud SQL አቅም በአሁኑ ጊዜ የተገደበ ነው። Cloud SQL ከፍተኛ ተገኝነት (HA) እና Read Replica (RR) ይደግፋል፣ ነገር ግን ተመሳሳይ RR የሚደገፈው በአንድ ክልል ውስጥ ብቻ ነው። በአሜሪካ ክልል ውስጥ የውሂብ ጎታ ከፈጠርክ በኋላ በአውሮፓ ክልል Cloud SQL ን በመጠቀም የተነበበ ቅጂ መስራት አትችልም፣ ምንም እንኳን ፖስትግሬስ እራሱ ይህን ከማድረግ አይከለክልህም። ከጎግል ሰራተኞች ጋር የተደረገው ግንኙነት የትም አልደረሰም እና “ችግሩን አውቀን እየሰራንበት ነው፣ አንድ ቀን ጉዳዩ እልባት ያገኛል” በሚሉ ተስፋዎች አብቅቷል።

የክላውድ SQLን አቅም ባጭሩ ከዘረዘርነው፣ እንደዚህ ያለ ነገር ይመስላል።

1. ከፍተኛ ተደራሽነት (HA):

• በአንድ ክልል ውስጥ;
• በዲስክ ማባዛት;
• PostgreSQL ሞተሮች ጥቅም ላይ አይውሉም;
• አውቶማቲክ እና በእጅ መቆጣጠር ይቻላል - አለመሳካት / ውድቀት;
• ሲቀይሩ ዲቢኤምኤስ ለብዙ ደቂቃዎች አይገኝም።

2. ቅጂ (RR) አንብብ፦

• በአንድ ክልል ውስጥ;
• ትኩስ ተጠባባቂ;
• PostgreSQL ዥረት ማባዛት።

በተጨማሪም ፣ እንደተለመደው ፣ አንድ ቴክኖሎጂ በሚመርጡበት ጊዜ ሁል ጊዜ ከአንዳንዶቹ ጋር ይጋፈጣሉ ገደቦች:

• ደንበኛው በ GKE በኩል ካልሆነ በስተቀር አካላትን መፍጠር እና IaaS ን መጠቀም አልፈለገም ።
• ደንበኛው የራስ አገልግሎት PostgreSQL/MySQL ማሰማራት አይፈልግም።
• ደህና ፣ በአጠቃላይ ፣ Google Spanner ለዋጋው ካልሆነ በጣም ተስማሚ ይሆናል ፣ ሆኖም ፣ Django ORM ከእሱ ጋር መሥራት አይችልም ፣ ግን ጥሩ ነገር ነው።

ሁኔታውን ከግምት ውስጥ በማስገባት ደንበኛው የሚከተለውን ጥያቄ ተቀብሏል- "እንደ ጎግል ስፓነር የሆነ ነገር ግን ከDjango ORM ጋር አብሮ ለመስራት ተመሳሳይ ነገር ማድረግ ይችላሉ?"

የመፍትሄ አማራጭ ቁጥር 0

ወደ አእምሮ የመጣው የመጀመሪያው ነገር:

• በ CloudSQL ውስጥ መቆየት;
• በክልሎች መካከል በማንኛውም መልኩ አብሮ የተሰራ ማባዛት አይኖርም።
• በPosgreSQL አንድ ቅጂ ካለ Cloud SQL ጋር ለማያያዝ ይሞክሩ;
• የሆነ ቦታ እና በሆነ መንገድ የPostgreSQL ምሳሌን ያስጀምሩ፣ ግን ቢያንስ ማስተርን አይንኩ።

ወዮ ፣ ይህ ሊሠራ እንደማይችል ተገለጠ ፣ ምክንያቱም የአስተናጋጁ መዳረሻ ስለሌለ (በተለየ ፕሮጀክት ውስጥ ነው) - pg_hba እና የመሳሰሉት ፣ እና እንዲሁም በሱፐርዩዘር ስር ምንም መዳረሻ የለም።

የመፍትሄ አማራጭ ቁጥር 1

ተጨማሪ ማሰላሰል እና የቀድሞ ሁኔታዎችን ከግምት ውስጥ በማስገባት የአስተሳሰብ ባቡር በተወሰነ መልኩ ተቀየረ፡-

• አሁንም በ CloudSQL ውስጥ ለመቆየት እየሞከርን ነው፣ ነገር ግን ወደ MySQL እየቀየርን ነው፣ ምክንያቱም Cloud SQL by MySQL ውጫዊ ማስተር ስላለው፡-

- ለውጫዊ MySQL ተኪ ነው;
- MySQL ምሳሌ ይመስላል;
- ከሌሎች ደመናዎች ወይም በግቢው ላይ ውሂብን ለማዛወር የተፈለሰፈ።

MySQL ማባዛትን ማዋቀር የአስተናጋጁን መዳረሻ ስለማይፈልግ በመርህ ደረጃ ሁሉም ነገር ሰርቷል ነገር ግን በጣም ያልተረጋጋ እና የማይመች ነበር. ወደ ፊት ስንሄድ ደግሞ ሙሉ በሙሉ አስፈሪ ሆነ፣ ምክንያቱም አጠቃላይ መዋቅሩን በቴራፎርም ስላሰማራነው፣ እና በድንገት የውጭው ጌታ በቴራፎርም ያልተደገፈ መሆኑ ታወቀ። አዎ፣ Google CLI አለው፣ ግን በሆነ ምክንያት ሁሉም ነገር እዚህ አልፎ አልፎ ይሰራል - አንዳንዴ ይፈጠራል፣ አንዳንዴም አልተፈጠረም። ምናልባት CLI የተፈለሰፈው ለውጫዊ ውሂብ ፍልሰት እንጂ ለቅጂዎች ስላልሆነ ነው።

በእውነቱ ፣ በዚህ ጊዜ Cloud SQL በጭራሽ ተስማሚ እንዳልሆነ ግልፅ ሆነ። እነሱ እንደሚሉት፣ የምንችለውን ሁሉ አድርገናል።

የመፍትሄ አማራጭ ቁጥር 2

በክላውድ SQL ማዕቀፍ ውስጥ መቆየት ስላልተቻለ፣ ለድርድር መፍትሄ መስፈርቶችን ለማዘጋጀት ሞክረናል። መስፈርቶቹ የሚከተሉት ሆነዋል።

• Kubernetes ውስጥ ሥራ, የ Kubernetes (DCS, ...) እና GCP (LB, ...) ሀብቶች እና ችሎታዎች ከፍተኛ አጠቃቀም;
• በደመና ውስጥ ካሉ አላስፈላጊ ነገሮች ስብስብ እንደ HA ፕሮክሲ የኳስ እጥረት;
• በዋናው HA ክልል ውስጥ PostgreSQL ወይም MySQL የማሄድ ችሎታ; በሌሎች ክልሎች - HA ከዋናው ክልል RR በተጨማሪ ቅጂው (ለአስተማማኝነት);
• መልቲ ማስተር (ከእሱ ጋር መገናኘት አልፈለግኩም ፣ ግን በጣም አስፈላጊ አልነበረም)

.
በእነዚህ ፍላጎቶች ምክንያት, ገጽተስማሚ DBMS እና የማስያዣ አማራጮች:

• MySQL Galera;
• CockroachDB;
• PostgreSQL መሳሪያዎች

:
- pgpool-II;
- ፓትሮኒ.

MySQL Galera

MySQL Galera ቴክኖሎጂ የተገነባው በCodership ሲሆን ለ InnoDB ተሰኪ ነው። ልዩ ባህሪያት፡

• ባለብዙ ማስተር;
• የተመሳሰለ ማባዛት;
• ከማንኛውም አንጓ ማንበብ;
• ወደ ማንኛውም መስቀለኛ መንገድ መቅዳት;
• አብሮ የተሰራ የ HA ዘዴ;
• ከ Bitnami የ Helm ገበታ አለ።

ኮክራክ ዲ.ቢ.

እንደ መግለጫው ነገሩ ፍፁም ቦምብ ነው እና በ Go ውስጥ የተጻፈ ክፍት ምንጭ ፕሮጀክት ነው. ዋናው ተሳታፊ የበረሮ ላብስ ነው (ከGoogle በመጡ ሰዎች የተመሰረተ)። ይህ ተዛማጅ ዲቢኤምኤስ በመጀመሪያ የተነደፈው እንዲሰራጭ ነው (ከሳጥኑ ውስጥ በአግድመት ልኬት) እና ስህተትን የሚቋቋም። የኩባንያው ደራሲዎች “የ SQL ተግባር ብልጽግናን ከNoSQL መፍትሄዎች ከሚታወቀው አግድም ተደራሽነት ጋር በማጣመር” የሚለውን ግብ ዘርዝረዋል።

ጥሩ ጉርሻ ለድህረ-ግስጋሴ ግንኙነት ፕሮቶኮል ድጋፍ ነው።

ፒግፑል

ይህ የ PostgreSQL ተጨማሪ ነው፣ በእውነቱ፣ ሁሉንም ግንኙነቶች የሚቆጣጠር እና የሚያስኬድ አዲስ አካል። በቢኤስዲ ፍቃድ የተፈቀደ የራሱ የሆነ የሎድ ሚዛን ሰጪ እና ተንታኝ አለው። ሰፊ እድሎችን ይሰጣል፣ ግን በተወሰነ መልኩ አስፈሪ ይመስላል፣ ምክንያቱም አዲስ አካል መኖሩ የአንዳንድ ተጨማሪ ጀብዱዎች ምንጭ ሊሆን ይችላል።

ፓትሮኒ

ይህ ዓይኖቼ የወደቁበት የመጨረሻው ነገር ነው, እና እንደ ተለወጠ, በከንቱ አይደለም. Patroni ክፍት ምንጭ መገልገያ ነው፣ እሱም በመሠረቱ የፓይዘን ዴሞን ነው፣ ይህም የPostgreSQL ስብስቦችን ከተለያዩ የማባዛት አይነቶች እና አውቶማቲክ ሚና መቀያየርን በራስ-ሰር እንዲጠብቁ ያስችልዎታል። ከኩባው ጋር በደንብ ስለሚዋሃድ እና ምንም አዲስ አካላትን ስለማያስተዋውቅ ነገሩ በጣም አስደሳች ሆኖ ተገኝቷል።

በመጨረሻ ምን መረጥክ?

ምርጫው ቀላል አልነበረም፡-

1. ኮክራክ ዲ.ቢ. - እሳት, ግን ጨለማ;
2. MySQL Galera - እንዲሁም መጥፎ አይደለም, በብዙ ቦታዎች ጥቅም ላይ ይውላል, ግን MySQL;
3. ፒግፑል - ብዙ አላስፈላጊ አካላት, ስለዚህ ከደመና እና ከ K8 ጋር መቀላቀል;
4. ፓትሮኒ - ከ K8s ጋር በጣም ጥሩ ውህደት ፣ ምንም አላስፈላጊ አካላት ፣ ከጂሲፒ LB ጋር በጥሩ ሁኔታ ይዋሃዳል።

ስለዚህ ምርጫው በፓትሮኒ ላይ ወድቋል.

ግኝቶች

በአጭሩ ለማጠቃለል ጊዜው አሁን ነው። አዎ፣ የአይቲ መሠረተ ልማት ዓለም በከፍተኛ ሁኔታ ተለውጧል፣ እና ይህ ገና ጅምር ነው። እና ከደመናው በፊት ሌላ የመሠረተ ልማት ዓይነት ከነበሩ አሁን ሁሉም ነገር የተለየ ነው። በተጨማሪም ፣ በደመና ውስጥ ያሉ ፈጠራዎች ያለማቋረጥ ይታያሉ ፣ እነሱ ይታያሉ እና ምናልባትም ፣ በደመና ውስጥ ብቻ ይታያሉ እና ከዚያ በኋላ በጅማሬዎች ጥረቶች ወደ ኦን-ግቢ ይተላለፋሉ።

ስለ SQL፣ SQL ይኖራል። ይህ ማለት PostgreSQL እና MySQL ን ማወቅ እና ከእነሱ ጋር መስራት መቻል አለቦት ነገርግን የበለጠ አስፈላጊው ነገር በትክክል መጠቀም መቻል ነው።

ምንጭ: hab.com