অন্য দিন HB টিম চ্যাট করছিল এবং বেন, আমাদের ডেভ-অপস মাস্টার, উল্লেখ করেছেন যে তিনি চান যে তিনি একটি নির্দিষ্ট সিস্টেমের জন্য UUID-এর পরিবর্তে ULID ব্যবহার করবেন।
যে কোনো অভিজ্ঞ ইঞ্জিনিয়ারের মতো, আমার প্রতিক্রিয়া ছিল অ-প্রতিশ্রুতিহীন কিছু বকবক করা, তারপর ULID কী জিনিস তা বোঝার জন্য Google-এর কাছে লুকিয়ে থাকা।
দুই ঘন্টা পরে আমি হাজার গজ দৃষ্টিতে আবির্ভূত হলাম এবং উপলব্ধি করলাম যে অনন্য শনাক্তকারীর জগৎ আমার কল্পনার চেয়েও বড় এবং আরও বিস্ময়কর।
আমরা ULID-এর সাথে শুরু করার আগে, আসুন মূল বিষয়গুলিতে ফিরে যাই এবং আলোচনা করি যে UUIDগুলি কী:
"নিয়মিত" আইডিতে সমস্যা কি?
বেশিরভাগ ওয়েব অ্যাপ্লিকেশন যা ডাটাবেস ডিফল্ট সংখ্যাসূচক আইডি ব্যবহার করে যা স্বয়ংক্রিয়ভাবে বৃদ্ধি পায়। উদাহরণস্বরূপ, রেলগুলিতে আপনি এইরকম আচরণ দেখতে পারেন:
p1 = Person.create!
p1.id
# => 1
p2 = Person.create!
p2.id
# => 2
ডেটাবেস ক্রমিক আইডি তৈরি করতে পারে কারণ এটি একটি কাউন্টার সঞ্চয় করে যা রেকর্ড তৈরিতে বৃদ্ধি পায়।
এই প্যাটার্ন ডাটাবেসের বাইরেও দেখা যায়। কখনও কখনও আমাদের ম্যানুয়ালি আইডি বরাদ্দ করতে হয়, এবং আমরা একটি কাস্টম কাউন্টার সংরক্ষণ করতে পারি - বলুন - একটি Redis উদাহরণ৷
অনুক্রমিক আইডিগুলি কম-ভলিউমের ব্যবহারের ক্ষেত্রে প্রয়োগ করা সহজ, কিন্তু ভলিউম বৃদ্ধির সাথে সাথে সেগুলি আরও সমস্যাযুক্ত হয়ে ওঠে:
- একসাথে রেকর্ড তৈরি করা অসম্ভব কারণ প্রতিটি সন্নিবেশের জন্য তার আইডি পাওয়ার জন্য লাইনে অপেক্ষা করতে হয়।
- একটি অনুক্রমিক আইডি অনুরোধ করার জন্য একটি নেটওয়ার্ক রাউন্ড ট্রিপের প্রয়োজন হতে পারে এবং এর ফলে কর্মক্ষমতা ধীর হতে পারে৷
- অনুক্রমিক আইডি প্রদান করে এমন ডেটা স্টোরের সংখ্যা বের করা কঠিন। আপনাকে বিভিন্ন সার্ভারের কাউন্টারগুলি সিঙ্কের বাইরে চলে যাওয়ার বিষয়ে চিন্তা করতে হবে৷
- কাউন্টার সহ নোডের ব্যর্থতার একক বিন্দুতে পরিণত হওয়া সহজ।
অনুক্রমিক আইডিও ডেটা ফাঁস করে, যা কিছু ক্ষেত্রে সমস্যা হতে পারে:
- আপনি সহজেই অনুমান করতে পারেন সম্পদের আইডি যা আপনার নাও হতে পারে।
- আপনি যদি একজন ব্যবহারকারী তৈরি করেন এবং তার আইডি 20 হয়, তাহলে আপনি জানেন যে পরিষেবাটির 20 জন ব্যবহারকারী রয়েছে৷
UUID হল ওয়েব-স্কেল
UUIDs অনুক্রমিক আইডি থেকে একটু ভিন্ন দেখায়। এগুলি হল 128-বিট সংখ্যা, সাধারণত 32 হেক্সাডেসিমেল সংখ্যা হিসাবে প্রকাশ করা হয়:
123e4567-e89b-12d3-a456-426655440000
UUID গুলি RFC 4122-এ সংজ্ঞায়িত নির্দিষ্ট অ্যালগরিদম ব্যবহার করে তৈরি করা হয়৷ তারা ক্রমিক আইডিগুলির সাথে ঘটে এমন অনেক সমস্যা সমাধান করার চেষ্টা করে:
- আপনি কোনো শেয়ার করা অবস্থা বা নোডের মধ্যে সমন্বয় ছাড়াই যেকোনো সংখ্যক নোডে UUID তৈরি করতে পারেন।
- এগুলি অনুক্রমিক আইডির তুলনায় একটু কম অনুমানযোগ্য (পরে আরও কিছু)
- তারা আপনার ডেটাসেটের আকার প্রকাশ করে না।
ধরা হল যে দুটি নোড স্বাধীনভাবে একই আইডি তৈরি করার একটি ছোট সম্ভাবনা রয়েছে। এই ঘটনাটিকে "সংঘর্ষ" বলা হয়৷
৷UUID-এর অনেক ফ্লেভার
RFC 4122-এ পাঁচ ধরনের UUID অ্যালগরিদম সংজ্ঞায়িত করা হয়েছে। তারা দুটি বিভাগে পড়ে:
- সময় এবং এলোমেলোতা-ভিত্তিক অ্যালগরিদম আমরা আলোচনা করা হয়েছে বেশী. তারা প্রতি রানের জন্য একটি নতুন UUID তৈরি করে।
- টাইপ 4 :একটি এলোমেলোভাবে তৈরি আইডি। নতুন কোডের জন্য সম্ভবত আমাদের সেরা বাজি৷
- টাইপ 1 :আইডিতে হোস্টের MAC ঠিকানা এবং বর্তমান টাইমস্ট্যাম্প রয়েছে। এগুলি অনুমান করা খুব সহজ কারণ এগুলিকে অবমূল্যায়ন করা হয়েছে৷ ৷
- টাইপ 2 :এগুলো অস্বাভাবিক বলে মনে হচ্ছে। সেগুলি RPC-এর একটি প্রাচীন রূপের জন্য উদ্দেশ্য-নির্মিত বলে মনে হয়৷ ৷
- নাম ভিত্তিক অ্যালগরিদম একটু ভিন্ন। প্রদত্ত ইনপুটের সেটের জন্য তারা সবসময় একই UUID তৈরি করে।
- টাইপ 5 :UUID তৈরি করতে SHA-1 হ্যাশ ব্যবহার করে। প্রস্তাবিত।
- টাইপ 3 :একটি MD5 হ্যাশ ব্যবহার করে এবং বাদ দেওয়া হয়েছে কারণ MD5 খুবই অনিরাপদ৷
রুবিতে, আপনি uuidtools এর মাধ্যমে UUID তৈরি করতে পারেন মণি এটি রহস্যময় টাইপ 2 ছাড়া প্রতিটি প্রকারকে সমর্থন করে;
# Code stolen from the uuidtools readme. :)
require "uuidtools"
# Type 1
UUIDTools::UUID.timestamp_create
# => #<UUID:0x2adfdc UUID:64a5189c-25b3-11da-a97b-00c04fd430c8>
# Type 4
UUIDTools::UUID.random_create
# => #<UUID:0x19013a UUID:984265dc-4200-4f02-ae70-fe4f48964159>
# Type 3
UUIDTools::UUID.md5_create(UUIDTools::UUID_DNS_NAMESPACE, "www.widgets.com")
# => #<UUID:0x287576 UUID:3d813cbb-47fb-32ba-91df-831e1593ac29>
# Type 5
UUIDTools::UUID.sha1_create(UUIDTools::UUID_DNS_NAMESPACE, "www.widgets.com")
# => #<UUID:0x2a0116 UUID:21f7f8de-8051-5b89-8680-0195ef798b6a>
ইউএলআইডিতে চলে যাওয়া
দ্রষ্টব্য: এই ব্লগ পোস্টের মূল সংস্করণে আমি ULID স্পেকের সাথে লিঙ্ক করতে ভুলে গেছি। এটা এখানে. এটি রুবি এবং অন্যান্য ভাষায় বাস্তবায়নের লিঙ্ক প্রদান করে।
ইউএলআইডি অনন্য শনাক্তকারীর জন্য একটি দরকারী নতুন গ্রহণ। সবচেয়ে স্পষ্ট পার্থক্য হল যে তারা দেখতে একটু আলাদা:
01ARZ3NDEKTSV4RRFFQ69G5FAV
এগুলি দুটি বেস 32-এনকোড করা সংখ্যা নিয়ে গঠিত; একটি UNIX টাইমস্ট্যাম্প একটি এলোমেলো সংখ্যা দ্বারা অনুসরণ করে। স্পেসিফিকেশনে সংজ্ঞায়িত হিসাবে এখানে গঠনটি রয়েছে:
01AN4Z07BY 79KA1307SR9X4MV3
|----------| |----------------|
Timestamp Randomness
48bits 80bits
এই কাঠামো আকর্ষণীয়! যদি আপনি মনে করেন, UUID হয় টাইমস্ট্যাম্প বা এলোমেলোতার উপর নির্ভর করে, কিন্তু ULID উভয় টাইমস্ট্যাম্প এবং ব্যবহার করে এলোমেলোতা।
ফলস্বরূপ, ULID-এর কিছু আকর্ষণীয় বৈশিষ্ট্য রয়েছে:
- এগুলি অভিধানগতভাবে (অর্থাৎ, বর্ণানুক্রমিকভাবে) সাজানো যায়।
- টাইমস্ট্যাম্প মিলিসেকেন্ডে নির্ভুল
- এগুলি UUID-এর চেয়ে সুন্দর :)
এগুলি কিছু দুর্দান্ত সম্ভাবনা উন্মুক্ত করে:
- যদি আপনি তারিখ অনুসারে আপনার ডাটাবেস বিভাজন করেন, আপনি সঠিক পার্টিশন নির্বাচন করতে ULID-এ এমবেড করা টাইমস্ট্যাম্প ব্যবহার করতে পারেন।
- যদি মিলিসেকেন্ডের নির্ভুলতা গ্রহণযোগ্য হয় তবে আপনি একটি পৃথক create_at কলামের পরিবর্তে ULID দ্বারা সাজাতে পারেন৷
কিছু সম্ভাব্য খারাপ দিকও আছে:
- যদি টাইমস্ট্যাম্প প্রকাশ করা আপনার অ্যাপ্লিকেশনের জন্য একটি খারাপ ধারণা হয়, তাহলে ULID সেরা বিকল্প নাও হতে পারে৷
-
sort by ulidআপনার সাব-মিলিসেকেন্ড নির্ভুলতার প্রয়োজন হলে পদ্ধতি কাজ নাও করতে পারে। - ইন্টারনেট অনুযায়ী, কিছু ULID বাস্তবায়ন বুলেটপ্রুফ নয়।
উপসংহার
UUID গুলি মান হিসাবে আছে এবং থাকবে। তারা চিরকালের কাছাকাছি ছিল, এবং লাইব্রেরিগুলি কল্পনা করা যায় এমন প্রতিটি ভাষায় উপলব্ধ। যাইহোক, নতুন পন্থাগুলি বিবেচনা করার মতো, বিশেষ করে যখন আমরা এমন একটি বিশ্বে প্রবেশ করি যা ক্রমবর্ধমানভাবে বিতরণ করা সিস্টেম দ্বারা চালিত হয়। নতুন অনন্য-আইডি পদ্ধতিগুলি আমাদের RFC4122 প্রকাশনার সময় প্রচলিত ছিল না এমন সমস্যাগুলি সমাধান করতে সাহায্য করতে পারে৷
