INDEX: সূচক

7.1 সূচকের উপস্থিতির কারণ

আরেকটি গুরুত্বপূর্ণ বিষয় যা ছাড়া কোন ডাটাবেস থাকতে পারে না তা হল সূচী।

এমন একটি পরিস্থিতি কল্পনা করুন যেখানে ব্যবহারকারীর টেবিলে 10 মিলিয়ন ব্যবহারকারী রয়েছে এবং আপনি 90 এর উপরে লেভেল আছে এমন প্রত্যেককে প্রদর্শন করতে চান। এই প্রশ্নটি লিখতে খুব সহজ:

SELECT * FROM user WHERE level > 90

দুর্দান্ত, আমরা এক মিনিটেরও কম সময়ের মধ্যে অনুরোধটি লিখেছি। এবং এসকিউএল সার্ভার থেকে এই প্রশ্নটি কার্যকর করতে কতক্ষণ সময় লাগবে? এই ধরনের একটি প্রশ্ন চালানোর জন্য, তাকে 10 মিলিয়ন রেকর্ডের মধ্য দিয়ে যেতে হবে এবং শুধুমাত্র একটি রেকর্ড থাকলেও এটি অনেক সময় লাগবে।

কিভাবে আমরা জাভা একটি অনুরূপ কাজ করতে হবে? আমরা প্রথমে স্তর অনুসারে ব্যবহারকারীদের সংগ্রহ বাছাই করব এবং তারপরে আমরা একটি বাইনারি অনুসন্ধান ব্যবহার করে খুব দ্রুত প্রয়োজনীয় রেকর্ডগুলি খুঁজে পেতে পারব। আমি এটা কি ব্যাখ্যা করার প্রয়োজন নেই আশা করি?

দুর্দান্ত, কিন্তু এখন যদি আমাদের এমন ব্যবহারকারীদের নির্বাচন করতে হয় যাদের নিবন্ধনের তারিখ 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}.

এই আইডির অ্যারেগুলিকে ইনডেক্স বলা হয় । উপাদানগুলি নিজেরাই বড়, আমরা তাদের স্পর্শ করি না। জাভাতে, আমরা বস্তুকে স্পর্শ করি না, কিন্তু তাদের রেফারেন্স সংরক্ষণ করি; এসকিউএল-এ, আমরা বাস্তব স্ট্রিংগুলি স্পর্শ করি না, তবে তাদের সংখ্যা সংরক্ষণ করি।

আমাকে জাভা কোডে এটি পুনরায় লিখতে দিন:

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;

সূচীগুলি নিজেই ডাটাবেসের একটি লুকানো অংশ। তারা কোনোভাবেই প্রশ্ন লেখার বিন্যাসকে প্রভাবিত করে না। এটি কেবলমাত্র তাদের উপস্থিতি ডেটা স্যাম্পলিংকে গতি দেয় এবং তাদের সংযোজন এবং ব্যাকআপকে ধীর করে দেয়।

কিন্তু আজকের বিশ্বে গতি কতটা গুরুত্বপূর্ণ এবং ডিস্ক স্পেস কতটা সস্তা তা বিবেচনা করে, সমস্ত অনুষ্ঠানের জন্য সূচী যোগ করতে নির্দ্বিধায়৷ আমাকে মাফ করবেন এডমিন...