OffsET እና LIMIT በፓጋኒንግ ጥያቄዎች ውስጥ አይጠቀሙ

የውሂብ ጎታ አፈጻጸምን ስለማሳባት መጨነቅ የማትጨነቅባቸው ቀናት አልፈዋል። ጊዜ አይቆምም። እያንዳንዱ አዲስ የቴክኖሎጂ ስራ ፈጣሪ ቀጣዩን ፌስቡክ መፍጠር ይፈልጋል, በእጃቸው ሊያገኙ የሚችሉትን ሁሉንም መረጃዎች ለመሰብሰብ እየሞከሩ ነው. ንግዶች ገንዘብ ለማግኘት የሚረዱ ሞዴሎችን በተሻለ ለማሰልጠን ይህንን ውሂብ ይፈልጋሉ። በእንደዚህ ዓይነት ሁኔታዎች ፕሮግራመሮች በፍጥነት እና በአስተማማኝ ሁኔታ በከፍተኛ መጠን መረጃ እንዲሰሩ የሚያስችላቸውን ኤፒአይ መፍጠር አለባቸው።

ለማንኛውም ጊዜ አፕሊኬሽን ወይም ዳታቤዝ ድጋፍ ሰጪዎችን እየነደፉ ከሆነ፣ ምናልባት በገጽ የተጻፉ መጠይቆችን ለማካሄድ ኮድ ጽፈው ይሆናል። ለምሳሌ፣ እንደዚህ፡-

SELECT * FROM table_name LIMIT 10 OFFSET 40

መንገድ ነው?

ነገር ግን የገጽታ ግንባታዎን በዚህ መንገድ ከሠሩት በጣም ቀልጣፋ በሆነ መንገድ እንዳልሠሩት በመግለጽ አዝናለሁ።

እኔን መቃወም ትፈልጋለህ? ይችላሉ አይደለም ማውጣት время. ትወርሱ, Shopify и ሚክሜክስ ዛሬ ልናገር የምፈልጋቸውን ቴክኒኮች አስቀድመው እየተጠቀሙ ነው።

በጭራሽ ተጠቅሞ የማያውቅ ቢያንስ አንድ የጀርባ ገንቢ ይጥቀሱ OFFSET и LIMIT በፓጊኒንግ ጥያቄዎችን ለማከናወን. በኤምቪፒ (አነስተኛ አዋጭ ምርት) እና አነስተኛ መጠን ያለው መረጃ ጥቅም ላይ በሚውልባቸው ፕሮጀክቶች ውስጥ ይህ አካሄድ በጣም ተግባራዊ ነው። "ብቻ ይሰራል" ለማለት ነው።

ነገር ግን አስተማማኝ እና ቀልጣፋ ስርዓቶችን ከባዶ መፍጠር ካስፈለገዎት በእንደዚህ አይነት ስርዓቶች ውስጥ ጥቅም ላይ የሚውሉ የውሂብ ጎታዎችን የመጠየቅ ቅልጥፍናን በተመለከተ አስቀድመው ጥንቃቄ ማድረግ አለብዎት.

ዛሬ ስለ ችግሮች እንነጋገራለን በተለምዶ ጥቅም ላይ በሚውሉ (በጣም መጥፎ) የፓጊኒት መጠይቅ ሞተሮች አተገባበር እና እንደዚህ ያሉ ጥያቄዎችን በሚፈጽሙበት ጊዜ ከፍተኛ አፈፃፀም እንዴት ማግኘት እንደሚቻል ።

በOFFSET እና LIMIT ላይ ምን ችግር አለበት?

ቀደም ሲል እንደተጠቀሰው OFFSET и LIMIT ከትልቅ የውሂብ መጠን ጋር መስራት በማይፈልጉ ፕሮጀክቶች ውስጥ ጥሩ ይሰራሉ.

ችግሩ የሚፈጠረው የመረጃ ቋቱ መጠን ሲያድግ ከአገልጋዩ ማህደረ ትውስታ ጋር የማይስማማ ነው። ሆኖም፣ ከዚህ ዳታቤዝ ጋር ሲሰሩ፣ በገጽ የተቀመጡ መጠይቆችን መጠቀም ያስፈልግዎታል።

ይህ ችግር እራሱን እንዲገለጥ፣ DBMS በእያንዳንዱ ገፅ በተዘጋጀው ጥያቄ ላይ ውጤታማ ያልሆነ የሙሉ የጠረጴዛ ቅኝት ስራ የሚጀምርበት ሁኔታ መኖር አለበት (የማስገባት እና የማጥፋት ስራዎች ሊከሰቱ ይችላሉ እና ጊዜ ያለፈበት ውሂብ አያስፈልገንም!)።

