UUID v4 / UUID v7 / ULID পূর্ণাঙ্গ তুলনা: সময়রেখা, দক্ষতা ও পঠনযোগ্যতা কোনটিতে জেতায়

UUID ও ULID হলো বিতরণকৃত সিস্টেম বা ডেটাবেসে “একমাত্রিক আইডি” তৈরি করার পদ্ধতি। দেখতে মিল থাকলেও স্ট্যান্ডার্ডাইজেশন, সংরক্ষণের দক্ষতা, মানুষের পঠনযোগ্যতা, তথ্য ফাঁসের ঝুঁকি—এসবের পার্থক্য বড়। এখানে তিনটি জনপ্রিয় পদ্ধতি—UUID v4, UUID v7, ULID—এর বৈশিষ্ট্য ও বেছে নেওয়ার গাইডলাইন সাজিয়ে, শেষে UUID v1 / v6 নিয়ে সংক্ষিপ্ত আলোচনা রেখেছি।

প্রতিটি আইডি তৈরি ও সময় তথ্য পড়ার জন্য সম্পূর্ণ ব্রাউজারভিত্তিক টুলগুলো এখানে:

• UUIDv4 জেনারেটর
• UUIDv7 জেনারেটর
• UUIDv7 সময় তথ্য রিডার
• ULID জেনারেটর
• ULID সময় তথ্য রিডার

UUID v4: সম্পূর্ণ র‌্যান্ডম ধারা

UUID v4-এ 128 বিটের মধ্যে 122 বিট র‌্যান্ডম, ফলে সংঘর্ষ সম্ভাবনা অত্যন্ত কম। তবে সময়ক্রমে সাজে না, তাই B-Tree ইন্ডেক্সে পেজ স্প্লিট বারবার হয়, ইনসার্ট লোক্যালিটি খারাপ। সেশন আইডি বা ওয়ান-টাইম কী—যেখানে “র‌্যান্ডম হলেই চলবে”—এ ধরনের কাজে উপযোগী।

UUID v7: সময় অনুযায়ী সাজানো সোজা বিবর্তন

2024 সালে RFC 9562 এ স্ট্যান্ডার্ড হওয়া UUID v7-এর প্রথম 48 বিটে ইউনিক্স এপোক সময় (মিলিসেকেন্ড) থাকে, বাকি অংশ র‌্যান্ডম। স্ট্রিং তুলনা মানেই সময়ক্রম—তাই প্রাইমারি কী হিসেবে ইন্ডেক্স লোক্যালিটি ভালো। বিদ্যমান uuid টাইপ বা BINARY(16) এ সরাসরি রাখা যায়—এটাও বড় সুবিধা।

• র‌্যান্ডম বিটের দৈর্ঘ্য: v7-এ version/variant বিট বাদে মোটামুটি প্রায় 74 বিট র‌্যান্ডম থাকে। কিছু ইমপ্লিমেন্টেশনে মনোটনিক জেনারেশন (একই মিলিসেকেন্ডে সংঘর্ষ ঠেকাতে) র‌্যান্ডমের অংশ সামান্য সামঞ্জস্য করে, কিন্তু পরিসংখ্যানগত র‌্যান্ডমনেস যথেষ্ট।
• তথ্য ফাঁস ঝুঁকি: আইডি থেকেই সৃষ্টির সময় (মিলিসেকেন্ড) জানা যায়। যদি প্রচুর আইডি তৈরি হয় আর র‌্যান্ডম দুর্বল হয়, তবে পাশের আইডি অনুমান তুলনামূলক সহজ হতে পারে। অভ্যন্তরীণ সিস্টেমে সাধারণত সমস্যা নয়, তবে পাবলিক এন্ডপয়েন্টে সিরিয়াল প্রকাশ অপছন্দ হলে সতর্ক থাকা দরকার।

ULID: মানুষের জন্য বেশি বন্ধুসুলভ আইডি

