آشنایی با Sharding پایگاه داده

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

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

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

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

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

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

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

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

با توجه به این نمای کلی در مورد Sharding ، بیایید برخی از مثبت ها و منفی های مرتبط با این معماری پایگاه داده را طی کنیم.

فواید Sharding

جذابیت اصلی درنگ کردن یک بانک اطلاعاتی این است که می تواند به تسهیل مقیاس افقی ، همچنین به عنوان مقیاس گذاری شناخته شود. مقیاس بندی افقی عمل اضافه کردن دستگاه های بیشتر به یک پشته موجود به منظور پخش بار و امکان ترافیک بیشتر و پردازش سریعتر است. این اغلب با مقیاس عمودی در تضاد است ، در غیر این صورت به عنوان مقیاس گذاری شناخته می شود ، که شامل ارتقاء سخت افزار یک سرور موجود است ، معمولاً با اضافه کردن رم یا CPU بیشتر.

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

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

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

اشکالاتی از Sharding

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

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

یکی از مشکلی که کاربران گاهی اوقات بعد از اینکه یک پایگاه داده را با آن روبرو می شوند با آن روبرو می شوند این است که در نهایت این قسمت ها نامتعادل می شوند. به عنوان مثال ، بیایید بگوییم که شما یک پایگاه داده با دو قسمت جداگانه دارید ، یکی برای مشتریانی که نام خانوادگی آنها با حروف A از طریق M شروع می شود و دیگری برای کسانی که نام آنها با حروف N از طریق Z شروع می شود. از افرادی که نام خانوادگی آنها با حرف G. شروع می شود ، بر این اساس ، A-M Shard به تدریج داده های بیشتری را نسبت به N-Z One جمع می کند و باعث می شود که این برنامه کند شود و برای بخش قابل توجهی از کاربران شما متوقف شود. A-M Shard به چیزی تبدیل شده است که به عنوان کانون پایگاه داده شناخته می شود. در این حالت ، هرگونه فواید برای کاهش بانک اطلاعاتی با کندی و تصادفات لغو می شود. این پایگاه داده به احتمال زیاد نیاز به تعمیر و بازسازی مجدد دارد تا امکان توزیع داده های یکنواخت تر فراهم شود.

یک اشکال مهم دیگر این است که به محض اینکه یک پایگاه داده خرد شد ، بازگشت آن به معماری بی نظیر خود بسیار دشوار است. هرگونه نسخه پشتیبان از پایگاه داده ساخته شده قبل از اینکه Sharded باشد ، داده هایی را که از زمان پارتیشن بندی نوشته شده است ، شامل نمی شود. در نتیجه ، بازسازی معماری اصلی بدون تغییر ، نیاز به ادغام داده های جدید پارتیشن با نسخه های پشتیبان قدیمی یا در عوض ، تبدیل DB پارتیشن به یک DB واحد است که هر دو تلاش پرهزینه و وقت گیر خواهند بود.

یک نقطه ضعف نهایی که باید در نظر بگیرید این است که Sharding به طور بومی توسط هر موتور پایگاه داده پشتیبانی نمی شود. به عنوان مثال ، PostgreSQL شامل Sharding اتوماتیک به عنوان یک ویژگی نیست ، اگرچه می توان به صورت دستی یک پایگاه داده PostgreSQL را به دست آورد. تعدادی از چنگال های Postgres وجود دارد که شامل Sharding اتوماتیک می شود ، اما این موارد اغلب در پشت آخرین انتشار PostgreSQL قرار دارند و از ویژگی های دیگری برخوردار نیستند. برخی از فن آوری های تخصصی پایگاه داده-مانند MySQL Cluster یا برخی از محصولات دیتابیس به عنوان یک سرویس مانند Atlas MongoDB-شامل ضبط خودکار به عنوان یک ویژگی هستند ، اما نسخه های وانیلی این سیستم های مدیریت پایگاه داده این کار را نمی کنند. به همین دلیل ، Sharding اغلب به رویکرد "رول خود" نیاز دارد. این بدان معنی است که مستندات مربوط به خرد کردن یا نکاتی برای مشکلات عیب یابی اغلب دشوار است.

این موارد ، البته ، فقط برخی از موضوعات کلی است که باید قبل از Sharding در نظر بگیرند. بسته به مورد استفاده از آن ، ممکن است اشکالاتی بالقوه بیشتری برای کاهش یک بانک اطلاعاتی وجود داشته باشد.

اکنون که چند اشکال و مزایای Sharding را پوشش داده ایم ، برای پایگاه داده های Sharded چند معماری مختلف را طی خواهیم کرد.

