طراحی یه سیستم کوتاه کننده لینک ساده [قسمت اول: تعریف قابلیت ها و دیاگرام دیتابیس و انتخاب DBMS]

سلام، میخوام توی این سری از مطالب یه سیستم کوتاه کننده لینک رو دیزاین بکنم و درباره چرایی همه تصمیماتم توضیح بدم و همونطور که احتمالا می‌دونید سیستمی نیست که بدون نقض باشه و همیشه جا برای بهبود هست پس ازتون می‌خوام این لطف رو در حق من بکنید و نقض های طراحیم رو بگید.

توی این مطلب قراره اول از همه مشخص بکنیم که از سیستممون چه انتظاراتی داریم.

کاربر های ما توی دو حالت احراز هویت شده یا نشده می‌تونن یه لینک رو کوتاه بکنن و ما نمی‌خوایم لینک های کوتاه شدمون خیلی طولانی باشه تا بشه راحت به یه نفر بیانش کرد.

برای احراز هویت امکان ورود با گوگل هم وجود داره.

امکان دیدن آمار های بازدید از لینک ها هم برای کاربران ایجاد کننده وجود داره.

اسم این سیستم هم با توجه به کارش گذاشتم کوچیکوک ? (در لهجه یزدی به یه چیز خیلی کوچیک میگن کوچیکوک)

طراحی دیتابیس

دیاگرام بالا با استفاده از diagrams.net ساخته شده و دلیل استفادم ازش اینه که رایگانه و فایلش رو می‌تونید ذخیره کنید و مجبور به ذخیره سازی فقط روی سرورهای خودش نیستید، همچنین داشتن اپ دسکتاپشم برام مزیت به حساب میاد چون نیاز دارم بتونم آفلاین هم کارهای دیاگرامیم رو پیش ببرم.

همونطور که توی دیاگرام مشخصه ما توی سیستمون سه تا موجودیت داریم که User, Link و View هستش.

موجودیت User برای احراز هویت کاربر استفاده میشه، Link برای ذخیره سازی لینک های کوتاه شده توسط کاربرا و View برای نمایش آمار.

فیلد provider توی موجودیت User برای اینکه که بتونیم بفهمیم User ما از چه طریقی رجیستر کرده یعنی عادی یا با استفاده از حساب گوگلش؟

فیلد statistics_key برای اینه که اگه یه کاربر لاگین نکرده بود و یه لینک کوتاه ساخت بتونه با دادن مقدار این فیلد آمار بازدید از لینک کوتاهش رو ببینه.

فیلد deleted_at توی موجودیت‌هامون برای حذف منطقی داده ها استفاده میشه. یعنی توی سیستمون هیچ داده‌ای رو قرار نیست واقعا حذف بکنیم و فقط قراره اونا رو نشون ندیم و یه برچسب حذف شده بزنیم بهشون.

مزیت حذف منطقی چیه؟ می‌تونیم تمام داده های تولید شده توسط سیستمون رو داشته باشیم و همچنین اگه مشکلی پیش اومد بتونیم برگردونیم.

این دیاگرام صد در صد تکمیل نیست و به مرور که میریم جلو نیاز به یه سری فلید های دیگه پیدا می‌کنیم که همون‌جا اضافشون می‌کنیم.

انتخاب دیتابیس

من دیتابیس مورد انتخابم برای پیاده سازی این سیستم PostgreSQL هست. ولی چرا؟ توی این سیستم ما رابطه داریم و بر اساس رابطه هایی که داریم می‌خوایم کوئری بزنیم و برای اینکار یه سیستم مدیریت پایگاه داده رابطه‌ای انتظار میره بهتر جوابمون رو بده. همچنین schema جداولمون مشخصه پس schema-less بودن برامون مزیت نیست.

حالا بین این همه RDBMS چرا PostgreSQL؟ چون بیشتر دوستش دارم و جواب نیازم رو میده :)

از کجا بفهمم این تکنولوژی من رو کند نمی‌کنه؟

بنچمارک می‌گیریم :)

یه اسکریپت برای seed کردن دیتاها داخل دیتابیس نوشتم و هر بخش رو با کامنتی که بالاشه جدا کردم.

چند تا نکته راجع به اسکریپت ها ?

سعی کردم حالت های مختلف داده‌ای رو داخلش ایجاد کنم تا بتونیم یه قضاوت منطقی داشته باشیم.

توی قسمت insert کردن view ها دلیل اینکه صد هزارتا صد هزارتا insert می‌کنم اینه که حافظه Heap جاوااسکریپت پر می‌شد و امکانش وجود نداشت که همه رو با هم بریزم توی دیتابیس.

خب حالا وقت اینه که سنگین ترین کوئری‌ای که توی نیازمندی هامون وجود داره و میزان فراخوانیش هم بالاست رو بزنیم و ببینیم چقد طول می‌کشه ریسپانس بده.
سنگین ترین جدولی که داریم برای view ها هستش پس انتظار میره گرفتن view های یه link کندترین کوئریمون باشه.

آیدی‌ای که بر اساسش کوئری زدم پر بازدید ترین لینک موجودمونه که 84 تا بازدید داره.

روی کامپیوتر من این کوئری با وجود ده میلیون رکوردی که وجود داره و عدم وجود ایندکس برای فیلد link_id، فقط 1.4 ثانیه طول کشید که بسی جذابه.

حالا با ایندکس چقد می‌شه؟ ۱۰ میلی ثانیه :))))

مشخصات سیستمی که باهاش بنچمارک گرفتم ?

Intel Core i7 7500 U (4 Cores)
16GB DDR4 RAM
SSD

البته در حینش اپلیکیشن های دیگه ای هم باز بود که باعث میشه PostgreSQL نتونه همه‌ی ظرفیت سیستم رو استفاده کنه.

لطفا به کامنت های این پست اهمیت بدید چون ممکنه دوستان اشتباهات من رو اصلاح کرده باشن و نظرات متفاوتی رو ببینیم.

محمد محمدعلیان | 22 فروردین 1401
کانال تلگرامم | لینکدینم