معرفی و آموزش

طراحی بانک اطلاعاتی مناسب برای تلگرام – یک مثال عملی

آشنایی با بانکهای اطلاعاتی مختلف و نقاط ضعف و قوت هر یک به ما کمک می کند تا بتوانیم بهترین طراحی را برای سیستم های نوین اطلاعاتی داشته باشیم. مدتی بود که ذهن بنده (از سر کنجکاوی) درگیر این شده بود که ساختار اطلاعاتی مورد نیاز برای طراحی یک برنامه پیام رسان مانند تلگرام چگونه است؟ و به چه نوع بانک اطلاعاتی نیاز خواهیم داشت ؟  که بعد از تحلیل اولیه این موضوع ،تصمیم گرفتم نتایج طراحی اولیه خودم را که برگرفته از تجربیات چند سال اخیر در حوزه NoSQL است را در اختیار علاقه مندان قرار دهم.

برنامه های پیام رسان مانند تلگرام ساختار ساده ای دارند : شما می توانید به مخاطبین خود پیام بفرستید و پیام از آنها دریافت کنید، گروهی از مخاطبین را ایجاد کنید، در یک گروه عضو شوید، می توانید برای متن های خودتان از برچسب یا هشتگ (#) استفاده کنید و براساس آنها بعداً به جستجوی مطالب بپردازید و علاوه بر متن، از عکس، فیلم، صوت و فایل هم در پیام های چندرسانه ای استفاده کنید .

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

با در نظر گرفتن معیار سرعت پاسخگویی به کاربر، به طراحی بانک اطلاعاتی مورد نیاز برای این سامانه می پردازیم :

۱. ذخیره برچسب ها

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

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

اگر با ساختار بانکهای اطلاعاتی سطرگسترده مانند کاساندرا آشنا باشید، این بخش به مدل داده ای آنها بسیار نزدیک است. توضیح اینکه در بانکهای اطلاعاتی سطر گسترده، به ازای یک سطر خاص که با یک کلید منحصر بفرد شناخته میشود، میلیونها ستون یا داده را می توانیم به ترتیب خاص (معمولاً ترتیب زمانی) ذخیره کنیم و با دادن یک کلید که در اینجا می تواند خود برچسب باشد، تمام مطالب مرتبط با آن برچسب را بازیابی کرده و به کاربر نمایش دهیم .بنابراین به ازای هر مطلبی که در یک گروه مطرح می شود و حاوی برچسب A‌ و B‌ است، این مطلب  در سطر A‌  و سطر B‌ (سطری که کلید آن A و B‌ باشد) ذخیره می شود که برای کاستن از میزان واکشی اطلاعات از بانک اطلاعتی  می توانیم  خلاصه چند کلمه ای از مطلب به همراه  کد گروه را هم کنار شماره شناسایی مطلب (Post#n)بیاوریم . شکل زیر این طراحی را به خوبی نشان می دهد .

Telegram1

البته این طراحی هنوز بهینه نشده است چون مطالبی که به کاربر الف نشان داده می شود متفاوت از مطالب نشان داده شده به کاربر ب است و در طراحی فوق این مورد دیده نشده است و محور ذخیره سازی خود برچسب (مستقل از کاربر) قرار گرفته است در صورتیکه که مطالب بر اساس کاربر و اینکه در چه گروه هایی عضو است باید بازیابی شده و نمایش داده شود و در روش فوق برای نیل به این هدف، ما باید به ازای مطالب هر بر چسب، چک کنیم که کاربر هم می تواند آن مطلب را ببیند یا نه که عملی زمان براست و با هدف اصلی ما که بازیابی سریع اطلاعات است، در تضاد خواهد بود.

طراحی درست برای این بخش این است که کلید هر سطر را ترکیب برچسب و نام کاربری بگیریم و به ازای هر مطلبی که با دو برچسب A و B منتشر می شود، کد مطلب در تمام سطرهایی که کلیدشان ترکیب برچسب و کد کاربران عضو همان گروه است درج شود . مثلاً اگر گروه حاوی مطلب اصلی، ۱۵۰ عضو داشته باشد در تمام صد و پنجاه سطری که کلید آنها ترکیب برچسب و کد کاربر است باید درج شود .

با این ترتیب، زمانی که یک کاربر روی یک برچسب کلیک می کند، کد کاربر و برچسب را داریم و کافیست ده ستون اول سطر متناظر که کلید آن ترکیب این دو مقدار است را بازیابی کرده و به کاربر نشان دهیم . در اینصورت هیچ گونه اتصال یا عمل پردازشی هنگام جستجوی مطالب متناظر با یک برچسب نیاز نخواهیم داشت . اگر کاربر نتایج بیشتری خواست ، ده ستون بعدی را به او نمایش می دهیم و به همین ترتیب مطالب قبل تر هم قابل مشاهده است  و اگر هزار نفر هم در ثانیه درخواست جستجو بر اساس برچسب ها را بدهند ، فقط هزار بازیابی و خواندن اطلاعات خواهیم داشت (به فرض اینکه چند کلمه اول مطب و نام گروه هم در هر سطر ذخیره شود که نیاز به اتصال یا استفاده از جدول دیگر نباشد) که برای بانکهایی مثل کاساندرا که در ثانیه تا حد چند میلیون خواندن را می توانند به راحتی انجام دهند، مساله ای حل شده است .

این مطلب ادامه دارد …..

 

مجتبی بنائی

دانشجوی دکترای نرم‌افزار دانشگاه تهران (yun.ir/smbanaie)، مدرس دانشگاه و فعال در حوزه توسعه نرم‌افزار و مهندسی داده که تمرکز کاری خود را در چند سال اخیر بر روی مطالعه و تحقیق در حوزه کلان‌داده و زیرساخت‌های پردازش داده و تولید محتوای تخصصی و کاربردی به زبان فارسی و انتشار آنها در سایت مهندسی داده گذاشته است. مدیریت پروژه‌های نرم‌افزاری و طراحی سامانه‌های مقیاس‌پذیر اطلاعاتی از دیگر فعالیتهای صورت گرفته ایشان در چند سال گذشته است.
0 0 رای ها
Article Rating
اشتراک در
اطلاع از
guest

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

9 Comments
قدیمی‌ترین
تازه‌ترین بیشترین رأی
بازخورد (Feedback) های اینلاین
مشاهده همه دیدگاه ها
دکمه بازگشت به بالا
9
0
افکار شما را دوست داریم، لطفا نظر دهید.x