NewSQL = NoSQL+ACID

እስከ ቅርብ ጊዜ ድረስ በኦድኖክላሲኒኪ 50 ቴባ የሚጠጋ መረጃ በእውነተኛ ጊዜ በSQL አገልጋይ ውስጥ ተከማችቷል። ለእንዲህ ዓይነቱ የድምጽ መጠን SQL DBMS ን በመጠቀም ፈጣን እና አስተማማኝ እና ስህተትን የሚቋቋም የውሂብ ማዕከልን ለማቅረብ ፈጽሞ የማይቻል ነው. ብዙውን ጊዜ እንደዚህ ባሉ አጋጣሚዎች ከ NoSQL መደብሮች ውስጥ አንዱ ጥቅም ላይ ይውላል, ነገር ግን ሁሉም ነገር ወደ NoSQL ሊተላለፍ አይችልም: አንዳንድ አካላት የ ACID ግብይት ዋስትናዎችን ይፈልጋሉ.

ይህ የኒውኤስኪኤል ማከማቻን እንድንጠቀም መርቶናል፣ ያም ማለት፣ የስህተት መቻቻልን፣ የNoSQL ስርዓቶችን ማሳደግ እና አፈጻጸምን የሚያቀርብ ዲቢኤምኤስ፣ ነገር ግን በተመሳሳይ ጊዜ ለጥንታዊ ስርዓቶች የ ACID ዋስትናዎችን እንደያዘ ይቆያል። የዚህ አዲስ ክፍል ጥቂት የሚሰሩ የኢንዱስትሪ ስርዓቶች አሉ, ስለዚህ እንዲህ ዓይነቱን ስርዓት እራሳችንን ተግባራዊ አድርገን ወደ ንግድ ሥራ አስገባነው.

እንዴት እንደሚሰራ እና ምን እንደተፈጠረ - በቆራጩ ስር ያንብቡ.

ዛሬ የ Odnoklassniki ወርሃዊ ተመልካቾች ከ 70 ሚሊዮን በላይ ልዩ ጎብኝዎች ናቸው. እኛ ከላይ አምስት አስገባ በዓለም ላይ ያሉ ትላልቅ ማህበራዊ አውታረ መረቦች እና ተጠቃሚዎች ብዙ ጊዜ በሚያሳልፉባቸው ሃያ ምርጥ ጣቢያዎች ውስጥ። የ"እሺ" መሠረተ ልማት በጣም ከፍተኛ ሸክሞችን ያስተናግዳል፡ በአንድ የፊት ለፊት ከአንድ ሚሊዮን በላይ የኤችቲቲፒ ጥያቄዎች/ሰከንድ። ከ 8000 በላይ ቁርጥራጮች መጠን ውስጥ የአገልጋይ መናፈሻ ክፍሎች እርስ በርስ ቅርብ ናቸው - አራት የሞስኮ ውሂብ ማዕከላት ውስጥ, ይህም የሚቻል በመካከላቸው ከ 1 ms ያነሰ የአውታረ መረብ መዘግየት ለማቅረብ ያደርገዋል.

ከ2010 ጀምሮ ካሳንድራን ስንጠቀም ነበር ከስሪት 0.6 ጀምሮ። ዛሬ፣ በርካታ ደርዘን ስብስቦች ስራ ላይ ናቸው። በጣም ፈጣኑ ክላስተር በሰከንድ ከ4 ሚሊዮን በላይ ስራዎችን ይሰራል፣ ትልቁ ደግሞ 260 ቲቢ ያከማቻል።

ሆኖም፣ እነዚህ ሁሉ ለማከማቸት የሚያገለግሉ ተራ NoSQL ስብስቦች ናቸው። ደካማ የተቀናጀ ውሂብ. እንዲሁም Odnoklassniki ከተመሠረተበት ጊዜ ጀምሮ ጥቅም ላይ የዋለውን ዋናውን የማይክሮሶፍት SQL አገልጋይን መተካት እንፈልጋለን። ማከማቻው ከ300 በላይ SQL የአገልጋይ መደበኛ እትም ማሽኖችን ያቀፈ ሲሆን 50 ቴባ መረጃ የያዘ - የንግድ ተቋማት። ይህ ውሂብ እንደ ACID ግብይቶች አካል ተስተካክሏል እና ያስፈልገዋል ከፍተኛ ወጥነት.

በSQL Server nodes ላይ መረጃን ለማሰራጨት ሁለቱንም አቀባዊ እና አግድም ተጠቀምን። መከፋፈል (ሻርዲንግ)። ከታሪክ አኳያ፣ ቀላል የውሂብ ማከፋፈያ ዘዴን እንጠቀማለን፡ እያንዳንዱ አካል ከቶከን ጋር የተቆራኘ ነው - የህጋዊ አካል መታወቂያ ተግባር። ተመሳሳይ ምልክት ያላቸው አካላት በተመሳሳይ የSQL አገልጋይ ላይ ተቀምጠዋል። የማስተር-ዝርዝር ግንኙነቱ የተተገበረው የጌታ እና የህፃናት መዛግብት ምልክቶች ሁል ጊዜ የሚዛመዱ እና በአንድ አገልጋይ ላይ በሚገኙበት መንገድ ነው። በማህበራዊ አውታረመረብ ውስጥ ሁሉም ማለት ይቻላል መዝገቦች የሚመነጩት በተጠቃሚው ምትክ ነው ፣ ይህ ማለት በአንድ ተግባራዊ ንዑስ ስርዓት ውስጥ ያሉ ሁሉም የተጠቃሚ መረጃዎች በአንድ አገልጋይ ላይ ይከማቻሉ። ማለትም፣ የንግድ ልውውጥ ሁልጊዜ ማለት ይቻላል የአንድ SQL አገልጋይ ሰንጠረዦችን ያካትታል፣ ይህም መጠቀም ሳያስፈልገው የአካባቢ የኤሲአይዲ ግብይቶችን በመጠቀም የውሂብ ወጥነትን ለማረጋገጥ አስችሎታል። ዘገምተኛ እና የማይታመን የተከፋፈለ የኤሲዲ ግብይቶች.

ለሻርዲንግ ምስጋና ይግባውና SQLን ለማፋጠን፡-

