چرا انتخاب uuid به عنوان primary key میتونه به شدت performance دیتابیس شمارو تحت تاثیر قرار بده؟

نمیتونم بگم این ویدیو چقدر دید خوبی میده به ما که چطور با دیتابیس برخورد کنیم. وقتی که دانش کافی و شناخت کافی از دیتابیس نداریم، خیلی تصمیمات اشتباهی میگیریم که در ابتدای راه خودشو بروز نمیده، حتی اگه هیچوقت scale نکنه اپلیکیشن ما شاید هیچوقت متوجه اشتباهمون نشیم. اما روی scale همه چیز متفاوته.
من تو بعضی از پروژه هام uuid رو به عنوان primary key در نظر میگرفتم. با دیدن این ویدیو به همین سادگی متوجه شدم چقدر این تصمیم اشتباهه، با این تصمیم چقدر دارم دیتابیس رو اذیت می کنم 🙂

خلاصه مطلب رو بخوام بگم اینه که هر دیتابیسی برای خودش یه بلاک کوچیک دیتا به اسم page داره و براش یه default page size داره، که همه read و write ها از طریق این page ها صورت میگیره. مثلا در postgres هر page بصورت پیشفرض ۸ کیلوبایت هست و در mysql هر page بصورت پیشفرض ۱۶ کیلوبایت هست. دیتابیس ها یه چیزی دارن به اسم buffer pool که اینpage هارو وقتی از disk میخونن در memory کش میکنن که بتونن عملکرد خوبی داشته باشن. خب قضیه از اینجا شروع میشه که اگه physical disk شما مثلا ssd باشه، خود ssd قاعده و قانون خودشو داره، در ssd هم ما block storage داریم یا همون page ولی اونجا page ها مثلا ۴ کیلوبایتی هستن، پس عملا هر وقت یه دیتابیس بخواد یه page خودشو روی disk بریزه داره بیشتر از یه عملیات io انجام میده و حتی یه سری کارهای بیشتر مثل shuffling و مپ کردن lba یا همون logical blcok address.

خب تا اینجا مشخص شد که دیتابیس ها برای write کردن دیتاشون روی disk به اندازه کافی دردسر دارن.
حالا بریم سراغ index های دیتابیس، که خود این ایندکس ها دارن توی یه سری page ذخیره میشن. اگه دیتای ایندکس مرتب شده نبود (که هست) کار دیتابیس ساده بود، همینطوری دیتای جدید رو پشت سر هم توی page ذخیره میکرد، تا جایی که به انتهای page میرسید و یه page جدید ایجاد میکرد.

ولی الان مساله اینه که ایندکس ها اساسا یه سری دیتای مرتب شده هستن و order مهمه. بنابراین اگه دیتای جدیدی که قراره ذخیره بشه قرار باشه وسط یه سری دیتای ایندکس شده ذخیره بشه، ما مجبور هستیم اون وسط یه جای خالی ایجاد کنیم و دیتای جدید رو ایندکس کنیم.
خب این کار باز تا وقتی که page ما به اندازه کافی جا برای ذخیره کردن همه رکوردها داشته باشه اوکیه. اما وقتی که به جایی میرسیم که page پر شده و قراره یه رکورد جدید رو وسط ایندکس های قدیمی قرار بدیم، مجبور میشیم page splitting انجام بدیم. فرض کنید میخوایم ایندکس ۴ رو به عنوان یه رکورد جدید تو pageی ایندکس کنیم که دیتای ۱ تا ۳ و ۵ تا ۱۰ رو داره. دیتابیس مجبور میشه یه page جدید بسازه و مثلا دیتای ۱ تا ۷ رو تو page قدیم و دیتای ۷ تا ۱۰ رو در page جدید ذخیره کنه.
اینو هم اشاره کنم که دیتابیس ها معمولا این کار رو نمیکنن، چون خیلی cost داره، اونا یه حرکت خیلی ساده تر میزنن، میگن اوکی، حالا که قراره ایندکس ۴ بیاد، و page جا نداره، ما یه page جدید میسازیم که ایندکس ۵ تا ۱۰ رو ذخیره کنه و یه page قدیمی هم دیتای ۱ تا ۴ رو ذخیره کنه. یه مساله ای که اینجا پیش میاد اینه که اینجا ما ۲ تا page داریم که هرکدومشون کلی فضای خالی دارن، و شما روی تعداد زیاد دیتا و ایندکس ببینید که چه تعداد page ایندکسی خواهید داشت که split شده هستن و کلی فضای خالی تو هر page وجود داره.
به این اتفاق میگن index fragmentation که ایندکس شما مدام شکسته میشه بین یه سری page. این fragmentation کجا شمارو دچار مشکل میکنه؟ وقتی که میخواید کوئری بزنید، اگه قبلا دیتابیس مجبور بود دیتای یه page رو بخونه برای کوئری شما الان مجبوره دو تا page رو بخونه و اصطلاحا ۲ تا logical io انجام بده. اینم در نظر بگیرید که این ۲ تا logical io با توجه به ساختار مثلا ssd عملا خیلی بیشتر از ۲ تا io هست، چون هر page دیتابیس خودش میتونه روی چندین بلاک ssd جداگانه ذخیره بشه و باید سمت ssd کلی کار انجام بشه که این ۲ تا logical io کامل بشه.

به همین دلیله که دیتابیس ها یه کانفیگی برای page هاشون دارن به اسم fillfactor که شما میتونی تنظیم کنی مثلا تا ۸۰ درصد هر page استفاده بشه و ۲۰ درصد بمونه برای ایندکس های جدید که splitting تا حدودی مدیریت بشه. تنظیم این fillfactor با توجه به نوع دیتای شما خیلی میتونه روی performance تاثیر بذاره.

#database #index #sql #uuid #hussein_nasser

@gocasts