ለNoSQL የውሂብ ሞዴል የመንደፍ ባህሪዎች

መግቢያ

"በቦታው ለመቆየት በምትችለው ፍጥነት መሮጥ አለብህ።
እና የሆነ ቦታ ለመድረስ ቢያንስ ሁለት ጊዜ በፍጥነት መሮጥ አለብዎት!”
(ሐ) አሊስ በዎንደርላንድ

ከተወሰነ ጊዜ በፊት ትምህርት እንድሰጥ ተጠየቅኩ። ተንታኞች ኩባንያችን የውሂብ ሞዴሎችን በመንደፍ ርዕስ ላይ ፣ ምክንያቱም በፕሮጀክቶች ላይ ለረጅም ጊዜ (አንዳንድ ጊዜ ለብዙ ዓመታት) መቀመጥ በ IT ቴክኖሎጂዎች ዓለም ውስጥ በዙሪያችን ምን እየሆነ እንዳለ እናጣለን ። በእኛ ኩባንያ ውስጥ (እንዲያውም እንዲሁ ነው) ብዙ ፕሮጀክቶች የ NoSQL የውሂብ ጎታዎችን አይጠቀሙም (ቢያንስ ለአሁን) ስለዚህ በትምህርቴ ውስጥ የ HBase ምሳሌን በመጠቀም ለእነሱ የተለየ ትኩረት ሰጥቻቸዋለሁ እና የቁሳቁስን አቀራረብ ለእነዚያ ለማቅናት ሞከርኩ ። በጭራሽ ያልተጠቀሙባቸው ሠርተዋል. በተለይም ከበርካታ አመታት በፊት ያነበብኩትን ምሳሌ በመጠቀም አንዳንድ የውሂብ ሞዴል ንድፍ ባህሪያትን አሳይቻለሁ በአማንዲፕ ኩራና “የHB ase Schema ንድፍ መግቢያ” በሚለው መጣጥፍ. ምሳሌዎችን ስመረምር ዋና ዋና ሃሳቦችን ለታዳሚው በተሻለ ሁኔታ ለማስተላለፍ ለተመሳሳይ ችግር ለመፍታት ብዙ አማራጮችን አወዳድሬያለሁ።

በቅርቡ፣ “ከምንም ነገር ውጪ” የሚለውን ጥያቄ እራሴን ጠየቅኩ (በኳራንቲን ውስጥ ያለው ረዥም የግንቦት መጨረሻ ቅዳሜና እሁድ በተለይ ለዚህ ጠቃሚ ነው) የንድፈ ሃሳባዊ ስሌቶች ከተግባር ጋር ምን ያህል ይዛመዳሉ? በእውነቱ ፣ የዚህ ጽሑፍ ሀሳብ የተወለደው በዚህ መንገድ ነው። ከNoSQL ጋር ለብዙ ቀናት ሲሰራ የቆየ ገንቢ ከሱ ምንም አዲስ ነገር ላይማር ይችላል (እና ስለዚህ ወዲያውኑ ግማሹን መጣጥፍ ሊዘለል ይችላል።) ግን ለ ተንታኞችከ NoSQL ጋር በቅርበት ላልሠሩት, ለ HBase የውሂብ ሞዴሎችን የመንደፍ ባህሪያትን መሠረታዊ ግንዛቤ ለማግኘት ጠቃሚ ይሆናል ብዬ አስባለሁ.

ምሳሌ ትንተና

በእኔ አስተያየት የ NoSQL የውሂብ ጎታዎችን መጠቀም ከመጀመርዎ በፊት በጥንቃቄ ማሰብ እና ጥቅሞቹን እና ጉዳቶቹን ማመዛዘን ያስፈልግዎታል. ብዙውን ጊዜ ችግሩ በተለምዷዊ DBMSs በመጠቀም ሊፈታ ይችላል። ስለዚህ, ያለ ጉልህ ምክንያቶች NoSQL ን አለመጠቀም የተሻለ ነው. ሆኖም የ NoSQL ዳታቤዝ ለመጠቀም ከወሰኑ፣ እዚህ ያሉት የንድፍ አቀራረቦች በተወሰነ መልኩ የተለያዩ መሆናቸውን ግምት ውስጥ ማስገባት አለብዎት። በተለይም አንዳንዶቹ ከዚህ ቀደም ተዛማጅ ዲቢኤምኤስን ብቻ ላስተናገዱ (እንደ እኔ ምልከታ) ያልተለመዱ ሊሆኑ ይችላሉ። ስለዚህ, በ "ግንኙነት" ዓለም ውስጥ, ብዙውን ጊዜ የችግሩን ጎራ በመቅረጽ እንጀምራለን, እና ከዚያ በኋላ, አስፈላጊ ከሆነ, ሞዴሉን መደበኛ ያድርጉት. በ NoSQL ውስጥ እኛ ከመረጃ ጋር አብሮ ለመስራት የሚጠበቁ ሁኔታዎችን ወዲያውኑ ግምት ውስጥ ማስገባት አለበት። እና መጀመሪያ ላይ መረጃውን መደበኛ ያድርጉት። በተጨማሪም, ሌሎች በርካታ ልዩነቶች አሉ, ከዚህ በታች ይብራራሉ.

መስራታችንን የምንቀጥልበትን የሚከተለውን “ሰው ሰራሽ” ችግርን እንመልከት፡-

