ጎግል ክላውድ ስፓነር፡ ጥሩ፣ መጥፎ፣ አስቀያሚ

ሰላም ካብሮቪትስ። በተለምዶ፣ አዲስ ኮርሶች በሚጀምሩበት ዋዜማ ላይ አስደሳች ነገሮችን ማካፈላችንን እንቀጥላለን። ዛሬ፣ በተለይ ለእናንተ፣ ትምህርቱ ከተጀመረበት ጊዜ ጋር በተገናኘ ጊዜ ስለ ጎግል ክላውድ ስፓነር አንድ ጽሑፍ ተርጉመናል። "AWS ለገንቢዎች".

በመጀመሪያ የታተመው በ Lightspeed HQ ብሎግ.

በዓለም ዙሪያ ላሉ ቸርቻሪዎች፣ ሬስቶራተሮች እና የመስመር ላይ ነጋዴዎች የተለያዩ ደመና ላይ የተመሰረቱ የPOS መፍትሄዎችን የሚያቀርብ ኩባንያ እንደመሆኑ መጠን Lightspeed ለተለያዩ የግብይት፣ ትንተናዎች እና የፍለጋ አጠቃቀም ጉዳዮች የተለያዩ አይነት የውሂብ ጎታ መድረኮችን ይጠቀማል። እነዚህ የመረጃ ቋት መድረኮች እያንዳንዳቸው የራሳቸው ጥንካሬዎች እና ድክመቶች አሏቸው።ስለዚህ ጎግል ክላውድ ስፓነርን ለገበያ ሲያስተዋውቅ - በግንኙነቱ የመረጃ ቋት አለም ከዚህ በፊት ታይተው የማይታወቁ ተስፋ ሰጪ ባህሪያት ለምሳሌ ያልተገደበ የአግድም ሚዛን እና የ99,999% የአገልግሎት ደረጃ ስምምነት (SLA)። እሷን በእጃችን ለመያዝ እድሉን ማለፍ አልቻልንም!

ስለ ክላውድ ስፓነር ያለንን ልምድ እና እንዲሁም የተጠቀምንባቸውን የግምገማ መስፈርቶች አጠቃላይ እይታ ለመስጠት የሚከተሉትን ርዕሶች እንሸፍናለን።

1. የእኛ የግምገማ መስፈርት
2. ክላውድ ስፓነር ባጭሩ
3. የእኛ ግምገማ
4. የእኛ ግኝቶች

1. የእኛ የግምገማ መስፈርት

የክላውድ ስፓነርን ዝርዝር ሁኔታ፣ ተመሳሳይነት እና በገበያ ላይ ካሉ ሌሎች መፍትሄዎች ጋር ያለውን ልዩነት ከመመልከታችን በፊት በመጀመሪያ ክላውድ ስፓነርን በመሠረተ ልማታችን ውስጥ የት ማሰማራት እንዳለብን ከግምት ውስጥ ስናስገባ ስለ ዋና ዋና የአጠቃቀም ጉዳዮች እንነጋገር።

• ለ(ያለ) ባህላዊ የSQL ዳታቤዝ መፍትሄ ምትክ ሆኖ
• እንደ OLAP የነቃ OLTP መፍትሄ

ማስታወሻ: ለማነጻጸር ቀላል ይህ መጣጥፍ ክላውድ ስፓነርን ከጂሲፒ ክላውድ SQL እና Amazon AWS RDS የመፍትሄ ቤተሰቦች MySQL ልዩነቶች ጋር ያወዳድራል።

ለባህላዊ የSQL ዳታቤዝ መፍትሄ ምትክ Cloud Spanner መጠቀም

በአካባቢው ባህላዊ የመረጃ ቋቶች፣ የውሂብ ጎታ መጠይቅ የምላሽ ጊዜ ሲቃረብ ወይም አስቀድሞ ከተገለጹት የመተግበሪያ ገደቦች (በዋነኛነት በተጠቃሚዎች እና/ወይም ጥያቄዎች መጨመር ምክንያት) ሲያልፍ፣ የምላሽ ጊዜን ወደ ተቀባይነት ደረጃዎች ለመቀነስ ብዙ መንገዶች አሉ። ይሁን እንጂ አብዛኛዎቹ እነዚህ መፍትሄዎች በእጅ ጣልቃ መግባትን ያካትታሉ.

ለምሳሌ፣ የሚወሰደው የመጀመሪያው እርምጃ የተለያዩ ከአፈጻጸም ጋር የተገናኙ የውሂብ ጎታ ቅንብሮችን መመልከት እና የመተግበሪያ አጠቃቀም ሁኔታን ቅጦችን በተሻለ ሁኔታ እንዲዛመድ ማድረግ ነው። ይህ በቂ ካልሆነ የውሂብ ጎታውን በአቀባዊ ወይም በአግድም ለመለካት መምረጥ ይችላሉ.

አፕሊኬሽኑን ከፍ ማድረግ የአገልጋዩን ምሳሌ ማዘመንን ይጠይቃል፣በተለምዶ ተጨማሪ ፕሮሰሰር/ኮርስ፣ተጨማሪ RAM፣ፈጣን ማከማቻ፣ወዘተ.ተጨማሪ የሃርድዌር ግብዓቶችን መጨመር የውሂብ ጎታ አፈጻጸምን ይጨምራል፣በዋነኛነት በሰከንድ ግብይቶች እና ለ OLTP ስርዓቶች የግብይት መዘግየት ያስከትላል። እንደ MySQL ልኬት ያሉ ተዛማጅ የውሂብ ጎታ ሥርዓቶች (ባለብዙ-ክር አቀራረብን የሚጠቀሙ) በጥሩ ሁኔታ በአቀባዊ።

