وبلاگ

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

sharding-chist-ak-01

شاردینگ چیست؟ یک الگوی معماری پایگاه داده است که شامل تقسیم یک مجموعه داده بزرگ به قطعات کوچکتر و قابل مدیریت تر به نام “شارد” است. هر خرده یک پایگاه داده مستقل است که شامل زیرمجموعه ای از داده های کلی است. هدف اشتراک گذاری بهبود مقیاس پذیری، عملکرد و در دسترس بودن با توزیع بار کاری پایگاه داده در چندین سرور است.

شاردینگ چگونه کار می کند؟

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

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

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

ویژگی های شاردینگ چیست؟

  1. پارتیشن بندی داده ها: Sharding یک پایگاه داده را به قطعات کوچکتر و قابل مدیریت تر به نام خرده تقسیم می کند که هر کدام شامل زیر مجموعه ای از داده های کلی است. این امکان مدیریت متمرکز و بازیابی داده ها را فراهم می کند.
  2. پردازش مستقل: هر خرده می تواند به طور مستقل عمل کند و تراکنش ها و درخواست های خود را مدیریت کند. این پردازش موازی باعث کاهش تنگناها و افزایش عملکرد کلی سیستم می شود.
  3. مقیاس پذیری: Sharding مقیاس افقی را فعال می کند و به سیستم اجازه می دهد تا با افزودن خرده های بیشتر در صورت نیاز رشد کند. این کمک می‌کند تا داده‌ها و فعالیت کاربر افزایش یافته را بدون به خطر انداختن عملکرد، تطبیق دهد.
  4. افزایش توان عملیاتی: با توزیع بار کاری در چند خرده، سیستم می تواند حجم بیشتری از تراکنش ها را به طور همزمان پردازش کند که منجر به زمان پاسخگویی سریع تر می شود.
  5. جداسازی خطا: اگر یک قطعه مشکل یا شکست را تجربه کند، بقیه می توانند به طور مستقل به کار خود ادامه دهند و انعطاف پذیری و قابلیت اطمینان کلی سیستم را بهبود بخشند.
  6. تأخیر کاهش یافته: Sharding می تواند به تأخیر کمتری برای کاربران منجر شود، زیرا درخواست ها می توانند بدون نیاز به پرس و جو از کل پایگاه داده به قطعه مربوطه هدایت شوند.
  7. استفاده از منابع پیشرفته: خرده‌ها را می‌توان در سرورها یا گره‌های مختلف توزیع کرد و استفاده از منابع و تعادل بار را در سیستم بهینه‌سازی کرد.

معماری فنی شاردینگ چیست؟

در اینجا مروری بر معماری فنی Sharding است:

  1. Shards: هر خرده زیرمجموعه ای مستقل از بلاک چین اتریوم است که شامل وضعیت، تراکنش ها و قراردادهای هوشمند خود است. خرده ها با تقسیم داده های شبکه بر اساس معیارهای خاص ایجاد می شوند و امکان پردازش موازی را فراهم می کنند.
  2. Beacon Chain: Beacon Chain شبکه را هماهنگ می کند، مکانیسم اجماع را مدیریت می کند و بر خرده ها نظارت می کند. برای اطمینان از امنیت و توافق، ثبت اعتبار، توزیع و هماهنگی بین خرده‌ها را انجام می‌دهد.
  3. ارتباطات متقاطع: باید مکانیسم‌هایی ایجاد شود تا ارتباط بین خرده‌ها را تسهیل کند و امکان به اشتراک‌گذاری داده‌ها و تراکنش‌هایی را فراهم کند که چندین خرده را در بر می‌گیرد. اطمینان از یکپارچگی و یکپارچگی در میان خرده‌ها حیاتی است و به پروتکل‌های قوی برای مدیریت تغییرات حالت و اعتبارسنجی داده‌ها نیاز دارد.
  4. در دسترس بودن داده ها: تکنیک نمونه گیری در دسترس بودن به گره ها اجازه می دهد تا بدون نیاز به دانلود کل قطعه، در دسترس بودن داده ها را تأیید کنند و کارایی را بهبود بخشد و پهنای باند مورد نیاز را کاهش دهد. هر قطعه ذخیره سازی داده های خود را حفظ می کند که شامل وضعیت و تاریخچه تراکنش خاص آن خرده می شود.
  5. مکانیسم اجماع: Sharding در اتریوم 2.0 تحت یک PoS Availability عمل می کند، جایی که اعتبار سنجی ها مسئول اعتبارسنجی تراکنش ها و ایجاد بلوک های جدید برای خرده های اختصاص داده شده خود هستند. هر خرده چرخه تولید بلوک مخصوص به خود را دارد که اجازه می دهد تراکنش ها مستقل از سایر خرده ها تأیید شوند.
  6. مدیریت شارد: اعتبار سنجی ها را می توان به صورت پویا به خرده های مختلف اختصاص داد تا بار را متعادل کرده و امنیت را بهبود بخشد. همانطور که شبکه تکامل می یابد، خرده ها را می توان مجدداً پیکربندی یا تنظیم کرد تا تغییرات حجم تراکنش یا فعالیت کاربر را تطبیق دهد.
  7. مکانیسم‌های امنیتی: اعتبارسنجی‌ها باید اتر را به‌عنوان وثیقه، ترویج رفتار صادقانه و جلوگیری از فعالیت‌های مخرب در اختیار داشته باشند. شاردینگ باید مکانیسم‌هایی را برای شناسایی و رسیدگی به خرابی‌ها در تک تک تکه‌ها بدون تأثیر بر کل شبکه ترکیب کند.

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

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

  1. مقیاس پذیری
  • مقیاس بندی عمودی (افزودن CPU/RAM بیشتر به یک دستگاه) محدودیت هایی دارد.
  • Sharding با اضافه کردن ماشین‌های بیشتر امکان مقیاس افقی را فراهم می‌کند.

