பக்க வினவல்களில் OFFSET மற்றும் LIMIT ஐப் பயன்படுத்துவதைத் தவிர்க்கவும்

தரவுத்தள செயல்திறனை மேம்படுத்துவது பற்றி நீங்கள் கவலைப்பட வேண்டியதில்லை. காலம் நிற்பதில்லை. ஒவ்வொரு புதிய தொழில்நுட்ப தொழில்முனைவோரும் அடுத்த Facebook ஐ உருவாக்க விரும்புகிறார்கள், அதே நேரத்தில் அவர்கள் தங்கள் கைகளில் கிடைக்கும் எல்லா தரவையும் சேகரிக்க முயற்சிக்கிறார்கள். வணிகங்களுக்கு பணம் சம்பாதிக்க உதவும் சிறந்த பயிற்சி மாடல்களுக்கு இந்தத் தரவு தேவை. இத்தகைய நிலைமைகளில், புரோகிராமர்கள் APIகளை உருவாக்க வேண்டும், அவை விரைவாகவும் நம்பகத்தன்மையுடனும் பெரிய அளவிலான தகவல்களுடன் வேலை செய்ய அனுமதிக்கின்றன.

நீங்கள் எந்த நேரத்திலும் பயன்பாடு அல்லது தரவுத்தள பின்தளங்களை வடிவமைத்திருந்தால், பக்க வினவல்களை இயக்க குறியீட்டை எழுதியிருக்கலாம். உதாரணமாக, இது போன்றது:

SELECT * FROM table_name LIMIT 10 OFFSET 40

அது தான் வழி?

ஆனால் நீங்கள் உங்கள் பக்கத்தை இவ்வாறு செய்தீர்கள் என்றால், நீங்கள் அதை மிகவும் திறமையான முறையில் செய்யவில்லை என்று வருந்துகிறேன்.

நீங்கள் என்னை எதிர்க்க விரும்புகிறீர்களா? நீங்கள் முடியும் இல்லை செலவு время. தளர்ந்த, shopify и மிக்ஸ்மேக்ஸ் இன்று நான் பேச விரும்பும் நுட்பங்களை அவர்கள் ஏற்கனவே பயன்படுத்துகிறார்கள்.

இதுவரை பயன்படுத்தாத ஒரு பின்தள டெவலப்பரையாவது குறிப்பிடவும் OFFSET и LIMIT பக்க வினவல்களைச் செய்ய. MVP (குறைந்தபட்ச சாத்தியமான தயாரிப்பு) மற்றும் சிறிய அளவிலான தரவு பயன்படுத்தப்படும் திட்டங்களில், இந்த அணுகுமுறை மிகவும் பொருந்தும். இது "வேலை செய்கிறது," எனவே பேச.

ஆனால் நீங்கள் புதிதாக நம்பகமான மற்றும் திறமையான அமைப்புகளை உருவாக்க வேண்டும் என்றால், அத்தகைய அமைப்புகளில் பயன்படுத்தப்படும் தரவுத்தளங்களை வினவுவதன் செயல்திறனை நீங்கள் முன்கூட்டியே கவனித்துக் கொள்ள வேண்டும்.

பேஜினேட் வினவல் என்ஜின்களின் பொதுவாகப் பயன்படுத்தப்படும் (மிக மோசமான) செயலாக்கங்களில் உள்ள சிக்கல்கள் மற்றும் அத்தகைய வினவல்களைச் செயல்படுத்தும்போது உயர் செயல்திறனை எவ்வாறு அடைவது என்பது பற்றி இன்று பேசுவோம்.

OFFSET மற்றும் LIMIT இல் என்ன தவறு?

ஏற்கனவே கூறியது போல, OFFSET и LIMIT பெரிய அளவிலான தரவுகளுடன் வேலை செய்யத் தேவையில்லாத திட்டங்களில் அவை சிறப்பாகச் செயல்படுகின்றன.

தரவுத்தளமானது சேவையகத்தின் நினைவகத்தில் பொருந்தாத அளவிற்கு வளரும்போது சிக்கல் எழுகிறது. இருப்பினும், இந்த தரவுத்தளத்துடன் பணிபுரியும் போது, ​​நீங்கள் பக்க வினவல்களைப் பயன்படுத்த வேண்டும்.