• የውጭ ቁልፍ ገደቦችን አንጠቀምም ፣ ምክንያቱም በሚከፋፈልበት ጊዜ የህጋዊ አካል መታወቂያ በሌላ አገልጋይ ላይ ሊገኝ ይችላል።
• በዲቢኤምኤስ ሲፒዩ ላይ ባለው ተጨማሪ ጭነት ምክንያት የተከማቹ ሂደቶችን እና ቀስቅሴዎችን አንጠቀምም።
• ከላይ በተጠቀሱት ሁሉ እና ብዙ በዘፈቀደ ከዲስክ ስለሚነበቡ JOINs አንጠቀምም።
• ከግብይት ውጪ፣ የሞት መቆለፊያዎችን ለመቀነስ ያልተነበበ የማግለል ደረጃን እንጠቀማለን።
• አጭር ግብይቶችን ብቻ ነው የምንፈጽመው (በአማካይ ከ100 ሚሴ በታች)።
• ባለብዙ ረድፍ ዝማኔ እና ሰርዝ አንጠቀምም ምክንያቱም ብዙ ቁጥር ያላቸው የሞት መቆለፊያዎች - በአንድ ጊዜ አንድ መዝገብ ብቻ እናዘምነዋለን።
• መጠይቆች ሁል ጊዜ የሚከናወኑት በመረጃ ጠቋሚዎች ብቻ ነው - ሙሉ የጠረጴዛ ቅኝት እቅድ ያለው መጠይቅ ማለት የውሂብ ጎታውን ከመጠን በላይ መጫን እና ውድቀቱ ነው።

እነዚህ እርምጃዎች ከSQL አገልጋዮች ከፍተኛውን አፈጻጸም እንድንጨምቅ አስችሎናል። ይሁን እንጂ ችግሮቹ ከጊዜ ወደ ጊዜ እየጨመሩ መጥተዋል. እስቲ እንያቸው።

በ SQL ላይ ችግሮች

• እኛ በራሳችን የተፃፈ ሻርዲንግ ስለተጠቀምን፣ አዳዲስ ሸርቆችን ማከል በአስተዳዳሪዎች በእጅ ተከናውኗል። በዚህ ጊዜ ሁሉ፣ ሊለኩ የሚችሉ የውሂብ ቅጂዎች ጥያቄዎችን አላቀረቡም።
• በሰንጠረዡ ውስጥ ያሉት መዝገቦች ቁጥር እየጨመረ ሲሄድ የማስገባቱ እና የማሻሻያው ፍጥነት ይቀንሳል, ኢንዴክሶችን ወደ ነባር ሠንጠረዥ ሲጨመሩ, ፍጥነቱ በአንድ ብዜት ይቀንሳል, ኢንዴክሶችን መፍጠር እና እንደገና መፈጠር ጊዜ ይወስዳል.
• በምርት ውስጥ አነስተኛ መጠን ያለው ዊንዶውስ ለ SQL አገልጋይ መኖሩ የመሠረተ ልማት አስተዳደርን አስቸጋሪ ያደርገዋል

ዋናው ችግር ግን ነው።

ስህተትን መታገስ

ክላሲክ SQL አገልጋይ ደካማ የስህተት መቻቻል አለው። አንድ የውሂብ ጎታ አገልጋይ ብቻ አለህ እንበል እና በየሶስት አመቱ ይከሽፋል። በዚህ ጊዜ ጣቢያው ለ 20 ደቂቃዎች ተዘግቷል, ይህ ተቀባይነት አለው. 64 ሰርቨሮች ካሉዎት በየሶስት ሳምንታት አንዴ ጣቢያው ይቋረጣል። እና 200 አገልጋዮች ካሉዎት ጣቢያው በየሳምንቱ አይሰራም። ይህ ችግር ነው።

የ SQL አገልጋይ ስህተት መቻቻልን ለማሻሻል ምን ማድረግ ይቻላል? ዊኪፔዲያ እንድንገነባ ይጋብዘናል። በጣም የሚገኝ ዘለላ: የማንኛውም አካላት ብልሽት በሚከሰትበት ጊዜ ምትኬ አለ።

ይህ ውድ መሣሪያዎች አንድ መርከቦች ያስፈልገዋል: በርካታ ማባዛት, ፋይበር ኦፕቲክስ, የጋራ ማከማቻ, እና የተጠባባቂ ማካተት አስተማማኝ አይሰራም: ስለ inclusions መካከል 10% ዋና መስቀለኛ ጀርባ ባቡር ጋር የመጠባበቂያ መስቀለኛ መንገድ ውድቀት ውስጥ ያበቃል.

ነገር ግን የዚህ ዓይነቱ በጣም የሚገኝ ክላስተር ዋነኛው ጉዳቱ የሚገኝበት የመረጃ ማእከል ውድቀት ከሆነ ዜሮ መገኘት ነው። Odnoklassniki አራት የመረጃ ማዕከሎች አሉት ፣ እና ሙሉ በሙሉ ውድቀት በሚከሰትበት ጊዜ በአንዱ ውስጥ ሥራን ማረጋገጥ አለብን።

ለዚህ አንድ ማመልከት ይቻላል ባለብዙ ማስተር በ SQL አገልጋይ ውስጥ የተሰራ ማባዛት። ይህ መፍትሔ በሶፍትዌር ዋጋ ምክንያት በጣም ውድ ነው እና በሚታወቁ የማባዛት ችግሮች ይሠቃያል - ያልተጠበቀ የግብይት መዘግየት ከተመሳሰለ ማባዛት እና መዘግየቶች ማባዛትን (እና በውጤቱም, የጠፉ ማሻሻያዎችን) ባልተመሳሰሉ. በተዘዋዋሪ በእጅ ግጭት መፍታት ይህ አማራጭ ለኛ ፈጽሞ የማይተገበር ያደርገዋል።

እነዚህ ሁሉ ችግሮች ካርዲናል መፍትሄ ያስፈልጋቸዋል እና ወደ ዝርዝር ትንታኔያቸው ሄድን። እዚህ SQL Server በመሠረቱ የሚያደርገውን ነገር መተዋወቅ አለብን - ግብይቶች።

ቀላል ግብይት

ከተተገበረ የ SQL ፕሮግራመር እይታ አንጻር በጣም ቀላሉን ግብይት አስቡበት፡ ፎቶን ወደ አልበም ማከል። አልበሞች እና ፎቶዎች በተለያዩ ሳህኖች ውስጥ ይቀመጣሉ። አልበሙ የህዝብ ፎቶ ቆጣሪ አለው። ከዚያም እንዲህ ዓይነቱ ግብይት በሚከተሉት ደረጃዎች ይከፈላል.

1. አልበሙን በቁልፍ እናግደዋለን።
2. በፎቶ ሠንጠረዥ ውስጥ ግቤት ይፍጠሩ.
3. ፎቶው ይፋዊ ደረጃ ካለው፣ በአልበሙ ውስጥ ያሉትን የህዝብ ፎቶዎች ቆጣሪ እናስነሳለን፣ መዝገቡን አዘምነን ግብይቱን እንፈፅማለን።

