ELI5: پارتیشن بندی پایگاه داده – جامعه Dev

این مقاله پارتیشن بندی پایگاه داده در ELI5 است. نه تنها این ، من هر موضوع را نیز با توضیحی دقیق تر پوشش می دهم. من پوشش خواهم داد:

• پارتیشن بندی چیست؟
• چرا پایگاه داده خود را پارتیشن بندی کنید؟
• پارتیشن بندی در مقابل تکثیر
• استراتژی های تقسیم ارزش کلیدی
• دست زدن به بارهای کاری و نقاط داغ
• فهرست های ثانویه با پارتیشن بندی
• درخواست مسیریابی و کشف خدمات
• اجرای پرس و جو موازی

پارتیشن بندی چیست؟ eli5

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

پارتیشن بندی = تقسیم یک پایگاه داده به قطعات کوچکتر در چندین دستگاه

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

توجه: نام های دیگری برای آن وجود دارد پارتیشیه ها، به عنوان مثال ، آن را خوانده می شود قسمت (توری) در MongoDB و Elasticsearch ، یا قرص با bigtable با این حال ، پارتیشن بندی مشخص ترین اصطلاح است.

چرا پارتیشن؟ eli5

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

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

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

ما DB را در نگه داشتن یک پارتیشن A می نامیم گرهبشر

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

پارتیشن بندی در مقابل تکثیر

پارتیشن بندی معمولاً است ترکیبی با تکثیر یعنی:

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

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

استراتژی های تقسیم ارزش کلیدی

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

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

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

1. پارتیشن بندی توسط دامنه کلیدی

چگونه کار می کند: به هر پارتیشن دامنه مداوم کلیدها (از حداقل تا حداکثر) اختصاص دهید.

مثال: با فیلم ها می توانید از نامه های شروع نام به عنوان کلیدها استفاده کنید. بنابراین فیلم هایی با A در یک گره ذخیره می شوند ، آنهایی که از B از طرف دیگر شروع می شوند و غیره.

مرزهای پارتیشن را می توان انتخاب کرد:

• به صورت دستی توسط یک مدیر
• به طور خودکار توسط پایگاه داده

این روش توسط:

• bigtable و hbase
• RETHINKDB
• MongoDB (قبل از نسخه 2.4)

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

نمونه: داده های شبکه سنسور که در آن کلید یک جدول زمانی است. به راحتی می توانید تمام خوانش ها را از یک ماه خاص واکشی کنید.

مشکل: برخی از الگوهای دسترسی نقاط داغ ایجاد می کنند. اگر کلید یک جدول زمانی است ، همه می نویسد برای “امروز” به پارتیشن می روند ، در حالی که سایر پارتیشن ها بیکار هستند.

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

ترتیب. پارتیشن بندی توسط هش کلید

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

یک عملکرد هش خوب داده های کم رنگ را به خود اختصاص داده و باعث می شود یکنواخت توزیع شود. به عنوان مثال ، کاساندرا و مونگودب از این استفاده می کنند (با MD5).

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

• به طور مساوی فاصله
• Pseudorandomly انتخاب شده (که گاهی اوقات به نام های هشدار دهنده نامیده می شود)

تجارت بزرگ: با استفاده از هش از کلید ، ما توانایی انجام پرس و جوهای کارآمد را از دست می دهیم. کلیدهایی که زمانی مجاور بودند اکنون در پارتیشن ها پراکنده شده اند و نظم مرتب سازی آنها از بین می رود.

• در MongoDB با Sharding مبتنی بر هش ، نمایش داده شدگان باید به همه پارتیشن ها ارسال شود
• نمایش داده شدگان در کلید اصلی در Riak ، Couchbase یا Voldemort پشتیبانی نمی شوند

دست زدن به بارهای کاری و نقاط داغ

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

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

با این وجود ، راه حل هایی برای این کار نیز وجود دارد.

درخواست مسیریابی و کشف خدمات

اکنون که مجموعه داده های خود را در چندین گره تقسیم کرده ایم. عالی

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

این مشکل به طور کلی (همچنین خارج از DBS) است که به عنوان شناخته می شود کشف خدماتیبشر رویکردهای اصلی وجود دارد:

1. مسیریابی ردیف

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

2. مسیریابی هر گره

• مشتری ها می توانند با هر گره تماس بگیرند (به عنوان مثال از طریق تعادل بار رابین دور)
• اگر آن گره پارتیشن درخواست را داشته باشد ، مستقیماً آن را کنترل می کند
• در غیر این صورت ، درخواست را به گره مناسب منتقل می کند و پاسخ را به عقب منتقل می کند

3. مسیریابی آگاه مشتری

• مشتریان از طرح پارتیشن بندی و نقشه برداری پارتیشن به گره اطلاع دارند
• آنها مستقیماً به گره مناسب و بدون واسطه متصل می شوند

بسیاری از سیستم ها برای ردیابی ابرداده خوشه ای به یک سرویس هماهنگی جداگانه مانند Zookeeper متکی هستند:

1. هر گره در باغ وحش ثبت می شود
2. Zookeeper نقشه برداری معتبر به گره را حفظ می کند
3. ردیف های مسیریابی یا مشتری در این اطلاعات مشترک هستند
4. وقتی پارتیشن ها مالکیت را تغییر می دهند ، Zookeeper به مشترکین اطلاع می دهد

مثالها:

• اسپرسو LinkedIn از Helix استفاده می کند (ساخته شده در Zookeeper)
• Hbase ، Solrcloud و Kafka مستقیماً از Zookeeper استفاده می کنند
• MongoDB از اجرای سرور پیکربندی خود با Daemons Mongos به عنوان ردیف مسیریابی استفاده می کند

چگونه مسیریابی درخواست با Zookeeper کار می کند

بنابراین ، شما مجموعه داده های خود را در چندین گره تقسیم کرده اید ، و از یک سرویس هماهنگی مانند Zookeeper برای مدیریت ابرداده خوشه استفاده می کنید. اما چگونه یک مشتری در واقع درخواست خود را به گره مناسب می رساند؟ بیایید جریان را تجزیه کنیم ، با تمرکز روی یک سیستم با ردیف مسیر و باغ وحش

جریان مسیریابی درخواست

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

1. مشتری درخواست را به مسیریابی ردیف ارسال می کند

   مشتری نمی داند کدام گره داده های مورد نیاز خود را در اختیار دارد ، بنابراین درخواست خود را (به عنوان مثال ، پرس و جو بانک اطلاعاتی) به یک ارسال می کند ردیف مسیربشر این یک متعادل کننده بار آگاه است ، مانند MongoDB mongos Daemon یا یک پروکسی سفارشی. کار ردیف مسیریابی این است که بفهمید درخواست را از کجا ارسال کنید.

2. Routing Tier با Zookeeper مشورت می کند

   ردیف مسیریابی باید بداند که کدام گره دارای پارتیشن برای داده های درخواستی است. پرس و جو می کند باغ وحش، که معتبر را حفظ می کند نقشه برداری پارتیشن به گرهبشر Zookeeper این ابرداده را در یک ساختار سلسله مراتبی (مانند یک سیستم فایل) ذخیره می کند ، هر زمان که گره ها به هم بپیوندند ، ترک شوند یا پارتیشن ها مجدداً تنظیم شوند. ردیف مسیریابی یا:

• این نقشه برداری را ذخیره کرده و برای به روزرسانی ها در Zookeeper مشترک می شود (برای ادامه کار) یا
• نمایش داده شد برای هر درخواست (به دلیل تأخیر کمتر) از Zookeeper در صورت تقاضا استفاده می کنند.

1. Zookeeper ابرداده را فراهم می کند

   Zookeeper با نقشه برداری پارتیشن به گره فعلی پاسخ می دهد. به عنوان مثال ، ممکن است بگوید ، “پارتیشن P1 روی گره A است (IP: 192.168.1.10) ، پارتیشن P2 روی گره B است (IP: 192.168.1.11).” این به ردیف مسیریابی دقیقاً می گوید که درخواست را از کجا ارسال کنید.

2. مسیریابی ردیف درخواست را به جلو می برد

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

3. مسیریابی ردیف پاسخ به مشتری را برمی گرداند

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