இந்தச் சிக்கல் வெளிப்படுவதற்கு, ஒவ்வொரு பக்க வினவலிலும் திறமையற்ற முழு அட்டவணை ஸ்கேன் செயல்பாட்டை DBMS நாடும் சூழ்நிலை இருக்க வேண்டும் (செருகுதல் மற்றும் நீக்குதல் செயல்பாடுகள் நிகழலாம் , மேலும் எங்களுக்கு காலாவதியான தரவு தேவையில்லை!).

"முழு அட்டவணை ஸ்கேன்" (அல்லது "வரிசை அட்டவணை ஸ்கேன்", தொடர் ஸ்கேன்) என்றால் என்ன? இது ஒரு செயல்பாட்டின் போது டிபிஎம்எஸ் அட்டவணையின் ஒவ்வொரு வரிசையையும், அதாவது அதில் உள்ள தரவுகளை தொடர்ச்சியாகப் படித்து, கொடுக்கப்பட்ட நிபந்தனையுடன் இணங்குகிறதா எனச் சரிபார்க்கிறது. இந்த வகை டேபிள் ஸ்கேன் மிகவும் மெதுவானதாக அறியப்படுகிறது. உண்மை என்னவென்றால், இது செயல்படுத்தப்படும் போது, ​​சேவையகத்தின் வட்டு துணை அமைப்பை உள்ளடக்கிய பல உள்ளீடு/வெளியீட்டு செயல்பாடுகள் செய்யப்படுகின்றன. வட்டுகளில் சேமிக்கப்பட்ட தரவுகளுடன் பணிபுரியும் தாமதத்தால் நிலைமை மோசமாகிறது, மேலும் வட்டில் இருந்து நினைவகத்திற்கு தரவை மாற்றுவது வள-தீவிர செயல்பாடாகும்.

எடுத்துக்காட்டாக, உங்களிடம் 100000000 பயனர்களின் பதிவுகள் உள்ளன, மேலும் நீங்கள் கட்டுமானத்துடன் வினவலை இயக்குகிறீர்கள் OFFSET 50000000. இதன் பொருள் DBMS இந்த எல்லா பதிவுகளையும் ஏற்ற வேண்டும் (எங்களுக்கு அவை தேவையில்லை!), அவற்றை நினைவகத்தில் வைக்கவும், அதன் பிறகு, 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 எம்எஸ்).

மேலும் தரவு இருந்தால், எல்லாம் இன்னும் மோசமாக இருக்கும் (இதை நம்புவதற்கு, என்னுடையதைப் பாருங்கள் உதாரணமாக 10 மில்லியன் வரிசைகளுடன்).

நாங்கள் இப்போது விவாதித்தவை, தரவுத்தள வினவல்கள் உண்மையில் எவ்வாறு செயலாக்கப்படுகின்றன என்பதைப் பற்றிய சில நுண்ணறிவை உங்களுக்கு வழங்க வேண்டும்.

அதிக மதிப்பு என்பதை நினைவில் கொள்க OFFSET - கோரிக்கையை முடிக்க அதிக நேரம் எடுக்கும்.

OFFSET மற்றும் LIMIT ஆகியவற்றின் கலவைக்குப் பதிலாக நான் எதைப் பயன்படுத்த வேண்டும்?

கலவைக்கு பதிலாக OFFSET и LIMIT பின்வரும் திட்டத்தின் படி கட்டப்பட்ட கட்டமைப்பைப் பயன்படுத்துவது மதிப்பு:

SELECT * FROM table_name WHERE id > 10 LIMIT 20

இது கர்சர் அடிப்படையிலான பேஜினேஷனுடன் கூடிய வினவல் செயலாக்கமாகும்.

தற்போதையவற்றை உள்ளூரில் சேமிப்பதற்குப் பதிலாக OFFSET и LIMIT ஒவ்வொரு கோரிக்கையிலும் அவற்றை அனுப்பவும், கடைசியாக பெறப்பட்ட முதன்மை விசையை நீங்கள் சேமிக்க வேண்டும் (பொதுவாக இது ID) மற்றும் LIMIT, இதன் விளைவாக, மேலே உள்ளதைப் போன்ற வினவல்கள் பெறப்படும்.

ஏன்? முக்கிய விஷயம் என்னவென்றால், கடைசி வரிசையின் அடையாளங்காட்டியை தெளிவாகக் குறிப்பிடுவதன் மூலம், தேவையான தரவைத் தேடத் தொடங்க வேண்டிய இடத்தை உங்கள் DBMS க்குக் கூறுங்கள். மேலும், விசையின் பயன்பாட்டிற்கு நன்றி, தேடல் திறமையாக மேற்கொள்ளப்படும்; குறிப்பிட்ட வரம்பிற்கு வெளியே உள்ள கோடுகளால் கணினி திசைதிருப்பப்பட வேண்டியதில்லை.