በዚህ አቀራረብ ላይ በርካታ ድክመቶች አሉ, ነገር ግን በጣም ግልጽ የሆነው በገበያ ላይ ያለው ከፍተኛው የአገልጋይ መጠን ነው. አንዴ ትልቁ የአገልጋይ ጊዜ ገደብ ላይ ከደረሰ አንድ መንገድ ብቻ ይቀራል፡ ልኬን ወደ ውጭ።

ስኬል-ውጭ ብዙ አገልጋዮች ሲጨመሩ በመስመር ላይ አፈጻጸምን ለመጨመር ብዙ አገልጋዮችን ወደ ክላስተር የሚጨምር አካሄድ ነው። አብዛኛው ባህላዊ የመረጃ ቋት ሲስተሞች በደንብ አይመዘኑም ወይም ጨርሶ አይመዘኑም። ለምሳሌ፣ MySQL የባሪያ አንባቢዎችን በማከል ለንባብ ክዋኔዎች ሊሰፋ ይችላል፣ ነገር ግን ለመፃፍ ስራዎች ሊመዘን አይችልም።

በሌላ በኩል፣ በተፈጥሮው ምክንያት፣ Cloud Spanner በትንሹ ጣልቃ ገብነት በቀላሉ በአግድም ሊለካ ይችላል።

ሙሉ ተለይቶ የቀረበ DBMS እንደ አገልግሎት ከተለያየ አቅጣጫ መገምገም አለበት። እንደ መሰረት, በደመና ውስጥ በጣም ታዋቂ የሆነውን DBMS ወስደናል - ለ Google, GCP Cloud SQL እና Amazon, AWS RDS. በግምገማችን፣ በሚከተሉት ምድቦች ላይ አተኩረን ነበር።

• የባህሪ ካርታ፡ SQL ስፋት፣ DDL፣ DML; የግንኙነት ቤተ-መጻሕፍት / ማገናኛዎች, የግብይት ድጋፍ, ወዘተ.
• የልማት ድጋፍ: የልማት እና የፈተና ቀላልነት.
• የአስተዳደር ድጋፍ፡ የአብነት አስተዳደር እንደ ወደላይ/ወደታች ማሳደግ እና ሁኔታዎችን ማሻሻል፤ SLA, ምትኬ እና ማግኛ; የደህንነት / የመዳረሻ መቆጣጠሪያ.

ክላውድ ስፓነርን እንደ OLAP የነቃ OLTP መፍትሄ መጠቀም

ጉግል ክላውድ ስፓነር ለትንታኔ መሆኑን በግልፅ ባይገልጽም አንዳንድ ባህሪያትን ለሌሎች እንደ Apache Impala & Kudu እና YugaByte ለOLAP የስራ ጫናዎች ከተነደፉ ሞተሮች ጋር ያካፍላል።

ክላውድ ስፓነር ወጥነት ያለው ሚዛን-ውጭ ኤችቲኤፒ (ድብልቅ ግብይት/አናላይቲክ ፕሮሰሲንግ) ሞተርን ከ(ከብዙ ወይም ባነሰ) ጥቅም ላይ ሊውል የሚችል የOLAP ባህሪ ስብስብን የማካተት እድሉ ትንሽ ቢሆንም፣ ትኩረታችንን የሚስብ ይመስለናል።

ይህን በአእምሯችን ይዘን፣ የሚከተሉትን ምድቦች ተመልክተናል።

• የውሂብ መጫን, ኢንዴክሶች እና ክፍልፍል ድጋፍ
• የጥያቄ አፈጻጸም እና ዲኤምኤል

2. ክላውድ ስፓነር ባጭሩ

ጎግል ስፓነር ጉግል ለብዙ የራሱ አገልግሎቶች የሚጠቀምበት የተሰባጠረ የግንኙነት ዳታቤዝ አስተዳደር ስርዓት (RDBMS) ነው። ጎግል በ2017 መጀመሪያ ላይ ለGoogle Cloud Platform ተጠቃሚዎች በይፋ እንዲገኝ አድርጓል።

አንዳንድ የክላውድ ስፓነር ባህሪያት እነኚሁና፡

