डेटा सॅम्पलिंग रेट ऑप्टिमायझेशन

6.1 परिचय

आता थिअरीकडून सरावाकडे वळू.

आम्ही वास्तविक जगात राहतो आणि सर्व सॉफ्टवेअर उत्पादने शेवटी जिवंत लोकांसाठी तयार केली जातात. आणि हे जिवंत लोक हळूहळू लोड होणार्‍या साइट्स आणि मंद होणार्‍या प्रोग्राममुळे खूप नाराज आहेत.

आणि डेटाबेस क्वेरीला सेकंदापेक्षा जास्त वेळ लागल्यास, हे अस्वीकार्य आहे . वापरकर्ते अशा उत्पादनाचा वापर करणार नाहीत ज्यात पृष्ठे/कार्यक्षमता इतकी मंद आहे.

परंतु अनेकदा, एक पृष्ठ प्रदर्शित करण्यासाठी, आपल्याला डेटाबेसमध्ये अनेक डझन क्वेरी करणे आवश्यक आहे. आणि जर ते क्रमाक्रमाने अंमलात आणले गेले, तर तुम्हाला यापुढे दुसरी मर्यादा नाही, परंतु प्रति विनंती 100ms म्हणूया.

प्रोग्रामर डेटाबेस क्वेरीचा वेग वाढवण्याचे शीर्ष 5 मार्ग येथे आहेत:

1. डेटाबेसमधील सारण्यांमध्ये अनुक्रमणिका जोडणे.
2. पुनर्लेखन आणि क्वेरी ऑप्टिमाइझ करणे.
3. डेटाबेस बाजूला कॅशिंग सक्षम (आणि कॉन्फिगर) करा.
4. क्लायंट बाजूला कॅशिंग सक्षम करा.
5. डेटाबेस डिनोर्मलायझेशन करत आहे.

आपण या सर्व गोष्टींसह बर्याच भागांसाठी आधीपासूनच परिचित आहात, म्हणून खालील केवळ व्यावहारिक सल्ला असेल.

6.2 निर्देशांक

हे रहस्य नाही की डेटाबेससह कार्य करणे जवळजवळ कोणत्याही साइटचे बहुतेक काम घेते. आणि हे डेटाबेससह कार्य करत आहे जे बहुतेक वेळा वेब ऍप्लिकेशन्सची अडचण असते.

या लेखात मी MySQL वापरण्याबाबत व्यावहारिक सल्ला देऊ इच्छितो.

मी लगेच म्हणेन:

• हा लेख MySQL बद्दल लिहिलेला आहे, जरी सामान्य गोष्टी कोणत्याही DBMS साठी सत्य असण्याची शक्यता आहे.
• लेखात लिहिलेली प्रत्येक गोष्ट माझा वैयक्तिक दृष्टिकोन आहे आणि अंतिम सत्य नाही.
• सल्ला नवीन असल्याचे भासवत नाही आणि वाचलेल्या साहित्याच्या आणि वैयक्तिक अनुभवाच्या सामान्यीकरणाचा परिणाम आहे.
• या लेखाच्या चौकटीत, मी MySQL कॉन्फिगरेशन समस्यांना स्पर्श करणार नाही.

MySQL वापरताना येणाऱ्या समस्या खालील तीन गटांमध्ये विभागल्या जाऊ शकतात (महत्त्वाच्या क्रमाने):

1. निर्देशांकांचा गैरवापर किंवा गैरवापर.
2. चुकीची डेटाबेस रचना.
3. चुकीच्या \ suboptimal SQL क्वेरी.

चला या प्रत्येक गटाचा जवळून विचार करूया.

निर्देशांक वापरणे