ወይም በሐሰት ኮድ፡-

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

ለንግድ ግብይት በጣም የተለመደው ሁኔታ ከመረጃ ቋቱ ወደ የመተግበሪያው አገልጋይ ማህደረ ትውስታ ማንበብ ፣ የሆነ ነገር መለወጥ እና አዲሶቹን እሴቶችን ወደ ዳታቤዝ መመለስ መሆኑን እናያለን። ብዙውን ጊዜ በእንደዚህ ዓይነት ግብይት ውስጥ ብዙ አካላትን ፣ ብዙ ጠረጴዛዎችን እናዘምናለን።

ግብይት ሲፈፀም ከሌላ ስርዓት ተመሳሳይ ውሂብ በአንድ ጊዜ ማሻሻያ ሊከሰት ይችላል። ለምሳሌ አንቲስፓም ተጠቃሚው በሆነ መንገድ ተጠራጣሪ ነው ብሎ ሊወስን ይችላል እና ስለዚህ ሁሉም የተጠቃሚው ፎቶዎች ይፋዊ መሆን የለባቸውም፣ ለካስ ልኩ መላክ አለባቸው፣ ይህ ማለት photo.statusን ወደ ሌላ እሴት መለወጥ እና ተጓዳኝ ቆጣሪዎችን ማጥፋት ማለት ነው። በግልጽ ለማየት እንደሚቻለው, ይህ ክዋኔው ያለ የትግበራ እና የአተገባበር ማሻሻያ ዋስትናዎች ሳይኖር የሚከሰት ከሆነ, እንደ እ.ኤ.አ. አሲድ, ከዚያ ውጤቱ እርስዎ የሚፈልጉትን አይሆንም - ወይም የፎቶ ቆጣሪው የተሳሳተ እሴት ያሳያል, ወይም ሁሉም ፎቶዎች ለሽምግልና አይላኩም.

በአንድ ግብይት ውስጥ የተለያዩ የንግድ ድርጅቶችን የሚቆጣጠር ብዙ እንደዚህ ያሉ ኮድ በኦድኖክላስኒኪ ሕልውና ሁሉ ተጽፏል። ወደ NoSQL በመሰደድ ልምድ መሰረት የክስተት ወጥነት ትልቁ ፈተና (እና ጊዜ የሚወስድ) የውሂብ ወጥነት ለመጠበቅ ኮድ ማዘጋጀት አስፈላጊ መሆኑን እናውቃለን። ስለዚህ, ለአዲሱ ማከማቻ ዋናው መስፈርት ለእውነተኛ ACID ግብይቶች የትግበራ አመክንዮ አቅርቦት እንደሆነ አድርገን ነበር.

ሌሎች ተመሳሳይ አስፈላጊ መስፈርቶች የሚከተሉት ነበሩ:

• የውሂብ ማእከል ብልሽት በሚከሰትበት ጊዜ ለአዲሱ ማከማቻ ማንበብ እና መጻፍ ሁለቱም መገኘት አለባቸው።
• አሁን ያለውን የእድገት ፍጥነት መጠበቅ. ማለትም ፣ ከአዲስ ማከማቻ ጋር በሚሰሩበት ጊዜ የኮዱ መጠን በግምት ተመሳሳይ መሆን አለበት ፣ ወደ ማከማቻው አንድ ነገር ማከል አያስፈልግም ፣ ግጭቶችን ለመፍታት ስልተ ቀመሮችን ያዳብሩ ፣ ሁለተኛ ደረጃ ኢንዴክሶችን ለመጠበቅ ፣ ወዘተ.
• የአዲሱ ማከማቻ ፍጥነት በበቂ ፈጣን መሆን አለበት፣ ሁለቱም መረጃዎችን በሚያነቡበት ጊዜ እና ግብይቶችን በሚሰሩበት ጊዜ፣ ይህም በውጤታማነት በአካዳሚክ ጥብቅ፣ አጠቃላይ-ዓላማ፣ ግን ቀርፋፋ መፍትሄዎች፣ ለምሳሌ ሁለት-ደረጃ ድርጊቶች.
• በበረራ ላይ ራስ-ሰር ልኬት።
• ያልተለመዱ የብረት ቁርጥራጮችን መግዛት ሳያስፈልግ ተራ ርካሽ አገልጋዮችን መጠቀም።
• በኩባንያው ገንቢዎች የማከማቻ ልማት ዕድል. በሌላ አነጋገር ቅድሚያ የሚሰጠው ለባለቤትነት ወይም ለክፍት ምንጭ መፍትሄዎች፣ በተለይም በጃቫ ነው።

ውሳኔዎች, ውሳኔዎች

ሊሆኑ የሚችሉ መፍትሄዎችን በመተንተን ሁለት ሊሆኑ የሚችሉ የሕንፃ አማራጮችን አቅርበናል፡-

የመጀመሪያው ማንኛውንም የSQL አገልጋይ ወስዶ የሚፈለገውን የስህተት መቻቻል፣የማሳያ ዘዴ፣የድክመት ስብስብ፣ግጭት አፈታትን እና የተሰራጨ፣ታማኝ እና ፈጣን የኤሲዲ ግብይቶችን መተግበር ነው። ይህንን አማራጭ በጣም ቀላል ያልሆነ እና ጊዜ የሚወስድ ነው ብለን ገምግመናል።

ሁለተኛው አማራጭ ዝግጁ የሆነ የNoSQL ማከማቻ ከተተገበረ ልኬት፣ ከሽምቅ ማሰባሰብ፣ ከግጭት አፈታት እና ግብይቶችን መተግበር እና SQL እራስዎ መውሰድ ነው። በመጀመሪያ ሲታይ, SQL ን የመተግበር ተግባር እንኳን, የኤሲአይዲ ግብይቶችን ሳይጠቅስ, ለዓመታት ስራ ይመስላል. ግን በተግባር የምንጠቀመው የ SQL ባህሪያት ስብስብ ከ ANSI SQL በጣም የራቀ መሆኑን ተገነዘብን. ካሳንድራ CQL ከ ANSI SQL በጣም የራቀ። CQL ን በጥልቀት ስንመረምር፣ ወደምንፈልገው ነገር ቅርብ መሆኑን ተገነዘብን።

ካሳንድራ እና CQL

ስለዚህ ስለ ካሳንድራ ምን አስደሳች ነገር አለ ፣ ምን ባህሪዎች አሉት?