ለአንዳንድ ረቂቅ ማህበራዊ አውታረ መረቦች ተጠቃሚዎች ጓደኞች ዝርዝር የማከማቻ መዋቅር መንደፍ አስፈላጊ ነው. ለማቃለል ሁሉም ግንኙነቶቻችን የሚመሩ ናቸው ብለን እንገምታለን (በኢንስታግራም ላይ እንዳለ እንጂ Linkedin አይደለም)። አወቃቀሩ ውጤታማ በሆነ መንገድ እንዲሰሩ መፍቀድ አለበት፡-

• ተጠቃሚ A ተጠቃሚ B ያነብ እንደሆነ (የንባብ ስርዓተ ጥለት) የሚለውን ጥያቄ ይመልሱ
• ከተጠቃሚ B (የውሂብ ለውጥ አብነት) የተጠቃሚ ምዝገባ/ደንበኝነት ምዝገባ ሲቋረጥ ግንኙነቶችን ማከል/ማስወገድ ፍቀድ

እርግጥ ነው, ችግሩን ለመፍታት ብዙ አማራጮች አሉ. በመደበኛ የግንኙነት ዳታቤዝ ውስጥ፣ በቀላሉ የግንኙነቶችን ሰንጠረዥ እንሰራለን (ምናልባትም የተጠቃሚ ቡድንን ማከማቸት ካለብን ይገለጻል፡ ቤተሰብ፣ ስራ፣ ወዘተ. ይህንን “ጓደኛ” የሚያካትት) እና ለማመቻቸት። የመዳረሻ ፍጥነት ኢንዴክሶችን/መከፋፈልን ይጨምራል። ምናልባትም የመጨረሻው ጠረጴዛ እንደዚህ ያለ ነገር ይመስላል

የተጠቃሚው መለያ
ጓደኛ_መታወቂያ

ቫሳ
ፔትያ።

ቫሳ
ኦሊያ

ከዚህ በኋላ፣ ግልጽነት እና የተሻለ ግንዛቤ ለማግኘት፣ ከመታወቂያ ይልቅ ስሞችን እጠቁማለሁ።

በHBase ሁኔታ፣ ያንን እናውቃለን፡-

• የተሟላ የሠንጠረዥ ቅኝት የማያመጣ ውጤታማ ፍለጋ ይቻላል በቁልፍ ብቻ
  • በእውነቱ ለዛ ነው ለብዙዎች የታወቁ የ SQL መጠይቆችን ለእንደዚህ ያሉ የውሂብ ጎታዎች መጻፍ መጥፎ ሀሳብ ነው ። በቴክኒካል፣ በእርግጥ፣ የSQL ጥያቄን ከተመሳሳዩ Impala ወደ HBase ከ Joins እና ከሌሎች አመክንዮዎች ጋር መላክ ይችላሉ፣ ግን ምን ያህል ውጤታማ ይሆናል...