பல்வேறு வினவல்களின் பின்வரும் செயல்திறன் ஒப்பீட்டைப் பார்ப்போம். இதோ ஒரு பயனற்ற வினவல்.

மெதுவான கோரிக்கை

இந்தக் கோரிக்கையின் உகந்த பதிப்பு இதோ.

விரைவான கோரிக்கை

இரண்டு வினவல்களும் ஒரே அளவிலான தரவைத் தருகின்றன. ஆனால் முதல் ஒன்று முடிக்க 12,80 வினாடிகள் ஆகும், இரண்டாவது 0,01 வினாடிகள் ஆகும். வித்தியாசத்தை உணர்கிறீர்களா?

சாத்தியமான சிக்கல்கள்

முன்மொழியப்பட்ட வினவல் முறை திறம்பட செயல்பட, அட்டவணையில் ஒரு முழு எண் அடையாளங்காட்டி போன்ற தனித்துவமான, தொடர் குறியீடுகளைக் கொண்ட ஒரு நெடுவரிசை (அல்லது நெடுவரிசைகள்) இருக்க வேண்டும். சில குறிப்பிட்ட சந்தர்ப்பங்களில், தரவுத்தளத்துடன் பணிபுரியும் வேகத்தை அதிகரிக்க இதுபோன்ற வினவல்களைப் பயன்படுத்துவதன் வெற்றியை இது தீர்மானிக்கலாம்.

இயற்கையாகவே, வினவல்களை உருவாக்கும்போது, ​​​​அட்டவணைகளின் குறிப்பிட்ட கட்டமைப்பை நீங்கள் கணக்கில் எடுத்துக்கொள்ள வேண்டும் மற்றும் ஏற்கனவே உள்ள அட்டவணையில் சிறப்பாக செயல்படும் அந்த வழிமுறைகளைத் தேர்வு செய்ய வேண்டும். எடுத்துக்காட்டாக, பெரிய அளவிலான தொடர்புடைய தரவுகளுடன் வினவல்களில் நீங்கள் பணியாற்ற வேண்டும் என்றால், நீங்கள் அதை சுவாரஸ்யமாகக் காணலாம் இந்த கட்டுரை.

முதன்மை விசையை தவறவிட்ட பிரச்சனையை நாம் எதிர்கொண்டால், எடுத்துக்காட்டாக, பல மற்றும் பல உறவுகளுடன் ஒரு அட்டவணை இருந்தால், அதைப் பயன்படுத்துவதற்கான பாரம்பரிய அணுகுமுறை OFFSET и LIMIT, நமக்கு ஏற்றதாக உத்தரவாதம் அளிக்கப்படுகிறது. ஆனால் அதன் பயன்பாடு மெதுவான வினவல்களுக்கு வழிவகுக்கும். இது போன்ற சமயங்களில், பேஜினேட் வினவல்களைக் கையாள மட்டுமே தேவைப்பட்டாலும், தானாக அதிகரிக்கும் முதன்மை விசையைப் பயன்படுத்த பரிந்துரைக்கிறேன்.

இந்த தலைப்பில் நீங்கள் ஆர்வமாக இருந்தால் - இங்கே, இங்கே и இங்கே - பல பயனுள்ள பொருட்கள்.

முடிவுகளை

நாம் எடுக்கக்கூடிய முக்கிய முடிவு என்னவென்றால், நாம் எந்த அளவு தரவுத்தளங்களைப் பற்றி பேசினாலும், வினவல் செயல்படுத்தும் வேகத்தை பகுப்பாய்வு செய்வது எப்போதும் அவசியம். இப்போதெல்லாம், தீர்வுகளின் அளவிடுதல் மிகவும் முக்கியமானது, மேலும் ஒரு குறிப்பிட்ட அமைப்பில் பணிபுரியும் ஆரம்பத்திலிருந்தே அனைத்தும் சரியாக வடிவமைக்கப்பட்டிருந்தால், இது எதிர்காலத்தில் டெவலப்பரை பல சிக்கல்களிலிருந்து காப்பாற்றும்.

தரவுத்தள வினவல்களை எவ்வாறு பகுப்பாய்வு செய்து மேம்படுத்துகிறீர்கள்?

ஆதாரம்: www.habr.com