በመጀመሪያ፣ እዚህ ለተለያዩ የውሂብ አይነቶች ድጋፍ ያላቸው ሰንጠረዦችን መፍጠር ትችላለህ፣ በዋና ቁልፍ ምረጥ ወይም አዘምን ማድረግ ትችላለህ።

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

የተባዛ የውሂብ ወጥነት ለማረጋገጥ፣ ካሳንድራ ይጠቀማል የምልአተ ጉባኤ አቀራረብ. በቀላል ሁኔታ ፣ ይህ ማለት በተመሳሳይ ረድፍ ሶስት ቅጂዎችን በተለያዩ የክላስተር አንጓዎች ላይ ሲያስቀምጡ ፣ አብዛኛዎቹ አንጓዎች (ማለትም ከሶስቱ ሁለቱ) የዚህ የጽሑፍ ሥራ ስኬት ካረጋገጡ ጽሑፉ ስኬታማ እንደሆነ ይቆጠራል። በተከታታዩ ውስጥ ያለው መረጃ፣ በሚያነቡበት ጊዜ፣ አብዛኛዎቹ መስቀለኛ መንገዶች ድምጽ ከተሰጣቸው እና ካረጋገጡ ወጥነት ያለው ነው ተብሎ ይታሰባል። ስለዚህ, ሶስት ቅጂዎች ካሉ, አንድ መስቀለኛ መንገድ ካልተሳካ ሙሉ እና ፈጣን የውሂብ ወጥነት ይረጋገጣል. ይህ አካሄድ ይበልጥ አስተማማኝ እቅድ እንድንተገብር አስችሎናል፡ ሁል ጊዜ ጥያቄዎችን ወደ ሶስቱም ቅጂዎች ይላኩ፣ ከሁለቱ ፈጣን ምላሽ በመጠባበቅ ላይ። የሶስተኛው ቅጂ ዘግይቶ ምላሽ ይጣላል. በተመሳሳይ ጊዜ ከምላሽ ጋር የዘገየ መስቀለኛ መንገድ ከባድ ችግሮች ሊኖሩት ይችላል - ብሬክስ ፣ በ ​​JVM ውስጥ የቆሻሻ መጣያ ፣ በሊኑክስ ከርነል ውስጥ ቀጥተኛ ማህደረ ትውስታን መመለስ ፣ የሃርድዌር ውድቀት ፣ ከአውታረ መረቡ ጋር ያለው ግንኙነት። ሆኖም የደንበኛ ክዋኔዎች እና መረጃዎች በምንም መልኩ አይነኩም።

ሶስት ኖዶችን ስናገኝ እና ከሁለት ምላሽ ስንቀበል አቀራረብ ይባላል ግምት: የተጨማሪ ቅጂዎች ጥያቄ "ከመውደቁ" በፊት ይላካል.

ሌላው የካሳንድራ ጥቅም ባችሎግ ሲሆን ያደረጓቸው ለውጦች ሙሉ በሙሉ ተግባራዊ መሆናቸውን ወይም ሙሉ በሙሉ በጥቅሉ ላይ እንዳልተተገበሩ የሚያረጋግጥ ዘዴ ነው። ይህ በ ACID ውስጥ A ን ለመፍታት ያስችለናል - ከሳጥኑ ውስጥ atomity.

በካሳንድራ ውስጥ ለሚደረጉ ግብይቶች በጣም ቅርብ የሆነው ነገር "" ተብሎ የሚጠራው ነው.ቀላል ክብደት ግብይቶች". ነገር ግን ከ "እውነተኛ" የ ACID ግብይቶች በጣም የራቁ ናቸው: በእውነቱ, ይህ ለማድረግ እድሉ ነው CAS የፓክሶስ የከባድ ክብደት ፕሮቶኮል ስምምነትን በመጠቀም በአንድ መዝገብ ላይ ብቻ። ስለዚህ የእንደዚህ አይነት ግብይቶች ፍጥነት ዝቅተኛ ነው.

ካሳንድራ ውስጥ ያመለጠን።

ስለዚህ፣ በካሳንድራ ውስጥ እውነተኛ የኤሲአይዲ ግብይቶችን መተግበር ነበረብን። እኛ በቀላሉ ሌሎች ሁለት ምቹ የጥንታዊ ዲቢኤምኤስ ባህሪዎችን መተግበር እንችላለን-ወጥነት ያላቸው ፈጣን ኢንዴክሶች ፣ ይህም በዋናው ቁልፍ ብቻ ሳይሆን ውሂብን እንድንመርጥ ያስችለናል ፣ እና የተለመደው የራስ-ሰር ጭማሪ መታወቂያዎች።

ሐ * አንድ

ስለዚህ አዲሱ ዲቢኤምኤስ ተወለደ ሐ * አንድሶስት አይነት የአገልጋይ ኖዶችን ያቀፈ፡-

• ማከማቻዎች (ከሞላ ጎደል) መደበኛ የካሳንድራ አገልጋዮች በሃገር ውስጥ ድራይቮች ላይ መረጃን የማከማቸት ኃላፊነት አለባቸው። የመረጃው ጭነት እና መጠን እያደገ ሲሄድ ቁጥራቸው በቀላሉ እስከ አስር እና በመቶዎች ሊደርስ ይችላል።
• የግብይት አስተባባሪዎች - የግብይቶችን አፈፃፀም ያረጋግጡ.
• ደንበኞች የንግድ ሥራዎችን የሚተገብሩ እና ግብይቶችን የሚጀምሩ የመተግበሪያ አገልጋዮች ናቸው። በሺዎች የሚቆጠሩ እንደዚህ ያሉ ደንበኞች ሊኖሩ ይችላሉ።

የሁሉም አይነት አገልጋዮች በጋራ ዘለላ ውስጥ ናቸው፣ እርስ በእርስ ለመግባባት የካሳንድራ የውስጥ መልእክት ፕሮቶኮልን ይጠቀሙ እና ሐሜት። ለክላስተር መረጃ መለዋወጥ. በ Heartbeat እርዳታ አገልጋዮች ስለ የጋራ ውድቀቶች ይማራሉ, አንድ ነጠላ የውሂብ መርሃ ግብር ይጠብቃሉ - ሰንጠረዦች, አወቃቀራቸው እና ማባዛታቸው; የመከፋፈል እቅድ፣ ክላስተር ቶፖሎጂ፣ ወዘተ.

ደንበኞች