ULID হলো 2016 সালে প্রস্তাবিত একটি ডি-ফ্যাক্টো স্ট্যান্ডার্ড, যেখানে Crockford Base32-এর 26 অক্ষর দিয়ে মান প্রকাশ হয়। পড়তে সমস্যা হয় এমন অক্ষর (O/I/L/1) বাদ, URL-এ বসানো ও কপি সহজ। UUID v7-এর মতোই, প্রথম 48 বিটে সময় (মিলিসেকেন্ড) থাকে—তাই স্ট্রিংয়ের অভিধান ক্রম = সময়ক্রম।

• সোর্ট গ্যারান্টি: ULID স্ট্রিংগুলোর অভিধান ক্রম সবসময় সময়ক্রমের সমান (মনোটনিক জেনারেশনও প্রচলিত)।
• সংরক্ষণের ধরন: TEXT(26)-এ পড়তে সুবিধা, কিন্তু ডেটাবেসে বাইনারি রাখতে Base32 ↔ 16 বাইট রূপান্তর দরকার। 128 বিটের বাইনারি হিসেবে রাখা যায়, কিন্তু RDB-এর UUID স্পেশাল টাইপের সাথে অসামঞ্জস্য বেশি।
• তথ্য ফাঁস ঝুঁকি: v7-এর মতোই, সময় (মিলিসেকেন্ড) প্রকাশ পায়। পাবলিক API-র রিসোর্স আইডি যেখানে “প্রকাশের ক্রম বোঝা যাবে না” চাই, সেখানে বিচার করে ব্যবহার করতে হবে।

তিন পদ্ধতির তুলনামূলক টেবিল (প্র্যাকটিক্যাল দৃষ্টিতে)

পরিশিষ্ট (v7/ULID-এর হটস্পট সমস্যা): একক শার্ড বা একক লিডারে শেষ প্রান্তে ইনসার্ট জমলে B-Tree-র শেষ অংশ গরম হয়ে যেতে পারে। সমাধান হিসেবে উপরের বিটে সামান্য শাফল (“prefix shuffle”) বা শার্ডিং কী বিবেচনা করুন।

ডেটাবেস ইমপ্লিমেন্টেশন নোট (PostgreSQL / MySQL / SQLite)

• PostgreSQL
  • v4/v7: uuid টাইপ সবচেয়ে ভাল। v7 স্ট্রিংকে uuid-এ রূপান্তর করলে সোর্ট সুবিধা মেলে।
  • ULID: char(26)/text বা bytea(16) (Base32 রূপান্তর) দিয়ে চালাতে হয়।
• MySQL / InnoDB
  • BINARY(16) সবচেয়ে দ্রুত ও সাশ্রয়ী (v4/v7)। v7-এ বিগ এন্ডিয়ান বিন্যাস রেখে তুললে সময়ক্রমে সাজে। ULID হলে CHAR(26) বা BINARY(16) + রূপান্তর।
• SQLite
  • আলাদা UUID টাইপ নেই। BLOB(16) বা TEXT হিসাবে ব্যবহার করুন। ইন্ডেক্সসহ BLOB তুলনা তুলনামূলক দ্রুত।

সিকিউরিটি দৃষ্টিকোণ থেকে

• অনুমান প্রতিরোধ: v7/ULID-এ সময়ের বিট মিল থাকায়, একই মিলিসেকেন্ডে অনেক আইডি তৈরি করলে আর র‌্যান্ডম দুর্বল হলে পাশের আইডি অনুমান ঝুঁকি বাড়ে। তাই ক্রিপ্টোগ্রাফিক PRNG ব্যবহার করুন, মনোটনিক জেনারেশনের পক্ষপাত কমান।
• মেটাডেটা ফাঁস: আইডি থেকে সৃষ্টির সময় ও মোটামুটি উৎপাদন পরিমাণ অনুমান করা যায়। পাবলিক API-তে অভ্যন্তরীণ আইডি ও প্রকাশিত আইডি আলাদা রাখা নিরাপদ।

