ULID জেনারেটর

সর্টযোগ্য, 26-অক্ষরের ULID (Crockford base32) জেনারেট করুন এবং এমবেডেড টাইমস্ট্যাম্পকে আবার তারিখে ডিকোড করুন। ডেটাবেস প্রাইমারি কী-র জন্য চমৎকার।

সর্টযোগ্য অনন্য শনাক্তকারী। একটি ULID হলো 26 অক্ষর: প্রথম 10টি মিলিসেকেন্ডে সৃষ্টির সময় এনকোড করে, শেষ 16টি র্যান্ডম। তাই সেগুলো লেক্সিকোগ্রাফিকভাবে সর্টযোগ্য এবং কী হিসাবে ব্যবহার করা নিরাপদ। আপনার ব্রাউজারে জেনারেট হয়।

ULID বনাম UUID

একটি ULID কী

একটি ULID হলো 128-বিট শনাক্তকারী, একটি UUID-এর সমান প্রস্থ, দুটি অংশে বিভক্ত: একটি 48-বিট মিলিসেকেন্ড টাইমস্ট্যাম্প এবং তারপরে 80টি র্যান্ডম বিট। এটি UUID-এর 36-অক্ষরের হাইফেনযুক্ত হেক্সের পরিবর্তে 26 অক্ষরের Crockford base32 হিসাবে রেন্ডার করা হয়, তাই এটি ছোট, কেস-সংবেদনশীল নয় এবং সবচেয়ে সহজে ভুলপড়া অক্ষরগুলো মুক্ত - I, L, O এবং U সবই বর্ণমালা থেকে বাদ দেওয়া হয়।

ফলস্বরূপ পার্থক্যটি এনকোডিং নয়, এটি অর্ডারিং। যেহেতু টাইমস্ট্যাম্পটি উচ্চ বিট দখল করে এবং base32 বাইট অর্ডার সংরক্ষণ করে, ULID-কে প্লেইন স্ট্রিং হিসাবে সাজালে সেগুলো সৃষ্টির সময় অনুসারে সাজানো হয়। একই মিলিসেকেন্ডে তৈরি দুটি ID তাদের র্যান্ডম উপাদানে ফিরে যায়, কিন্তু মিলিসেকেন্ড জুড়ে ক্রমটি নির্ভুল।

ডেটাবেসের জন্য সর্টেবিলিটি কেন গুরুত্বপূর্ণ

UUIDv4 সম্পূর্ণরূপে র্যান্ডম, যা একটি ক্লাস্টারড ইনডেক্সে আপনি যা চান না ঠিক তা। প্রতিটি ইনসার্ট B-ট্রিতে একটি র্যান্ডম পয়েন্টে পড়ে, তাই ডেটাবেস পেজ বিভক্ত করতে থাকে এবং ঠান্ডা পেজগুলো স্পর্শ করে। ইনডেক্স প্রয়োজনের চেয়ে বড় হয়ে যায় এবং টেবিল বাড়ার সাথে সাথে লেখার থ্রুপুট হ্রাস পায়। এটি MySQL-এর InnoDB এবং SQL Server-এ UUID প্রাইমারি কী-র একটি সুপরিচিত সমস্যা।

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

কখন অন্য কিছু ব্যবহার করবেন

UUIDv7, RFC 9562-এ মানকৃত, স্ট্যান্ডার্ড UUID ফরম্যাট এবং বিন্যাসে ULID-এর মতো একই কাজ করে। আপনার স্ট্যাকে যদি ইতিমধ্যেই নেটিভ UUID কলাম টাইপ এবং টুলিং থাকে, তবে UUIDv7 সাধারণত এখন ভালো পছন্দ, কারণ এটি কেবল বিদ্যমান ইকোসিস্টেমে ঢুকে যায়। ULID আকর্ষণীয় থাকে যখন আপনি URL বা লগে ছোট, বন্ধুত্বপূর্ণ টেক্সট ফর্ম চান।

যেভাবেই হোক, স্পষ্ট থাকুন যে টাইমস্ট্যাম্পটি ID ধারণকারী যে কারো কাছে দৃশ্যমান। সৃষ্টির সময় লিক হয়, এবং সন্নিহিত ID অর্ডার প্রকাশ করে - এনুমারেশন বা টাইমিং সংবেদনশীল এমন যেকোনো কিছুর জন্য এগুলো ব্যবহার করবেন না। এবং প্রতি মিলিসেকেন্ডে 80টি র্যান্ডম বিটে, সংঘর্ষ একটি বাস্তব উদ্বেগ নয়, তবে ULID গোপন নয় এবং কখনো ক্ষমতা টোকেন হিসাবে ব্যবহার করা উচিত নয়।

ওপেন-সোর্স নোট: crypto.getRandomValues এবং স্ক্র্যাচ থেকে তৈরি Crockford base32 কোডেক দিয়ে বাস্তবায়িত। কোনো থার্ড-পার্টি লাইব্রেরি নেই।

সচরাচর জিজ্ঞাসিত প্রশ্ন

একটি ULID কীভাবে একটি UUID থেকে ভিন্ন?
দুটোই 128 বিট, কিন্তু একটি ULID প্রথমে একটি 48-বিট মিলিসেকেন্ড টাইমস্ট্যাম্প রাখে, তাই স্ট্রিংগুলো সাজালে সৃষ্টির সময় অনুসারে সাজানো হয়। UUIDv4 সম্পূর্ণরূপে র্যান্ডম এবং নির্বিচারে সাজায়।
ডেটাবেসের জন্য সর্টেবিলিটি কেন গুরুত্বপূর্ণ?
র্যান্ডম প্রাইমারি কী একটি B-ট্রি জুড়ে ইনসার্ট ছড়িয়ে দেয় এবং ইনডেক্স ফ্র্যাগমেন্ট করে। সময়-ক্রমিক কী শেষের কাছে যুক্ত হয়, যা লেখাগুলো ক্রমিক রাখে এবং হট পেজগুলো ছোট রাখে।
একই মিলিসেকেন্ডে তৈরি ID কি এখনও ক্রমিক থাকে?
মনোটোনিক মোডে, হ্যাঁ। র্যান্ডম অংশ পুনরায় অঙ্কনের পরিবর্তে টুলটি এটিকে বৃদ্ধি করে, তাই এক মিলিসেকেন্ডের মধ্যে তৈরি বেশ কয়েকটি ID এখনও ক্রমে বেরিয়ে আসে।
একটি ULID কি জনসমক্ষে প্রকাশ করা নিরাপদ?
র্যান্ডম অর্ধ অনুমানযোগ্য নয়, কিন্তু টাইমস্ট্যাম্প যে কেউ পড়তে পারে। একটি রেকর্ডের সৃষ্টির সময় যদি সংবেদনশীল হয়, তবে এটির পাবলিক শনাক্তকারী হিসাবে ULID ব্যবহার করবেন না।
আমার কি ULID নাকি UUIDv7 বেছে নেওয়া উচিত?
তারা একই সমস্যা সমাধান করে। UUIDv7 RFC 9562-এ মানকৃত এবং বিদ্যমান UUID কলাম ও লাইব্রেরিতে খাপ খায়, তাই নতুন কাজের জন্য এটি পছন্দ করুন, যদি না আপনি বিশেষভাবে 26-অক্ষরের Crockford ফর্ম চান।
কেন 26 অক্ষর?
Crockford Base32-এ এনকোড করা 128 বিটের জন্য 26টি সিম্বল প্রয়োজন। প্রতিলিপি ভুল এবং আকস্মিক শব্দ উভয় এড়াতে বর্ণমালা I, L, O এবং U বাদ দেয়।