INDEX: अनुक्रमणिका

7.1 निर्देशांक दिसण्याची कारणे

दुसरी महत्त्वाची गोष्ट ज्याशिवाय डेटाबेस असू शकत नाही ती म्हणजे अनुक्रमणिका.

अशा परिस्थितीची कल्पना करा जिथे वापरकर्ता सारणीमध्ये 10 दशलक्ष वापरकर्ते आहेत , आणि तुम्ही प्रत्येकाला प्रदर्शित करू इच्छित आहात ज्यांची पातळी 90 पेक्षा जास्त आहे. ही क्वेरी लिहिणे खूप सोपे आहे:

SELECT * FROM user WHERE level > 90

छान, आम्ही एका मिनिटापेक्षा कमी वेळात विनंती लिहिली. आणि SQL सर्व्हरवरून ही क्वेरी कार्यान्वित करण्यासाठी किती वेळ लागेल? अशी क्वेरी अंमलात आणण्यासाठी, त्याला 10 दशलक्ष रेकॉर्डमधून जावे लागेल, आणि जरी एकच रेकॉर्ड असेल तर त्याला खूप वेळ लागेल.

आपण Java मध्ये असेच कार्य कसे करू? आम्ही प्रथम वापरकर्त्यांचा संग्रह स्तरानुसार क्रमवारी लावू, आणि नंतर आम्ही बायनरी शोध वापरून आवश्यक नोंदी पटकन शोधू शकू. मला आशा आहे की मला ते काय आहे हे स्पष्ट करण्याची गरज नाही?

छान, पण आता आम्हाला असे वापरकर्ते निवडायचे असतील ज्यांची नोंदणी तारीख 2020 पूर्वी होती? नोंदणी तारखेनुसार पुन्हा क्रमवारी लावा आणि बायनरी शोध वापरा.

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

आणि वेगवेगळ्या फील्डनुसार एकाच वेळी क्रमवारी लावलेला डेटा कसा संग्रहित करायचा?

आणि उत्तर अगदी सोपे आहे - आपल्याला डेटा स्वतःच नाही तर त्यांचे निर्देशांक काही जागतिक टेबलमध्ये संग्रहित करणे आवश्यक आहे.

समजा आयडी असलेले 10 वापरकर्ते आहेत: {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}.

आणि तुम्ही त्यांना स्तरानुसार क्रमवारी लावण्याचा निर्णय घ्या, नंतर त्यांच्या आयडीचा अॅरे असेल, उदाहरणार्थ, याप्रमाणे: {9, 2, 3, 1, 5, 4, 8, 6, 7, 10}.

आणि जर आम्ही त्यांची तारखेनुसार क्रमवारी लावली तर आम्हाला मिळेल, उदाहरणार्थ: {10, 1, 8, 7, 2, 3, 5, 9, 6}.

या आयडीच्या अॅरेला इंडेक्सेस म्हणतात . घटक स्वतः मोठे आहेत, आम्ही त्यांना स्पर्श करत नाही. जावामध्ये, आम्ही वस्तूंना स्पर्श करत नाही, परंतु त्यांचे संदर्भ संग्रहित करतो; SQL मध्ये, आम्ही वास्तविक तारांना स्पर्श करत नाही, परंतु त्यांची संख्या संग्रहित करतो.

मला हे जावा कोडमध्ये पुन्हा लिहू द्या:

List<String> list = List.of("A", "C", "B", "Z", "Cc", "Bb", "Zz", "Y");  //this is a list of objects
List<String> alphabeticsList = new ArrayList(list);
Collections.sort(alphabeticsList); //collection sorted alphabetically

List<String> lengthList = new ArrayList(list);
Collections.sort(lengthList, lengthComparator); //collection sorted by string length

संग्रहांची क्रमवारी लावणे म्हणजे वास्तविक घटक हलवणे असा नाही. संग्रह वास्तविक वस्तू संग्रहित करत नाही, परंतु त्यांच्याशी लिंक करतो. SQL टेबल्ससाठीही हेच आहे. वास्तविक ओळी स्वत: ला खोटे बोलतात आणि खोटे बोलतात.

आणि जेव्हा आपल्याला काही फील्डसाठी वारंवार निवड करण्याची आवश्यकता असते, तेव्हा आम्ही टेबलमध्ये दुसरी अनुक्रमणिका जोडतो (जावामधील नवीन संग्रहाप्रमाणे) आणि टेबलच्या पंक्ती क्रमवारी लावतो, त्यांचा क्रमबद्ध क्रम एका विशेष इंडेक्स फाइलमध्ये संग्रहित करतो.

मला आशा आहे की जावा तुलना थोडी मदत करेल. थोडा सराव - आणि आपल्यासाठी, निर्देशांकांचा वापर देखील सर्वात स्पष्ट उपाय होईल.

7.2 टेबलमध्ये अनुक्रमणिका जोडणे

इंडेक्स टेबलच्या निर्मिती दरम्यान लगेच निर्दिष्ट केला जाऊ शकतो किंवा नंतर जोडला जाऊ शकतो. बर्‍याचदा, ही दुसरी परिस्थिती उद्भवते - सारणीचा आकार जसजसा वाढत जातो आणि डेटा सॅम्पलिंग मंदावतो तसतसे निर्देशांक जोडले जातात.

टेबलमध्ये निर्देशांक जोडणे खूप सोपे आहे:

ALTER TABLE table
    ADD INDEX index_name (column);

तुम्ही एकाच वेळी अनेक स्तंभांमध्ये रेकॉर्ड पाहत असल्यास, तुम्ही संमिश्र अनुक्रमणिका निर्दिष्ट करू शकता: SQL ते तयार करण्यासाठी एकाधिक स्तंभ वापरते.

सारणीमध्ये संमिश्र निर्देशांक जोडणे देखील खूप सोपे आहे:

ALTER TABLE table
    ADD INDEX index_name (column 1, column 2, column 3, ...);

इंडेक्स डिस्कमध्ये भरपूर जागा घेतात, त्यामुळे तुम्हाला यापुढे इंडेक्सची आवश्यकता नसल्यास, तुम्ही ते नेहमी काढू शकता:

ALTER TABLE table
    DROP INDEX index_name;

निर्देशांक स्वतःच डेटाबेसचा एक लपलेला भाग आहेत. ते प्रश्न लिहिण्याच्या स्वरूपावर कोणत्याही प्रकारे परिणाम करत नाहीत. फक्त त्यांची उपस्थिती डेटा सॅम्पलिंगला गती देते आणि त्यांची जोडणी आणि बॅकअप कमी करते.

परंतु आजच्या जगात वेग किती महत्त्वाचा आहे आणि डिस्क स्पेस किती स्वस्त आहे हे लक्षात घेऊन, सर्व प्रसंगांसाठी निर्देशांक जोडण्यास मोकळ्या मनाने. मला माफ करा अॅडमिन्स...