• ከፍተኛ ወጥነት ያለው፣ ሊለካ የሚችል RDBMS ክላስተር፡ የውሂብ ወጥነትን ለማረጋገጥ የሃርድዌር ጊዜ ማመሳሰልን ይጠቀማል።
• የጠረጴዛ ተሻጋሪ የግብይት ድጋፍ፡ ግብይቶች ብዙ ሠንጠረዦችን ሊሸፍኑ ይችላሉ - የግድ በአንድ ሠንጠረዥ ብቻ የተገደበ አይደለም (እንደ Apache HBase ወይም Apache Kudu በተለየ)።
• በዋና ቁልፍ ላይ የተመሰረቱ ሠንጠረዦች፡ ሁሉም ሠንጠረዦች የታወጀ ዋና ቁልፍ (ፒሲ) ሊኖራቸው ይገባል፣ እሱም በርካታ የሰንጠረዥ አምዶችን ሊይዝ ይችላል። የሰንጠረዡ መረጃ በፒሲ ቅደም ተከተል ተቀምጧል፣ ይህም ለፒሲ ፍለጋዎች በጣም ቀልጣፋ እና ፈጣን ያደርገዋል። ልክ እንደሌሎች ፒሲ ላይ የተመሰረቱ ስርዓቶች፣ አፈፃፀሙ ቀድሞ ከታሰበባቸው የአጠቃቀም ጉዳዮች ጋር መምሰል አለበት። ምርጥ አፈጻጸም.
• የተጣሩ ጠረጴዛዎች: ጠረጴዛዎች እርስ በእርሳቸው አካላዊ ጥገኛ ሊኖራቸው ይችላል. የልጁ ጠረጴዛ ረድፎች ከወላጅ ጠረጴዛው ረድፎች ጋር ሊመሳሰሉ ይችላሉ. ይህ አቀራረብ በመረጃ ሞዴል ደረጃ ላይ ሊወሰኑ የሚችሉ ግንኙነቶችን ፍለጋን ያፋጥናል, ለምሳሌ ደንበኞችን እና ደረሰኞቻቸውን አንድ ላይ ሲያስቀምጡ.
• ኢንዴክሶች፡ Cloud Spanner ሁለተኛ ደረጃ ኢንዴክሶችን ይደግፋል። ኢንዴክስ የተጠቆሙ አምዶች እና ሁሉንም የፒሲ አምዶች ያካትታል። እንደ አማራጭ፣ መረጃ ጠቋሚው ሌሎች ጠቋሚ ያልሆኑ አምዶችን ሊይዝ ይችላል። መጠይቆችን ለማፋጠን መረጃ ጠቋሚው ከወላጅ ሠንጠረዥ ጋር ሊጣመር ይችላል። በመረጃ ጠቋሚ ውስጥ ሊቀመጡ የሚችሉ ከፍተኛው ተጨማሪ ዓምዶች በመሳሰሉ ኢንዴክሶች ላይ በርካታ ገደቦች ተፈጻሚ ይሆናሉ። እንዲሁም፣ በመረጃ ጠቋሚዎች የሚቀርቡ ጥያቄዎች እንደሌሎች RDBMSዎች ቀጥተኛ ላይሆኑ ይችላሉ።

“ክላውድ ስፔነር ኢንዴክስን የሚመርጠው አልፎ አልፎ ብቻ ነው። በተለይም፣ ክላውድ ስፓነር መጠይቁ ያልተቀመጡትን አምዶች ከጠየቀ ሁለተኛ ደረጃ መረጃ ጠቋሚን በራስ ሰር አይመርጥም ኢንዴክስ ».

• የአገልግሎት ደረጃ ስምምነት (ኤስኤልኤ): ነጠላ ክልል ከ 99,99% SLA ጋር; ባለብዙ ክልል ማሰማራት 99,999% SLA. SLA ራሱ ስምምነት እንጂ የትኛውም ዓይነት ዋስትና ባይሆንም፣ የጉግል ሰዎች ይህን የመሰለ ጠንካራ የይገባኛል ጥያቄ ለማቅረብ አንዳንድ ከባድ ውሂብ እንዳላቸው አምናለሁ። (ለማጣቀሻ፣ 99,999% ማለት በወር 26,3 ሰከንድ የአገልግሎት ቅነሳ ማለት ነው።)
• ተጨማሪ: https://cloud.google.com/spanner/

ማስታወሻ: የApache Tephra ፕሮጀክት የላቀ የግብይት ድጋፍን ወደ Apache HBase ያክላል (አሁን በአፓቼ ፎኒክስ እንደ ቅድመ-ይሁንታ ተተግብሯል)።

3. የእኛ ግምገማ

ስለዚህ፣ ሁላችንም የGoogle መግለጫዎችን ስለ ክላውድ ስፓነር ጥቅሞች አንብበነዋል - ከፍተኛ ወጥነት ያለው እና በጣም ከፍተኛ የሆነ SLA። ምንም እንኳን እነዚህ የይገባኛል ጥያቄዎች በማንኛውም ሁኔታ ለመድረስ እጅግ በጣም ከባድ ቢሆኑም ግባችን እነሱን ውድቅ ለማድረግ አልነበረም። ይልቁንስ አብዛኞቹ የውሂብ ጎታ ተጠቃሚዎች ትኩረት በሚሰጣቸው ሌሎች ነገሮች ላይ እናተኩር፡ እኩልነት እና አጠቃቀም።

Cloud Spanner የ Sharded MySQL ምትክ እንዲሆን ደረጃ ሰጥተናል

Google Cloud SQL እና Amazon AWS RDS, በደመና ገበያ ውስጥ በጣም ታዋቂ ከሆኑ የ OLTP የውሂብ ጎታዎች መካከል ሁለቱ በጣም ትልቅ የባህሪ ስብስብ አላቸው። ነገር ግን፣ እነዚህን የውሂብ ጎታዎች ከአንድ መስቀለኛ መንገድ መጠን ለማለፍ፣ የመተግበሪያ ክፍፍልን ማከናወን አለቦት። ይህ አካሄድ ለሁለቱም መተግበሪያዎች እና አስተዳደር ተጨማሪ ውስብስብ ነገሮችን ይፈጥራል. ስፓነር ብዙ ሻርዶችን ወደ አንድ ምሳሌ በማጣመር እንዴት እንደሚስማማ እና ምን አይነት ባህሪያት (ካለ) መስዋዕት መሆን እንዳለበት ተመልክተናል።

ለ SQL፣ DML እና DDL፣ እንዲሁም ማገናኛ እና ቤተ-መጻሕፍት ድጋፍ?