معماری های Sharding

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

شاردرینگ کلیدی

اشتراک گذاری مبتنی بر کلید، که به عنوان اشتراک گذاری مبتنی بر هش نیز شناخته می شود، شامل استفاده از یک مقدار گرفته شده از داده های تازه نوشته شده - مانند شماره شناسه مشتری، آدرس IP برنامه مشتری، یک کد پستی و غیره - و اتصال آن به یک تابع درهم سازی برای تعیین است. داده ها باید به کدام قطعه بروند. تابع هش تابعی است که بخشی از داده (مثلاً یک ایمیل مشتری) را به عنوان ورودی می گیرد و یک مقدار مجزا به نام مقدار هش خروجی می دهد. در مورد اشتراک گذاری، مقدار هش یک شناسه خرده ای است که برای تعیین اینکه داده های دریافتی در کدام قطعه ذخیره می شود استفاده می شود. در مجموع، روند به صورت زیر است:

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

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

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

شاردینگ مبتنی بر محدوده

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

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

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

شاردینگ مبتنی بر دایرکتوری

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

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

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

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

باید شارد؟

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

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

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

قبل از Sharding ، شما باید تمام گزینه های دیگر را برای بهینه سازی پایگاه داده خود خسته کنید. برخی از بهینه سازی هایی که ممکن است بخواهید در نظر بگیرید عبارتند از:

• تنظیم یک پایگاه داده از راه دور. اگر در حال کار با یک برنامه یکپارچه هستید که در آن همه مؤلفه های آن در همان سرور زندگی می کنند ، می توانید با انتقال آن به دستگاه خود ، عملکرد پایگاه داده خود را بهبود بخشید. این به همان اندازه پیچیدگی اضافه نمی کند زیرا جداول پایگاه داده دست نخورده باقی مانده است. با این حال ، هنوز هم به شما امکان می دهد تا از بقیه زیرساخت های خود ، پایگاه داده خود را به صورت عمودی مقیاس بندی کنید.
• اجرای حافظه پنهاناگر عملکرد خوانده شده برنامه شما همان چیزی است که باعث ایجاد مشکل می شود ، ذخیره سازی یک استراتژی است که می تواند به بهبود آن کمک کند. ذخیره سازی شامل ذخیره موقت داده هایی است که قبلاً در حافظه درخواست شده است و به شما امکان می دهد بعداً خیلی سریعتر به آن دسترسی پیدا کنید.
• ایجاد یک یا چند ماکت خوانده شده. استراتژی دیگری که می تواند به بهبود عملکرد خواندن کمک کند ، این شامل کپی کردن داده ها از یک سرور پایگاه داده (سرور اصلی) بر روی یک یا چند سرور ثانویه است. پس از این ، هر نوشتن جدید قبل از کپی کردن در ثانیه ها به ابتدای کار می رود ، در حالی که خوانده شده ها منحصراً به سرورهای ثانویه ساخته می شوند. توزیع خواندن و نوشتن مانند این باعث می شود که هر یک از دستگاه ها بیش از حد بار را از آن استفاده کنند و به جلوگیری از کند شدن و تصادفات کمک می کنند. توجه داشته باشید که ایجاد ماکت های خواندن شامل منابع محاسباتی بیشتری است و بنابراین هزینه بیشتری هزینه می کند ، که می تواند برای برخی محدودیت قابل توجهی باشد.
• ارتقاء به یک سرور بزرگتر. در بیشتر موارد ، مقیاس گذاری سرور پایگاه داده شخص به دستگاهی با منابع بیشتر نیاز به تلاش کمتری نسبت به خرد کردن دارد. همانطور که با ایجاد ماکت های خواندن ، یک سرور به روز شده با منابع بیشتر احتمالاً هزینه بیشتری خواهد داشت. بر این اساس ، اگر واقعاً بهترین گزینه شما باشد ، فقط باید با تغییر اندازه استفاده کنید.

به خاطر داشته باشید که اگر برنامه یا وب سایت شما از یک نقطه خاص رشد کند ، هیچ یک از این استراتژی ها برای بهبود عملکرد به تنهایی کافی نخواهد بود. در چنین مواردی ، در واقع ممکن است Sharding بهترین گزینه برای شما باشد.

نتیجه

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

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

اگر از این آموزش و جامعه وسیع ما لذت بردید ، در نظر بگیرید که محصولات دیجیتالی ما را بررسی کنید که می تواند به شما در دستیابی به اهداف توسعه نیز کمک کند.