Database Sharding چیست، چه مزایا و معایبی دارد؟

شاردینگ چیست؟

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

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

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

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

تفاوت‌های پارتیشن‌بندی افقی و عمودی

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

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

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

شکل 1

معماری شاردینگ چه مزایایی ارائه می‌دهد؟ 

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

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

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

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

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

معماری  شاردینگ چه معایبی دارد؟

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

مشکل دیگر معماری شاردینگ، برهم خوردن تعادل بین پارتیشن‌های مختلف است. برای درک بهتر این موضوع، فرض کنید دو جدول داریم که در یکی از آن‌ها اسامی کاربرانی را که نام‌شان با حروف a تا s  آغاز می‌شود ذخیره می‌کنیم و دیگری داده‌های کاربرانی را که نام‌‌شان o تا z است ذخیره‌سازی می‌کند. به‌طور معمول، ممکن است کاربرانی که اسم آن‌ها با حرف B شروع می‌شود بیشتر از سایر حروف الفبا باشد. در چنین شرایطی، جدولی که مسئول ذخیره‌‌سازی حروف a تا s است، بیش‌ازاندازه بزرگ می‌شود که باعث می‌شود سرعت فراخوانی داده‌ها از میان حجم انبوهی از رکوردها زیاد شود. 

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

معماری شاردینگ به چه صورتی کار می‌کند؟

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

• Key Based Sharding:  در معماری فوق، وقتی داده‌های جدیدی در پایگاه داده ذخیره‌سازی می‌شوند، کلیدی مرتبط با آن داده‌ها در نظر گرفته می‌شود. به‌طور مثال، اگر مشتری جدیدی در فروشگاه آنلاینی ثبت‌نام می‌کند، customer_id  به‌عنوان کلید در نظر گرفته می‌شود. در ادامه، این کلید در اختیار تابعی قرار می‌گیرد که بسته به ورودی‌ای که دریافت می‌کند، مشخص می‌کند داده‌ها باید روی چه پارتیشنی ذخیره‌سازی شوند. به‌منظور حصول اطمینان از این‌که داده‌ها روی پارتیشن‌های مناسبی ذخیره می‌شوند، نیاز است تا مقادیری که وارد چنین تابعی می‌شوند، به‌عنوان Hash Function شناخته شوند تا ماهیتی منحصربه‌فرد پیدا کنند. برای درک بهتر این موضوع، می‌توان Primary Key  را به‌عنوان چنین داده‌ای در نظر گرفت که در معماری فوق به‌عنوان Shard Key شناخته می‌شود. نکته ظریفی که باید در این زمینه به آن دقت کنید این است که کلید فوق نباید در طول زمان دست‌خوش تغییر شود، زیرا یکپارچگی داده‌ها از دست خواهد رفت و حتا اگر مشکلی برای یکپارچگی داده‌ها به وجود نیاید، فرآیند پردازشی و محاسباتی زیادی برای به‌روزرسانی پارتیشن‌های مربوطه نیاز خواهد بود.

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

• Range Based Sharding: پارتیشن‌بندی مبتنی بر محدوده، شامل به اشتراک‌گذاری داده‌ها بر اساس بازه‌ای از مقادیر مشخص است. برای درک بهتر الگوی فوق، فرض کنید در یک فروشگاه آنلاین پایگاه داده‌ای دارید که داده‌های مرتبط با تمامی محصولات در آن ذخیره شده است. به‌منظور پارتیشن‌بندی این پایگاه داده می‌توان از پایگاه‌های داده یا جداول مختلفی بر اساس قیمت محصولات استفاده کرد. یکی از مزایای پیاده‌سازی این معماری، سهولت در استفاده است، به طوری‌که طرح‌واره تمامی پارتیشن‌ها یکسان است. در چنین شرایطی، وقتی در نظر داشته باشید تغییری در سطح برنامه کاربردی اعمال کنیم تا مشخص کنیم داده‌ها‌ی جدید در کدام پارتیشن باید ذخیره‌سازی شوند، تنها کاری که باید انجام دهیم این است که به بازه قیمتی آن دقت کنیم و بر مبنای آن، پارتیشن مناسب را انتخاب کنیم. البته، مشابه با حالت قبل و مثالی که در مورد حروف الفبا ارائه کردیم، در این نوع معماری نیز ممکن است تعادل به‌هم بخورد، به طوری‌که این احتمال وجود دارد تا محصولاتی که در بازه ده هزار تا یک میلیون تومان هستند، زیاد باشند و پارتیشن بیش‌از‌اندازه میزبان رکوردهای اطلاعاتی شود. 
• Directory Based Sharding: همان‌طور که در شکل ۲ مشاهده می‌کنید، در این معماری به مولفه‌ای که Lookup Table  نام دارد، نیاز داریم. این مولفه وظیفه ذخیره‌سازی Shard Key را بر عهده دارد تا بر مبنای آن مشخص شود چه پارتیشنی چه نوع داده‌ای را باید ذخیره‌سازی کند. به عبارت دیگر، این جدول مثل فهرست واژگان انتهای کتاب‌ها است که از آن طریق مشخص می‌شود کدام اصطلاح در کدام بخش یا کدام صفحه استفاده شده است. 

همان‌طور که در شکل ۲ مشاهده می‌کنید، ستون Delivery Zone به‌عنوان Shard Key در نظر گرفته شده است. در ادامه، داده‌ها بر مبنای این ستون در Lookup Table ثبت می‌شوند. در این حالت، مشخص می‌شود هر کلید مرتبط با کدام پارتیشن است. در مقایسه با معماری قبلی (Range Based Sharding)، در مواقعی که مهم نباشد برای ذخیره‌سازی داده‌ها از کدام پارتیشن باید استفاده شود، Directory Based Sharding  عملکرد بهتری نسبت به نمونه قبل دارد. یکی از مزایای معماری فوق  انعطاف‌پذیری زیادی است که ارائه می‌کند. در این حالت، توسعه‌دهندگان می‌توانند از الگوریتم اختصاصی خودشان برای توزیع داده‌ها بین پارتیشن‌های مختلف استفاده کنند. علاوه بر این، افزودن پارتیشن‌های جدید به‌شکل پویا ساده خواهد بود. تنها نقطه ضعف معماری فوق این است که اگر Lookup Table که نقطه شروع کوئری است، به هر دلیلی با مشکل روبه‌رو شود، عملکرد کل برنامه یا حداقل بخش‌های زیادی از آن از کار خواهند افتاد.

شکل 2

کلام آخر

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

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

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