“የሙሉ ሠንጠረዥ ቅኝት” (ወይም “ተከታታይ የሰንጠረዥ ቅኝት”፣ ተከታታይ ቅኝት) ምንድን ነው? ይህ DBMS የሠንጠረዡን እያንዳንዱን ረድፍ ማለትም በውስጡ ያለውን መረጃ በቅደም ተከተል የሚያነብበት እና የተወሰነ ቅድመ ሁኔታን የሚያከብር መሆኑን የሚፈትሽበት ክዋኔ ነው። የዚህ ዓይነቱ የሠንጠረዥ ቅኝት በጣም ቀርፋፋ እንደሆነ ይታወቃል. እውነታው ሲተገበር የአገልጋዩን የዲስክ ንዑስ ስርዓት የሚያካትቱ ብዙ የግብአት/ውፅዓት ስራዎች ይከናወናሉ። በዲስኮች ላይ ከተከማቸ መረጃ ጋር አብሮ በመስራት ላይ ያለው መዘግየት ሁኔታውን ያባብሰዋል እና መረጃን ከዲስክ ወደ ማህደረ ትውስታ ማስተላለፍ ሃብትን የሚጨምር ተግባር ነው።

ለምሳሌ፣ የ100000000 ተጠቃሚዎች መዝገቦች አሉዎት እና ከግንባታው ጋር ጥያቄን ያካሂዳሉ። OFFSET 50000000. ይህ ማለት ዲቢኤምኤስ እነዚህን ሁሉ መዝገቦች መጫን አለበት (እና እኛ እንኳን አንፈልጋቸውም!)፣ በማህደረ ትውስታ ውስጥ ያስቀምጧቸው እና ከዚያ በኋላ 20 ውጤቶች ተዘግበዋል። LIMIT.

ይህን ይመስላል እንበል፡ "ከ 50000 እስከ 50020 ከ100000 ረድፎችን ይምረጡ"። ማለትም ፣ ጥያቄውን ለማጠናቀቅ ስርዓቱ በመጀመሪያ 50000 ረድፎችን መጫን አለበት። ምን ያህል አላስፈላጊ ሥራ መሥራት እንዳለባት ታያለህ?

ካላመንከኝ ባህሪያቱን ተጠቅሜ የፈጠርኩትን ምሳሌ ተመልከት db-fiddle.com. 

ምሳሌ በ db-fiddle.com ላይ

እዚያ በግራ በኩል በሜዳው ውስጥ Schema SQLበመረጃ ቋቱ ውስጥ 100000 ረድፎችን የሚያስገባ ኮድ አለ ፣ በቀኝ በኩል ፣ በመስክ ላይ። Query SQL, ሁለት መጠይቆች ይታያሉ. የመጀመሪያው፣ ቀርፋፋ፣ ይህን ይመስላል።

SELECT *
FROM `docs`
LIMIT 10 OFFSET 85000;

እና ለተመሳሳይ ችግር ውጤታማ መፍትሄ የሆነው ሁለተኛው እንደዚህ ነው ።

SELECT *
FROM `docs`
WHERE id > 85000
LIMIT 10;

እነዚህን ጥያቄዎች ለመፈጸም በቀላሉ ቁልፉን ጠቅ ያድርጉ Run በገጹ አናት ላይ. ይህንን ካደረግን በኋላ ስለ መጠይቁ አፈፃፀም ጊዜ መረጃን እናነፃፅራለን። ውጤታማ ያልሆነን ጥያቄ ለማስፈጸም ሁለተኛውን ከመፈፀም ቢያንስ 30 እጥፍ የሚፈጅ ጊዜ እንደሚወስድ ነው (ይህ ጊዜ ከሩጫ ወደ ሩጫ ይለያያል፤ ለምሳሌ ስርዓቱ የመጀመሪያው ጥያቄ ለማጠናቀቅ 37 ሚሴ እንደወሰደ ሊዘግብ ይችላል ነገር ግን አፈፃፀሙ ሁለተኛ - 1 ms).

እና ተጨማሪ ውሂብ ካለ ፣ ከዚያ ሁሉም ነገር የበለጠ የከፋ ይመስላል (በዚህ ለማመን ፣ የእኔን ይመልከቱ) ምሳሌ ከ 10 ሚሊዮን ረድፎች ጋር).

አሁን የተወያየንበት ነገር የውሂብ ጎታ መጠይቆች እንዴት በትክክል እንደሚስተናገዱ የተወሰነ ግንዛቤ ሊሰጥዎ ይገባል።

እባካችሁ እሴቱ ከፍ ያለ መሆኑን ያስተውሉ OFFSET - ጥያቄው ለማጠናቀቅ ረዘም ያለ ጊዜ ይወስዳል።

ከOFFSET እና LIMIT ጥምረት ይልቅ ምን ልጠቀም?

ከማጣመር ይልቅ OFFSET и LIMIT በሚከተለው እቅድ መሰረት የተገነባውን መዋቅር መጠቀም ጠቃሚ ነው.

SELECT * FROM table_name WHERE id > 10 LIMIT 20

ይህ በጠቋሚ ላይ የተመሰረተ የጥያቄ አፈጻጸም ነው።

