طراحی نرم افزار اندروید
طراحی اپلیکیشن موبایل
Database Sharding چیست؟
چنانچه وب اپلیکیشنی با اقبال عمومی مواجه شده و رشد قابل‌توجهی داشته باشد و مخاطبین بسیاری را به سمت خود جذب کند، زیرساخت آن باید به گونه‌ای باشد که توانایی هندل کردن میلیون‌ها ریکئوست در هر ثانیه را داشته باشد مضاف بر اینکه برای ذخیره‌سازی داده‌ها نیز باید سازوکاری اندیشید که پایگاه داده به صورت دینامیک و بسته به نیازهای آن وب اپلیکیشن اصطلاحاً Scale شود و اینجا است که پای معماری Database Sharding به میان می‌آید.
Shard در لغت به معنی «تکه» است و Sharding نیز یک الگوی طراحی دیتابیس است که در آن داده‌ها در قالب چندین و چند جدول و دیتابیس مختلف تقسیم‌بندی می‌شوند و همین مسئله منجر بدان خواهد شد که مدیریت ریکوئست‌های زیاد راحت‌تر گردد.
آشنایی با تفاوت‌های پارتیشن‌بندی Horizontal و Vertical
این دو واژه به ترتیب به معنی «افقی» و «عمودی» است. پارتیشن‌بندی افقی (Horizontal Partitioning) به این موضوع اشاره دارد که رکوردهای ثبت‌شده در یک جدول را از یکدیگر جدا ساخته و هر گروه را در یک جدول که در اینجا تحت عنوان پارتیشن شناخته می‌شود ذخیره می‌سازند و این در حالی است که هر جدول (پارتیشن) از اِسکما و ستون‌های دقیقاً مشابهی برخوردار است اما دادههای ذخیره‌شده در آن‌ها متفاوت و در عین حال منحصربهفرد هستند؛ به عبارتی، هیچ جدولی حاوی دادههای یکسان نخواهد بود.
در پارتیشن‌بندی عمودی (Vertical Partitioning) یکسری ستون خاص در یک جدول و یکسری ستون خاص دیگر در جدولی دیگر طراحی می‌شود و دادههای ذخیره‌شده در این دست جداول نیز منحصربهفرد هستند؛ به عبارتی، هیچ دو جدول (پارتیشن) را نمی‌توان یافت که حاوی ساختار و دادههای یکسانی باشد.
در پاسخ به این پرسش که «تفاوت مابین پارتیشن‌بندی افقی و پارتیشن‌بندی عمودی چیست؟» می‌توان گفت که در پارتیشن‌بندی افقی فقط دادههای جداول منحصربهفرد هستند در حالی که در پارتیشن‌بندی عمودی علاوه بر داده‌ها، ستون‌های جداول نیز با یکدیگر فرق دارند. همان‌طور که در تصویر فوق ملاحظه می‌شود، یک جدول داریم تحت عنوان Original Table که وقتی آن را به صورت افقی پارتیشن‌بندی کنیم دو جدول تحت عناوین HP1 و HP2 خواهیم داشت که در هر دوی آن‌ها اِسکما (ساختار) دیتابیس یکسان است اما هر کدام حاوی دادههای متفاوتی است اما زمانی که این جدول را به صورت عمودی پارتیشن‌بندی می‌کنیم، دو جدول خواهیم داشت تحت عناوین VP1 و VP2 که اِسکمای آن‌ها با یکدیگر فرق داشته مضاف بر اینکه هر کدام از آن‌ها مسئول ذخیره‌سازی دادهٔ خاصی است.
با این توضیحات می‌توان گفت که Sharding به پروسهٔ شکستن داده‌ها به واحدهای کوچکی که هر کدام در جدول خاصی ذخیره می‌شوند گفته می‌شود که با کنار هم قرار گرفتن تک‌تک جداول و داده‌ها در کنار یکدیگر، به یک دیتابیس کامل دست خواهیم یافت.
Sharding گاهی اوقات در سطح اپلیکیشن صورت می‌گیرد بدان معنا که فانکشن‌هایی توسط دولوپر نوشته می‌شود که مشخص می‌سازند ارتباط اپلیکیشن با دیتابیس برای فرآیندهای خواندن و نوشتن دیتا به چه صورت باشد اما در عین حال برخی سیستم‌های مدیریت دیتابیس هستند که به صورت پیش‌فرض قابلیت Sharding را دارند و این کار در سطح دیتابیس صورت می‌گیرد.
این بخش از محتوا مخصوص کاربرانی است که ثبت‌نام کرده‌اند.
چه زمانی باید از معماری Sharding استفاده کرد؟
برخی متخصصین بر این باورند که با حجیم شدن دیتابیس مهاجرت به سمت معماری Sharding حتمی است اما برخی هم بر این باورند که به خاطر پیچیدگی‌هایی که دارد، تا حد ممکن باید از آن اجتناب کرد مگر آنکه واقعاً راه چاره‌ای در کار نباشد. در همین راستا، در ادامه موقعیت‌هایی را معرفی می‌کنیم که در آن‌ها این نوع معماری می‌تواند به بهبود پرفورمنس کمک کند:
- حجم داده‌ها آن‌قدر بالا است که یک دیتابیس به تنهایی نمی‌تواند آن‌ها را هندل کند.
- حجم خواندن/نوشتن دیتا آن‌قدر بالا است که منابع یک سرور کفایت نمی‌کند.
- پهنای‌باند لازم برای کارکرد صحیح اپلیکیشن از پهنای‌باندی که در اختیار دیتابیس است پیشی می‌گیرد و بالتبع پرفورمنس کاهش می‌یابد.
به طور کلی، پیش از تصمیم‌گیری به منظور پارتیشن‌بندی دیتابیس خود، بهتر است دیگر گزینه‌ها را مورد بررسی قرار دهیم به طوری که برخی از بهبودهایی که می‌توانیم انجام دهیم عبارتند از:
- مجزاسازی سرور اپلیکیشن از سرور دیتابیس: اگر یک اپلیکیشن به اصطلاح Monolithic داشته باشیم که تمامی اجزای آن روی تنها یک سرور است، شاید بتوان با انتقال دیتابیس به یک سرور مجزا پرفورمنس آن را بهبود بخشید به طوری که با دنبال کردن این استراتژی می‌توان دست به Vertical Scaling زد که در ابتدای مقاله با مفهوم آن آشنا شدیم.
- استفاده از سازوکارهای کَش مناسب: چنانچه فراخوانی داده‌ها در اپلیکیشن‌مان بیش از ثبت دادههای جدید باشد، در چنین مواقعی می‌توان با کَش کردن کوئری‌ها بار روی سرور را کم و در نتیجه پرفورمنس را زیاد کرد.
- استفاده از رِپلیکیشن: در معماری دیتابیس، Replication به فرآیند گفته می‌شود که به موجب آن دیتا از یک دیتابیس به یک یا چند دیتابیس دیگر کپی می‌شود به طوری که تمامی آن‌ها از دادههای یکسانی برخوردار خواهند بود و این کار باعث می‌شود تا پروسهٔ فراخوانی داده‌ها مابین چندین سرور پخش گردد و در نتیجه از کِرش‌های احتمالی جلوگیری شود.
طراحی اپلیکیشن اندروید | طراحی وب سایت | شرکت ایده پردازان پاراکس |