2. بهبود عملکرد

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

3. در دسترس بودن بالا و تحمل خطا

  • اگر یک قطعه از کار بیفتد، تنها بخشی از داده ها تحت تأثیر قرار می گیرد، نه کل سیستم.
  • از یک نقطه شکست (SPOF) جلوگیری می کند.

5. توزیع جغرافیایی

  • داده ها را می توان در نزدیکی کاربران در مناطق مختلف ذخیره کرد تا تأخیر کاهش یابد.

2. Sharding کجا ممکن است؟

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

  1. برنامه های کاربردی وب در مقیاس بزرگ
  • رسانه های اجتماعی (فیس بوک، توییتر، اینستاگرام)
  • پلتفرم های تجارت الکترونیک (Amazon، eBay)
  • برنامه های بازی آنلاین

2. برنامه های کاربردی SaaS چند مستاجر

  • زمانی که هر مشتری یا مستاجر داده های خاص خود را دارد.

3. سیستم های مالی

  • حجم معاملات بزرگ (بورس سهام، پردازش پرداخت).

4. پایگاه داده های سری زمانی

  • سیستم های ورود به سیستم (Splunk، ELK Stack).

کجا Sharding توصیه نمی شود؟

خرد کردن زمانی ایده آل نیست:

  1. داده ها کوچک هستند و به راحتی در یک پایگاه داده قرار می گیرند.
  2. پرس و جوهای متقاطع متداول و پیچیده هستند.
  • اتصالات و تجمیع در بین خرده ها ممکن است گران باشد.

3. انطباق با اسید سختگیرانه است.

  • مدیریت تراکنش‌های توزیع‌شده بین خرده‌ها ممکن است سخت باشد.

4. Sharding پیچیدگی عملیاتی را اضافه می کند.

  • نیاز به برنامه ریزی دقیق، نظارت و نگهداری دارد.

3. SQL در مقابل NoSQL: مقایسه Sharding

به دلیل تفاوت در مدل های داده و مدیریت تراکنش، شاردینگ در پایگاه های داده SQL (رابطه ای) و پایگاه های داده NoSQL (غیر رابطه ای) متفاوت عمل می کند.

طراحی طرحواره

  • پایگاه های داده SQL (MySQL، PostgreSQL):
    پایگاه های داده SQL از یک طرح واره سفت و سخت و ساختار یافته بر اساس جداول و روابط استفاده می کنند. ساختار قبل از درج داده ها تعریف می شود و هر تغییری معمولاً نیاز به مهاجرت دارد.
  • پایگاه های داده NoSQL (MongoDB، Cassandra):
    سیستم های NoSQL طراحی انعطاف پذیر و اغلب بدون طرح واره را ارائه می دهند. داده‌ها را می‌توان در قالب‌هایی مانند JSON یا جفت‌های کلید-مقدار ذخیره کرد که امکان تکرار و تنظیمات سریع را بدون نیاز به ساختارهای از پیش تعریف‌شده دقیق فراهم می‌کند.

مکانیزم های خرد کردن

  • پایگاه های داده SQL:
    Sharding در محیط های SQL به طور کلی دستی است. توسعه دهندگان باید منطق اشتراک گذاری را در سطح برنامه پیاده سازی کنند یا از میان افزار برای پارتیشن بندی داده ها در چندین پایگاه داده استفاده کنند. این رویکرد می‌تواند پیچیده باشد، به‌ویژه زمانی که با محدودیت‌های رابطه‌ای و پیوندها سروکار داریم.
  • پایگاه های داده NoSQL:
    بسیاری از پایگاه های داده NoSQL دارای قابلیت های اشتراک گذاری داخلی هستند. سیستم‌هایی مانند MongoDB و Cassandra به‌طور خودکار داده‌ها را بر اساس یک کلید خرده تعریف‌شده در بین خرده‌ها توزیع می‌کنند و هزینه عملیاتی را کاهش می‌دهند و فرآیند مقیاس‌بندی را ساده می‌کنند.

