ለብዙ ዓመታት፣ PostgreSQL እንደ ChatGPT እና OpenAI API ያሉ ዋና ምርቶችን የሚያንቀሳቅሱ ከጀርባ የሚሰሩ እጅግ አስፈላጊ የውሂብ ስርዓቶች መካከል አንዱ ሆኖ ነበር። የተጠቃሚ መሠረታችን በፍጥነት እያደገ ሲሄድ፣ በዳታቤዞቻችን ላይ ያለው ፍላጎትም በከፍተኛ ደረጃ ጨምሯል። ባለፈው ዓመት ውስጥ፣ የእኛ የ PostgreSQL የሥራ ጫና ከ10 እጥፍ በላይ ያደገ ሲሆን፣ አሁንም በፍጥነት እየጨመረ ይገኛል።
ይህንን እድገት ለማስቀጠል የምርት መሠረተ ልማታችንን ለማሳደግ ያደረግነው ጥረት አዲስ ግንዛቤ አሳገኝቷል፦ PostgreSQL ቀደም ሲል ብዙዎች ከሚያስቡት በላይ በጣም ትልቅ ንባብ-የሚበዛባቸው የሥራ ጫናዎችን በአስተማማኝ ሁኔታ ለመደገፍ ሊስፋፋ ይችላል። ስርዓቱ (በመጀመሪያ በCalifornia ዩኒቨርስቲ፣ በBerkeley የሳይንስ ሊቃውንት ቡድን የተፈጠረ) በነጠላ-ዋነኛ የAzure PostgreSQL ተጣጣፊ አገልጋይ ኢንስታንስ(በአዲስ መስኮት ውስጥ ይክፈታል) እና በዓለም አቀፍ ደረጃ በብዙ ክልሎች በተሰራጩ ወደ 50 በሚጠጉ የንባብ ተመሳሳይ ስሪቶች ግዙፍ የሆነ ዓለም አቀፍ ትራፊክን ለመደገፍ አስችሎናል። ይህ፣ በጥብቅ ማመቻቸት እና ጠንካራ ምሕንድስና አማካኝነት ለ800 ሚሊዮን ተጠቃሚዎች በሴኮንድ በሚሊዮን የሚቆጠሩ መጠይቆችን ለመደገፍ PostgreSQL በOpenAI ላይ እንዴት እንዳስፋፋነው ታሪክ ሲሆን እንዲሁም በመንገድ ላይ የተማርነውን ቁልፍ ነጥቦች የምንሸፍን ይሆናል።
ChatGPT ከተጀመረ በኋላ ትራፊክ ታይቶ በማይታወቅ ፍጥነት አደገ። እሱን ለመደገፍ፣ በመተግበሪያውም ሆነ በPostgreSQL የውሂብ ጎታ ንብርብሮች ላይ ሰፊ ማሻሻያዎችን በፍጥነት ተግባራዊ ያደረግን ሲሆን እነሱም የኢንስታንስ መጠኑን በመጨመር ሰርቨሩን ኃይለኛ አደረግን እንዲሁም ተጨማሪ የንባብ ተመሳሳይ ስሪቶችን በመጨመር ሥራውን አከፋፍለናል። ይህ ዓይነት የንድፍ አሠራር ለብዙ ጊዜ ጥሩ አድርጎ አገልግሎናል። ቀጣይነት ባለው መሻሻል፣ ለወደፊት እድገት በቂ መንገድ መስጠቱን የሚቀጥል ሆኖ ተገኝቷል።
አንድ ነጠላ-ዋና አርክቴክቸር የ OpenAI ስፋት ፍላጎቶችን ሊያሟላ መቻሉ አስገራሚ ሊመስል ይችላል፣ ነገር ግን ይህን በተግባር እንዲሰራ ማድረግ ቀላል አይደለም። በPostgres መብዛት ምክንያት የተከሰቱ በርካታ ከፍተኛ የአገልግሎት መቋረጦችን አይተናል፤ እነዚህም ብዙውን ጊዜ ተመሳሳይ መልክ አላቸው፦ አንድ ከላይኛው ክፍል የሚመጣ ችግር በድንገት በዳታቤዙ ላይ ከፍተኛ ጫና ይፈጥራል። ለምሳሌ፦ የካሽ ንብርብር በመውደቁ ምክንያት የሚከሰቱ ሰፊ የካሽ ስህተቶች፣ የሲ.ፒ.ዩ አቅምን የሚያጨናንቁ ውስብስብ የመረጃ ጥምረቶች ፣ ወይም አዲስ አገልግሎት ሲጀመር የሚፈጠር ከፍተኛ የመረጃ ጽሑፍ ጫና። የሃብት አጠቃቀሙ እየጨመረ ሲሄድ፣ የጥያቄዎች ምላሽ ጊዜ ይረዝማል እንዲሁም ጥያቄዎች ጊዜ አልፎባቸው መቋረጥ ይጀምራሉ። ተደጋጋሚ ሙከራዎች ጭነቱን በተጨማሪ ያበዛሉ፣ ይህም መላውን ChatGPT እና የAPI አገልግሎቶች ሊያበላሹ የሚችሉ አደገኛ ዙር ሂደትን ያስነሳሉ።
ምንም እንኳን PostgreSQL መረጃን ለማንበብ ለሚበዛባቸው ስራዎች በጥሩ ሁኔታ ቢያገለግልም፣ ከፍተኛ የመረጃ መጻፍ ስራ በሚበዛባቸው ወቅቶች አሁንም ፈተናዎች ያጋጥሙናል። ይህ የሆነበት ምክንያት በዋነኝነት PostgreSQL የሚጠቀምበት የባለብዙ-ስሪት ተጓዳኝ ቁጥጥር አተገባበር ነው፤ ይህም መረጃን መጻፍ ለሚበዛባቸው ስራዎች ውጤታማነቱ ይቀንሳል። ለምሳሌ፦ አንድ ጥያቄ የተወሰኑ መረጃዎችን ወይም አንዲትን መስክ ብቻ ለማሻሻል ሲሞክር፣ አዲስ ስሪት ለመፍጠር ሲባል አጠቃላይ ረድፉ በሙሉ ይገለበጣል። በከባድ የመረጃ መጻፍ ጫና ወቅት፣ ይህ ሂደት ከፍተኛ የሆነ የመጻፍ ስራ መብዛትን ያስከትላል። የቅርብ ጊዜውን መረጃ ለማግኘት ጥያቄዎች በርካታ የረድፍ ስሪቶችን መፈተሽ ስላለባቸው የንባብ ስራንም ይጨምራል። MVCC የሰንጠረዥ እና የማውጫ መወጠር ፣ የማውጫ ጥገና ጫና መጨመር እና ውስብስብ የራስ-ጽዳት ማስተካከያ ፍላጎቶችን ያስከትላል። (ስለነዚህ ጉዳዮች በዝርዝር ለማወቅ በካርኔጊ ሜሎን ዩኒቨርሲቲ ከፕሮፌሰር አንዲ ፓቭሎ ጋር በመሆን The Part of PostgreSQL We Hate the Most(በአዲስ መስኮት ውስጥ ይክፈታል) በሚል ርዕስ የጻፍኩትን ብሎግ ማንበብ ትችላላችሁ፤ ይህም በPostgreSQL ውክፔዲያ ገጽ ላይተጠቅሷል(በአዲስ መስኮት ውስጥ ይክፈታል)።)
እነዚህን ገደቦች ለማቃለል እና የጽሁፍ ጫናን ለመቀነስ፣ ተከፋፋይ (ማለትም በአግድሞሽ ሊከፋፈሉ የሚችሉ የሥራ ጫናዎች)፣ ጽሁፍ-የሚበዛባቸው የሚፈልጉ የሥራ ጫናዎችን አላስፈላጊ ጽሑፎችን ለመቀነስ የመተግበሪያ አመክንዮን በማመቻቸት ወደ እንደ Azure Cosmos DB ያሉ የተከፋፈሉ ስርዓቶች አሸጋግረናል፣ ማሸጋገራችንንም የምንቀጥል ይሆናል። እንዲሁም ከአሁን በኋላ በአሁኑ የPostgreSQL ትግበራ ላይ አዲስ ሰንጠረዦች እንዲጨመሩ የማንፈቅድ ይሆናል። አዲስ የሥራ ጫናዎች ወደ ክፍልፋይ ስርዓቶች በነባሪነት የሚመለሱ ርሆናል።
መሠረተ ልማታችን እየተሻሻለ ቢመጣም፣ PostgreSQL አንድ ዋነኛ ኢንስታንስ ለሁሉም ጽሁፎች በማገልገል ያልተከፋፈለ ሆኖ ቆይቷል። ዋናው ምክንያት አሁን ያሉትን የመተግበሪያ የሥራ ጫናዎችን መከፋፈል በጣም ውስብስብ እና ጊዜ የሚወስድ፣ በመቶዎች ለሚቆጠሩ የመተግበሪያ መጨረሻ ነጥቦች ላይ ለውጦችን የሚጠይቅ እና ምናልባትም ወራትን ወይም ዓመታትን የሚፈጅ እንደሚሆን ነው። የሥራ ጫናዎቻችን በዋናነት ንባብ-የሚበዛባቸው ስለሆኑ እና ሰፊ ማሻሻያዎችን ተግባራዊ ስላደረግን፣ የአሁኑ የንድፍ አሠራር የትራፊክ ዕድገትን ቀጣይነት ለመደገፍ በቂ ቦታ ይሰጣል። ወደፊት PostgreSQLን መከፋፈል ባንከለክልም፣ ለአሁኑም ሆነ ለወደፊቱ እድገት ባለን በቂ መንገድ ምክንያት ይህ በቅርብ ጊዜ ውስጥ ቅድሚያ የሚሰጠው ጉዳይ አይደለም።
በሚቀጥሉት ክፍሎች፣ ያጋጠሙንን ተግዳሮቶች እና እነሱን ለመፍታት እንዲሁም ወደፊት አገልግሎት እንዳይቋረጥ ለማድረግ ተግባራዊ ያደረግናቸውን ሰፊ ማሻሻያዎች በጥልቀት እንመረምራለን። ይህም PostgreSQLን እስከ ጥግ አቅሙ በመግፋት በሚሊዮኖች ለሚቆጠሩ የሰከንድ ጥያቄዎች እንዴት እንዳሳደግነው ያሳያል።
ተግዳሮት፦ አንድ ብቻ የመጻፍ ፍቃድ ያለው ነጠላ-ዋነኛ ሲኖር፣ የጽሁፍ አቅምን በመጨመር ማስፋፋት አይቻልም። ከፍተኛ የጽሁፍ ድንገተኛ ጫናዎች በፍጥነት ዋነኛውን ከአቅም በላይ ሊጫኑ የሚችሉ ሲሆን ChatGPT እና የእኛ API ላይ አገልግሎቶች ላይ ተጽዕኖ ሊያሳድሩ ይችላሉ።
መፍትሔ፡- ዋነኛው ድንገተኛ የጽሁፍ ጫናዎችን ለመቋቋም በቂ አቅም እንዲኖረው—በሁለቱም በንባብ እና በጽሁፍ በኩል—በተቻለ መጠን ጫናውን የምንቀንስ ይሆናል። የንባብ ትራፊክ በተቻለ መጠን ወደ ተመሳሳይ ስሪቶች የሚተላለፍ ይሆናል። ሆኖም፣ አንዳንድ የንባብ መጠይቆች የፅሁፍ ግብይቶች አካል እንደመሆናቸው በዋናው ጽሑፍ ላይ መቆየት ይኖርባቿል። ለእነዚህ፣ ቀልጣፋ መሆናቸውን ማረጋገጥ እና ከዝግተኛ መጠይቆች መቆጠብ ላይ እናተኩራለን። ለጽሁፍ ትራፊክ፣ ሊከፋፈሉ የሚችሉ እና ጽሁፍ-የሚበዛባቸው የሥራ ጫናዎችን እንደ Azure CosmosDB ያሉ የተከፋፈሉ ስርዓቶች አሸጋግረናል። ለመከፋፈል አስቸጋሪ የሆኑ ነገር ግን ከፍተኛ የጽሁፍ መጠን የሚያመነጩ የሥራ ጫናዎች ለማሸጋገር በዙ ጊዜ የሚወስዱ ስለሆነ እና እሱ ሂደት አሁንም በመቀጠል ላይ ይገኛል። እንዲሁም የጽሁፍ ጭነትን ለመቀነስ መተግበሪያዎቻችንን በከፍተኛ ሁኔታ አመቻችተናል፤ ለምሳሌ፣ የጽሁፍ ድግግሞሽ ይፈጠርባቸው የነበሩ የመተግበሪያ ስህተቶችን አስተካክለናል እንዲሁም የትራፊክ ፍጥነት እንዲቀንስ ለማድረግም እንደአስፈላጊነቱ ሰነፍ ጽሁፎችን አስተዋውቀናል። በተጨማሪም የሰንጠረዥ መስኮችን በምንሞላበት ጊዜ ከመጠን በላይ የጽሁፍ ጫናን ለመከላከል ጥብቅ የተመን ገደቦችን እናስፈጽማለን።
ተግዳሮት፦ በ PostgreSQL ውስጥ በርካታ ከፍተኛ ወጪ ያላቸው ጥያቄዎችን ለይተናል። በቀደም ሲል፣ በእነዚህ ጥያቄዎች ውስጥ ድንገተኛ የመጠን መጨመር ብዙ የCPU ኃይል ይበላ ነበር፣ ይህም የ ChatGPT እና የ API ጥያቄዎችን ያዘግይ ነበር።
መፍትሄ፡ እንደ ብዙ ሰንጠረዦችን አንድ ላይ የሚያገናኙ ያሉ ጥቂት ውድ ጥያቄዎች አገልግሎቱን በከፍተኛ ሁኔታ ሊያበላሹ ወይም መላውን አገልግሎት ድረስ ሊያቆሙት ይችላሉ። ውጤታማ መሆናቸውን ለማረጋገጥ እና የተለመዱ የOnline Transaction Processing (OLTP) ፀረ-ቅጦችን ከማድረግ ለመቆጠብ የPostgreSQL ጥያቄዎችን ያለማቋረጥ ማመቻቸት አለብን። ለምሳሌ፣ አንድ ጊዜ 12 ሰንጠረዦችን የሚያገናኝ እጅግ ውድ የሆነ ጥያቄ ለይተን ነበር፣ በዚህ ጥያቄ ውስጥ የሚከሰቱ ከፍተኛ ጭማሪዎች በቀደሙት ጊዜያት ከፍተኛ-ክብደት ላላቸው SEVዎች ተጠያቂ ነበሩ። በተቻለ መጠን ውስብስብ ባለብዙ-ሰንጠረዥ ማገናኘቶችን ማስወገድ አለብን። ማገናኘቶች አስፈላጊ ከሆኑ፣ ጥያቄውን መከፋፈል እና ውስብስብ የሆነውን የማገናኘት ሎጂክን ወደ አፕሊኬሽን ንብርብር ማዛወርን ተምረናል። ብዙዎቹ ከእነዚህ ችግር ያለባቸው ጥያቄዎች የሚመነጩት በObject-Relational Mapping ማዕቀፎች (ORMs) ይፈጠራሉ፣ ስለዚህ የሚያመነጩትን SQL በጥንቃቄ መገምገም እና እንደተጠበቀው እንደሚሰራ ማረጋገጥ አስፈላጊ ነው። በPostgreSQL ውስጥ ለረጅም ጊዜ የሚቆዩ ስራ ፈት ጥያቄዎችን ማግኘትም የተለመደ ነው። እንደ idle_in_transaction_session_timeout ያሉ የጊዜ ማቆያዎችን ማዋቀር ኦቶቫኩምን እንዳያግዱ ለመከላከል አስፈላጊ ነው።
ተግዳሮት፦ አንድ የመረጃ ማንበቢያ ቅጂ ቢቋረጥ፣ መረጃ የማስተላለፍ ስራው ወደ ሌሎች ቅጂዎች ሊመራ ይችላል። ሆኖም፣ በአንድ የመረጃ መጻፊያ ላይ ብቻ መተማመን የአንድ ነጥብ ውድቀት እንዲኖር ያደርጋል—እሱ ከተቋረጠ አጠቃላይ አገልግሎቱ ይጎዳል።
መፍትሔ፦ አብዛኛዎቹ ወሳኝ መጠይቆች የሚያካትቱት የንባብ መጠይቆችን ብቻ ነው። በዋነኛው ላይ ያለውን የውድቀት ነጥብ ለመቀነስ፣ እነዚያን ንባቦች ከጸሐፊው ወደ ተመሳሳይ ስሪቶች በማውረድ ዋነኛው ቢጠፋም እንኳ እነዚያ ጥያቄዎች ማገልገላቸውን እንዲቀጥሉ አረጋግጠናል። የጽሁፍ ሥራዎች አሁንም የማይሳኩ ቢሆንም ተጽዕኖው የሚቀንስ ይሆናል ንባቦች መገኘታቸውን ስለሚቀጥሉ SEV0 አይሆንም።
ዋና ዋና ውድቀቶችን ለመቀነስ፣ ዋናውን በከፍተኛ-አቅርቦት (HA) ሁነታ እናስኬዳለን፣ ይህም ሁልጊዜም የማቅረቢያ ትራፊክን ለመቆጣጠር ዝግጁ የሆነ ቀጣይነት ያለው የተመሳሰለ ቅጂ ነው። ዋናው ስራ ካቆመ ወይም ለጥገና ከመስመር ውጭ መሆን ካስፈለገ፣ የእረፍት ጊዜን ለመቀነስ የመጠባበቂያ ጊዜን በፍጥነት ማስተዋወቅ እንችላለን። የAzure PostgreSQL ቡድን እነዚህ የብልሽት ስህተቶች በጣም ከፍተኛ ጫና ውስጥ ቢሆኑም እንኳን ደህንነታቸው የተጠበቀ እና አስተማማኝ ሆነው እንዲቀጥሉ ለማድረግ ጉልህ ስራ ሰርቷል። የንባብ ተደጋጋሚ ቅጂ ብልሽቶችን ለመቆጣጠር፣ በእያንዳንዱ ክልል ውስጥ በቂ አቅም ያላቸው በርካታ ቅጂዎችን እናሰማራለን፣ ይህም የአንድ ቅጂ ብልሽት ወደ ክልላዊ መቆራረጥ እንዳይመራ ያረጋግጣል።
ፈተና፦ አንዳንድ ጥያቄዎች በPostgreSQL አጋጣሚዎች ላይ ያልተመጣጠነ መጠን ያላቸውን ሀብቶች የሚጠቀሙባቸው ሁኔታዎች ብዙ ጊዜ ያጋጥሙናል። ይህ በተመሳሳይ ሁኔታ ላይ ለሚሰሩ ሌሎች የስራ ጫናዎች አፈፃፀምን ሊያሳጣ ይችላል። ለምሳሌ፣ አዲስ ባህሪ ማስጀመር የPostgreSQL CPUን በከፍተኛ ሁኔታ የሚጠቀሙ ውጤታማ ያልሆኑ ጥያቄዎችን ሊያስተዋውቅ ይችላል፣ ይህም ለሌሎች ወሳኝ ባህሪያት የሚላኩ ጥያቄዎችን ያዘግያል።
መፍትሔ፦ መዘግየትን ለመቀነስ በተለያዩ ምድረጽፋዊ ክልሎች የተዘረጉ ወደ 50 የሚጠጉ የንባብ ተመሳሳይ ስሪቶችን የምናካሄ ድይሆናል። ሆኖም ግን፣ በአሁኑ የንድፍ አሠራር፣ ዋነኛው WALን ወደ እያንዳንዱ ተመሳሳይ ስሪት መልቀቅ ይኖርበታል። ምንም እንኳን በአሁኑ ጊዜ በጣም ትልቅ በሆኑ የኢንስታንት አይነቶች እና ከፍተኛ የበይነ-መረብ የመተላለፊያ ይዘት መጠን ቢስፋፋም፣ ዋነኛውን ሳናጨናንቅ ላልተወሰነ ጊዜ ተመሳሳይ ስሪቶችን ማከል የማንችል ይሆናል። ይህንን ለመፍታት፣ ከAzure PostgreSQL ቡድን ጋር መካከለኛ ተመሳሳይ ስሪቶች WALን ወደ ታችኛው ተመሳሳይ ስሪቶች የሚያስተላልፋበት የተደራራቢ ተመሳሳይ ስሪት(በአዲስ መስኮት ውስጥ ይክፈታል) ላይ እየሰራን እንገኛለን። ይህ ዘዴ ዋነኛውን ሳያስጨናንቅ ከመቶ በላይ ሊደርሱ የሚችሉ ተመሳሳይ ስሪቶችን እንድናስፋፋ የሚያስችለን ይሆናል። ይሁን እንጂ፣ በተለይም የውድቀት አስተዳደርን በተመለከተ ተጨማሪ የአሠራር ውስብስብነትን ያስተዋውቃል። ባህሪው አሁንም በሙከራ ላይ ሲሆን ወደ ምርት ከመላካችን በፊት ጠንካራ መሆኑን እና ደህንነቱ በተጠበቀ ሁኔታ ሊበላሽ እንደሚችል የምናረጋግጥ ይሆናል።
ፈተና፡- በተወሰኑ የመጨረሻ ነጥቦች ላይ ድንገተኛ የትራፊክ መጨናነቅ፣ ውድ የሆኑ ጥያቄዎች መጨመር ወይም የድጋሚ ሙከራ ማዕበል እንደ CPU፣ I/O እና ግንኙነቶች ያሉ ወሳኝ ሀብቶችን በፍጥነት ሊያሟጥጥ ይችላል፣ ይህም ሰፊ የአገልግሎት ብልሽት ያስከትላል።
መፍትሔ፦ ከመጠን በላይ ከሆኑ የውሂብ ጎታ ኢንስታንሶች የተነሣ ትራፊክ በድንገት እንዳይጨምር እና ተደራራቢ ውድቀቶችን እንዳያስከትል ለመከላከል በብዙ ንብርብሮች—መተግበሪያ፣ የግንኙነት ማሰባሰቢያ፣ ተተኪ እና መጠይቅ—ላይ ተመን-ገደብ ተግባራዊ አድርገናል። እንዲሁም የዳግም-ሙከራ ጊዜ በጣም አጭር ከመሆኑ የተነሳ የዳግም-ሙከራ ማዕበል እንዳይከሰት ማድረግም ወሳኝ ነው። እንዲሁም ተመንን ለመወሰን እና እንደአስፈላጊነቱ የተወሰኑ የመጠይቅ ቡድኖችን ሙሉ በሙሉ ለማገድ የሚያስችል የORM ንብርብርን አሻሽለናል። ይህ የተመረጠ የጭነት መቀነሻ ዘዴ ከድንገተኛ የውድ መጠይቆች ጭማሪ በፍጥነት ለማገገም የሚያስችል ይሆናል።
ተግዳሮት፡- እንደ የአምድ አይነት መቀየር ያሉ ትንሽ የእቅድ ማውጣት ለውጥ እንኳን ሙሉ የሠንጠረዥ ዳግም መፃፍን(በአዲስ መስኮት ውስጥ ይክፈታል)ሊያስጀምር ይችላል። ስለዚህ የእቅድ ማውጣት ለውጦችን በጥንቃቄ የምንተገብር ይሆናል—ቀላል ክብደት ላላቸው ሥራዎች ብቻ በመገደብ እና ሙሉ ሰንጠረዦችን ዳግም የሚጽፉ ማንኛውንም ነገሮች በመጠበቅ።
መፍትሔ፦ ሙሉ የሰንጠረዥ ዳግም መጻፍን የማያስነሱ የተወሰኑ አምዶችን መጨመር ወይም ማስወገድን የመሳሰሉ ቀላል የእቅድ ማውጣት ለውጦች ብቻ የሚፈቀዱ ይሆናል። በእቅድ ማውጣት ለውጦች ላይ ጥብቅ የ5 ሴኮንድ የጊዜ ገደብ የምናስፈጽም ይሆናል። መረጃ ጠቋሚዎችን በተመሳሳይ ጊዜ መፍጠር እና መጣል የሚፈቀድ ይሆናል። የእቅድ ማውጣት ለውጦች በነባር ሰንጠረዦች ላይ ብቻ የተገደቡ ይሆናሉ። አዲስ ባህሪ ተጨማሪ ሰንጠረዦችን የሚፈልግ ከሆነ፣ PostgreSQL ላይ ሳይሆን እንደ Azure CosmosDB ባሉ አማራጭ የተከፋፈሉ ስርዓቶች ውስጥ መሆን ይኖርባቸዋል። የሰንጠረዥ መስኮችን በምንሞላበት ጊዜ የመጻፍ ድንገተኛ ጭማሪዎችን ለመከላከል ጥብቅ የተመን ገደቦችን የምናስፈጽም ይሆናል። ምንም እንኳን ይህ ሂደት አንዳንድ ጊዜ ከአንድ ሳምንት በላይ የሚወስድ ቢሆንም መረጋጋትን ያረጋግጣል እንዲሁም ማንኛውንም የምርት ተጽዕኖ ያስወግዳል።
ይህ ጥረት በትክክለኛ ንድፍ እና ማሻሻያዎች ከተደረጉ በኋላ፣ Azure PostgreSQL ትላልቅ የምርት ስራ ጫናዎችን ለመቋቋም ሊሰፋ እንደሚችል ያሳያል። PostgreSQL ለንባብ ከባድ የሥራ ጫናዎች በሚሊዮን የሚቆጠሩ QPSዎችን ያስተናግዳል፣ እንደ ChatGPT እና የAPI መድረክ ያሉ በጣም ወሳኝ የሆኑ የOpenAI ምርቶችን ያጎለብታል። ወደ 50 የሚጠጉ የንባብ ቅጂዎችን ያከለን ሲሆን ይህም የመባዛት መዘግየትን ወደ ዜሮ አካባቢ አቆይተን፣ በአካባቢ የተከፋፈሉ ክልሎች ውስጥ ዝቅተኛ መዘግየት ያላቸው ንባቦችን ጠብቀን እና የወደፊት እድገትን ለመደገፍ የሚያስችል በቂ አቅም ገንብተን ነው።
ይህ የማስፋፋት ዘዴ ፍጥነት መቀነስን እና አስተማማኝነት ማሻሻልን እያስጠበቀ የሚሰራ ይሆናል። በተከታታይ ዝቅተኛ የሁለት አሃዝ ሚሊሴኮንድ p99 በደንበኛ-በኩል መዘግየት እና የአምስት-ዘጠኞች ተደራሽነትን በምርት ጊዜ የምናቀርብ ይሆናል። እንዲሁም ባለፉት 12 ወራት ውስጥ፣ አንድ የSEV-0 PostgreSQL ክስተት ብቻ ነው ያጋጠመን (ይህ የተከሰተው የChatGPT ImageGen መጀመሪያ የስፋት ስርጭት(በአዲስ መስኮት ውስጥ ይክፈታል) ላይ ሲሆን፣ የጽሁፍ ትራፊክ በድንገት በ10 እጥፍ በመጨመር ከ100 ሚሊዮን በላይ አዳዲስ ተጠቃሚዎች በሳምንት ውስጥ ሲመዘገቡ ነው።)
እስካሁን PostgreSQL ባደረሰን ርቀት ደስተኞች ብንሆንም፣ ለወደፊት እድገታችን በቂ ዝግጅት እንዲኖረን አቅሙን እስከ ጥግ መግፋታችንን እንቀጥላለን። ሊከፋፈሉ የሚችሉ እና ከፍተኛ የመረጃ መጻፍ ስራ የሚጠይቁ ስራዎችን እንደ CosmosDB ወደመሳሰሉ የተከፋፈሉ ስርአቶች አስቀድመን አዘዋውረናል። የቀሩት በመጻፍ ላይ ከፍተኛ ጫና ያላቸው የሥራ ጫናዎች ለመከፋፈል የበለጠ አስቸጋሪ ናቸው—እነዚህንም እንዲሁ ከ PostgreSQL ዋና ሰርቨር ላይ የመጻፍ ጫናን በተጨማሪ ለመቀነስ በንቃት እያስተላለፍናቸው ነው። በተጨማሪም፣ የመረጃ ማንበቢያ ቅጂዎችን በከፍተኛ ሁኔታ ለማሳደግ ተከታታይ ቅጂ ለመጠቀም ከ Azure ጋር እየሰራን እንገኛለን።
ወደፊት ስንመለከት፣ የመሠረተ ልማት ፍላጎቶቻችን እያደጉ ሲሄዱ የተከፋፈሉ PostgreSQL ወይም አማራጭ የተሰራጩ ስርዓቶችን ጨምሮ ይበልጥ ለመስፋፋት ተጨማሪ መንገዶችን ማሰስ የምንቀጥል ይሆናል።
ደራሲ
ምስጋናዎች
ለዚህ ጽሑፍ መሳካት አስተዋጽኦ ላደረጉት Jon Lee፣ Sicheng Liu፣ Chaomin Yu እና Chenglong Hao፣ እንዲሁም PostgreSQL-ን ለማሳደግ ለረዳው መላው ቡድን ልዩ ምስጋና ይድረሳቸው። በተጨማሪም፣ ላሳዩን ጠንካራ አጋርነት የAzure PostgreSQL ቡድንን እናመሰግናለን።


