Sharding demystified – جامعه dev

به دنبال وبلاگ های طراحی سیستم من ، این وبلاگ دیگری است که ما در مورد “Sharding vs Partition” یاد خواهیم گرفت.

بسیاری از افراد فرض می کنند که Sharding و Partition یکسان هستند اما اینگونه نیستند. هنگام کار با سیستم های توزیع شده ، با برنامه های فشرده داده ها و داده ها این 2 مفهوم مفید خواهد بود.

برای درک تکه تکه شدن و پارتیشن ، ما به یک مشکل خواهیم پرداخت و سپس خواهیم دید که چگونه و کجا اینها کمک خواهد کرد.

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

مشکل

تصور کنید که شما یک برنامه وب به سبک ملاقات ایجاد کرده اید. کاربران می توانند ثبت نام ، مرور رویدادها و RSVP را به مواردی که به آنها علاقه مند هستند ، ثبت نام کنند.

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

1 ایجاد و به روزرسانی پروفایل

2 مرور صدها رویداد آینده

3 ارسال RSVP در زمان واقعی

در نتیجه ، شما شروع به توجه به علائم استرس در باطن خود می کنید:

1 ملاقات ها بیشتر از آنچه انتظار می رود طول می کشد

2 اقدامات RSVP انجام می شود تأخیر یا وقت خارج

3 صفحات به آرامی بارگیری می شوند، به خصوص در ساعات اوج

در بازرسی عمیق تر ، شما موضوعات اصلی را شناسایی می کنید:

1 الگوهای خواندن/نوشتن سنگین در همان جداول پایگاه داده (کاربران ، ملاقات ها ، RSVPS)

2 تأخیر پرس و جو رشد با اندازه داده ؛ با افزایش ردیف ها ، شاخص ها نفخ می شوند و کارآمدتر می شوند

3 مشاجره بنویسید روی میزهای داغ مانند RSVP

4 IOPS و استفاده از CPU در نمونه پایگاه داده خود به محدودیت های آنها ضربه بزنید

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

راه حل

برای رفع موضوعات فوق ، پارتیشن بندی و Sharding وارد می شود. در این وبلاگ ما Sharding را کشف خواهیم کرد.

توری

Sharding فرآیند تقسیم یک بانک اطلاعاتی بزرگ به قطعات کوچکتر و مستقل به نام shards است که در سرور متعدد توزیع می شوند. هر قسمت شامل زیر مجموعه ای از داده ها است. یک کلید Shard نحوه توزیع داده ها را تعیین می کند.

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

مزایای شاری:

1 مقیاس بندی : Sharding “مقیاس افقی” است. این کمک می کند تا در مقیاس بندی سیستم و همچنین Shard در چندین سرور توزیع شود.

2 تالریس تقصیر : اگر یک قطعه شکست بخورد ، این شکست روی سایر قسمتهای دیگر تأثیر نمی گذارد. این سیستم همانطور که انتظار می رود ادامه خواهد داد و این کمک می کند تا از Tolrance Fault اطمینان حاصل شود. صفتی که هر معماری باید داشته باشد.

3 عمل : از آنجا که داده ها در چندین قطعه پخش می شوند و سرورها عملکرد پرس و جو بهبود می یابد و همچنین خطر “نقاط داغ” را کاهش می دهد.

4 از همزمانی بالا پشتیبانی می کند : هر شارد می تواند نمایش داده ها را به طور مستقل پردازش کند.

5 قرار دادن داده های متناسب : Shard مبتنی بر جغرافیا ، مستاجر یا الگوهای دسترسی

انواع Shard:

قرص جادویی؟

Sharding قرص جادویی نیست که همه مشکلات را برطرف می کند. این همراه با چند مورد توافق است. اساساً “تجارت”. در مشکل ملاقات ما ، Sharding by Scale به مقیاس کمک می کند: US → Shard A ، Eu → Shard B.But کاربرانی که در رویدادها در مناطق شرکت می کنند ممکن است با تأخیر یا جستجوی متقاطع روبرو شوند.

1 پیچیدگی عملیاتی : قطعات بیشتر در حال حرکت: نظارت ، تهیه نسخه پشتیبان و استقرار پیچیده تر می شود.

2 پیچیدگی داده ها : رسیدگی به داده ها در Sharding پیچیده است و در مقایسه با راه حل غیر خرد کننده است. شما باید داده ها را تهیه کرده و آنها را برای تصحیح Shard و همچنین مدیریت بازیابی داده ها نیز ذخیره کنید.

3 مجدداً : اگر مجبور به مجدداً شوید ، پیچیدگی دیگری خواهد بود

4 نمایش داده شد : نمایش داده شدگان بین قسمتها آسان نیست. پیوستن ، جمع آوری و معاملات در سراسر Shard دشوار و کندتر است.

5 توزیع بار متناقض : انتخاب کلید Shard ضعیف می تواند به “قسمتهای داغ” با بار نابرابر منجر شود.

قوام داده ها و اندازه گیری

با استفاده از Sharding ، ما در حال دور زدن ، ذخیره و بازیابی داده ها از چندین قطعه توزیع شده در سرور متعدد هستیم. این ما را به این سؤال سوق می دهد – “چگونه قوام داده ها چگونه خواهد بود؟ – قوی ، ضعیف یا در نهایت”.