پشتیبانی و سازگاری اسید

  • پایگاه های داده SQL:
    پایگاه های داده SQL به گونه ای طراحی شده اند که تضمین های قوی ACID (اتمی، سازگاری، جداسازی، دوام) را ارائه دهند. در حالی که این یکپارچگی تراکنش های قوی را تضمین می کند، همچنین شاردینگ را چالش برانگیزتر می کند زیرا حفظ ویژگی های ACID در چندین خرده می تواند پیچیده باشد.
  • پایگاه‌های داده NoSQL:
    در مقابل، پایگاه‌های داده NoSQL اغلب مقیاس‌پذیری را بر سازگاری قوی اولویت می‌دهند و مدل‌های سازگاری نهایی را ترجیح می‌دهند. این مبادله، اجرای شاردینگ را آسان‌تر می‌کند، زیرا سیستم می‌تواند الزامات تراکنش سخت‌گیرانه را به نفع عملکرد و مقیاس‌پذیری افقی کاهش دهد.

پیچیدگی پرس و جو و روابط داده ها

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

مقیاس پذیری

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

SQL Sharding

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

چالش ها :

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

NoSQL Sharding

خودکار یا داخلی : پایگاه های داده NoSQL مانند MongoDB و Cassandra از اشتراک گذاری بومی پشتیبانی می کنند.

مزایا :

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

4. استراتژی های خرد کردن

روش‌های مختلفی برای توزیع داده‌ها در بین خرده‌ها وجود دارد:

  1. مبتنی بر کلید (Hash Sharding)
  • یک تابع هش تعیین می کند که کدام قطعه یک رکورد را ذخیره می کند.
  • توزیع یکنواخت را تضمین می کند اما تغییر تعداد خرده ها سخت است.
  • مورد استفاده در MongoDB، Cassandra .

2. Sharding مبتنی بر محدوده

  • داده ها بر اساس یک محدوده تقسیم می شوند (مثلاً کاربران با شناسه 1-1000 در قطعه A).
  • برای پرس و جوهای متوالی خوب است اما می تواند نقاط اتصال ایجاد کند .
  • در PostgreSQL (پارتیشن بندی) استفاده می شود .

3. Sharding جغرافیایی

  • داده ها بر اساس مکان کاربر (به عنوان مثال، داده های ایالات متحده در یک خرده، داده های اتحادیه اروپا در دیگری) به صورت خرده ذخیره می شوند.
  • در پایگاه داده های چند منطقه ای استفاده می شود .

4. Sharding مبتنی بر موجودیت

  • داده های مربوط به یک نهاد خاص (به عنوان مثال، شناسه مشتری، شرکت) در یک قطعه ذخیره می شود.
  • در SaaS چند مستاجر استفاده می شود .

5. زمان و مکان استفاده از Sharding

وقتی از Sharding استفاده کنید :

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

زمانی که :

  • حجم پایگاه داده شما کوچک است.
  • پرس و جوهای شما نیاز به پیوستن مکرر در بین خرده ها دارند.
  • شما نیاز به تراکنش های سخت ACID دارید.

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

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

اتریوم چگونه از شاردینگ استفاده می کند؟

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

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

6. نتیجه گیری

Sharding یک تکنیک قدرتمند برای مقیاس‌بندی پایگاه‌های داده است، اما در پیچیدگی و سازگاری داده‌ها دارای معاوضه‌هایی است .

  • پایگاه داده های SQL نیاز به اشتراک گذاری دستی و مبارزه با عملیات متقاطع دارند.
  • پایگاه‌های اطلاعاتی NoSQL مانند MongoDB و Cassandra ، اشتراک‌گذاری داخلی را برای مقیاس‌بندی افقی آسان‌تر فراهم می‌کنند .

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

سوالات متداول مربوط به شاردینگ در اتریوم چیست؟

1. چه زمانی اشتراک گذاری در اتریوم اجرا می شود؟

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

2. اشتراک گذاری چگونه بر تجربه کاربر تأثیر می گذارد؟

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

3. Beacon Chain چه نقشی در شاردینگ دارد؟

Beacon Chain کل شبکه اتریوم را هماهنگ می‌کند، اعتبارسنجی‌ها را مدیریت می‌کند، بر عملکرد خرده‌ها نظارت می‌کند، و از اجماع و امنیت در بین خرده‌ها اطمینان می‌دهد.

دیدگاهتان را بنویسید

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