इंडेक्सेस न वापरणे किंवा त्याचा गैरवापर न करणे हे बहुतेक वेळा प्रश्नांची गती कमी करते. ज्यांना निर्देशांक कसे कार्य करतात या यंत्रणेशी परिचित नाहीत किंवा मॅन्युअलमध्ये त्याबद्दल अद्याप वाचलेले नाही, मी तुम्हाला ते वाचण्याचा जोरदार सल्ला देतो.

निर्देशांक वापरण्यासाठी टिपा:

• आपल्याला सर्वकाही अनुक्रमित करण्याची आवश्यकता नाही . बर्‍याचदा, अर्थ न समजता, लोक टेबलच्या सर्व फील्डची अनुक्रमणिका करतात. अनुक्रमणिका मिळवण्याचा वेग वाढवतात, परंतु पंक्ती घालणे आणि अद्यतने कमी करतात, म्हणून प्रत्येक अनुक्रमणिकेची निवड अर्थपूर्ण असणे आवश्यक आहे.
• निर्देशांकाचे वैशिष्ट्य दर्शविणारे मुख्य पॅरामीटर्स म्हणजे निवडकता, जी निर्देशांकातील विविध घटकांची संख्या आहे. दोन किंवा तीन संभाव्य मूल्ये असलेले फील्ड अनुक्रमित करण्यात काही अर्थ नाही. अशा निर्देशांकाचा फारसा फायदा होणार नाही.
• निर्देशांकांची निवड दिलेल्या सारणीवरील सर्व प्रश्नांच्या विश्लेषणाने सुरू झाली पाहिजे. बर्‍याचदा, अशा विश्लेषणानंतर, तीन किंवा चार निर्देशांकांऐवजी, आपण एक संमिश्र बनवू शकता.
• संमिश्र निर्देशांक वापरताना, निर्देशांकातील फील्डचा क्रम महत्त्वाचा असतो.
• कव्हर इंडेक्स बद्दल विसरू नका. जर क्वेरीमधील सर्व डेटा इंडेक्समधून पुनर्प्राप्त केला जाऊ शकतो, तर MySQL टेबलवर थेट प्रवेश करणार नाही. अशा विनंत्या फार लवकर अंमलात आणल्या जातील. उदाहरणार्थ, अनुक्रमणिका (लॉगिन, नाव) असलेल्या क्वेरीसाठी SELECT name FROM user WHERE login='test', टेबलमध्ये प्रवेश आवश्यक नाही. काहीवेळा संमिश्र निर्देशांकात अतिरिक्त फील्ड जोडणे अर्थपूर्ण आहे, जे निर्देशांक कव्हर करेल आणि प्रश्नांची गती वाढवेल.
• पंक्ती निर्देशांकांसाठी, पंक्तीचा फक्त काही भाग अनुक्रमित करणे पुरेसे असते. यामुळे निर्देशांकाचा आकार लक्षणीयरीत्या कमी होऊ शकतो.
• जर %ते सुरुवातीला असेल तर, LIKE(SELECT * FROM table WHERE field LIKE '%test')निर्देशांक वापरले जाणार नाहीत.
• FULLTEXT इंडेक्स फक्त MATCH ... AGAINST सिंटॅक्ससह वापरला जातो .

6.3 डेटाबेस रचना

डेटाबेससह जलद आणि कार्यक्षम कार्य करण्यासाठी योग्यरित्या डिझाइन केलेला डेटाबेस ही गुरुकिल्ली आहे. दुसरीकडे, खराब डिझाइन केलेला डेटाबेस विकासकांसाठी नेहमीच डोकेदुखी असतो.

डेटाबेस डिझाइन टिपा:

