UUID v7 জেনারেটর পৃষ্ঠা: সময়-ভিত্তিক অনন্য শনাক্তকারী তৈরি করার সম্পূর্ণ নির্দেশিকা
এই পৃষ্ঠাটি আপনাকে UUID v7 ফরম্যাটে এক থেকে একশোটি পর্যন্ত অনন্য শনাক্তকারী (আইডি) তৈরি করতে দেয়। আপনি একটি সংখ্যা নির্বাচন করেন (১ থেকে ১০০ এর মধ্যে), কয়েকটি প্রদর্শন পছন্দ সেট করেন, এবং পৃষ্ঠাটি তৎক্ষণাৎ একটি তালিকা তৈরি করে — প্রতিটি আইডি একটি ৩৬ অক্ষরের স্ট্রিং, যা সময় অনুসারে সাজানো এবং অনুমান করা অসম্ভব। পৃথক আইডি কপি করা যায় বা একবারে সবগুলো কপি করা যায়।
UUID v7 কী এবং কেন এটি অন্যদের থেকে আলাদা
UUID v7 হলো ইউনিভার্সাল ইউনিক আইডেন্টিফায়ারের সপ্তম সংস্করণ। এটি একটি ১২৮-বিট মান, যা দুটি প্রধান অংশ নিয়ে গঠিত: প্রথম ৪৮ বিট হলো ইউনিক্স মিলিসেকেন্ড টাইমস্ট্যাম্প (১৯৭০ সালের ১ জানুয়ারি থেকে মিলিসেকেন্ডে গণনা করা সময়), এবং বাকি ৮০ বিট হলো ক্রিপ্টোগ্রাফিক্যালি শক্তিশালী র্যান্ডম সংখ্যা। টেক্সট উপস্থাপনায় এটি ৩৬ অক্ষরের একটি স্ট্রিং, যেখানে ৩২টি হেক্সাডেসিমেল অক্ষর এবং ৪টি হাইফেন (স্ট্যান্ডার্ড ফরম্যাটে) থাকে, যেমন 018f3a6e-1b2c-7d8e-9f0a-123456789abc।
UUID v7-এর মূল বৈশিষ্ট্য হলো এটি তৈরি হওয়ার সময় অনুসারে সাজানো যায়। যেহেতু প্রথম অক্ষরগুলো টাইমস্ট্যাম্প নির্দেশ করে, তাই ডেটাবেসে সংরক্ষণ করলে এগুলি কালানুক্রমিকভাবে (chronologically) কাছাকাছি থাকে। এটি UUID v4-এর একটি বড় সমস্যার সমাধান করে: UUID v4 সম্পূর্ণ র্যান্ডম, তাই ডেটাবেসে ইনসার্ট করলে বিট্রি (B-tree) ইনডেক্সে ফ্র্যাগমেন্টেশন তৈরি হয়, যা কর্মক্ষমতা কমিয়ে দেয়।
তবে UUID v7 একই মিলিসেকেন্ডে তৈরি আইডিগুলোর জন্য কঠোর ক্রম (strict ordering) নিশ্চিত করে না। যদি একই মিলিসেকেন্ডে একাধিক UUID v7 তৈরি করা হয়, তবে তাদের অর্ডার নির্ভর করবে র্যান্ডম অংশের উপর, টাইমস্ট্যাম্পের উপর নয় — কারণ টাইমস্ট্যাম্প একই থাকে। এটি ডিজাইন অনুসারে: প্যারালাল সিস্টেমে একাধিক জেনারেটর একই মিলিসেকেন্ডে কাজ করতে পারে এবং তাদের আইডি কখনোই সংঘর্ষ করবে না, কিন্তু তাদের মধ্যে কে আগে তৈরি হয়েছে তা নির্ধারণ করা যায় না।
UUID v7 জেনারেটর পৃষ্ঠার ইনপুট ও আউটপুট
ইনপুট বিকল্পসমূহ
| ইনপুট | বিবরণ | অনুমোদিত মান |
|---|---|---|
| ফরম্যাট | UUID v7 (ফরম্যাট পিকার থেকে নির্বাচিত) | UUID v7 |
| সংখ্যা (Count) | কতটি আইডি তৈরি হবে | ১ থেকে ১০০ (সহ) |
| বড় হাতের অক্ষর (Uppercase) | হ্যাঁ/না টগল | UUID-তে A-F বড় হাতে বা ছোট হাতে |
| হাইফেন অন্তর্ভুক্তি (Include hyphens) | হ্যাঁ/না টগল | স্ট্যান্ডার্ড ফরম্যাটে হাইফেন সহ বা ছাড়া |
আউটপুট ও অবস্থা বার্তা
- তালিকা: তৈরি হওয়া UUID v7 আইডিগুলোর একটি তালিকা, প্রতিটি আলাদা লাইনে।
- আইডি সংখ্যা (ID count): তালিকায় মোট কয়টি আইডি আছে তা দেখায়।
- "Ready." অবস্থা: পৃষ্ঠাটি নিষ্ক্রিয় অবস্থায় থাকে।
- "Generated." অবস্থা: আইডি তৈরি হওয়ার পর দেখায়।
- "Copied all!" অবস্থা: যখন ব্যবহারকারী "সব কপি করুন" বোতামে ক্লিক করেন এবং সবগুলো আইডি ক্লিপবোর্ডে কপি হয়।
- পৃথক আইডি কপি: যেকোনো একটি আইডির উপর ক্লিক করলে সেটি ক্লিপবোর্ডে কপি হয়।
নিয়ম ও বিশেষ ক্ষেত্র
- যেকোনো ইনপুট পরিবর্তন করলেই (সংখ্যা, বড় হাতের অক্ষর, হাইফেন) সঙ্গে সঙ্গে সব আইডি পুনরায় তৈরি হয়। কোনো "জেনারেট" বোতামে ক্লিক করার প্রয়োজন নেই।
- আইডি সম্পূর্ণ ব্রাউজারের ভিতরে তৈরি হয়। ব্রাউজারের ক্রিপ্টো API (যেমন
crypto.getRandomValues) ব্যবহার করে র্যান্ডম সংখ্যা উৎপন্ন হয়। কোনও ডেটা ব্রোব্রোগো (BroBroGo) সার্ভারে পাঠানো হয় না। - UUID v7 এবং ULID উভয়ই টাইমস্ট্যাম্প-ভিত্তিক এবং সাজানো যায়, কিন্তু উভয়ই একই মিলিসেকেন্ডে তৈরি আইডিগুলোর জন্য কঠোর ক্রম নিশ্চিত করে না।
- সর্বোচ্চ ১০০টি আইডি একবারে তৈরি করা যায়। আরও প্রয়োজন হলে পুনরায় জেনারেট করতে পারেন।
UUID v7 বনাম UUID v4: মূল পার্থক্য
UUID v4 দীর্ঘদিন ধরে মানসম্পন্ন র্যান্ডম আইডি হিসেবে ব্যবহৃত হচ্ছে। কিন্তু ডেটাবেস কর্মক্ষমতার দৃষ্টিকোণ থেকে UUID v4-এর একটি গুরুতর দুর্বলতা আছে:
-
ইনডেক্স লোকালিটি (Index Locality): UUID v4 সম্পূর্ণ র্যান্ডম, তাই বিট্রি ইনডেক্সে নতুন রেকর্ড ইনসার্ট করলে প্রায়শই বিভিন্ন পৃষ্ঠায় (page) পড়ে। এর ফলে ইনডেক্সের ঘন ঘন স্প্লিট হয় এবং ডিস্ক I/O বেড়ে যায়। UUID v7-এ টাইমস্ট্যাম্প অংশের কারণে একই সময়ের কাছাকাছি আইডিগুলো একই বা কাছাকাছি বিট্রি পাতায় পড়ে, যা ইনডেক্সের কার্যকারিতা উন্নত করে।
-
সংঘর্ষের সম্ভাবনা (Collision Probability): UUID v4-এ ১২২ বিট র্যান্ডম সংখ্যা (৬টি সংস্করণ ও বৈচিত্র্য বিট বাদে) ব্যবহার হয়, যার ফলে সংঘর্ষের সম্ভাবনা অত্যন্ত কম। UUID v7-এ ৭৪ বিট র্যান্ডম সংখ্যা (টাইমস্ট্যাম্পের জন্য ৪৮ বিট বাদে) থাকে, কিন্তু টাইমস্ট্যাম্পের কারণে একই সময়ে তৈরি আইডির সংখ্যা সীমিত, তাই সামগ্রিক সংঘর্ষের ঝুঁকি একই রকম কম।
-
অনুমানযোগ্যতা (Guessability): UUID v4 সম্পূর্ণ র্যান্ডম এবং অনুমান করা অত্যন্ত কঠিন। UUID v7-ও একইভাবে অনুমান করা কঠিন, যেহেতু র্যান্ডম অংশটি ক্রিপ্টোগ্রাফিক্যালি শক্তিশালী। তবে টাইমস্ট্যাম্প অংশটি আইডির প্রথম কয়েক অক্ষর দেখে আনুমানিক তৈরি সময় বের করা সম্ভব, যা কিছু সিকিউরিটি সিস্টেমে গোপনীয়তা প্রকাশ করতে পারে।
-
ব্যবহারিক উদাহরণ: ধরুন আপনি একটি ই-কমার্স অর্ডার সিস্টেমে UUID ব্যবহার করছেন। UUID v4 ব্যবহার করলে অর্ডারগুলোর আইডি ক্রমহীনভাবে ডেটাবেসে ইনসার্ট হবে; ১০০০টি অর্ডারের জন্য ইনডেক্সে ছড়িয়ে পড়বে। UUID v7 ব্যবহার করলে আইডিগুলো অর্ডার সময় অনুসারে কাছাকাছি থাকবে, যার ফলে ইনসার্ট দ্রুত হবে এবং ডিস্ক স্পেস কম নষ্ট হবে।
কাদের জন্য এই টুলটি প্রয়োজনীয়
১. ডিস্ট্রিবিউটেড সিস্টেম ডেভেলপার: যারা মাইক্রোসার্ভিস, ইভেন্ট সোর্সিং, বা মেসেজিং সিস্টেমে কালানুক্রমিকভাবে সাজানো যায় এমন অনন্য আইডি প্রয়োজন।
২. ডেটাবেস অ্যাডমিনিস্ট্রেটর: যারা UUID v4-এর কারণে বিট্রি ইনডেক্স ফ্র্যাগমেন্টেশনের মুখোমুখি হন এবং বিকল্প খুঁজছেন। UUID v7-এ স্যুইচ করলে ইনসার্ট কর্মক্ষমতা উন্নত হয় এবং রি-ইনডেক্সিংয়ের প্রয়োজন কমে।
৩. নিরাপত্তা-সচেতন প্রকৌশলী: যাদের অ-অনুমানযোগ্য আইডি প্রয়োজন কিন্তু সময়-ভিত্তিক সাজানোর সুবিধাও চান। UUID v7-এর র্যান্ডম অংশটি ক্রিপ্টোগ্রাফিক মানদণ্ডে শক্তিশালী, তাই এটি হ্যাকিং প্রতিরোধে কার্যকর।
৪. UUID v4 থেকে মাইগ্রেটকারী: যারা পুরনো র্যান্ডম আইডি সিস্টেম আপগ্রেড করে টাইম-বেসড ফরম্যাটে যেতে চান, যা ইনসার্ট কর্মক্ষমতা উন্নত করে এবং অনন্যতার নিশ্চয়তা বজায় রাখে।
UUID v7 কাঠামো ও বাস্তবায়ন বিশদ
UUID v7 এর বিট অ্যালোকেশন RFC 9562 (পূর্বে IETF ড্রাফট) অনুযায়ী:
- বিট ০-৪৭: ইউনিক্স টাইমস্ট্যাম্প (মিলিসেকেন্ড, ৪৮ বিট)। সর্বাধিক প্রায় ১০,০০০ বছর পর্যন্ত সময় ধারণ করতে পারে।
- বিট ৪৮-৫১: UUID সংস্করণ (ver) = 7 (০১১১ বাইনারি)
- বিট ৫২-৫৫: UUID বৈচিত্র্য (variant) = 10xx (RFC 4122 অনুসারে ২ বিট)
- বিট ৫৬-৬৩: র্যান্ডম বা কাউন্টার (৮ বিট)
- বিট ৬৪-১২৭: র্যান্ডম (৬৪ বিট)
টেক্সট ফরম্যাট: TTTTTTTT-TTTT-VTTT-ARRR-RRRRRRRRRRRR যেখানে T = টাইমস্ট্যাম্প (হেক্স), V = সংস্করণ (7), A = বৈচিত্র্য (8, 9, A, or B), R = র্যান্ডম।
হাইফেন এবং অক্ষরের কেস পরিবর্তন করলে UUID-র মান পরিবর্তন হয় না — শুধু উপস্থাপনা পদ্ধতি বদলায়। ডেটাবেসে সংরক্ষণের সময় হাইফেন ছাড়া ছোট হাতের অক্ষর ব্যবহার করা সুবিধাজনক, কিন্তু প্রদর্শনে হাইফেন পড়া সহজ।
সাধারণ ভুল ও সতর্কতা
- একই মিলিসেকেন্ডে অর্ডার: মনে রাখবেন, UUID v7 দুটি আইডি একই মিলিসেকেন্ডে তৈরি হলে তাদের মধ্যে কে আগে তা নির্ধারণ করা যায় না। যদি আপনার কঠোর ক্রম প্রয়োজন (যেমন ইভেন্ট লগে প্রতিটি ইভেন্টের জন্য নিখুঁত অর্ডার), তাহলে কাউন্টার বা সিকোয়েন্স নম্বর ব্যবহার করুন।
- টাইমস্ট্যাম্প গোপনীয়তা: UUID v7-এর টাইমস্ট্যাম্প অংশ থেকে আইডি তৈরি হওয়ার সময় অনুমান করা যায়। যদি আপনার প্রয়োজনে সময় গোপন রাখা জরুরি (যেমন টিকিট নম্বর), তাহলে UUID v4 বা NanoID ব্যবহার করা ভালো।
- ডেটাবেস ইনডেক্স: UUID v7 টাইমস্ট্যাম্প-প্রথম ফরম্যাটে বিট্রি ইনডেক্সের জন্য উপযুক্ত, কিন্তু কিছু ডেটাবেসে UUID টাইপের কলামে ডিফল্ট ইনডেক্সিং পদ্ধতি ভিন্ন হতে পারে। আপনার ডেটাবেসের UUID হ্যান্ডলিং ডকুমেন্টেশন দেখে নিন।
- সংঘর্ষ ব্যবস্থাপনা: যদিও সংঘর্ষের সম্ভাবনা অত্যন্ত কম, তবে তাত্ত্বিকভাবে সম্ভব। ডিস্ট্রিবিউটেড সিস্টেমে ডেটাবেস ইউনিক কনস্ট্রেন্ট ব্যবহার করে সংঘর্ষ প্রতিরোধ করা উচিত।
প্রশ্নোত্তর (FAQ)
প্রশ্ন ১: UUID v7 কি UUID v4-এর মতোই অনন্য? উত্তর: হ্যাঁ, সংঘর্ষের সম্ভাবনা প্রায় একই। UUID v7-এ কম র্যান্ডম বিট থাকলেও টাইমস্ট্যাম্পের কারণে একই সময়ে তৈরি আইডির সংখ্যা সীমিত থাকে, ফলে সামগ্রিক সংঘর্ষের সম্ভাবনা UUID v4-এর সমতুল্য।
প্রশ্ন ২: আমি কি এই পৃষ্ঠায় তৈরি আইডি সরাসরি প্রোডাকশনে ব্যবহার করতে পারি? উত্তর: হ্যাঁ, কারণ আইডিগুলো আপনার ব্রাউজারের ভিতরে তৈরি হয় এবং কোনো সার্ভারে পাঠানো হয় না। তবে নিশ্চিত করুন যে আপনার ব্রাউজার সঠিক সিস্টেম টাইম ব্যবহার করছে এবং টাইমস্ট্যাম্পের জন্য পর্যাপ্ত নির্ভুলতা আছে।
প্রশ্ন ৩: UUID v7 এবং ULID-এর মধ্যে পার্থক্য কী? উত্তর: উভয়ই টাইমস্ট্যাম্প-ভিত্তিক এবং সাজানো যায়। UUID v7 ৩৬ অক্ষরের স্ট্যান্ডার্ড UUID ফরম্যাট ব্যবহার করে, যেখানে ULID ২৬ অক্ষরের ক্রকফোর্ড বেস৩২ ফরম্যাট ব্যবহার করে। ULID এক মিলিসেকেন্ডের মধ্যে আরও সূক্ষ্ম অর্ডারিং দিতে পারে (কাউন্টার ব্যবহার করে), কিন্তু UUID v7-এ তা নেই।
প্রশ্ন ৪: কেন হাইফেন এবং বড় হাতের অক্ষর পরিবর্তন করলে আইডি পুনরায় তৈরি হয়? উত্তর: পৃষ্ঠাটি প্রতিটি ইনপুট পরিবর্তনের সাথে সাথে সম্পূর্ণ নতুন তালিকা জেনারেট করে, যাতে ব্যবহারকারী সবসময় সাম্প্রতিক পছন্দের সাথে সঙ্গতিপূর্ণ আইডি দেখতে পান। এটি ডিজাইন অনুসারে।
প্রশ্ন ৫: আমি কি একবারে ১০০-এর বেশি আইডি তৈরি করতে পারি? উত্তর: না, সর্বোচ্চ সীমা ১০০। প্রয়োজনে একাধিকবার জেনারেট করে আইডি সংগ্রহ করতে পারেন। তবে মনে রাখবেন, প্রতিবার জেনারেট করলে টাইমস্ট্যাম্প পরিবর্তিত হবে, তাই আইডিগুলো আলাদা মিলিসেকেন্ডের অন্তর্ভুক্ত হবে।
প্রশ্ন ৬: UUID v7 কি RFC-তে স্বীকৃত? উত্তর: হ্যাঁ, UUID v7 RFC 9562-তে সংজ্ঞায়িত। এটি UUID স্পেসিফিকেশনের সর্বশেষ সংস্করণগুলির একটি এবং ব্যাপকভাবে গৃহীত হচ্ছে।