সংক্ষেপে (বেছে নেওয়ার গাইড)

• UUID v4: সম্পূর্ণ র‌্যান্ডম। সময়ক্রম নেই। তাত্ত্বিক সংঘর্ষ ঝুঁকি সামান্য আছে। সেশন আইডি বা CSRF টোকেনের মতো ক্ষেত্রে উপযোগী।
• UUID v7: সুশৃঙ্খলভাবে সাজানো UUID। অভ্যন্তরীণ সিস্টেম বা ডেটাবেস প্রাইমারি কী-তে আদর্শ। মনোটনিক জেনারেশনে সংঘর্ষ বাস্তবে এড়ানো যায়।
• ULID: (অন্য দুটির তুলনায়) মানুষ-পঠিত বন্ধুসুলভ। URL বা লগের পঠনযোগ্যতা গুরুত্বপূর্ণ হলে শক্ত প্রার্থী, তবে অভ্যন্তরীণ প্রাইমারি কী হিসেবে বেশিরভাগ সময় v7-ই সুবিধাজনক। মনোটনিক জেনারেশন এখানে-ও সংঘর্ষ কমায়।

পরিশিষ্ট: UUID v1 / v6 (সংক্ষিপ্ত)

• UUID v1 (টাইম + MAC) 60 বিট টাইমস্ট্যাম্প (100ns ইউনিট) + নোড আইডি (প্রায়শই MAC ঠিকানা)। সময়ক্রম শক্তিশালী, তবে MAC থেকে হোস্ট তথ্য ফাঁস ঝুঁকি আছে; ক্লক পিছলে গেলে সামলানোও কঠিন। আধুনিক সময়ে গোপনীয়তার কারণে অপ্রস্তাবিত।

• UUID v6 (v1-এর পুনর্বিন্যাস) v1-এর টাইমস্ট্যাম্পকে বিগ এন্ডিয়ানে সাজিয়ে অভিধান ক্রম উন্নত করার প্রস্তাব। ইতিহাসে “সাজানো সহজ v1” হিসেবে আলোচিত হলেও, স্ট্যান্ডার্ডাইজেশন শেষ পর্যন্ত v7-এ গিয়ে থেমেছে। নতুন ডিজাইনে সাধারণত v6-এর বদলে v7 বেছে নেওয়া হয়।

চেকলিস্ট: বাস্তবায়নে কী দেখবেন

• র‌্যান্ডম অবশ্যই ক্রিপ্টোগ্রাফিক PRNG (ওএস প্রদান করা নিরাপদ উৎস) থেকে নিন।
• v7/ULID-এর মনোটনিক জেনারেশন একই মিলিসেকেন্ডে সংঘর্ষ এড়ায়, তবে র‌্যান্ডম পক্ষপাত কমিয়ে রাখুন।
• ডেটাবেসে সম্ভব হলে uuid টাইপ / BINARY(16) ব্যবহার করুন, স্ট্রিং কোলেশনজনিত পারফরম্যান্স ক্ষতি এড়াতে।
• বাহ্যিক আইডি নীতিমালা (সিরিয়াল প্রকাশযোগ্য কি না ) আগে ঠিক করুন। প্রয়োজন হলে অভ্যন্তরীণ ও বাহ্যিক আইডি আলাদা রাখুন।

সব মিলিয়ে প্রযুক্তিগত বাস্তবতায় অভ্যন্তরীণ প্রাইমারি কী হিসেবে UUID v7 প্রথম পছন্দ, আর পঠনযোগ্যতা জরুরি বা বিশেষ সীমাবদ্ধতা থাকলে ULID একটি যুক্তিসঙ্গত বিকল্প। সময় প্রকাশ নিষেধ বা অন্য বিশেষ চাহিদা থাকলেই কেবল v4 বা অন্য পদ্ধতি বিবেচনা করা উচিত।