1. सर्वात लहान शक्य डेटा प्रकार वापरा. डेटा प्रकार जितका मोठा, टेबल जितका मोठा असेल तितका डेटा मिळविण्यासाठी अधिक डिस्क प्रवेश आवश्यक आहेत. एक अतिशय सोयीस्कर प्रक्रिया वापरा: SELECT * FROM table_name PROCEDURE ANALYSE();किमान संभाव्य डेटा प्रकार निर्धारित करण्यासाठी.
2. डिझाइन टप्प्यात सामान्य स्वरूपांचे निरीक्षण करा. बर्‍याचदा प्रोग्रामर या टप्प्यावर आधीपासूनच डिनोर्मलायझेशनचा अवलंब करतात. तथापि, बहुतेक प्रकरणांमध्ये, प्रकल्पाच्या सुरूवातीस, याचा परिणाम कसा होऊ शकतो हे स्पष्ट नाही. सब-ऑप्टिमली डिनॉर्मलाइज्ड टेबलचा त्रास सहन करण्यापेक्षा टेबल डिनोर्मलायझ करणे खूप सोपे आहे. आणि JOINकाहीवेळा ते चुकीच्या डिनॉर्मलाइज्ड टेबलपेक्षा जलद कार्य करते.
3. NULLतुम्हाला जाणीवपूर्वक गरज असल्याशिवाय स्तंभ वापरू नका .

6.4 SQL क्वेरी.

नेहमी सर्व क्वेरी मूळ SQL मध्ये पुन्हा लिहिण्याची इच्छा असते जेणेकरून क्वेरी शक्य तितक्या जलद होईल. आपण हे करण्याचे ठरविल्यास, येथे काही टिपा आहेत:

1. लूपमधील विनंत्या टाळा. एसक्यूएल ही संचांची भाषा आहे आणि लेखन प्रश्न फंक्शन्सच्या भाषेत नाही, तर सेटच्या भाषेत विचारले पाहिजेत.
2. *प्रश्नांमध्ये (तारक) टाळा . तुम्ही निवडलेल्या फील्डची यादी करण्यास मोकळ्या मनाने. हे प्राप्त आणि पाठवलेल्या डेटाचे प्रमाण कमी करेल. तसेच, निर्देशांक कव्हर करण्याबद्दल विसरू नका. जरी तुम्ही सारणीतील सर्व फील्ड निवडले तरीही त्यांची यादी करणे चांगले आहे. प्रथम , ते कोडची वाचनीयता सुधारते. तारका वापरताना, त्यामध्ये न पाहता टेबलमध्ये कोणती फील्ड आहेत हे शोधणे अशक्य आहे. दुसरे म्हणजे , आज तुमच्या टेबलमध्ये पाच INT स्तंभ आहेत, आणि एका महिन्यानंतर आणखी एक TEXT आणि BLOB जोडले गेले , आणि तारा जसा होता तसाच राहिला.
3. पृष्ठांकन केल्यावर, रेकॉर्डची एकूण संख्या मिळवण्यासाठी, वापरा SQL_CALC_FOUND_ROWSआणि SELECT FOUND_ROWS();वापरा तेव्हा SQL_CALC_FOUND_ROWS MySQL, निवडलेल्या पंक्तींची संख्या कॅश करते (LIMIT लागू करण्यापूर्वी), आणि जेव्हा वापरली जाते तेव्हा, SELECT FOUND_ROWS()क्वेरी पुन्हा कार्यान्वित न करता फक्त हे कॅशे केलेले मूल्य परत करते.
4. हे विसरू नका की INSERTएकाधिक इन्सर्टसाठी एक वाक्यरचना आहे. लूपमधील एकाधिक क्वेरींपेक्षा एक क्वेरी तीव्रतेचा क्रम चालवेल.
5. LIMITजिथे तुम्हाला सर्व डेटाची आवश्यकता नाही तिथे वापरा .
6. INSERT… ON DUPLICATE KEY UPDATE…च्‍या जागी आणि INSERTकिंवा UPDATEनिवडीनंतर वापरा आणि अनेकदा च्‍या जागी वापरा REPLACE.
7. हे आश्चर्यकारक वैशिष्ट्य विसरू नका GROUP_CONCAT. हे जटिल प्रश्नांमध्ये मदत करू शकते.