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 خواهیم پرداخت.