ከመደበኛ አሽከርካሪዎች ይልቅ የ Fat Client ሁነታ ጥቅም ላይ ይውላል. እንዲህ ዓይነቱ መስቀለኛ መንገድ መረጃን አያከማችም, ነገር ግን እንደ ጥያቄ ማስፈጸሚያ አስተባባሪ ሆኖ ሊያገለግል ይችላል, ማለትም, ደንበኛው ራሱ የጥያቄዎቹ አስተባባሪ ሆኖ ይሠራል: የማከማቻ ቅጂዎችን ይመርጣል እና ግጭቶችን ይፈታል. ይህ ከርቀት አስተባባሪ ጋር መገናኘትን ከሚጠይቀው መደበኛ አሽከርካሪ የበለጠ አስተማማኝ እና ፈጣን ብቻ ሳይሆን የጥያቄዎችን ስርጭት ለመቆጣጠርም ያስችላል። በደንበኛው ላይ ከተከፈተ ግብይት ውጪ፣ ጥያቄዎች ወደ ማከማቻዎች ይላካሉ። ደንበኛው ግብይት ከከፈተ በግብይቱ ውስጥ ያሉ ሁሉም ጥያቄዎች ወደ ግብይቱ አስተባባሪው ይላካሉ።

ሐ * አንድ የግብይት አስተባባሪ

አስተባባሪው ለ C * አንድ ከባዶ ተግባራዊ ያደረግነው ነው። ግብይቶችን፣ መቆለፊያዎችን እና ግብይቶችን የሚተገበሩበትን ቅደም ተከተል የማስተዳደር ኃላፊነት አለበት።

ለእያንዳንዱ አገልግሎት የሚሰጠው ግብይት አስተባባሪው የጊዜ ማህተም ያመነጫል፡ እያንዳንዱ ተከታይ ከቀዳሚው ግብይት ይበልጣል። በካሳንድራ ያለው የግጭት አፈታት ስርዓት በጊዜ ማህተም ላይ የተመሰረተ ስለሆነ (ከሁለት እርስ በርስ የሚጋጩ መዝገቦች፣ የቅርብ ጊዜው የጊዜ ማህተም አስፈላጊ ነው ተብሎ ይታሰባል) ግጭቱ ሁል ጊዜ የሚፈታው ለቀጣዩ ግብይት በመደገፍ ነው። በዚህም ተግባራዊ አድርገናል። ላምፖርት ሰዓት በተከፋፈለ ሥርዓት ውስጥ ግጭቶችን ለመፍታት ርካሽ መንገድ ነው።

መቆለፊያዎች

ማግለልን ለማረጋገጥ ቀላሉን መንገድ ለመጠቀም ወስነናል - ተስፋ አስቆራጭ ቁልፎች በመዝገቡ ዋና ቁልፍ ላይ። በሌላ አነጋገር፣ በግብይት ውስጥ፣ መዝገብ መጀመሪያ መቆለፍ፣ ከዚያም ማንበብ፣ ማሻሻል እና ማስቀመጥ አለበት። ከተሳካ ቃል ኪዳን በኋላ ብቻ መዝገብ ሊከፈት የሚችለው ተፎካካሪ ግብይቶች ሊጠቀሙበት ይችላሉ።

እንደዚህ አይነት መቆለፊያን መተግበር ባልተከፋፈለ አካባቢ ውስጥ ቀላል ነው. በተከፋፈለ ሥርዓት ውስጥ፣ ሁለት ዋና መንገዶች አሉ፡ ወይ የተከፋፈለ መቆለፊያን በክላስተር ላይ መተግበር፣ ወይም ግብይቶችን በማሰራጨት ተመሳሳይ መዝገብ የሚያካትቱ ግብይቶች በተመሳሳይ አስተባባሪ ሁልጊዜ አገልግሎት ይሰጣሉ።

በእኛ ሁኔታ መረጃው ቀድሞውኑ በ SQL ውስጥ ባሉ የአካባቢ ግብይቶች ቡድኖች መካከል ተሰራጭቷል ፣ የአካባቢ ግብይቶች ቡድኖችን ለአስተባባሪዎች ለመመደብ ተወስኗል-አንድ አስተባባሪ ሁሉንም ግብይቶች ከ 0 እስከ 9 ፣ ሁለተኛው - ከ ማስመሰያ ጋር ያከናውናል ። ከ 10 እስከ 19, ወዘተ. በውጤቱም, እያንዳንዱ የአስተባባሪው ሁኔታ የግብይቱ ቡድን ዋና ይሆናል.

ከዚያም መቆለፊያዎች በአስተባባሪው ማህደረ ትውስታ ውስጥ እንደ ባናል HashMap ሊተገበሩ ይችላሉ.

የአስተባባሪዎች እምቢተኝነት

አንድ አስተባባሪ የግብይቱን ቡድን ብቻ ​​የሚያገለግል በመሆኑ፣ ግብይቱን ለማስፈጸም ተደጋጋሚ ሙከራው በጊዜ ማብቂያ ላይ እንዲሆን የውድቀቱን እውነታ በፍጥነት መወሰን በጣም አስፈላጊ ነው። ይህንን ፈጣን እና አስተማማኝ ለማድረግ፣ ሙሉ ለሙሉ የተጠላለፈ የምልአተ ጉባኤ የመስማት ምት ፕሮቶኮልን ተጠቀምን።

እያንዳንዱ የመረጃ ማዕከል ቢያንስ ሁለት አስተባባሪ አንጓዎችን ያስተናግዳል። በየጊዜው እያንዳንዱ አስተባባሪ ለሌሎች አስተባባሪዎች የልብ ምት መልእክት ይልካልና ስለ አሠራሩ ያሳውቃል እንዲሁም ለመጨረሻ ጊዜ ከየትኞቹ አስተባባሪዎች በክላስተር ውስጥ የልብ ምት መልእክት እንደደረሰው ያሳውቃል።

ከቀሪዎቹ ተመሳሳይ መረጃ እንደ የልብ ትርታ መልእክቶች በመቀበል እያንዳንዱ አስተባባሪ የትኞቹ የክላስተር አንጓዎች እንደሚሠሩ እና እንደማይሠሩ ለራሱ ይወስናል ፣ በኮረም መርሆው ይመራሉ። መደበኛው የመልእክት ደረሰኝ ከኖድ Y፣ ከዚያ፣ Y ይሰራል። በአንጻሩ፣ ብዙሃኑ የጎደሉ መልዕክቶችን ከአንጓ ዋይ እንደዘገበ፣ ያኔ Y አልተሳካም። የሚገርመው፣ ምልአተ ጉባኤው መስቀለኛ መንገድ Xን ከሱ ምንም መልእክት እንደማይቀበል ከነገረው፣ መስቀለኛ መንገድ X እራሱ እንደወደቀ ይቆጥራል።

