در این مقاله به معماری‌های  Shardingو sharding-19c-new-features خواهیم پرداخت. در مقاله قبلی به معرفی sharding و انواع پارتیش بندی های آن و بررسی مزایا و معایب آن پرداختیم.

یادآوری مزایای استفاده از sharding

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

آشنایی با معماری‌های Sharding

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

Key Based Sharding : در این نوع معماری وقتی که دیتای جدیدی در دیتابیس ثبت می‌گردد، کلیدی مرتبط با آن دیتا در نظر گرفته می‌شود (به طور مثال، اگر یک مشتری جدید در فروشگاه آنلاینی ثبت‌نام می‌کند، customer_id به عنوان چنین کلیدی در نظر گرفته خواهد شد.) سپس این کلید به فانکشنی داده می‌شود که بسته به ورودی‌ای که می‌گیرد، مشخص می‌کند که آن دیتا روی چه پارتیشنی باید ذخیره گردد به طوری که داریم:

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

یکی از چالش‌های کار با معماری Key Based Sharding آن است که در صورت نیاز به افزودن سرورهای جدید و یا کم کردن تعداد سرورهای موجود، کار ممکن است به مشکل برخورد بدین صورت که مثلاً وقتی سرور جدیدی به کلاستر خود اضافه می‌کنیم، هر سرور نیاز به اصطلاحاً یک Hash Value دارد تا در حین ثبت‌ داده‌های جدید مورد استفاده قرار گیرد اما این در صورتی است که اگر بخواهیم داده‌های موجود را روی این سرور انتقال دهیم، نیاز به آپدیت دیتا به منظور شناخت این 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، که نقطه ی شروع کوئری است، به هر دلیلی با مشکل مواجه گردد، کل اپلیکیشن یا حداقل بخش‌های بسیاری از آن از کار خواهند افتاد!

sharding-19c-new-features

از مهمترین قابلیت های  shardingدر Oracle 19c  می توان به موارد زیر اشاره کرد:

MULTIPLE SHARDS IN A SINGLE MULTITENANT DATABASE

درoracle 19  امکان ادغام sharded database فراهم شده است. یعنی مثلا فرض کنیم سه دیتابیس DB-A,DB-B,DB-C را هر کدام شامل 3 shard  می باشند. می توان هر کدام از این شاردها را به عنوان یک PDB در نظر گرفت که به آنها PDB- Shards  می گویند.

در اوراکل 19 می توان با استفاده از CDB میزبان PDBهای مختلف از دیتابیس های مختلف بود.در این صورت با استفاده و سود بردن از قابلیت های CDBها می توان به کارایی دیتابیس ها نیز افزود :

SCALABLE CROSS SHARD QUERY COORDINATORS

از دیگر ویژگی های sharding در اوراکل 19 می توان به مبحث SCALABLE CROSS SHARD QUERY COORDINATORS اشاره کرد.

یعنی برای استفاده از شاردینگ می توان از Shard Catalog استفاده کرد و می توان از آن به عنوان هماهنگ کننده shard query ها استفاده کرد و همچنین برای این Shard Catalog یک یا چند سرور را به عنوان Active Data Guard standby databases در نظر گرفت :

MULTIPLE TABLE FAMILIES

همانطور که در قسمت معماری sharding هم بیان شد، یکShard Database می تواند از ادغام جداول و یا قسمت های مختلف از جداول مخلف استفاده کند.

نتیجه گیری:

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