አሁን ያሉትን በአገር ውስጥ ከማስቀመጥ ይልቅ OFFSET и LIMIT እና በእያንዳንዱ ጥያቄ ያስተላልፉዋቸው, የመጨረሻውን የተቀበሉት ዋና ቁልፍ ማከማቸት ያስፈልግዎታል (ብዙውን ጊዜ ይህ ነው ID) እና LIMITበውጤቱም, ከላይ ከተጠቀሱት ጋር ተመሳሳይነት ያላቸው ጥያቄዎች ይደርሳሉ.

ለምን? ነጥቡ የመጨረሻውን ረድፍ የተነበበውን መለያ በግልፅ በመግለጽ ለዲቢኤምኤስዎ አስፈላጊውን ውሂብ የት መፈለግ እንዳለበት ይነግሩታል። ከዚህም በላይ ፍለጋው ለቁልፍ አጠቃቀሙ ምስጋና ይግባውና በተቀላጠፈ ሁኔታ ይከናወናል, ስርዓቱ ከተጠቀሰው ክልል ውጭ ባሉ መስመሮች መበታተን የለበትም.

የሚከተለውን የተለያዩ መጠይቆችን የአፈጻጸም ንጽጽር እንመልከት። ውጤታማ ያልሆነ መጠይቅ ይኸውና።

ቀርፋፋ ጥያቄ

እና የዚህ ጥያቄ የተመቻቸ ስሪት እዚህ አለ።

ፈጣን ጥያቄ

ሁለቱም መጠይቆች ልክ አንድ አይነት የውሂብ መጠን ይመለሳሉ። ግን የመጀመሪያው ለማጠናቀቅ 12,80 ሰከንድ ይወስዳል, ሁለተኛው ደግሞ 0,01 ሰከንድ ይወስዳል. ልዩነቱ ይሰማዎታል?

ሊሆኑ የሚችሉ ችግሮች

የታቀደው የመጠይቅ ዘዴ ውጤታማ በሆነ መንገድ እንዲሠራ ሠንጠረዡ ልዩ የሆኑ ተከታታይ ኢንዴክሶችን የያዘ አምድ (ወይም አምዶች) ሊኖረው ይገባል፣ ለምሳሌ ኢንቲጀር ለዪ። በአንዳንድ ልዩ ሁኔታዎች, ይህ ከመረጃ ቋቱ ጋር አብሮ የመስራትን ፍጥነት ለመጨመር እንደነዚህ ያሉ መጠይቆችን የመጠቀም ስኬት ሊወስን ይችላል.

በተፈጥሮ ፣ መጠይቆችን በሚገነቡበት ጊዜ የጠረጴዛዎቹን ልዩ ንድፍ ግምት ውስጥ ማስገባት እና አሁን ባሉት ጠረጴዛዎች ላይ በተሻለ ሁኔታ የሚሰሩትን ስልቶች መምረጥ ያስፈልግዎታል ። ለምሳሌ፣ በትላልቅ ጥራዞች ተዛማጅ መረጃዎች ባሉ መጠይቆች መስራት ካስፈለገዎት አስደሳች ሆኖ ሊያገኙት ይችላሉ። ይሄ ጽሑፍ.

ዋና ቁልፍ የማጣት ችግር ካጋጠመን ለምሳሌ ከብዙ እና ከብዙ ግንኙነት ጋር ጠረጴዛ ካለን የአጠቃቀም ባሕላዊ መንገድ OFFSET и LIMIT, ለእኛ ተስማሚ እንደሚሆን ዋስትና ተሰጥቶታል. ነገር ግን አጠቃቀሙ ቀርፋፋ መጠይቆችን ሊያስከትል ይችላል። በእንደዚህ ዓይነት ሁኔታዎች ፣ ምንም እንኳን በፓጊኒንግ ጥያቄዎችን ለማስተናገድ ብቻ የሚያስፈልገው ቢሆንም ፣ በራስ-የሚጨምር ዋና ቁልፍ እንዲጠቀሙ እመክራለሁ።

በዚህ ርዕስ ላይ ፍላጎት ካሎት - እነሆም, እነሆም и እነሆም - በርካታ ጠቃሚ ቁሳቁሶች.

ውጤቶች

ልንወስደው የምንችለው ዋናው መደምደሚያ, የምንናገረው ምንም ያህል የውሂብ ጎታዎች መጠን ምንም ይሁን ምን, የጥያቄ አፈፃፀምን ፍጥነት መተንተን ሁልጊዜ አስፈላጊ ነው. በአሁኑ ጊዜ የመፍትሄዎች መስፋፋት እጅግ በጣም አስፈላጊ ነው, እና ሁሉም ነገር በተወሰነ ስርዓት ላይ ከመሥራት ጀምሮ በትክክል ከተሰራ, ይህ ለወደፊቱ, ገንቢውን ከብዙ ችግሮች ሊያድነው ይችላል.

የውሂብ ጎታ መጠይቆችን እንዴት ይተነትናል እና ያሻሽላሉ?

ምንጭ: hab.com