شاردینگ (Sharding)

شاردینگ sharding

شاردینگ یک نوع پارتیشن بندی پایگاه داده است که پایگاه های داده بسیار بزرگ را به قطعات کوچکتر ، سریعتر و با سهولت بیشتری مدیریت می کند که شاردز(shards) داده ها را جدا می کند. کلمه شارد به معنی بخش کوچکی از یک کل است. در اینجا چگونگی توضیحات جیسون تی شاردینگ( Jason Tee Sharding) در سمت سرور آمده است: “به ساده ترین معنا ، خرد کردن پایگاه داده شما شامل تجزیه پایگاه داده بزرگ شما به پایگاه های داده بسیار کوچکتر است که هیچ چیزی ندارند و می توانند در سرورهای مختلف پخش شوند.

شاردینگ sharding

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

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

 توضیحاتی در رابطه با  تکنوپدیا شاردینگ (Techopedia Sharding )

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

 معایب شاردینگ( Sharding)

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

 پیوستن به پیچیدگی:

هنگامی که یک پایگاه داده واحد در سرورهای متعدد تکه تکه می شود ، دیگر انجام پیوستن ساده نیست ، زیرا این پیوند باید در سرورهای متعددی اجرا شود. یک راه حل معمول برای این مشکل ، غیر عادی سازی است که به موجب آن ویژگی های خاصی در جداول متعدد تکرار می شوند در مثال پورتال توخالی( Pustak Portal)، فرض کنید انجمن های گفتگو حاوی موضوعاتی هستند که مشتریان می توانند راه اندازی کنند. هنگامی که مشتری به پورتال وارد می شود ، این سوال را در نظر بگیرید که لیستی از پاسخ ها را در مورد همه موضوعاتی که توسط مشتری آغاز شده است نمایش دهید. یک راه متداول برای انجام این کار این است که یک جدول موضوعات ، که شامل فهرستی از موضوعات است ، به همراه userid مشتری که موضوع را آغاز کرده است ، و یک جدول پاسخ ها ، که دارای یک لیست از پاسخ ها و شناسه های موضوع است ، داشته باشید. با پیوستن به جدول موضوعات و پاسخ ها در شناسه موضوع و شناسه مشتری می توان لیست مورد نظر را ایجاد کرد.

 یکی از راه های حل این مشکل افزودن مبحث شروع کننده userid (در این مورد ۹۹۹) به جدول پاسخ ها است. این امر باعث می شود که بتوان به راحتی گزارشی را که قبلاً توضیح داده شد ایجاد کرد ، اما از آنجا که جداول دیگر عادی نیستند ، حجم پایگاه داده را افزایش می دهد و مشکل ایجاد یکپارچگی جدول موضوعات و پاسخ ها را ایجاد می کند. اگر ناسازگاری وجود داشته باشد ، ممکن است مشتری در مورد موضوعاتی که آغاز کرده است پاسخ نبیند یا برعکس.

سازگاری داده ها (در شاردینگ):

مثال قبلی تنها یکی از مسائل بالقوه سازگاری داده ها است که ممکن است بوجود آید. از آنجا که جداول در سرورهای پایگاه داده متعدد تقسیم شده اند ، اطمینان از سازگاری داده ها بر عهده برنامه است.

 خرد کردن مجدد:

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

 قابلیت اطمینان (در شاردینگ) :

 پشتیبان گیری یا عکس های فوری پیچیده تر می شوند ، زیرا برای اطمینان از سازگاری ، همه تکه ها باید به صورت هماهنگ پشتیبان گیری شوند.

 پیچیدگی کلید افزایش خودکار (در شاردینگ) :

 پیاده سازی کلیدهای افزایش خودکار (جایی که هر ردیف درج شده یک کلید شماره دار متوالی دریافت می کند) باید در بین قطعات هماهنگ شود.

محدودیت های طراحی سیستم فعلی چندین محدودیت طراحی در معماری انبار داده های فعلی وجود دارد.

خرد کردن RDBMS به دلیل قوانین مطابقت با ACID نمی تواند داده ها را به طور مثر خرد کند. استفاده از مفاهیم خرد در روش های تقسیم بندی داده ها مقیاس پذیری و کاهش حجم کار را به دنبال ندارد. پارتیشن بندی اغلب باعث افزایش حجم کار می شود.

 ● معماری دیسک (در شاردینگ)

 معماری دیسک برای SAN عملکرد ضعیفی دارد و به دلیل معماری داده ها و مسائل مربوط به مدل داده ، توزیع داده ها بسیار کج است و باعث می شود بهینه سازی ضعیفی در لایه پایگاه داده رخ دهد.

 ● معماری چیدمان داده ها (در شاردینگ)

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

 ● عدم استفاده ازسی پی یو( CPU) (در شاردینگ)

 در بسیاری از سیستمها ، CPU همیشه کم استفاده می شود و این امر برای کارآیی کارآمد و مدیریت نخ مقیاس پذیر باید اصلاح شود.

 ● عدم استفاده از حافظه

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

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

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

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

 در زمینه یک فروشگاه آر دی اف(RDF) توزیع شده ، تخصیص داده ها را می توان با استفاده از یکی از روش های عملی زیر انجام داد:

 • تخصیص تصادفی

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