የልብ ምት መልእክቶች በከፍተኛ ድግግሞሽ፣ በሴኮንድ 20 ጊዜ ያህል፣ በ50 ms ጊዜ ይላካሉ። በጃቫ በቆሻሻ ሰብሳቢው ምክንያት በተነፃፃሪ ለአፍታ ማቆም ጊዜዎች ምክንያት የመተግበሪያ ምላሽ በ50ሚሴ ውስጥ ዋስትና መስጠት ከባድ ነው። ይህንን የምላሽ ጊዜ ማሳካት የቻልነው G1 የቆሻሻ አሰባሳቢን በመጠቀም ነው፣ ይህም ለጂሲ ፋታዎች ቆይታ ዒላማውን እንዲገልጹ ያስችልዎታል። ነገር ግን፣ አንዳንድ ጊዜ፣ በጣም አልፎ አልፎ፣ ሰብሳቢው ባለበት ይቆማል ከ50 ሚሴ በላይ ይሄዳል፣ ይህም ወደ የተሳሳተ ውድቀት ሊያመራ ይችላል። ይህንን ለማስቀረት አስተባባሪው የርቀት መስቀለኛ መንገድ አለመሳካቱን አይዘግብም ከሱ የመጣው የመጀመሪያ የልብ ምት መልእክት ሲጠፋ ብቻ በተከታታይ ብዙ ጠፍተዋል ።ስለዚህ የአስተባባሪው መስቀለኛ መንገድ ውድቀት በ 200 ሚ.

ነገር ግን የትኛው መስቀለኛ መንገድ መሥራት እንዳቆመ በፍጥነት ለመረዳት በቂ አይደለም. ስለ እሱ አንድ ነገር መደረግ አለበት.

ቦታ ማስያዝ

ክላሲካል እቅዱ የሚገምተው ጌታው ካልተሳካለት አንዱን በመጠቀም የአዲሱን ምርጫ ለማስጀመር ነው ። ፋሽን ያለው ሁለንተናዊ አልጎሪዝም. ይሁን እንጂ እንደነዚህ ያሉት ስልተ ቀመሮች በጊዜ ውስጥ መገጣጠም እና የምርጫው ሂደት የሚቆይበት ጊዜ ላይ የታወቁ ችግሮች አሏቸው. ሙሉ በሙሉ በተገናኘ አውታረ መረብ ውስጥ የአስተባባሪ መተኪያ እቅድን በመጠቀም እንደዚህ ያሉ ተጨማሪ መዘግየቶችን ለማስወገድ ችለናል፡

በቡድን 50 ውስጥ ግብይትን መፈጸም እንፈልጋለን እንበል. የመተኪያ እቅድን አስቀድመን እንገልፃለን, ማለትም, የትኞቹ አንጓዎች የቡድን 50 ግብይቶችን በዋና አስተባባሪው ውድቀት ውስጥ ያስፈጽማሉ. ግባችን የመረጃ ማእከል ብልሽት ሲከሰት ስርዓቱን እና ስራውን መቀጠል ነው። የመጀመሪያው መጠባበቂያ ከሌላ የመረጃ ማእከል መስቀለኛ መንገድ እንደሚሆን እና ሁለተኛው መጠባበቂያ ከሦስተኛው መስቀለኛ መንገድ እንደሚሆን እንገልፃለን። ይህ እቅድ አንድ ጊዜ የተመረጠ ነው እና የክላስተር ቶፖሎጂ እስኪቀየር ድረስ አይለወጥም ማለትም አዳዲስ አንጓዎች እስኪገቡ ድረስ (ይህም በጣም አልፎ አልፎ ነው የሚከሰተው)። የአሮጌው ውድቀት ቢከሰት አዲስ ንቁ ጌታን የመምረጥ ቅደም ተከተል ሁል ጊዜ እንደሚከተለው ይሆናል-የመጀመሪያው ተጠባባቂ ንቁ ጌታ ይሆናል ፣ እና መስራቱን ካቆመ ፣ ሁለተኛው ተጠባባቂ ይሆናል።

እንዲህ ዓይነቱ ዕቅድ ከዓለም አቀፋዊ አልጎሪዝም የበለጠ አስተማማኝ ነው, ምክንያቱም አዲስ ጌታን ለማንቃት, የአሮጌውን ውድቀት እውነታ ለመወሰን በቂ ነው.

ግን ደንበኞች የትኛው ጌታ በአሁኑ ጊዜ እየሰራ እንደሆነ እንዴት ይረዱታል? በ 50 ms ውስጥ በሺዎች ለሚቆጠሩ ደንበኞች መረጃን ለመላክ የማይቻል ነው. ይህ ጌታ ከአሁን በኋላ እየሰራ እንዳልሆነ ገና ሳያውቅ አንድ ደንበኛ ግብይት ለመክፈት ጥያቄ ልኮ ሊሆን ይችላል፣ እና ጥያቄው በጊዜ ማብቂያ ላይ ይንጠለጠላል። ይህ እንዳይሆን ደንበኞች በግምታዊ ሁኔታ ለቡድኑ ዋና እና ለሁለቱም መጠባበቂያዎች ግብይት ለመክፈት ጥያቄን ይልካሉ ፣ ግን በዚህ ጊዜ ንቁ የሆነው ጌታው ብቻ ለዚህ ጥያቄ ምላሽ ይሰጣል ። በግብይቱ ውስጥ ያሉ ሁሉም ቀጣይ ግንኙነቶች በደንበኛው የሚከናወኑት ከነቃ ጌታ ጋር ብቻ ነው።

ተጠባባቂ ጌቶች የራሳቸው ላልሆኑ ግብይቶች የተቀበሉትን ጥያቄዎች ለተወሰነ ጊዜ በተከማቹበት ያልተወለዱ ግብይቶች ወረፋ ላይ ያስቀምጣሉ። ገባሪው ጌታ ከሞተ አዲሱ ማስተር ሂደቶችን ከወረፋው ለመክፈት ይጠይቃል እና ለደንበኛው ምላሽ ይሰጣል። ደንበኛው ቀድሞውኑ ከቀድሞው ጌታ ጋር ግብይት ለመክፈት ከቻለ, ሁለተኛው ምላሽ ችላ ይባላል (እና, በግልጽ, እንዲህ ዓይነቱ ግብይት አይጠናቀቅም እና በደንበኛው ይደጋገማል).