በመጀመሪያ በማንኛውም የውሂብ ጎታ ሲጀምሩ የውሂብ ሞዴል መፍጠር ያስፈልግዎታል. JDBC Spanner ን ከምትወደው የSQL መሳሪያ ጋር ማገናኘት ትችላለህ ብለህ ካሰብክ በሱ ውሂብህን መጠየቅ እንደምትችል ታገኛለህ ነገር ግን ሠንጠረዥ ለመፍጠር ወይም ለማዘመን (ዲኤልኤል) ወይም ማንኛውንም ማስገባት/ማዘመን/ሰርዝ ልትጠቀምበት አትችልም። ኦፕሬሽኖች (ዲኤምኤል) የጎግል ኦፊሴላዊ JDBC ሁለቱንም አይደግፍም።

"አሽከርካሪዎች በአሁኑ ጊዜ የዲኤምኤልን ወይም የዲዲኤል መግለጫዎችን አይደግፉም።"
Spanner Documentation

ሁኔታው በጂሲፒ ኮንሶል የተሻለ አይደለም - የ SELECT መጠይቆችን ብቻ መላክ ይችላሉ. እንደ እድል ሆኖ፣ ግብይቶችን ጨምሮ ከማህበረሰቡ የዲኤምኤል እና የዲዲኤል ድጋፍ ያለው የJDBC ሹፌር አለ። github.com/olavloite/spanner-jdbc. ይህ ሾፌር እጅግ በጣም ጠቃሚ ቢሆንም፣ የራሱ የGoogle JDBC ሾፌር አለመኖሩ አስገራሚ ነው። እንደ እድል ሆኖ፣ Google ሰፋ ያለ የደንበኛ ላይብረሪ ድጋፍ ይሰጣል (በgRPC ላይ የተመሰረተ)፡ C#፣ Go፣ Java፣ node.js፣ PHP፣ Python እና Ruby።

የክላውድ ስፓነር ብጁ ኤፒአይዎች (በDDL እና ዲኤምኤል እጥረት በJDBC ውስጥ) በግዴታ መቅረብ ለ ተዛማጅ የኮድ ቦታዎች እንደ የግንኙነት ማሰባሰብ ወይም የውሂብ ጎታ ማሰሪያ ማዕቀፎች (እንደ ስፕሪንግ MVC) ያሉ አንዳንድ ገደቦችን ያስከትላል። በአጠቃላይ፣ JDBCን ሲጠቀሙ፣ የሚወዱትን የግንኙነት ገንዳ (ለምሳሌ HikariCP፣ DBCP፣ C3PO፣ ወዘተ.) የተሞከረ እና በደንብ የሚሰራውን ለመምረጥ ነፃ ነዎት። ብጁ ስፓነር ኤፒአይዎችን በተመለከተ፣ እራሳችንን በፈጠርናቸው ማዕቀፎች/ማሰሪያ/የክፍለ ጊዜ ገንዳዎች ላይ መተማመን አለብን።

ዋናው ቁልፍ (ፒሲ) ተኮር ንድፍ ክላውድ ስፓነር በፒሲ በኩል መረጃን ሲደርስ በጣም ፈጣን እንዲሆን ያስችለዋል፣ ነገር ግን አንዳንድ የጥያቄ ችግሮችንም ያስተዋውቃል።

• የዋና ቁልፍን ዋጋ ማዘመን አይችሉም; መጀመሪያ የመጀመሪያውን ፒሲ ግቤት መሰረዝ እና በአዲሱ እሴት እንደገና ማስገባት አለብዎት። (ይህ ከሌሎች ፒሲ ተኮር የውሂብ ጎታ/ማከማቻ ሞተሮች ጋር ተመሳሳይ ነው።)
• ማንኛውም ማዘመኛ እና ሰርዝ መግለጫዎች ፒሲውን በ WHERE ውስጥ መግለጽ አለባቸው፣ስለዚህ ባዶ ሊሆኑ አይችሉም ሁሉንም መግለጫዎች ሰርዝ - ሁል ጊዜ ንዑስ መጠይቅ መኖር አለበት፣ ለምሳሌ፦ አዘምን xxx መታወቂያ ከገባ (ከሠንጠረዥ1 ምረጥ)
• የፒሲ መስኩን ቅደም ተከተል የሚያዘጋጅ የራስ-ማሳያ አማራጭ ወይም ተመሳሳይ ነገር አለመኖር። ይህ እንዲሰራ, ተጓዳኝ እሴት በመተግበሪያው በኩል መፈጠር አለበት.

ሁለተኛ ደረጃ ኢንዴክሶች?

ጎግል ክላውድ ስፓነር ለሁለተኛ ደረጃ ኢንዴክሶች አብሮ የተሰራ ድጋፍ አለው። ይህ ሁልጊዜ በሌሎች ቴክኖሎጂዎች ውስጥ የማይገኝ በጣም ጥሩ ባህሪ ነው. Apache Kudu በአሁኑ ጊዜ ሁለተኛ ኢንዴክሶችን በፍጹም አይደግፍም እና Apache HBase ኢንዴክሶችን በቀጥታ አይደግፍም ነገር ግን በApache Phoenix በኩል ሊያክላቸው ይችላል።

በKuዱ እና HBase ውስጥ ያሉ ኢንዴክሶች እንደ ተለየ ሠንጠረዥ ሊቀረጹ ይችላሉ የተለያዩ የመጀመሪያ ቁልፎች ቅንብር ነገር ግን በወላጅ ጠረጴዛ እና በተዛማጅ ማውጫ ሰንጠረዦች ላይ የተከናወኑ ተግባራት ተውሳክነት በአፕሊኬሽን ደረጃ መከናወን አለበት እና በትክክል መተግበር ቀላል አይደለም.