در Sharding ، ما قوام نهایی را خواهیم داشت

چگونه خرد کنیم؟

اکنون که ما می دانیم که چه چیزی برای تجارت ، تجارت ، زمان لازم برای یادگیری در مورد نحوه انجام کار کردن است. برای مشکل ملاقات ما ، بیایید با:

1 داده ها و بار کار را درک کنید : کدام جدول بزرگ است ، و خواندن/نوشتن زیاد می شود. به عنوان مثال: در جدول ملاقات است usersبا rsvpsبا meetupsبشر

2 یک کلید Shard را انتخاب کنید : زمان انتخاب یک کلید Shard ، این نحوه توزیع داده ها را تعیین می کند. شناسایی کلید Shard که به طور مساوی بار ، کاردینال بودن بالا (مقدار زیادی از مقادیر منحصر به فرد) را توزیع می کند ، مهمترین الگوهای پرس و جو است. به عنوان مثال: users -> user_id با meetups -> location یا organizer_id

3 یک استراتژی Sharding را انتخاب کنید : استراتژی Sharding چه باید باشد؟ در مورد ما ، ما می توانیم با Sharding مبتنی بر جغرافیایی برویم. به عنوان مثال: هنگامی که کاربر وارد برنامه می شود ، منطقه کاربر را مشخص می کند ، درخواست ها را به سمت صحیح و کلیه عملیات (ملاقات های واکشی ، RSVP و غیره) به آن Shard می رساند. به عنوان مثال: کاربر از ایالات متحده به Shard A (داشتن داده های ایالات متحده) می رود.

4 منطق برنامه را به روز کنید : اینجاست که کد می رود. نوشتن درخواست های مسیر ، رسیدگی به نمایش داده های متقاطع و غیره

هنگامی که داده های شما به هم ریخته شد ، یک کار مهم دیگر برای مراقبت از چه کسی تصمیم می گیرد که داده ها به کجا می رود: مشتری (برنامه پس زمینه) یا سرور؟

تنظیم: زمان کد

PS: نمونه های کد زیر فقط برای درک مفهوم Sharding است. اینها کد “آماده” نیستند.

پیکربندی

یک فایل پیکربندی که شامل رشته اتصال پایگاه داده در برابر منطقه است. مقیاس افقی امکان پذیر است (با رشد قسمت های بیشتر مناطق بیشتری را اضافه کنید)

// shard-config.js
export const shardMap = {
  US: {
    name: 'Shard A',
    connectionString: 'postgres://user:pass@shard-us.example.com/meetupdb',
  },
  EU: {
    name: 'Shard B',
    connectionString: 'postgres://user:pass@shard-eu.example.com/meetupdb',
  },
  ASIA: {
    name: 'Shard C',
    connectionString: 'postgres://user:pass@shard-asia.example.com/meetupdb',
  },
};

روتر

روتر مسئول مسیریابی کاربران به سمت صحیح خواهد بود. نمایش داده ها فقط به قسمتهای مربوطه هدایت می شوند و تأخیر را کاهش می دهند.

// db-router.js
import { shardMap } from './shard-config.js';
import { Client } from 'pg';

export function getShardClient(region) {
  const shard = shardMap[region];
  if (!shard) throw new Error(`No shard found for region: ${region}`);

  const client = new Client({ connectionString: shard.connectionString });
  return client;
}

RSVP

// rsvp.js
import { getShardClient } from './db-router.js';

export async function rsvpToMeetup(region, userId, meetupId) {
  const client = getShardClient(region);
  await client.connect();

  await client.query(`
    INSERT INTO rsvps (user_id, meetup_id) VALUES ($1, $2)
  `, [userId, meetupId]);

  await client.end();
  console.log(`User ${userId} RSVPed to meetup ${meetupId} in ${region}`);
}

ابزارهایی برای Sharding

1. Viticess (لایه Sharding for MySQL)

2 MongoDB (Sharding داخلی)

3 citus (postgres مقیاس پذیر با Sharding)

4 proxysql (mysql مسیریابی/پروکسی Sharding)

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

پس از اجرای Sharding در پروژه Meetup ما می توانیم پیشرفت های زیر را مشاهده کنیم:

1 بهبود عملکرد

2 تأخیر کم

3 مقیاس بندی

4 Tolrance Fault (بدون Spof)

خلاصه

1 Sharding = تقسیم داده ها در چندین پایگاه داده برای رسیدگی به مقیاس ، عملکرد و تحمل گسل.

2 این همان پارتیشن بندی نیست – نشان دادن شامل توزیع فیزیکی است.

3 Sharding باعث افزایش مقیاس پذیری می شود اما پیچیدگی در پرس و جو ، قوام و تعادل مجدد را می افزاید.

4 انتخاب کلید Shard Right بسیار مهم است – برای کاردینالیت بالا و الگوهای دسترسی متعادل.

5 استراتژی های متداول شامل شیاطین مبتنی بر جغرافیا ، مستاجر یا مبتنی بر ویژگی است.

6 از چالش هایی مانند نمایش داده های متقاطع ، مجدداً و سربار عملیاتی آگاه باشید.

7 فقط در صورت لزوم از Sharding استفاده کنید – این قدرتمند است ، اما یک گلوله نقره ای نیست.

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

یادگیری مبارک !!