ግብይት እንዴት እንደሚሰራ

ደንበኛው ለእንደዚህ አይነት እና ለእንደዚህ ያለ ዋና ቁልፍ ላለው አካል ግብይት ለመክፈት ለአስተባባሪው ጥያቄ ልኮ እንበል። አስተባባሪው ይህንን አካል ቆልፎ በማስታወሻ ውስጥ ባለው የመቆለፊያ ጠረጴዛ ላይ ያስቀምጠዋል. አስፈላጊ ከሆነ አስተባባሪው ይህንን አካል ከሱቁ ያነባል እና የተቀበለውን ውሂብ በአስተባባሪው ማህደረ ትውስታ ውስጥ ወደ ግብይት ሁኔታ ያስቀምጣል።

አንድ ደንበኛ በግብይት ውስጥ ውሂቡን ለመለወጥ ሲፈልግ ህጋዊውን እንዲያስተካክል ለአስተባባሪው ጥያቄ ይልካል እና አስተባባሪው አዲሱን መረጃ በግብይት ሁኔታ ሰንጠረዥ ውስጥ በማህደረ ትውስታ ውስጥ ያስቀምጣል። ይህ ቀረጻውን ያጠናቅቃል - ማከማቻው አልተጻፈም።

አንድ ደንበኛ እንደ ንቁ ግብይት አካል የራሱን የተቀየረ ውሂብ ሲጠይቅ አስተባባሪው እንደሚከተለው ይሠራል።

• መታወቂያው ቀድሞውኑ በግብይቱ ውስጥ ከሆነ ውሂቡ ከማህደረ ትውስታ ይወሰዳል ፣
• በማህደረ ትውስታ ውስጥ ምንም መታወቂያ ከሌለ የጎደለው መረጃ ከማስታወሻ ኖዶች ውስጥ ይነበባል ፣ ቀድሞውኑ በማህደረ ትውስታ ውስጥ ካሉት ጋር ይደባለቃል እና ውጤቱ ወደ ደንበኛው ይመለሳል።

ስለዚህ ደንበኛው የራሱን ለውጦች ማንበብ ይችላል, እና ሌሎች ደንበኞች እነዚህን ለውጦች አያዩም, ምክንያቱም በአስተባባሪው ማህደረ ትውስታ ውስጥ ብቻ ስለሚከማቹ, በካሳንድራ አንጓዎች ውስጥ ገና አይደሉም.

ደንበኛው ቃል ኪዳን ሲልክ፣ አገልግሎቱ በማህደረ ትውስታ ውስጥ የነበረው ሁኔታ በአስተባባሪው በተሰቀለ ባች ውስጥ ይከማቻል እና ወደ ካሳንድራ መደብሮች እንደ መዝገብ ቤት ይላካል። ማከማቻዎቹ ይህ ፓኬጅ በአቶሚክ (ሙሉ በሙሉ) እንዲተገበር አስፈላጊውን ሁሉ ያደርጋሉ እና ለአስተባባሪው ምላሽ ይመልሱ, መቆለፊያዎቹን ይለቃሉ እና የግብይቱን ስኬት ለደንበኛው ያረጋግጣል.

እና መልሶ ለመመለስ አስተባባሪው በግብይቱ ሁኔታ የተያዘውን ማህደረ ትውስታን ነጻ ማድረግ ብቻ ያስፈልገዋል።

ከላይ በተገለጹት ማሻሻያዎች ምክንያት የኤሲዲ መርሆችን ተግባራዊ አድርገናል፡-

• አቶሚዝም. ይህ በሲስተሙ ውስጥ ምንም አይነት ግብይት በከፊል እንደማይስተካከል ዋስትና ነው, ወይም ሁሉም ንዑስ ክዋኔዎቹ ይፈጸማሉ ወይም አንዳቸውም አይፈጸሙም. በእኛ ሁኔታ, ይህ መርህ በካሳንድራ ውስጥ በተመዘገበው ባች ምክንያት ይታያል.
• ወጥነት. እያንዳንዱ የተሳካ ግብይት በትርጉሙ ትክክለኛ ውጤቶችን ብቻ ይፈጽማል። ግብይቱን ከከፈቱ እና አንዳንድ ስራዎችን ካከናወኑ በኋላ ውጤቱ ትክክል እንዳልሆነ ከተረጋገጠ መልሶ መመለስ ይከናወናል።
• ነጠላ. ግብይት ሲፈፀም፣ ትይዩ ግብይቶች በውጤቱ ላይ ተጽዕኖ ማሳደር የለባቸውም። ተመሳሳይ ግብይቶች በአስተባባሪው ላይ አፍራሽ በሆኑ መቆለፊያዎች ተለይተዋል። ከግብይት ውጭ ላሉ ንባቦች፣ በተነበበ ቃል ደረጃ የመገለል መርህ የተከበረ ነው።
• ዘላቂነት።. በዝቅተኛ ደረጃዎች ላይ ያሉ ችግሮች ምንም ቢሆኑም - የስርዓት መቋረጥ, የሃርድዌር ውድቀት - በተሳካ ሁኔታ በተጠናቀቀ ግብይት የተደረጉ ለውጦች ስራውን ከጀመሩ በኋላ መቆጠብ አለባቸው.

በመረጃ ጠቋሚዎች ማንበብ

አንድ ቀላል ጠረጴዛ እንውሰድ፡-

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

መታወቂያ (ዋና ቁልፍ)፣ ባለቤት እና የማሻሻያ ቀን አለው። በጣም ቀላል ጥያቄን ማቅረብ አለብዎት - በባለቤቱ ላይ "ለመጨረሻው ቀን" ከተቀየረበት ቀን ጋር ውሂብን ይምረጡ.

SELECT *
WHERE owner=?
AND modified>?

እንዲህ ዓይነቱን መጠይቅ በፍጥነት ለማስኬድ፣ በሚታወቀው SQL DBMS ውስጥ፣ በአምዶች (ባለቤት፣ የተሻሻለ) ላይ ኢንዴክስ መገንባት ያስፈልግዎታል። አሁን የኤሲአይዲ ዋስትና ስላለን ይህንን በቀላሉ ማድረግ እንችላለን።

ኢንዴክሶች በሲ * አንድ

የመመዝገቢያ መታወቂያ ዋና ቁልፍ የሆነበት ፎቶ ያለበት የመጀመሪያ ሠንጠረዥ አለ።