በክላውድ ስፓነር ግምገማ ላይ እንደተጠቀሰው ኢንዴክሶቹ ከ MySQL ኢንዴክሶች ሊለያዩ ይችላሉ። ስለሆነም ትክክለኛ ኢንዴክስ በሚፈለግበት ቦታ ጥቅም ላይ እንዲውል መጠይቁን በመገንባት እና በመገለጽ ረገድ ልዩ ጥንቃቄ መደረግ አለበት።

ውክልና?

በመረጃ ቋት ውስጥ በጣም ታዋቂ እና ጠቃሚ ነገር እይታዎች ነው። ለብዙ የአጠቃቀም ጉዳዮች ጠቃሚ ሊሆኑ ይችላሉ; ሁለቱ ተወዳጆች አመክንዮአዊ የአብስትራክሽን ንብርብር እና የደህንነት ንብርብር ናቸው። የአጋጣሚ ነገር ሆኖ Cloud Spanner እይታዎችን አይደግፍም። ነገር ግን፣ እይታዎች ተቀባይነት ያለው መፍትሄ የሚሆኑበት የመዳረሻ ፍቃዶች ምንም የአምድ-ደረጃ ቅንጣት ስለሌለ ይህ በከፊል ብቻ ይገድበናል።

ኮታዎችን እና ገደቦችን ለሚዘረዝር ክፍል የCloud Spanner ሰነዱን ይመልከቱ (spanner / ኮታዎችበተለይ ለአንዳንድ አፕሊኬሽኖች ችግር የሚፈጥር አንድ አለ፡ Cloud Spanner ከሳጥን ውስጥ ቢበዛ 100 የውሂብ ጎታዎች በአንድ ምሳሌ አለው። ከ100 በላይ የውሂብ ጎታዎችን ለመመዘን ለተዘጋጀ የውሂብ ጎታ ይህ ትልቅ እንቅፋት ሊሆን እንደሚችል ግልጽ ነው። እንደ እድል ሆኖ፣ ከጎግል ቴክኒካል ወኪላችን ጋር ከተነጋገርን በኋላ፣ ይህ ገደብ በGoogle ድጋፍ በኩል ወደ ማንኛውም እሴት ሊጨምር እንደሚችል ደርሰንበታል።

የልማት ድጋፍ?

ክላውድ ስፓነር ከኤፒአይ ጋር አብሮ ለመስራት ጥሩ የፕሮግራም አወጣጥ ቋንቋ ድጋፍ ይሰጣል። በይፋ የሚደገፉት ቤተ-መጻሕፍት በC#፣ Go፣ Java፣ node.js፣ PHP፣ Python እና Ruby አካባቢ ናቸው። ሰነዱ በትክክል ተዘርዝሯል፣ነገር ግን እንደሌሎች ዘመናዊ ቴክኖሎጂዎች ማህበረሰቡ በጣም ታዋቂ ከሆኑ የመረጃ ቋት ቴክኖሎጂዎች ጋር ሲወዳደር በጣም ትንሽ ነው፣ይህም ብዙ ጊዜ ጥቅም ላይ ባልዋሉ ጉዳዮች ወይም ችግሮች ላይ ሊያጠፋ ይችላል።

ስለዚህ የአካባቢ ልማት ድጋፍስ?

በግቢው ውስጥ የክላውድ ስፓነር ምሳሌ የምንፈጥርበት መንገድ አላገኘንም። ያገኘነው የዶከር ምስል ነው። ኮክራክ ዲ.ቢ.በመርህ ደረጃ ተመሳሳይ ነው, በተግባር ግን በጣም የተለየ ነው. ለምሳሌ CockroachDB PostgreSQL JDBCን መጠቀም ይችላል። የልማት አካባቢው በተቻለ መጠን ለአምራች አካባቢ ቅርብ መሆን ስላለበት ክላውድ ስፓነር ተስማሚ አይደለም ምክንያቱም ሙሉ የስፓነር ምሳሌን መደገፍ ያስፈልግዎታል። ወጪዎችን ለመቆጠብ የአንድ ክልል ምሳሌ መምረጥ ይችላሉ።

የአስተዳደር ድጋፍ?

የክላውድ ስፓነር ምሳሌ መፍጠር በጣም ቀላል ነው። የብዝሃ-ክልል ወይም የነጠላ ክልል ምሳሌን ከመፍጠር መካከል መምረጥ ብቻ ያስፈልግዎታል፣ ክልሉን(ቹን) እና የአንጓዎችን ብዛት ይግለጹ። ከአንድ ደቂቃ ባነሰ ጊዜ ውስጥ ምሳሌው ይነሳል እና ይሰራል።

በርካታ የአንደኛ ደረጃ መለኪያዎች በGoogle Console ውስጥ በስፓነር ገጽ ላይ በቀጥታ ይገኛሉ። ተጨማሪ ዝርዝር እይታዎች በStackdriver በኩል ይገኛሉ፣ እዚያም ሜትሪክ ገደቦችን እና የማንቂያ መመሪያዎችን ማዘጋጀት ይችላሉ።

የሀብቶች መዳረሻ?

MySQL ሰፊ እና በጣም ግዙፍ የተጠቃሚ ፍቃድ/ሚና ቅንብሮችን ያቀርባል። የአንድ የተወሰነ ሰንጠረዥ መዳረሻን ወይም የአምዶቹን ንዑስ ስብስብ በቀላሉ ማበጀት ይችላሉ። ክላውድ ስፓነር የGoogle Identity & Access Management (IAM) መሣሪያን ይጠቀማል፣ ይህም ፖሊሲዎችን እና ፈቃዶችን በከፍተኛ ደረጃ እንዲያዘጋጁ ብቻ ይፈቅድልዎታል። በጣም ጥቃቅን የሆነው አማራጭ የውሂብ ጎታ-ደረጃ ፍቃድ ነው, ይህም በአብዛኛዎቹ የምርት ጉዳዮች ላይ አይጣጣምም. ያልተፈቀደ የስፓነር ሃብቶችን ለመከላከል ይህ ገደብ ተጨማሪ የደህንነት እርምጃዎችን ወደ ኮድዎ፣ መሠረተ ልማትዎ ወይም ሁለቱም እንዲያክሉ ያስገድድዎታል።

ምትኬ?

በቀላሉ ለማስቀመጥ፣ በ Cloud Spanner ውስጥ ምንም ምትኬዎች የሉም። የ Google ከፍተኛ SLA መስፈርቶች በሃርድዌር ወይም የውሂብ ጎታ ውድቀቶች, የሰው ስህተት, የመተግበሪያ ጉድለቶች, ወዘተ ምንም ውሂብ ማጣት አይደለም ማረጋገጥ ይችላሉ ቢሆንም, ሁላችንም ደንቡን እናውቃለን: ከፍተኛ ተገኝነት ዘመናዊ የመጠባበቂያ ስትራቴጂ ምንም ምትክ አይደለም. በአሁኑ ጊዜ የውሂብ ምትኬን ለማስቀመጥ ብቸኛው መንገድ ከመረጃ ቋቱ ወደ ተለየ የማከማቻ አካባቢ ፕሮግራማዊ በሆነ መንገድ ማስተላለፍ ነው።

የጥያቄ አፈጻጸም?

ውሂብ ለመጫን እና ጥያቄዎችን ለመሞከር ያሁ!ን ተጠቅመንበታል። የክላውድ አገልግሎት ቤንችማርክ። ከታች ያለው ሠንጠረዥ ከ95% ከንባብ እስከ 5% የመፃፍ ጥምርታ ያለው የቢ YCSB የስራ ጫና ያሳያል።

* የመጫኛ ሙከራው በ n1-standard-32 Compute Engine (CE) (32 vCPUs፣ 120GB memory) ላይ ነበር የተካሄደው እና የፈተናው ምሳሌ በፈተናዎች ውስጥ ማነቆ ሆኖ አያውቅም።
** በአንድ YCSB ምሳሌ ውስጥ ያለው ከፍተኛው የክሮች ብዛት 400 ነው። በአጠቃላይ 2400 ትይዩ የYCSB ፈተናዎች በድምሩ XNUMX ክሮች ማግኘት ነበረባቸው።

የቤንችማርክ ውጤቶችን ስንመለከት በተለይም የሲፒዩ ሎድ እና TPS ጥምርነት፣ ክላውድ ስፓነር በጥሩ ሁኔታ እንደሚመዘን በግልፅ እናያለን። በበርካታ ክሮች የተፈጠረ ትልቅ ጭነት በክላውድ ስፓነር ክላስተር ውስጥ ባሉ በርካታ ኖዶች ተስተካክሏል። ምንም እንኳን መዘግየት በጣም ከፍተኛ ቢመስልም በተለይም በ 2400 ክሮች ላይ ሲሰራ, የበለጠ ትክክለኛ ቁጥሮችን ለማግኘት በ 6 ትናንሽ የኮምፒዩተር ሞተሮች እንደገና መሞከር አስፈላጊ ሊሆን ይችላል. እያንዳንዱ ምሳሌ ከአንድ ትልቅ CE ምሳሌ ይልቅ አንድ የYCSB ፈተና ከ6 ትይዩ ሙከራዎች ጋር ያካሂዳል። ይህ በክላውድ ስፓነር መዘግየቶች እና በ Cloud Spanner መካከል ባለው የአውታረ መረብ ግንኙነት እና በፈተናው ላይ ባለው CE ምሳሌ መካከል የተጨመሩ መዘግየቶችን መለየት ቀላል ያደርገዋል።

ክላውድ ስፓነር እንደ OLAP እንዴት ይሰራል?

መከፋፈል?

መረጃን በአካል እና/ወይም በሎጂካዊ ገለልተኛ ክፍሎች ማለትም ክፍልፍሎች ተብለው መከፋፈል በአብዛኛዎቹ የOLAP ሞተሮች ውስጥ የሚገኝ በጣም ታዋቂ ጽንሰ-ሀሳብ ነው። ክፍልፋዮች የጥያቄ አፈጻጸምን እና የውሂብ ጎታ ማቆየትን በእጅጉ ሊያሻሽሉ ይችላሉ። ወደ ክፍልፍል የበለጠ ማጥለቅለቅ የተለየ መጣጥፍ(ቶች) ይሆናል፣ ስለዚህ የመከፋፈያ እቅድ እና ንዑስ ክፍልፋዮችን አስፈላጊነት ብቻ እንጥቀስ። መረጃን ወደ ክፍልፋዮች እና እንዲያውም ወደ ንዑስ ክፍልፋዮች የመከፋፈል ችሎታ ለትንታኔ ጥያቄዎች አፈፃፀም ቁልፍ ነው።

ክላውድ ስፓነር በእያንዳንዱ ክፍል ክፍሎችን አይደግፍም። መረጃን ከውስጥ ወደ ሚጠራው ይለያል ሰነጠቀ- በዋና ቁልፍ ክልሎች ላይ የተመሠረተ። በክላውድ ስፓነር ክላስተር ላይ ያለውን ሸክም ለማመጣጠን ክፋዩ በራስ ሰር ይከናወናል። በጣም ምቹ የሆነ የክላውድ ስፓነር ባህሪ የወላጅ ጠረጴዛን (ከሌላ ጋር ያልተጠላለፈ ሠንጠረዥ) የመሠረት ጭነት እየከፈለ ነው። ስፓነር በውስጡ የያዘው ከሆነ በራስ-ሰር ይገነዘባል ሰነጠቀ ከሌላው መረጃ በበለጠ በተደጋጋሚ የሚነበብ ውሂብ ሰነጠቀ-አህ, እና ተጨማሪ መለያየት ላይ ሊወስን ይችላል. በዚህ መንገድ፣ በጥያቄ ውስጥ ብዙ አንጓዎች ሊሳተፉ ይችላሉ፣ ይህም ደግሞ የውጤት መጠንን በሚገባ ይጨምራል።

ውሂብ በመጫን ላይ?

ለጅምላ መረጃ የክላውድ ስፓነር ዘዴ ከመደበኛ ሰቀላ ጋር ተመሳሳይ ነው። ለከፍተኛ አፈጻጸም፣ የሚከተሉትን ጨምሮ አንዳንድ መመሪያዎችን መከተል ያስፈልግዎታል፡-

• ውሂብህን በዋና ቁልፍ ደርድር።
• በ10* ይከፋፍሏቸውየአንጓዎች ብዛት የግለሰብ ክፍሎች.
• ውሂብን በትይዩ የሚጭኑ የሰራተኛ ተግባራት ስብስብ ይፍጠሩ።

ይህ የውሂብ ጭነት ሁሉንም የ Cloud Spanner nodes ይጠቀማል።

የ10M የረድፍ ዳታ ስብስብ ለመፍጠር የYCSB የስራ ጫናን ተጠቅመንበታል።

* የመጫኛ ሙከራው የተካሄደው በ n1-standard-32 compute engine (32 vCPUs፣ 120 GB memory) ሲሆን የፈተናው ምሳሌ በፈተናዎች ውስጥ ማነቆ ሆኖ አያውቅም።
** 1 መስቀለኛ መንገድ ማዋቀር ለማንኛውም የምርት የስራ ጫና አይመከርም።

ከላይ እንደተገለፀው ክላውድ ስፓነር እንደ ሸክማቸው ክፍሎቹን በራስ ሰር ያካሂዳል፣ ስለዚህ ውጤቶቹ ከበርካታ ተከታታይ የፈተና ድግግሞሽ በኋላ ይሻሻላሉ። እዚህ የቀረቡት ውጤቶች እኛ ያገኘናቸው ምርጥ ውጤቶች ናቸው. ከላይ ያሉትን ቁጥሮች ስንመለከት በክላስተር ውስጥ ያሉት የአንጓዎች ብዛት ሲጨምር ክላውድ ስፓነር እንዴት እንደሚመዘን እናያለን። ጎልተው የታዩት ቁጥሮች እጅግ በጣም ዝቅተኛ የአማካይ መዘግየት ናቸው፣ ይህም ከላይ ባለው ክፍል እንደተገለፀው ከተደባለቀ የስራ ጫና ውጤቶች (95% ማንበብ እና 5% መጻፍ) ጋር ይቃረናል።

ማመጣጠን?

የክላውድ ስፓነር ኖዶችን ቁጥር መጨመር እና መቀነስ የአንድ ጊዜ ጠቅታ ተግባር ነው። መረጃን በፍጥነት ለመጫን ከፈለጉ ፣ ምሳሌውን ወደ ከፍተኛው ከፍ ለማድረግ ያስቡ ይሆናል (በእኛ ሁኔታ በUS-EAST ክልል ውስጥ 25 ኖዶች ነበሩ) እና ከዚያ በኋላ ለመደበኛ ጭነትዎ ተስማሚ የሆኑ የአንጓዎችን ብዛት ይቀንሱ። በመረጃ ቋቱ ውስጥ ያለው መረጃ የ 2 ቴባ / የመስቀለኛ መንገድ ወሰንን ከግምት ውስጥ በማስገባት።

በጣም ትንሽ በሆነ የውሂብ ጎታ እንኳን ይህን ገደብ አስታወስን። ከበርካታ የጭነት ሙከራ ሙከራዎች በኋላ የውሂብ ጎታችን 155 ጂቢ ያህል ነበር፣ እና ወደ 1 መስቀለኛ መንገድ ሲመዘን የሚከተለው ስህተት አጋጥሞናል።

ከ 25 ወደ 2 አጋጣሚዎች ዝቅ ማድረግ ችለናል, ነገር ግን በሁለት አንጓዎች ላይ ተጣብቀናል.

በክላውድ ስፓነር ክላስተር ውስጥ ያሉ የአንጓዎችን ብዛት ማሳደግ እና መቀነስ REST API በመጠቀም በራስ ሰር ሊደረግ ይችላል። ይህ በተለይ ሥራ በሚበዛበት ጊዜ በሲስተሙ ላይ ያለውን ጭነት ለመቀነስ ጠቃሚ ሊሆን ይችላል።

የOLAP መጠይቅ አፈጻጸም?

በመጀመሪያ በዚህ ክፍል ስፓነርን ለመገምገም ብዙ ጊዜ ለማሳለፍ አቅደናል። ከጥቂት SELECT COUNTs በኋላ፣ ፈተናው አጭር እንደሚሆን እና Spanner ለ OLAP ተስማሚ ሞተር እንደማይሆን ወዲያውኑ ተገነዘብን። በክላስተር ውስጥ ያሉት የአንጓዎች ብዛት ምንም ይሁን ምን የረድፎችን ብዛት በ10M ረድፍ ሠንጠረዥ መምረጥ ብቻ ከ55 እስከ 60 ሰከንድ ፈጅቷል። እንዲሁም መካከለኛ ውጤቶችን ለማከማቸት ተጨማሪ ማህደረ ትውስታ የሚያስፈልገው ማንኛውም መጠይቅ በOOM ስህተት አልተሳካም።

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

ለTPC-H መጠይቆች አንዳንድ ቁጥሮች በቶድ ሊፕኮን ጽሑፍ ውስጥ ይገኛሉ nosql-kudu-spanner-slides.html, ስላይድ 42 እና 43. እነዚህ ቁጥሮች ከራሳችን ውጤቶች ጋር የሚጣጣሙ ናቸው (እንደ አለመታደል ሆኖ).

4. ግኝቶቻችን

አሁን ካለው የክላውድ ስፓነር ባህሪያት ሁኔታ አንፃር፣ ለነባር OLTP መፍትሄ እንደ ቀላል ምትክ ሆኖ ማየት ከባድ ነው፣በተለይም ፍላጎቶችዎ ሲያድግ። በክላውድ ስፓነር ድክመቶች ዙሪያ መፍትሄን ለመገንባት ብዙ ጊዜ ይወስዳል።

ክላውድ ስፓነርን መገምገም ስንጀምር የአስተዳደር ባህሪያቱ ከሌሎች የGoogle SQL መፍትሄዎች ጋር እኩል ወይም ቢያንስ ብዙም አይርቅም ብለን ጠብቀን ነበር። ነገር ግን ሙሉ በሙሉ የመጠባበቂያ እጦት እና የሀብቶች መዳረሻ ቁጥጥር በጣም ውስን በመሆኑ አስገርሞናል። ምንም አይነት እይታዎችን መጥቀስ አይደለም, ምንም የአካባቢ ልማት አካባቢ, ያልተደገፉ ቅደም ተከተሎች, JDBC ያለ ዲኤምኤል እና ዲ ዲኤል ድጋፍ, ወዘተ.

ስለዚህ፣ የግብይት ዳታቤዝ ልኬትን ለሚያስፈልገው ሰው ወዴት መሄድ አለበት? ለሁሉም የአጠቃቀም ጉዳዮች የሚስማማ አንድ ወጥ መፍትሄ በገበያ ላይ እስካሁን ያለ አይመስልም። ብዙ የተዘጉ እና ክፍት ምንጭ መፍትሄዎች አሉ (አንዳንዶቹ በዚህ ጽሑፍ ውስጥ ተጠቅሰዋል), እያንዳንዳቸው የራሳቸው ጥንካሬዎች እና ድክመቶች አሏቸው, ግን አንዳቸውም ሳአኤስን ከ 99,999% SLA እና ከፍተኛ ደረጃ ጋር አያቀርቡም. ከፍተኛ SLA የእርስዎ ተቀዳሚ ግብ ከሆነ እና ለብዙ ደመናዎች የራስዎን መፍትሄ ለመገንባት ፍላጎት ከሌለዎት ፣ Cloud Spanner እርስዎ የሚፈልጉት መፍትሄ ሊሆን ይችላል። ግን ሁሉንም ገደቦች ማወቅ አለብዎት።

እውነቱን ለመናገር፣ ክላውድ ስፓነር ለሕዝብ የተለቀቀው በ2017 የጸደይ ወቅት ብቻ ነው፣ ስለዚህ አሁን ያሉት አንዳንድ ጉድለቶች በመጨረሻ ሊጠፉ ይችላሉ (ተስፋ እናደርጋለን) ብሎ መጠበቅ ምክንያታዊ ነው። ደግሞም ክላውድ ስፓነር ለGoogle የጎን ፕሮጀክት ብቻ አይደለም። ጎግል ለሌሎች የጉግል ምርቶች መሰረት አድርጎ ይጠቀምበታል። እና ጎግል በቅርቡ ሜጋስቶርን በጎግል ክላውድ ማከማቻ በክላውድ ስፓነር ሲተካ ጎግል ክላውድ ማከማቻ በአለምአቀፍ ደረጃ ለነገሮች ዝርዝር በጣም ወጥነት ያለው እንዲሆን አስችሎታል (ይህ አሁንም እንደዛ አይደለም የአማዞን S3).

ስለዚህ አሁንም ተስፋ አለ... ተስፋ እናደርጋለን።

ይኼው ነው. እንደ መጣጥፉ ደራሲ እኛም ተስፋ መሆናችንን እንቀጥላለን ፣ ግን ስለዚህ ጉዳይ ምን ያስባሉ? በአስተያየቶቹ ውስጥ ይፃፉ

ሁሉም ሰው የእኛን እንዲጎበኙ እንጋብዛለን ነጻ ዌቢናር ስለ ትምህርቱ በዝርዝር የምንነግርበት "AWS ለገንቢዎች" ከ OTUS.

ምንጭ: hab.com