• تخصیص مبتنی بر هش یک تابع هش ، دستگاهی را که باید قطعه روی آن ذخیره شود ، مشخص می کند. عملکرد هش بر روی یک کلید اصطلاحاً شاردینگ( Sharding )کار می کند ، که در بسیاری موارد موضوع سه برابرآر دی اف( RDF) است. این اطمینان می دهد که همه سه گانه با یک موضوع مشخص در یک دستگاه ذخیره می شوند. این رویکرد امکان جستجوی مستقیم به ماشین هایی را می دهد که در آنها سه گانه یا چهارگانه با یک تابع هش شناخته شده جهانی ذخیره می شوند. برای پرس و جوهای حلقه شاخص ساده کارآمد شناخته می شود اما برای موارد پیچیده ، زیرا ارتباطات شبکه ای زیادی مورد نیاز است. این روش در سیستم هایی مانند  شارد(YARS2 ، (SHARD و Virtuoso استفاده می شود.

 • پارتیشن بندی

نمودار این روش از یک تابع گراف برای تقسیم نمودار به زیرگرافها و ذخیره آنها بر روی ماشینهای مختلف استفاده می کند. ایده اصلی این است که سه گانه های نزدیک به هم را در نمودار روی یک دستگاه نگه دارید. این امر باید حداقل برای برخی از کلاسهای پرس و جو ، ارتباط شبکه بین گره ها را در زمان پاسخگویی به پرس و جو محدود کند. پارتیشن بندی گراف یک مشکل سخت است که معمولاً به الگوریتم های اکتشافی و تقریبی نیاز دارد. با این وجود ، کارهای تحقیقی مانند هوانگ و همکاران. (۲۰۱۱) و D-SPARQ این مشکل را برای داده های RDF برطرف کرده اند و نتایج ارزیابی دلگرم کننده ای دارند. • درخواست تخصیص بر اساس بار این نوع تخصیص در نظر می گیرد که یک نفر دارای حجم کاری معمولی از پایگاه داده توزیع شده به مدل است. با توجه به مجموعه ای از پرس و جوها ، می توان یک تخصیص مطلوب تعریف کرد ، یعنی حفظ سه گانه ای که قرار است به آن دسترسی داشته باشیم.

در نهایت ، تکرار نشان می دهد که سیستم چندین نسخه از یک قطعه را در ماشین های مختلف ذخیره می کند. این ما را قادر می سازد تا دسترسی به داده ها را افزایش دهیم (زیرا قطعه یکسانی از ماشین های مختلف قابل دسترسی است) و از ارزیابی سریعتر پرس و جو برای جستجوهای ساده خوانده شده که نیاز به دسترسی به قطعه ذخیره شده در همان مکان یا هنگام پردازش پرس و جو موازی دارند پشتیبانی می کند. توسعه یافته. در مواردی که به روز رسانی سه گانه پشتیبانی می شود ، که به ندرت اتفاق می افتد ، باید کپی ها حفظ شوند. این را می توان از طریق رویکردهای مختلف انجام داد که می توانند به صورت همزمان یا ناهمزمان طبقه بندی شوند. تکرار همزمان بسیار پرهزینه تلقی می شود زیرا به طور کلی نیاز به قفل اختصاصی در همه نسخه های قطعه اصلاح شده دارد. این امر برخی تأخیرها را معرفی می کند و حتی می تواند مانع از اتمام برخی معاملات شود. به همین دلایل ، تکرار ناهمزمان بیشتر در سیستم های مدیریت پایگاه داده اخیر مانند NoSQL و NewSQL استفاده می شود. با این وجود ، می تواند برخی ناهماهنگی های موقتی را بین قطعات ذخیره شده در ماشین های مختلف ایجاد کند. به عنوان مثال ، قطعه ای که در ماشینهای M1 و M2 ذخیره می شود ممکن است برای مدت کوتاهی دارای حالات متفاوتی باشد.

 ۴.۴.۲تقسیم بندی ، تکرار و ذخیره خودکار شاردینگ(Sharding)

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

ارزجو

گس Gas چیست؟

اندازه بلاک (Block Size) چیست؟

پاداش بلاک Block Reward چیست؟

به اشتراک بگذارید:

اشتراک گذاری در email
اشتراک گذاری در twitter
اشتراک گذاری در linkedin
اشتراک گذاری در telegram
اشتراک گذاری در whatsapp
دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

پنج − 4 =

CMO
تحلیل تکنیکال
khabaz

اندیکاتور CMO

اندیکاتور Chande momentum oscillator یا CMO  یک شاخص مومنتوم در تحلیل تکنیکال است که توسط Tushar Chande  ابداع شده است.او این شاخص را در کتاب

سوزاندن کوین
ارزهای دیجیتال
khabaz

سوزاندن کوین Coin burning

سوزاندن کوین از نظر ارز رمزپایه، به ارسال یک رمز (یا کسری از آن) و در غیر این صورت به یک حساب غیر قابل استفاده

لایت کوین
ارزهای دیجیتال
khabaz

لایت کوین چیست

لایت کوین Litecoin جزو اولین ارز های دیجیتال می باشد که بعد از بیت کوین مورد استقبال قرار گرفت و ایده اولیه این ارز گرفتن