کمی در باب UUID
توی اکثر سیستم‌های اطلاعاتی، چه در مورد پیام‌های مورد تبادل بین سرویس‌های یک نرم‌افزار مبتنی بر مایکروسرویس صحبت کنیم، چه در مورد داده‌های دیتابیس، نیاز به یک روش مطمئن برای شناسایی منحصربه‌فرد داده‌ها وجود داره. استفاده از شناسه‌های ترتیبی (Sequential Integers) مثل Auto-Increment توی دیتابیس‌ها ساده و سریعه ولی توی محیط‌های توزیع‌شده که چندین سرور به طور همزمان ID تولید می‌کنن، برای جلوگیری از تکرار، نیاز به هماهنگی مرکزی دارن که خودش گلوگاه مقیاس‌پذیریه (Scalability).
برای پاسخ به این نیاز، UUID (Universally Unique Identifier) به وجود اومده. UUIDها شناسه‌های 128 بیتی (۳۶ کاراکتر) هستن که بدون نیاز به هماهنگی مرکزی، منحصر به فرد بودن رو در سطح جهانی تضمین می‌کنن. سال ۲۰۲۴، استاندارد رسمی RFC 9562 نسخه‌ی ۷ رو معرفی کرده: ۴۸ بیتِ اول «تایم‌استمپ یونیکس بر حسب میلی‌ثانیه»، بقیه بیت‌ها تصادفیِ امن. نتیجه؟ شناسه‌ها زمان‌مرتب و در عین حال یونیک هستن. چرا زمان‌مرتب بودن این شناسه‌ها مهمه؟ چون مثلا توی نسخه ۴، شناسه کاملا تصادفیه و اگر به ترتیب بخواهیم مرتب کنیم احتمال اینکه شناسه‌ای که الان تولید می‌کنید بعد از شناسه‌ای که دو ساعت پیش یا دو سال پیش تولید کردید قرار بگیره زیاده. این یعنی شروع مشکل. چه مشکلی؟ ایندکس جداول یا سری‌های زمانی.
فرض کنین یه کتاب دارید که شماره صفحاتش کاملا رندوم ولی یکتا باشه. در حالت عادی که شماره صفحات مرتب و دنبال هم هستن وقتی دنبال صفحه ۱۳۷ کتاب می‌گردید، اول یه جای کتاب رو باز می‌کنید و می‌بینید مثلا ۱۸۹ است، چون مطمئنید شماره ۱۳۷ قبلش است دیگه صفحات بعدی رو نگاه نمی‌کنید، یه جا قبل‌تر رو باز می‌کنید می‌بینید ۱۲۵ است، دیگه قبل‌تر و نمی‌گردید و چند صفحه جلوتر، ۱۳۷ رو پیدا می‌کنید. این یعنی پیدا کردن سریع‌تر مطالب. حالا اگر شماره صفحات رندوم باشه، هر بار که مرتبش کنیم با اولین مقدار جدید، نظم به هم می‌ریزه و پیدا کردن صفحات دشوار میشه.
مرور نسخه‌ها تا به امروز:
نسخه v1: مبتنی بر زمان و MAC Address » ترتیبی بر اساس زمان، یونیک جهانی » ولی افشای آدرس MAC (مشکل حریم خصوصی)
نسخه v2: مبتنی بر Domain محلی و Security » رزرو شده برای DCE Security » کاربری و استفاده بسیار محدود.
نسخه v3: مبتنی بر نام (MD5 Hashing) » همیشه برای یک "نام" و "دامین" مقدار یکسان تولید میشه. » از هش قدیمی MD5 استفاده میکنه که منسوخ شده.
نسخه v4: کاملاً تصادفی، یونیک جهانی با بالاترین میزان تصادفی بودن. » نامرتب؛ عملکرد ایندکس دیتابیس (B-tree) رو به شدت کاهش می‌دهه. » متاسفانه همچنان رایج، اما برای Primary Key نامناسب.
نسخه v5: مبتنی بر نام (SHA-1 Hashing) مشابه v3، اما از هش بهتر SHA-1 استفاده میکنه » فقط برای مواردی که نیاز به تکرارپذیری UUID است، مناسبه. » بهتر از v3، برای تولید شناسه‌های ثابت از URL یا نام.
نسخه v6: مشابه v1 ولی با ترتیب زمانی بهتر » مرتب زمانی، ولی بدون افشای MAC
» هنوز نسخه draft است، » کاربردش جایگزینی v1 در آینده
نسخه v7: مبتنی بر زمان یونیکس + مقدار تصادفی » مرتب بر اساس زمان و در عین حال یونیک جهانی + عملکرد بهینه دیتابیس » بهینه برای Primary Key خصوصا توی سیستم‌های توزیع‌شده و سری‌های زمانی » امکان افزودن کسریِ زیرِ میلی‌ثانیه و/یا کانتر هم برای تضمین مرتب‌بودن در همان میلی‌ثانیه پیش‌بینی شده.
نسخه v8: فضای سفارشی/تجربی برای نیازهای خاص.
📌 نسخه UUIDv7 به صورت بومی توی PostgreSQL 18 و SQL Server 2025 و پایتون ۳.۱۴ و دات‌نت ۹ و گو هم gofrs/uuid v5 پشتیبانی میشه ولی MySQL و MariaDB و جاوا هنوز نسخه بومی رو پیاده نکردن.
✍تِک افترنون
توی اکثر سیستم‌های اطلاعاتی، چه در مورد پیام‌های مورد تبادل بین سرویس‌های یک نرم‌افزار مبتنی بر مایکروسرویس صحبت کنیم، چه در مورد داده‌های دیتابیس، نیاز به یک روش مطمئن برای شناسایی منحصربه‌فرد داده‌ها وجود داره. استفاده از شناسه‌های ترتیبی (Sequential Integers) مثل Auto-Increment توی دیتابیس‌ها ساده و سریعه ولی توی محیط‌های توزیع‌شده که چندین سرور به طور همزمان ID تولید می‌کنن، برای جلوگیری از تکرار، نیاز به هماهنگی مرکزی دارن که خودش گلوگاه مقیاس‌پذیریه (Scalability).
برای پاسخ به این نیاز، UUID (Universally Unique Identifier) به وجود اومده. UUIDها شناسه‌های 128 بیتی (۳۶ کاراکتر) هستن که بدون نیاز به هماهنگی مرکزی، منحصر به فرد بودن رو در سطح جهانی تضمین می‌کنن. سال ۲۰۲۴، استاندارد رسمی RFC 9562 نسخه‌ی ۷ رو معرفی کرده: ۴۸ بیتِ اول «تایم‌استمپ یونیکس بر حسب میلی‌ثانیه»، بقیه بیت‌ها تصادفیِ امن. نتیجه؟ شناسه‌ها زمان‌مرتب و در عین حال یونیک هستن. چرا زمان‌مرتب بودن این شناسه‌ها مهمه؟ چون مثلا توی نسخه ۴، شناسه کاملا تصادفیه و اگر به ترتیب بخواهیم مرتب کنیم احتمال اینکه شناسه‌ای که الان تولید می‌کنید بعد از شناسه‌ای که دو ساعت پیش یا دو سال پیش تولید کردید قرار بگیره زیاده. این یعنی شروع مشکل. چه مشکلی؟ ایندکس جداول یا سری‌های زمانی.
فرض کنین یه کتاب دارید که شماره صفحاتش کاملا رندوم ولی یکتا باشه. در حالت عادی که شماره صفحات مرتب و دنبال هم هستن وقتی دنبال صفحه ۱۳۷ کتاب می‌گردید، اول یه جای کتاب رو باز می‌کنید و می‌بینید مثلا ۱۸۹ است، چون مطمئنید شماره ۱۳۷ قبلش است دیگه صفحات بعدی رو نگاه نمی‌کنید، یه جا قبل‌تر رو باز می‌کنید می‌بینید ۱۲۵ است، دیگه قبل‌تر و نمی‌گردید و چند صفحه جلوتر، ۱۳۷ رو پیدا می‌کنید. این یعنی پیدا کردن سریع‌تر مطالب. حالا اگر شماره صفحات رندوم باشه، هر بار که مرتبش کنیم با اولین مقدار جدید، نظم به هم می‌ریزه و پیدا کردن صفحات دشوار میشه.
مرور نسخه‌ها تا به امروز:
نسخه v1: مبتنی بر زمان و MAC Address » ترتیبی بر اساس زمان، یونیک جهانی » ولی افشای آدرس MAC (مشکل حریم خصوصی)
نسخه v2: مبتنی بر Domain محلی و Security » رزرو شده برای DCE Security » کاربری و استفاده بسیار محدود.
نسخه v3: مبتنی بر نام (MD5 Hashing) » همیشه برای یک "نام" و "دامین" مقدار یکسان تولید میشه. » از هش قدیمی MD5 استفاده میکنه که منسوخ شده.
نسخه v4: کاملاً تصادفی، یونیک جهانی با بالاترین میزان تصادفی بودن. » نامرتب؛ عملکرد ایندکس دیتابیس (B-tree) رو به شدت کاهش می‌دهه. » متاسفانه همچنان رایج، اما برای Primary Key نامناسب.
نسخه v5: مبتنی بر نام (SHA-1 Hashing) مشابه v3، اما از هش بهتر SHA-1 استفاده میکنه » فقط برای مواردی که نیاز به تکرارپذیری UUID است، مناسبه. » بهتر از v3، برای تولید شناسه‌های ثابت از URL یا نام.
نسخه v6: مشابه v1 ولی با ترتیب زمانی بهتر » مرتب زمانی، ولی بدون افشای MAC
» هنوز نسخه draft است، » کاربردش جایگزینی v1 در آینده
نسخه v7: مبتنی بر زمان یونیکس + مقدار تصادفی » مرتب بر اساس زمان و در عین حال یونیک جهانی + عملکرد بهینه دیتابیس » بهینه برای Primary Key خصوصا توی سیستم‌های توزیع‌شده و سری‌های زمانی » امکان افزودن کسریِ زیرِ میلی‌ثانیه و/یا کانتر هم برای تضمین مرتب‌بودن در همان میلی‌ثانیه پیش‌بینی شده.
نسخه v8: فضای سفارشی/تجربی برای نیازهای خاص.
📌 نسخه UUIDv7 به صورت بومی توی PostgreSQL 18 و SQL Server 2025 و پایتون ۳.۱۴ و دات‌نت ۹ و گو هم gofrs/uuid v5 پشتیبانی میشه ولی MySQL و MariaDB و جاوا هنوز نسخه بومی رو پیاده نکردن.
✍تِک افترنون
🔥17❤1👍1👎1
به نظر شما، اینکه Everything in Python is an object نقطه قوت ع پایتون ع یا ضعفش؟
Final Results
29%
هنوز درکش نکردم، نمیتونم نظر بدم
66%
نقطه قوت
5%
نقطه ضعف
ابزار WSL ویندوز چیه؟
ابزاری که مایکروسافت طراحی کرده تا بتونید یک محیط لینوکسی رو تو ویندوز اجرا کنید یعنی دیگه نیاز نیست از ماشین مجازی استفاده کنید
این WSL به منابع کمتری نسبت به یک ماشین مجازی کامل نیاز داره درحالی که به کاربر ها اجازه میده فایل های خودشونو تو هردو محیط ویندوز و لینوکس استفاده کنن.
در سال 2019 نسخه دوم (WSL 2 ) معرفی شده که توی ماشین مجازی مدیریت شده اجرا میشه و یه کرنل کامل لینوکسی داره و همه برنامه های لینوکسی رو اجرا میکنه.
من باهاش Debian رو نصب کردم. کل فرایندش حدودا نیم ساعت شد.
همونطوری هم که توی تصویر مشخصه، اضافه میشه به منو start فعلا با مشکلات احتمالی ش آشنا نیستم.
اگه موردی دیدم، توی کامنت های همین پست میزارم.
با تشکر از کانال CHET CODE
ابزاری که مایکروسافت طراحی کرده تا بتونید یک محیط لینوکسی رو تو ویندوز اجرا کنید یعنی دیگه نیاز نیست از ماشین مجازی استفاده کنید
این WSL به منابع کمتری نسبت به یک ماشین مجازی کامل نیاز داره درحالی که به کاربر ها اجازه میده فایل های خودشونو تو هردو محیط ویندوز و لینوکس استفاده کنن.
در سال 2019 نسخه دوم (WSL 2 ) معرفی شده که توی ماشین مجازی مدیریت شده اجرا میشه و یه کرنل کامل لینوکسی داره و همه برنامه های لینوکسی رو اجرا میکنه.
من باهاش Debian رو نصب کردم. کل فرایندش حدودا نیم ساعت شد.
همونطوری هم که توی تصویر مشخصه، اضافه میشه به منو start فعلا با مشکلات احتمالی ش آشنا نیستم.
اگه موردی دیدم، توی کامنت های همین پست میزارم.
با تشکر از کانال CHET CODE
👍9❤2