ስለዚህ የተጠቃሚ መታወቂያውን እንደ ቁልፍ ለመጠቀም እንገደዳለን። እና “የጓደኞች መታወቂያዎችን የት እና እንዴት ማከማቸት?” በሚለው ርዕስ ላይ የመጀመሪያ ሀሳቤ ምናልባት በአምዶች ውስጥ እነሱን ለማከማቸት ሀሳብ. ይህ በጣም ግልጽ እና "የዋህ" አማራጭ እንደዚህ ያለ ነገር ይመስላል (እንጠራው አማራጭ 1 (ነባሪ)ለተጨማሪ ማጣቀሻ፡-

RowKey
ዓምዶች

ቫሳ
1: ፔትያ
2፡ ኦሊያ
3፡ ዳሻ

ፔትያ።
1: ማሻ
2፡ ቫሳያ

እዚህ እያንዳንዱ መስመር ከአንድ የአውታረ መረብ ተጠቃሚ ጋር ይዛመዳል። ዓምዶቹ ስሞች አሏቸው: 1, 2, ... - እንደ ጓደኞች ብዛት, እና የጓደኞች መታወቂያዎች በአምዶች ውስጥ ይቀመጣሉ. እያንዳንዱ ረድፍ የተለያየ የአምዶች ብዛት እንደሚኖረው ልብ ሊባል የሚገባው ጉዳይ ነው። ከላይ ባለው ሥዕል ላይ ባለው ምሳሌ አንድ ረድፍ ሶስት ዓምዶች (1 ፣ 2 እና 3) ያሉት ሲሆን ሁለተኛው ደግሞ ሁለት (1 እና 2) ብቻ ነው - እዚህ እኛ ራሳችን ተዛማጅ የውሂብ ጎታዎች የሌሉትን ሁለት የ HBase ንብረቶችን ተጠቀምን።

• የአምዶችን ስብጥር በተለዋዋጭ የመቀየር ችሎታ (ጓደኛን ያክሉ -> አምድ ይጨምሩ ፣ ጓደኛን ያስወግዱ -> አምድ ይሰርዙ)
• የተለያዩ ረድፎች የተለያዩ የአምድ ጥንቅሮች ሊኖራቸው ይችላል።

ከተግባሩ መስፈርቶች ጋር መጣጣምን የእኛን መዋቅር እንፈትሽ፡-

• የንባብ ውሂብ: ቫሳያ ለኦሊያ ደንበኝነት መመዝገቡን ለመረዳት፣ መቀነስ አለብን መላውን መስመር በቁልፍ RowKey = "Vasya" እና በእነሱ ውስጥ ኦሊያን "እስከምንገናኝ" ድረስ በአምድ እሴቶቹ ደርድር። ወይም የሁሉንም ዓምዶች እሴቶች በመድገም ኦሊያን “አላሟላም” እና መልሱን በውሸት ይመልሱ።
• ውሂብን ማረም፡ ጓደኛ ማከል: ለተመሳሳይ ተግባር ደግሞ መቀነስ አለብን መላውን መስመር የጓደኞቹን ጠቅላላ ቁጥር ለማስላት ቁልፉን RowKey = "Vasya" በመጠቀም. የአዲሱን ጓደኛ መታወቂያ ለመጻፍ የምንፈልገውን የአምድ ቁጥር ለመወሰን ይህ አጠቃላይ የጓደኞች ብዛት እንፈልጋለን።
• ውሂብ መቀየር፡ ጓደኛን መሰረዝ:
  • መቀነስ ያስፈልጋል መላውን መስመር በቁልፍ RowKey = "Vasya" እና የሚሰረዘው ጓደኛ የተመዘገበበትን ለማግኘት በአምዶች ውስጥ መደርደር;
  • በመቀጠል, ጓደኛን ከሰረዝን በኋላ, በቁጥራቸው ላይ "ክፍተቶችን" ላለማግኘት ሁሉንም ውሂብ ወደ አንድ አምድ "መቀየር" ያስፈልገናል.

በ“ሁኔታዊ አተገባበር” በኩል መተግበር የሚያስፈልገን እነዚህ ስልተ ቀመሮች ምን ያህል ውጤታማ እንደሚሆኑ እንገምግም ኦ-ምልክት. የኛን መላምታዊ ማህበራዊ አውታረ መረብ መጠን እንደ n እንጥቀስ። ከዚያም አንድ ተጠቃሚ ሊኖረው የሚችለው ከፍተኛው የጓደኛ ብዛት (n-1) ነው። በኦ-ምልክቶች አጠቃቀም ማዕቀፍ ውስጥ አስፈላጊ ስላልሆነ ይህንን (-1) ለኛ ዓላማ ልንዘነጋው እንችላለን።

• የንባብ ውሂብ: መላውን መስመር መቀነስ እና በገደቡ ውስጥ ባሉት ሁሉም ዓምዶች ውስጥ መድገሙ አስፈላጊ ነው. ይህ ማለት የወጪዎች ከፍተኛ ግምት በግምት O(n) ይሆናል ማለት ነው።
• ውሂብን ማረም፡ ጓደኛ ማከል: የጓደኞችን ብዛት ለመወሰን የረድፉ አምዶችን ሁሉ መድገም ያስፈልግዎታል እና ከዚያ አዲስ አምድ => ኦ(n) ያስገቡ።
• ውሂብ መቀየር፡ ጓደኛን መሰረዝ:
  • ከመደመር ጋር ተመሳሳይ - በገደቡ ውስጥ ያሉትን ሁሉንም አምዶች ማለፍ ያስፈልግዎታል => ኦ (n)
  • ዓምዶቹን ካስወገዱ በኋላ "ማንቀሳቀስ" ያስፈልገናል. ይህንን "በፊት ላይ" ተግባራዊ ካደረጉ, በገደቡ ውስጥ እስከ (n-1) ስራዎች ያስፈልግዎታል. ግን እዚህ እና በተጨማሪ በተግባራዊው ክፍል የተለየ አቀራረብን እንጠቀማለን ፣ ይህም ለተወሰኑ ኦፕሬሽኖች “የይስሙላ-shift” ተግባራዊ ይሆናል - ማለትም ፣ ምንም ይሁን ምን የማያቋርጥ ጊዜ በእሱ ላይ ይውላል። ይህ ቋሚ ጊዜ (ኦ(2) ትክክለኛ መሆን) ከኦ(n) ጋር ሲነጻጸር ችላ ሊባል ይችላል። አቀራረቡ ከዚህ በታች ባለው ስእል ላይ ተገልጿል፡ በቀላሉ ውሂቡን ከ“የመጨረሻው” አምድ ወደ ሚያስወግደው ውሂቡ እንገለብጣለን እና የመጨረሻውን አምድ እንሰርዛለን።
    

በአጠቃላይ፣ በሁሉም ሁኔታዎች የO(n) አስምፕቶቲክ ስሌት ውስብስብነት አግኝተናል።
ሁልጊዜ ማለት ይቻላል ሙሉውን ረድፍ ከመረጃ ቋቱ ውስጥ ማንበብ እንዳለብን እና ከሶስቱ ውስጥ በሁለት አጋጣሚዎች ሁሉንም አምዶች ውስጥ ለማለፍ እና የጓደኛዎችን አጠቃላይ ቁጥር ለማስላት እንደምናነብ አስቀድመህ አስተውለህ ይሆናል። ስለዚህ, የማመቻቸት ሙከራ እንደመሆንዎ መጠን የእያንዳንዱን የአውታረ መረብ ተጠቃሚ ጓደኞች ጠቅላላ ቁጥር የሚያከማች የ "መቁጠር" አምድ ማከል ይችላሉ. በዚህ ሁኔታ, የጓደኛዎችን ጠቅላላ ቁጥር ለማስላት ሙሉውን ረድፍ ማንበብ አንችልም, ግን አንድ "መቁጠር" አምድ ብቻ ያንብቡ. ዋናው ነገር መረጃን በሚጠቀሙበት ጊዜ "መቁጠር" ማዘመንን መርሳት የለብዎትም. ያ። ተሻሽለናል። አማራጭ 2 (ቁጥር)

RowKey
ዓምዶች

ቫሳ
1: ፔትያ
2፡ ኦሊያ
3፡ ዳሻ
ቆጠራ፡ 3

ፔትያ።
1: ማሻ
2፡ ቫሳያ

ቆጠራ፡ 2

ከመጀመሪያው አማራጭ ጋር ሲነጻጸር፡-

• የንባብ ውሂብ"ቫስያ ኦሊያን ያነብባል?" ለሚለው ጥያቄ መልስ ለማግኘት. ምንም አልተለወጠም => ኦ (n)
• ውሂብን ማረም፡ ጓደኛ ማከል: አዲስ ጓደኛ ማስገባትን ቀለል አድርገነዋል ፣ ምክንያቱም አሁን ሙሉውን መስመር ማንበብ እና በአምዶቹ ላይ መደጋገም አያስፈልገንም ፣ ግን የ “መቁጠር” አምድ ፣ ወዘተ ዋጋ ብቻ ማግኘት እንችላለን ። አዲስ ጓደኛ ለማስገባት ወዲያውኑ የአምድ ቁጥሩን ይወስኑ. ይህ ወደ ኦ(1) ስሌት ውስብስብነት እንዲቀንስ ያደርጋል።
• ውሂብ መቀየር፡ ጓደኛን መሰረዝ: ጓደኛን ስንሰርዝ፣ ውሂቡን አንድ ሕዋስ ወደ ግራ "በሚቀይሩበት ጊዜ" የ I/O ስራዎችን ቁጥር ለመቀነስ ይህን አምድ መጠቀም እንችላለን። ነገር ግን መሰረዝ ያለበትን ለማግኘት በአምዶች ውስጥ የመድገም አስፈላጊነት አሁንም ይቀራል ፣ ስለዚህ => ​​ኦ (n)
• በሌላ በኩል ፣ አሁን መረጃን ሲያዘምን ሁል ጊዜ “መቁጠር” የሚለውን አምድ ማዘመን አለብን ፣ ግን ይህ የማያቋርጥ ጊዜ ይወስዳል ፣ ይህም በኦ-ምልክቶች ማዕቀፍ ውስጥ ችላ ሊባል ይችላል ።

በአጠቃላይ፣ አማራጭ 2 ትንሽ የተሻለ ይመስላል፣ ነገር ግን የበለጠ እንደ “ከአብዮት ይልቅ ዝግመተ ለውጥ” ነው። "አብዮት" ለማድረግ ያስፈልገናል አማራጭ 3 (ኮል).
ሁሉንም ነገር "ወደላይ" እናዞር: እንመድባለን የአምድ ስም የተጠቃሚ መታወቂያ! በአምዱ ውስጥ የሚፃፈው ነገር ከአሁን በኋላ ለእኛ አስፈላጊ አይደለም, ቁጥር 1 ይሁን (በአጠቃላይ, ጠቃሚ ነገሮች እዚያ ሊቀመጡ ይችላሉ, ለምሳሌ, "ቤተሰብ / ጓደኞች / ወዘተ") ቡድን. ይህ አካሄድ ከNoSQL የውሂብ ጎታዎች ጋር የመሥራት ልምድ የሌለውን ያልተዘጋጀውን “ምእመናን” ሊያስደንቅ ይችላል፣ ነገር ግን በትክክል በዚህ ተግባር ውስጥ የHBaseን አቅም በብቃት እንድትጠቀም የሚፈቅድልህ ይህ አካሄድ ነው።

RowKey
ዓምዶች

ቫሳ
ፔትያ: 1
ኦሊያ፡ 1
ዳሻ፡ 1

ፔትያ።
ማሻ፡ 1
ቫሳ: 1

እዚህ ብዙ ጥቅሞችን በአንድ ጊዜ እናገኛለን. እነሱን ለመረዳት አዲሱን መዋቅር እንመርምር እና የስሌት ውስብስብነቱን እንገምታለን።

• የንባብ ውሂብ: ቫሳያ ለኦሊያ ተመዝግቧል ወይ የሚለውን ጥያቄ ለመመለስ አንድ አምድ “ኦሊያ” ማንበብ በቂ ነው፡ እዚያ ካለ መልሱ እውነት ነው፣ ካልሆነ መልሱ እውነት ነው - ውሸት => ኦ(1)
• ውሂብን ማረም፡ ጓደኛ ማከልጓደኛ ማከል፡ አዲስ አምድ ጨምር "የጓደኛ መታወቂያ" => ኦ(1)
• ውሂብ መቀየር፡ ጓደኛን መሰረዝየጓደኛ መታወቂያ አምድ ብቻ ያስወግዱ => ኦ(1)

እንደሚመለከቱት ፣ የዚህ የማከማቻ ሞዴል ጉልህ ጥቅም እኛ በምንፈልጋቸው ሁሉም ሁኔታዎች ውስጥ አንድ አምድ ብቻ እንሰራለን ፣ ሙሉውን ረድፍ ከመረጃ ቋቱ ውስጥ ከማንበብ እና በተጨማሪ ፣ ሁሉንም የዚህ ረድፍ አምዶች መዘርዘር ነው። እዚያ ማቆም እንችላለን ፣ ግን ...

ዳታቤዙን በሚደርሱበት ጊዜ አፈጻጸምን በማሳደግ እና የI/O ስራዎችን በመቀነስ መንገዱ ግራ ሊጋቡ እና ትንሽ ወደፊት መሄድ ይችላሉ። ሙሉውን የግንኙነት መረጃ በቀጥታ በረድፍ ቁልፉ ውስጥ ብናከማችስ? ማለትም፣ ቁልፉን ጥንቅር እንደ userID.friendID አድርግ? በዚህ አጋጣሚ የመስመሩን አምዶች ጨርሶ ማንበብ የለብንም (አማራጭ 4(ረድፍ)):

RowKey
ዓምዶች

Vasya.Petya
ፔትያ: 1

Vasya.Olya
ኦሊያ፡ 1

Vasya.ዳሻ
ዳሻ፡ 1

ፔትያ.ማሻ
ማሻ፡ 1

ፔትያ.ቫስያ
ቫሳ: 1

በግልጽ ለማየት እንደሚቻለው, በእንደዚህ አይነት መዋቅር ውስጥ ያሉ ሁሉንም የውሂብ መጠቀሚያ ሁኔታዎች ግምገማ, ልክ እንደ ቀድሞው ስሪት, O (1) ይሆናል. ከአማራጭ 3 ጋር ያለው ልዩነት በመረጃ ቋቱ ውስጥ ባለው የ I/O ስራዎች ቅልጥፍና ላይ ብቻ ይሆናል።

መልካም, የመጨረሻው "ቀስት". በአማራጭ 4 ውስጥ የረድፍ ቁልፉ ተለዋዋጭ ርዝመት ሊኖረው እንደሚችል ለመረዳት ቀላል ነው, ይህ ምናልባት አፈፃፀሙን ሊጎዳ ይችላል (እዚህ ላይ HBase በባይት እና በሰንጠረዦች ውስጥ ያሉ ረድፎች በቁልፍ እንደሚደረደሩ እናስታውሳለን). በተጨማሪም በአንዳንድ ሁኔታዎች ላይ ማስተናገድ ሊያስፈልገው የሚችል መለያ አለን። ይህንን ተጽዕኖ ለማስወገድ ከተጠቃሚ መታወቂያ እና ከጓደኛ መታወቂያ ሀሽ መጠቀም ይችላሉ ፣ እና ሁለቱም hashes የማያቋርጥ ርዝመት ስለሚኖራቸው ፣ ያለ መለያየት በቀላሉ ማገናኘት ይችላሉ። ከዚያ በሰንጠረዡ ውስጥ ያለው መረጃ ይህን ይመስላል (አማራጭ 5 (ሃሽ)):

RowKey
ዓምዶች

dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
ፔትያ: 1

dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
ኦሊያ፡ 1

dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
ዳሻ፡ 1

1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
ማሻ፡ 1

1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
ቫሳ: 1

በምንመረምራቸው ሁኔታዎች ውስጥ ከእንደዚህ ዓይነት መዋቅር ጋር አብሮ የመስራት ስልተ-ቀመር ውስብስብነት ከአማራጭ 4 - ማለትም ኦ(1) ጋር ተመሳሳይ እንደሚሆን ግልጽ ነው።
በጠቅላላው፣ ሁሉንም የሂሳብ ውስብስብነት ግምቶቻችንን በአንድ ሠንጠረዥ ውስጥ እናጠቃልል።

ጓደኛ መጨመር
ጓደኛን በመፈተሽ ላይ
ጓደኛን ማስወገድ

አማራጭ 1 (ነባሪ)
ሆይ (n)
ሆይ (n)
ሆይ (n)

አማራጭ 2 (ቁጥር)
ኦ (1)
ሆይ (n)
ሆይ (n)

አማራጭ 3 (አምድ)
ኦ (1)
ኦ (1)
ኦ (1)

አማራጭ 4 (ረድፍ)
ኦ (1)
ኦ (1)
ኦ (1)

አማራጭ 5 (ሃሽ)
ኦ (1)
ኦ (1)
ኦ (1)

እንደሚመለከቱት ፣ አማራጮች 3-5 በጣም ተመራጭ እና በንድፈ-ሀሳብ ሁሉንም አስፈላጊ የውሂብ አጠቃቀም ሁኔታዎች በቋሚነት ጊዜ ውስጥ መፈጸሙን ያረጋግጣሉ። በተግባራችን ሁኔታዎች ውስጥ የተጠቃሚውን ጓደኞች ዝርዝር ለማግኘት ምንም አይነት ግልጽ መስፈርት የለም, ነገር ግን በእውነተኛ የፕሮጀክት እንቅስቃሴዎች ውስጥ, እንደ ጥሩ ተንታኞች, እንዲህ አይነት ተግባር ሊፈጠር እንደሚችል እና "መተንበይ" ጥሩ ይሆናል. "ገለባ ዘርጋ" ስለዚህ የእኔ ሀዘኔታ ከአማራጭ 3 ጎን ነው ። ግን በእውነተኛ ፕሮጀክት ውስጥ ይህ ጥያቄ ቀድሞውኑ በሌሎች መንገዶች ሊፈታ ይችል ነበር ፣ ስለሆነም አጠቃላይ የችግሩ አጠቃላይ እይታ ከሌለ ፣ ባይሆን ይሻላል ። የመጨረሻ መደምደሚያዎች.

የሙከራው ዝግጅት

ከላይ የተጠቀሱትን የንድፈ ሃሳባዊ ክርክሮች በተግባር መሞከር እፈልጋለሁ - ይህ በረጅም ቅዳሜና እሁድ የተነሳው የሃሳቡ ግብ ነበር። ይህንን ለማድረግ የኛን "ሁኔታዊ አፕሊኬሽን" የስራ ፍጥነትን መገምገም አስፈላጊ ነው በሁሉም የተገለጹ ሁኔታዎች የውሂብ ጎታውን ለመጠቀም, እንዲሁም በዚህ ጊዜ እየጨመረ የመጣውን የማህበራዊ አውታረመረብ (n). እኛን የሚስብ እና በሙከራው ወቅት የምንለካው የዒላማ ግቤት አንድ "የንግድ ሥራን" ለማከናወን "ሁኔታዊ መተግበሪያ" ያሳለፈው ጊዜ ነው. “የንግድ ግብይት” ስንል ከሚከተሉት ውስጥ አንዱን ማለታችን ነው።

• አንድ አዲስ ጓደኛ ማከል
• ተጠቃሚ A የተጠቃሚ B ጓደኛ መሆኑን ማረጋገጥ
• አንድ ጓደኛን ማስወገድ

ስለዚህ ፣ በመጀመሪያ መግለጫው ውስጥ የተዘረዘሩትን መስፈርቶች ከግምት ውስጥ በማስገባት ፣ የማረጋገጫ ሁኔታው ​​እንደሚከተለው ይወጣል ።

• የውሂብ ቀረጻ. በዘፈቀደ የመጠን የመጀመሪያ አውታረ መረብ ያመነጫል። ወደ “እውነተኛው ዓለም” ለመቅረብ፣ እያንዳንዱ ተጠቃሚ ያለው የጓደኛ ብዛት እንዲሁ በዘፈቀደ ተለዋዋጭ ነው። የእኛ "ሁኔታዊ መተግበሪያ" ሁሉንም የመነጨ ውሂብ ወደ HBase የሚጽፍበትን ጊዜ ይለኩ። ከዚያ የተገኘውን ጊዜ በተጨመሩ ጓደኞች ብዛት ይከፋፍሉት - ለአንድ “የንግድ ሥራ” አማካይ ጊዜ የምናገኘው በዚህ መንገድ ነው ።
• የንባብ ውሂብ. ለእያንዳንዱ ተጠቃሚ ተጠቃሚው ለእነሱ ተመዝግቧል ወይም አልተመዘገበም መልስ ለማግኘት የሚያስፈልግዎትን "የግለሰቦች" ዝርዝር ይፍጠሩ። የዝርዝሩ ርዝመት = በግምት የተጠቃሚው ጓደኞች ብዛት, እና ከተረጋገጡት ጓደኞች መካከል ግማሽ የሚሆኑት መልሱ "አዎ" መሆን አለበት, እና ለሌላኛው ግማሽ - "አይ" መሆን አለበት. ቼኩ የሚከናወነው በቅደም ተከተል ነው "አዎ" እና "አይ" የሚሉት መልሶች ተለዋጭ (ማለትም በእያንዳንዱ ሁለተኛ ሁኔታ ለአማራጮች 1 እና 2 ሁሉንም የመስመሩን አምዶች ማለፍ አለብን)። አጠቃላይ የፍተሻ ጊዜ በአንድ ርዕሰ ጉዳይ አማካኝ የማጣሪያ ጊዜ ለማግኘት በተሞከሩት ጓደኞች ብዛት ይከፋፈላል።
• ውሂብን በመሰረዝ ላይ. ሁሉንም ጓደኞች ከተጠቃሚው ያስወግዱ። ከዚህም በላይ የስረዛ ትዕዛዙ በዘፈቀደ ነው (ይህም ውሂቡን ለመቅዳት ጥቅም ላይ የዋለውን የመጀመሪያውን ዝርዝር "በማዋሃድ" እናደርጋለን). ጠቅላላ የፍተሻ ጊዜ በቼክ አማካይ ጊዜ ለማግኘት በተወገዱ ጓደኞች ብዛት ይከፈላል.

ሁኔታዎች እያደገ ሲሄድ ጊዜ እንዴት እንደሚለዋወጥ ለማየት ለእያንዳንዱ የ 5 የውሂብ ሞዴል አማራጮች እና ለተለያዩ የማህበራዊ አውታረ መረቦች መጠኖች መሮጥ አለባቸው። በአንድ n ውስጥ፣ በኔትወርኩ ውስጥ ያሉ ግንኙነቶች እና የተጠቃሚዎች ዝርዝር ለመፈተሽ፣ ለ5ቱም አማራጮች አንድ አይነት መሆን አለባቸው።
ለተሻለ ግንዛቤ ከዚህ በታች ለ n= 5 የመነጨ ዳታ ምሳሌ ነው። የተፃፈው "ጄነሬተር" ሶስት የመታወቂያ መዝገበ ቃላትን እንደ ውፅዓት ያወጣል።

• የመጀመሪያው ለመክተት ነው
• ሁለተኛው ለመፈተሽ ነው
• ሦስተኛው - ለመሰረዝ

{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей

{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов

{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей

እንደሚመለከቱት፣ ለመፈተሽ በመዝገበ-ቃላቱ ውስጥ ያሉት ከ10 የሚበልጡ መታወቂያዎች በሙሉ በትክክል መልሱ ሐሰት ናቸው። "ጓደኞችን" ማስገባት, መፈተሽ እና መሰረዝ በትክክል በመዝገበ-ቃላቱ ውስጥ በተጠቀሰው ቅደም ተከተል ይከናወናሉ.

ሙከራው የተካሄደው ኤች.ቢ.ሴ በአንድ ዶከር ኮንቴይነር ውስጥ በሚሰራበት ዊንዶውስ 10 በሚሰራ ላፕቶፕ ላይ ሲሆን በሌላኛው ደግሞ ፒቲን ከጁፒተር ኖትቡክ ጋር እየሰራ ነበር። ዶከር 2 ሲፒዩ ኮር እና 2 ጂቢ ራም ተመድቧል። ሁሉም አመክንዮዎች፣ ልክ እንደ "ሁኔታዊ አፕሊኬሽን" እና "የቧንቧ መስመር" ለሙከራ መረጃን ለማመንጨት እና ጊዜን ለመለካት በፓይዘን ውስጥ ተጽፈዋል። ቤተ መፃህፍቱ ከHBase ጋር ለመስራት ያገለግል ነበር። Happybase, hashes (MD5) ለማስላት ለአማራጭ 5 - hashlib

የአንድ የተወሰነ ላፕቶፕ የኮምፒዩተር ሃይል ግምት ውስጥ በማስገባት ለ n = 10, 30, ... ማስጀመር በሙከራ ተመርጧል. 170 - የሙሉ የሙከራ ዑደት አጠቃላይ የስራ ጊዜ (ሁሉም አማራጮች ለሁሉም አማራጮች) የበለጠ ወይም ያነሰ ምክንያታዊ እና በአንድ የሻይ ግብዣ ጊዜ (በአማካይ 15 ደቂቃዎች) ተስማሚ በሆነ ጊዜ።

እዚህ ላይ በዚህ ሙከራ ውስጥ ፍጹም የአፈፃፀም አሃዞችን በዋናነት እየገመገምን እንዳልሆነ ልብ ማለት ያስፈልጋል. የተለያዩ ሁለት አማራጮች አንጻራዊ ንጽጽር እንኳን ሙሉ በሙሉ ትክክል ላይሆን ይችላል። አሁን በ n ላይ በመመስረት የጊዜ ለውጥ ተፈጥሮ ላይ ፍላጎት አለን ፣ ከላይ ያለውን የ “የሙከራ አቋም” ውቅር ከግምት ውስጥ በማስገባት ፣ የዘፈቀደ እና ሌሎች ምክንያቶች ተጽዕኖ “የተጸዳ” የጊዜ ግምቶችን ማግኘት በጣም ከባድ ነው ( እና እንደዚህ አይነት ተግባር አልተዘጋጀም).

የሙከራ ውጤት

የመጀመሪያው ፈተና የጓደኛዎችን ዝርዝር ለመሙላት ያሳለፈው ጊዜ እንዴት እንደሚለወጥ ነው. ውጤቱ ከታች ባለው ግራፍ ውስጥ ነው.

አማራጮች 3-5, እንደተጠበቀው, ከሞላ ጎደል ቋሚ "የንግድ ግብይት" ጊዜን ያሳያሉ, ይህም በኔትወርኩ መጠን እድገት እና በአፈፃፀም ላይ የማይለይ ልዩነት ላይ የተመሰረተ አይደለም.
አማራጭ 2 ደግሞ የማያቋርጥ, ነገር ግን በትንሹ የከፋ አፈጻጸም ያሳያል, ከአማራጮች 2-3 ጋር ሲነጻጸር በትክክል 5 ጊዜ ማለት ይቻላል. እና ይህ ከንድፈ-ሀሳብ ጋር ስለሚዛመድ ከመደሰት በስተቀር - በዚህ ስሪት ውስጥ የ I/O ስራዎች ወደ / ከ HBase በትክክል 2 እጥፍ ይበልጣል። ይህ የእኛ የሙከራ አግዳሚ ወንበር በመርህ ደረጃ ጥሩ ትክክለኛነትን እንደሚያቀርብ ቀጥተኛ ያልሆነ ማስረጃ ሆኖ ሊያገለግል ይችላል።
አማራጭ 1 እንዲሁ እንደተጠበቀው ፣ በጣም ቀርፋፋ ሆኖ ተገኝቷል እና እርስ በእርስ በመደመር ጊዜ ውስጥ በኔትወርኩ መጠን ላይ የሚያሳልፈውን የመስመር ጭማሪ ያሳያል።
አሁን የሁለተኛውን ፈተና ውጤት እንመልከት.

አማራጮች 3-5 እንደገና እንደተጠበቀው - ቋሚ ጊዜ, ከአውታረ መረቡ መጠን ነጻ. አማራጮች 1 እና 2 የአውታረ መረቡ መጠን ሲጨምር እና ተመሳሳይ አፈፃፀም በጊዜ ውስጥ መስመራዊ ጭማሪ ያሳያሉ። ከዚህም በላይ፣ አማራጭ 2 ትንሽ ቀርፋፋ ይሆናል - ተጨማሪውን “መቁጠር” አምድ ማረም እና ማካሄድ ስለሚያስፈልገው፣ n እያደገ ሲሄድ የበለጠ ትኩረት የሚስብ ይሆናል። ነገር ግን የዚህ ንፅፅር ትክክለኛነት በአንጻራዊነት ዝቅተኛ ስለሆነ አሁንም ማንኛውንም መደምደሚያ ከማድረግ እቆጠባለሁ. በተጨማሪም, እነዚህ ሬሾዎች (የትኛው አማራጭ, 1 ወይም 2, ፈጣን ነው) ከሩጫ ወደ ሩጫ (የጥገኝነት ባህሪን በመጠበቅ እና "አንገትና አንገት እየሄዱ").

ደህና, የመጨረሻው ግራፍ የማስወገድ ሙከራ ውጤት ነው.

እንደገና, እዚህ ምንም አያስደንቅም. አማራጮች 3-5 በቋሚ ጊዜ መወገድን ያከናውናሉ.
በተጨማሪም ፣ የሚገርመው ፣ አማራጮች 4 እና 5 ፣ ከቀደምት ሁኔታዎች በተለየ ፣ ከአማራጭ 3 በተሻለ ሁኔታ በትንሹ የከፋ አፈፃፀም ያሳያሉ።

አማራጮች 1 እና 2, እንደተጠበቀው, የጊዜ መጨመርን ያሳያሉ. በተመሳሳይ ጊዜ, አማራጭ 2 ከአማራጭ 1 በተከታታይ ቀርፋፋ ነው - ተጨማሪ የ I / O ክዋኔ ምክንያት የቆጠራውን አምድ "ለመጠበቅ".

የሙከራው አጠቃላይ ድምዳሜዎች-

• አማራጮች 3-5 የ HBase ጥቅም ሲያገኙ የበለጠ ቅልጥፍናን ያሳያሉ; ከዚህም በላይ አፈፃፀማቸው እርስ በርስ በቋሚነት ይለያያል እና በአውታረ መረቡ መጠን ላይ የተመካ አይደለም.
• በአማራጮች 4 እና 5 መካከል ያለው ልዩነት አልተመዘገበም. ይህ ማለት ግን አማራጭ 5 ጥቅም ላይ መዋል የለበትም ማለት አይደለም። የሙከራ ወንበሩን የአፈፃፀም ባህሪያት ከግምት ውስጥ በማስገባት ጥቅም ላይ የዋለው የሙከራ ሁኔታ እንዲታይ አልፈቀደም.
• ከመረጃ ጋር "የንግድ ስራዎችን" ለማከናወን በሚያስፈልገው ጊዜ ውስጥ የመጨመር ባህሪ በአጠቃላይ ቀደም ሲል የተገኙትን የንድፈ ሃሳቦች ለሁሉም አማራጮች አረጋግጧል.

Epilogue

የተካሄዱት አስቸጋሪ ሙከራዎች እንደ ፍፁም እውነት መወሰድ የለባቸውም። ከግምት ውስጥ ያልተገቡ እና ውጤቱን ያዛቡ ብዙ ምክንያቶች አሉ (እነዚህ ውጣ ውረዶች በተለይ በትንሽ የኔትወርክ መጠን ባለው ግራፎች ውስጥ ይታያሉ)። ለምሳሌ ፣ በ Happybase ጥቅም ላይ የሚውለው የቁጠባ ፍጥነት ፣ በፓይዘን ውስጥ የጻፍኩትን አመክንዮ የመተግበር መጠን እና ዘዴ (ኮዱ በጥሩ ሁኔታ የተጻፈ እና የሁሉንም አካላት ችሎታዎች በትክክል ተጠቅሟል ማለት አልችልም) ፣ ምናልባት የHBase መሸጎጫ ገፅታዎች፣ የዊንዶውስ 10 ዳራ እንቅስቃሴ በእኔ ላፕቶፕ ላይ ወዘተ በአጠቃላይ ሁሉም የንድፈ ሃሳባዊ ስሌቶች ትክክለኛነታቸውን በሙከራ አሳይተዋል ብለን መገመት እንችላለን። ደህና፣ ወይም ቢያንስ እንዲህ ባለው “የራስ ጥቃት” ማስተባበል አልተቻለም።

በማጠቃለያው ፣ በHBase ውስጥ የውሂብ ሞዴሎችን ለመንደፍ ገና ለጀመሩ ሰዎች ሁሉ ምክሮች-ከቀድሞው ተዛማጅ የውሂብ ጎታዎች ጋር የመሥራት ልምድ እና “ትዕዛዞቹን” ያስታውሱ-

• ዲዛይን ስንሰራ ከዳታ ማጭበርበር ተግባር እና ቅጦች እንቀጥላለን እንጂ ከጎራ ሞዴል አይደለም።
• ቀልጣፋ መዳረሻ (ያለ ሙሉ የሰንጠረዥ ቅኝት) - በቁልፍ ብቻ
• መደበኛ ያልሆነ አሠራር
• የተለያዩ ረድፎች የተለያዩ ዓምዶችን ሊይዙ ይችላሉ።
• የድምጽ ማጉያዎች ተለዋዋጭ ቅንብር

ምንጭ: hab.com