در مورد استفاده از UUID در پایگاه داده خود تجدید نظر کنید

استفاده از UUID (شناسه‌های منحصربه‌فرد جهانی) به‌عنوان کلیدهای اصلی در پایگاه‌های داده، برای ما به‌عنوان توسعه‌دهنده یک روش معمول است، اما این رویکرد می‌تواند اشکالات عملکردی قابل‌توجهی داشته باشد. من قصد دارم با شما دو مشکل عمده عملکرد مرتبط با استفاده از UUID به عنوان کلید در جداول پایگاه داده شما را بررسی کنم.

UUID چیست؟

UUID (Universal Unique Identifier) ​​یک مقدار 128 بیتی است که برای شناسایی منحصر به فرد یک شی یا موجودیت در اینترنت استفاده می شود. در بین نسخه های مختلف، UUIDv4 محبوب ترین است.

در اینجا نمونه ای از UUIDv4 آمده است:

123e4567-e89b-12d3-a456-426614174000

UUID ها مانند بازیکنان ستاره یک تیم فوتبال هستند – آنها برجسته و منحصر به فرد هستند، اما همیشه بهترین انتخاب برای هر بازی نیستند.

مشکل 1: درج عملکرد – The Fumble

هنگامی که یک رکورد جدید در جدول درج می شود، شاخص کلید اولیه باید برای حفظ عملکرد بهینه پرس و جو به روز شود. ایندکس ها با استفاده از ساختار داده B+ Tree ساخته می شوند که برای کارآمد ماندن، با هر درج تعادل مجدد نیاز دارد.

با UUID ها، تصادفی بودن ذاتی این فرآیند را پیچیده می کند و منجر به ناکارآمدی قابل توجهی می شود. همانطور که پایگاه داده شما مقیاس می شود، میلیون ها گره نیاز به تعادل مجدد دارند و عملکرد درج را هنگام استفاده از کلیدهای UUID به شدت کاهش می دهد.

مثال:

CREATE TABLE players (
    id UUID PRIMARY KEY,
    name VARCHAR(255)
);

INSERT INTO players (id, name) VALUES ('123e4567-e89b-12d3-a456-426614174000', 'Kevin Lebron');

نکته: به جای آن از UUIDv7 استفاده کنید، زیرا دارای نظم ذاتی است که نمایه سازی را ساده می کند، مانند داشتن یک خط حمله کاملاً هماهنگ 😊!

مشکل 2: نیازهای ذخیره سازی بالاتر

UUID ها در مقایسه با کلیدهای عدد صحیح افزایش دهنده خودکار فضای ذخیره سازی بسیار بیشتری مصرف می کنند. اعداد صحیح افزایش دهنده خودکار از 32 بیت در هر مقدار استفاده می کنند، در حالی که UUID ها از 128 بیت استفاده می کنند – چهار برابر بیشتر در هر ردیف. هنگامی که یک UUID به شکل قابل خواندن توسط انسان ذخیره می شود، می تواند تا 688 بیت، تقریبا 20 برابر بیشتر در هر ردیف، مصرف کند.

این مثل گرفتن پرچم پنالتی برای جشن زیاد است. غیر ضروری و پرهزینه است.

مثال:

CREATE TABLE players (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255)
);

INSERT INTO players (name) VALUES ('Kevin Lebron');

بیایید تاثیر را با دو جدول شبیه سازی کنیم:

• جدول 1: شامل 1 میلیون ردیف با UUID است.
• جدول 2: شامل 1 میلیون ردیف با اعداد صحیح افزایش دهنده خودکار است.

نتایج:

• اندازه کل میز: جدول UUID حدود 2.3 برابر بزرگتر از جدول اعداد صحیح است.
• اندازه فیلد شناسه: یک فیلد UUID مجزا به 9.3 برابر فضای ذخیره سازی بیشتری نسبت به یک فیلد عدد صحیح نیاز دارد.
• اندازه ستون شناسه: بدون احتساب سایر ویژگی ها، ستون UUID 3.5 برابر بزرگتر از ستون عدد صحیح است.

استفاده از UUID مانند ضربه زدن با پرچم‌های پنالتی مکرر است – الزامات ذخیره‌سازی شما به طور غیرضروری افزایش می‌یابد و بر عملکرد تأثیر می‌گذارد.

نتیجه

در حالی که UUID ها برای اطمینان از منحصر به فرد بودن عالی هستند، چالش های مقیاس پذیری قابل توجهی را ارائه می دهند. مسائل مربوط به عملکرد مورد بحث در مقیاس بیشتر قابل توجه است، بنابراین برای برنامه های کوچکتر، تأثیر ممکن است حداقل باشد. با این حال، درک این مفاهیم و طراحی پایگاه داده بر اساس آن بسیار مهم است.

یاد آوردن: هم در فوتبال و هم در پایگاه‌های اطلاعاتی، همه چیز در مورد ساخت نمایش‌های مناسب در زمان مناسب است!

اگر این مقاله برای شما مفید بود، لطفاً به اشتراک بگذارید و با من ارتباط برقرار کنید!

منابع
UUID چیست و چه کاربردی دارد؟
مشکل UUID
B Trees و B+ Trees. چگونه آنها در پایگاه داده مفید هستند