ለኢንዴክስ፣ C * አንድ የዋናው ሠንጠረዥ ቅጂ የሆነ አዲስ ሠንጠረዥ ይፈጥራል። ቁልፉ ከመረጃ ጠቋሚ አገላለጽ ጋር ተመሳሳይ ነው፣ ነገር ግን ከምንጩ ሠንጠረዥ የመዝገቡን ዋና ቁልፍም ያካትታል፡-

አሁን የ«ባለፉት XNUMX ሰዓታት ውስጥ» ጥያቄ ከሌላ ሠንጠረዥ እንደተመረጠ እንደገና ሊጻፍ ይችላል።

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

የምንጭ ሰንጠረዥ ፎቶዎች እና መረጃ ጠቋሚ i1 መካከል ያለው የውሂብ ወጥነት በአስተባባሪው በራስ-ሰር ይጠበቃል። በመረጃ መርሃ ግብር ላይ ብቻ, ለውጥ ሲደርስ, አስተባባሪው ያመነጫል እና ለውጡን ዋናውን ሰንጠረዥ ብቻ ሳይሆን የቅጂዎችን ለውጦች ያስታውሳል. በመረጃ ጠቋሚ ሠንጠረዥ ምንም ተጨማሪ ድርጊቶች አይከናወኑም, ምዝግብ ማስታወሻዎች አይነበቡም, መቆለፊያዎች ጥቅም ላይ አይውሉም. ማለትም ፣ ኢንዴክሶችን ማከል ሀብቶችን አይፈጅም እና በተግባር ማሻሻያዎችን የመተግበር ፍጥነት ላይ ተጽዕኖ አያሳድርም።

በኤሲአይዲ እርዳታ “እንደ SQL” ኢንዴክሶችን መተግበር ችለናል። በCQL መጠይቅ ቋንቋ ውስጥ ወጥነት ያላቸው፣ ሊለኩ የሚችሉ፣ ፈጣን፣ ሊጣመሩ የሚችሉ እና የተገነቡ ናቸው። የመረጃ ጠቋሚ ድጋፍ በመተግበሪያው ኮድ ላይ ምንም አይነት ለውጥ አያስፈልገውም። በ SQL ውስጥ እንዳለው ሁሉም ነገር ቀላል ነው. እና ከሁሉም በላይ ፣ ኢንዴክሶች በዋናው የግብይት ሠንጠረዥ ላይ የተደረጉ ለውጦችን የማስፈጸሚያ ፍጥነት ላይ ተጽዕኖ አያሳርፉም።

ምንድን ነው የሆነው

ከሶስት አመት በፊት C * አንድን አዘጋጅተን ለንግድ ስራ አስገባነው።

ምን አገባን? በማህበራዊ አውታረመረብ ውስጥ ካሉ በጣም አስፈላጊ የመረጃ ዓይነቶች አንዱ የሆነውን ፎቶግራፎችን ለማቀናበር እና ለማከማቸት ንዑስ ስርዓት ምሳሌ ላይ ይህንን እንገምግመው። ይህ ስለ ፎቶግራፎቹ አካላት ሳይሆን ስለ ሁሉም ዓይነት ሜታ-መረጃዎች ነው. አሁን በኦድኖክላስኒኪ ውስጥ ወደ 20 ቢሊዮን የሚጠጉ እንደዚህ ያሉ መዝገቦች አሉ ፣ ስርዓቱ በሴኮንድ 80 ሺህ ጥያቄዎችን ያንብቡ ፣ በሴኮንድ እስከ 8 ሺህ የኤሲአይዲ ግብይቶች ከመረጃ ማሻሻያ ጋር ይዛመዳሉ።

SQLን በማባዛት ምክንያት = 1 (ነገር ግን በ RAID 10) ስንጠቀም የፎቶ ዲበ መረጃው በከፍተኛ ደረጃ በሚገኙ 32 የማይክሮሶፍት SQL አገልጋይ ማሽኖች (በተጨማሪ 11 መለዋወጫዎች) ላይ ተከማችቷል። እንዲሁም፣ መጠባበቂያ ቅጂዎችን ለማከማቸት 10 አገልጋዮች ተመድበዋል። በድምሩ 50 ውድ መኪኖች። በተመሳሳይ ጊዜ, ስርዓቱ በተሰየመ ጭነት, ያለ ህዳግ ሠርቷል.

ወደ አዲስ ሥርዓት ከተሸጋገርን በኋላ፣ የማባዛት ፋክተር = 3 - በእያንዳንዱ የመረጃ ማዕከል ውስጥ ቅጂ አግኝተናል። ስርዓቱ 63 የካሳንድራ ማከማቻ ኖዶች እና 6 አስተባባሪ ማሽኖች በድምሩ 69 አገልጋዮች አሉት። ነገር ግን እነዚህ ማሽኖች በጣም ርካሽ ናቸው, በአጠቃላይ የ SQL ስርዓት ዋጋ 30% ያህሉ. በዚህ ሁኔታ, ጭነቱ በ 30% ደረጃ ላይ ይቆያል.

C * Oneን በማስተዋወቅ፣ መዘግየትም ቀንሷል፡ በ SQL፣ የመፃፍ ስራ 4,5 ሚሴ ያህል ወስዷል። በ C * አንድ - ወደ 1,6 ሚ.ሜ. የግብይት ጊዜ በአማካይ ከ 40 ms ያነሰ ነው, ቁርጠኝነት በ 2 ms ውስጥ ይጠናቀቃል, የማንበብ እና የመጻፍ ጊዜ በአማካይ 2 ms ነው. 99ኛው ፐርሰንታይል ከ3-3,1 ሚሴ ብቻ ነው፣የጊዜ ማብቂያዎች ቁጥር በ100 ጊዜ ቀንሷል - ሁሉም በሰፊው ግምታዊ አጠቃቀም ምክንያት።

እስከዛሬ፣ አብዛኛዎቹ የ SQL አገልጋይ ኖዶች ተቋርጠዋል፣ አዳዲስ ምርቶች የሚዘጋጁት C * አንድን በመጠቀም ነው። በደመናችን ውስጥ እንዲሰራ C * አንድን አስተካክለናል። አንድ-ደመና, ይህም የአዳዲስ ስብስቦችን ዝርጋታ ለማፋጠን, ውቅረትን ቀላል እና ኦፕሬሽንን በራስ-ሰር ለማድረግ አስችሏል. የምንጭ ኮድ ከሌለ ይህ በጣም አስቸጋሪ እና የተጠለፈ ይሆናል።

አሁን ሌሎች ማከማቻዎቻችንን ወደ ደመና ለማስተላለፍ እየሰራን ነው - ግን ያ ፍጹም የተለየ ታሪክ ነው።

ምንጭ: hab.com