Database Sharding چیست؟

 Shard در لغت به معنی «تکه» است و Sharding نیز یک الگوی طراحی دیتابیس است که در آن داده‌ها در قالب چندین و چند جدول و دیتابیس مختلف تقسیم ‌بندی می‌شوند و همین مسئله منجر بدان خواهد شد که مدیریت ریکوئست‌های زیاد راحت‌تر گردد.

Oracle Sharding بخش‌هایی از یک مجموعه داده را در بسیاری از پایگاه‌های داده (شاردها) در رایانه‌های مختلف، در محل یا در cloud توزیع می‌کند.

Oracle Sharding به طور خودکار داده ها را روی قطعه مورد نظر قرار می دهد، در زمان صرفه جویی می شود و آماده سازی دستی داده ها را حذف می کند.

برای درک بیشتر مفهوم بهتر است ابتدا با انواع پارتیشن بندی اطلاعات و تفاوت آنها بایکدیگر آَشنا شویم:

این دو واژه به ترتیب به معنی «افقی» و «عمودی» است. پارتیشن‌بندی افقی (Horizontal Partitioning) به این موضوع اشاره دارد که رکوردهای ثبت‌شده در یک جدول را از یکدیگر جدا ساخته و هر گروه را در یک جدول که در اینجا تحت عنوان پارتیشن شناخته می‌شود ذخیره می‌سازند و این در حالی است که هر جدول (پارتیشن) از اِسکما و ستون‌های دقیقاً مشابهی برخوردار است اما داده‌های ذخیره ‌شده در آن‌ها متفاوت و در عین حال منحصر‌به‌فرد هستند؛ به عبارتی، هیچ جدولی حاوی داده‌های یکسان نخواهد بود.

آشنایی با تفاوت‌های پارتیشن‌بندی Horizontal و Vertical

در پارتیشن ‌بندی عمودی (Vertical Partitioning) یکسری ستون خاص در یک جدول و یکسری ستون خاص دیگر در جدولی دیگر طراحی می‌شود و داده ‌های ذخیره‌شده در این دست جداول نیز منحصربه‌فرد هستند؛ به عبارتی، هیچ دو جدول (پارتیشن) را نمی‌توان یافت که حاوی ساختار و داده‌های یکسانی باشد.

در پاسخ به این پرسش که «تفاوت مابین پارتیشن ‌بندی افقی و پارتیشن ‌بندی عمودی چیست؟» می‌توان گفت که در پارتیشن‌ بندی افقی فقط داده‌های جداول منحصربه ‌فرد هستند در حالی که در پارتیشن‌ بندی عمودی علاوه بر داده‌ها، ستون‌های جداول نیز با یکدیگر فرق دارند. همان‌طور که در تصویر زیر ملاحظه می‌شود، یک جدول داریم تحت عنوان Original Table که وقتی آن را به صورت افقی پارتیشن‌بندی کنیم دو جدول تحت عناوین HP1 و HP2 خواهیم داشت که در هر دوی آن‌ها اِسکیما (ساختار) دیتابیس یکسان است اما هر کدام حاوی داده‌های متفاوتی است اما زمانی که این جدول را به صورت عمودی پارتیشن‌بندی می‌کنیم، دو جدول خواهیم داشت تحت عناوین VP1 و VP2 که اِسکیمای آن‌ها با یکدیگر فرق داشته مضاف بر اینکه هر کدام از آن‌ها مسئول ذخیره‌سازی داده یخاصی است.

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

آشنایی با مزایای Sharding

یکی از کلیدی‌ترین مزایای Sharding آن است که امکانی را در اختیار توسعه‌دهندگان می‌گذارد تا بتوانند دست به توسعه ی افقی (Horizontal Scaling) بزنند بدان معنا که به منظور پخش کردن بار روی سرورها و بالطبع افزایش سرعت پردازش داده‌ها، از مجموع چندین و چندین دیتابیس مختلف استفاده می‌شود. این نوع معماری نقطه ی مقابل توسعه ی عمودی (Vertical Scaling) قرار دارد که در آن تیم دوآپس به افزایش قدرت سخت‌افزاری همچون ارتقاء رَم و سی‌پی‌یو می‌پردازد تا بتواند در آنِ واحد تعداد ریکوئست‌های بیشتری را با حفظ پرفورمنس هندل کند.

اساساً وقتی پای توسعه ی عمودی به میان می‌آید، به راحتی می‌توان زیرساخت سخت‌افزاری را دائماً ارتقاء داد تا با رشد تعداد کاربران، سرور نیز بتواند به همان میزان پاسخ‌گوی نیاز ایشان باشد اما به خاطر داشته باشیم که این کار نهایتاً تا یک جایی امکان‌پذیر است مضاف بر اینکه کاری هزینه ‌بر است!

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

همچنین Sharding این تضمین را ایجاد می‌کند که در حین downtime و به طور کلی زمان‌هایی که مشکلی برای سرور رخ می‌دهد، اپلیکیشن پایدارتر باشد. برای درک بهتر این موضوع، فرض کنیم وب اپلیکیشنی داریم که مبتنی بر یک دیتابیس معمولی (Unsharded Database) است که در چنین شرایطی رخداد مشکل برای سرور دیتابیس منجر بدان خواهد شد که کل اپلیکیشن از دسترس خارج گردد اما این در حالی است که با برخورداری از یک Sharded Database احتمال آنکه مشکل فقط یک Shard را از کار بیندازد بیشتر است که این مسلماً باعث پایداری بیشتر اپلیکیشن خواهد شد و فقط بخش‌هایی از اپلیکیشن به طور موقت از کار خواهند افتاد.

آشنایی با معایب Sharding

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

یکی دیگر از مشکلات مرتبط با Sharding آن است که احتمال دارد تا تعادل مابین پارتیشن‌های مختلف از بین برود. به منظور درک بهتر این موضوع، فرض کنیم دو جدول داریم که در یکی از آن‌ها اسامی کاربرانی که نام‌شان با حروف «الف» تا «س» شروع می‌شود را ذخیره می‌کنیم و در دیگری دیتای کاربرانی که نام ‌شان با حروف «ش» تا «ی» آغاز می‌گردد اما این در حالی است که مثلاً کاربرانی که اسم آن‌ها با حرف «ب» شروع می‌شود به مراتب بیش از سایر حروف الفبا است که در چنین شرایطی جدولی که مسئول ذخیره‌سازی حروف «الف» تا «س» است بسیار حجیم شده و بالطبع فراخوانی داده‌ها برای حجم قابل‌توجهی از کاربران کُند خواهد شد. 

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

نتیجه گیری:

برخی متخصصین بر این باورند که با حجیم شدن دیتابیس مهاجرت به سمت معماری Sharding حتمی است از انجا که حجم داده‌ها آن‌قدر بالا است که یک دیتابیس به تنهایی نمی‌تواند آن‌ها را هندل کند  ویا حجم خواندن/ نوشتن دیتا آن‌قدر بالا است که منابع یک سرور کفایت نمی‌کند لذا از Sharding استفاده می شود.لازم به ذکر است Shardها را می‌توان اضافه و حذف کرد، و داده‌ها را می‌توان بدون هیچ‌گونه خرابی یا از دست دادن داده، مجدداً تغییر Shard داد. در مقاله بعدی به طور مفصل تر به انواع Sharding و new-features در Oracle 19c خواهیم پرداخت.