این مقاله توضیح میدهد که شرکت هایی مانند هوندا ، کانن و فوجی- زیراکس چگونه به کمک رویکردی مقیاس پذیر و تیم محور در توسعه یکباره‌ی محصول توانستند محصولاتی در کلاس جهانی تولید کنند.
در این بخش قصد داریم در مورد Chunk شدن فایل‌ها بدانیم. ولی قبل از هر چیز، نیاز است که ابتدا با اصول اولیه مونگو و حتی بانک‌های nosql آشنا شویم.
رپلیکیشن: اگر در زمینه بانک‌های اطلاعاتی، چه رابطه‌ای و چه nosql فعالیت کرده باشید، میدانید که رپلیکیشن به معنی انتقال و جابجایی داده‌ها، بین سرورهای مختلف در مکانهای مختلف میباشد و این عمل باید ضمانت یکپارپگی و یکسان سازی دیتا را در همه سرورها تضمین کند. اینگونه، بار بین سرورها کاهش پیدا کرده و کاربران راه دور نیازی نیست فاصله زیادی با سرور داشته باشند و میشود از نزدیک‌ترین سرور، داده‌ها را درخواست کنند و از آنجا که بانک‌های nosql در مبحث توزیع پذیری همانند یک قهرمان رفتار میکنند، پس اولین اصطلاحی که باید با آن آشنایی داشته باشید، همین عملیات رپلیکیشن میباشد.
Sharding : یک خوشه شاردینگ(Sharded Cluster) در واقع مجموعه‌ای از همین سرورهای ریپلیکیشن میباشد که ماموریتشان توزیع یکسان بار، بر روی سرورهاست که به ما امکان مدیریت داده‌های حجیم و توسعه و به روزرسانی افقی سرورها (Horizontally Scale) را میدهد.
از این پس میدانیم که ریپلیکیشن‌ها شامل داده‌های یکسانی بوده و شاردینگ‌ها، تقسیم بندی دیتا را صورت میدهند و هر شارد میتواند شامل رپلیکشن‌های متفاوتی باشد.
اصلی‌ترین هدف این خوشه شاردینگ‌ها عبارتند از:
1- مقیاس پذیری: توزیع بار پردازشی بر روی سرورهای مختلف.
2- موازنه سازی لود دیتا: دیتا به طور خودکار در بین شاردهای مختلف توزیع میشود. موازنه‌گر تصمیم میگیرد که چگونه دیتا انتقال داده شده و به چه سروری منتقل شود و از طریق یک کلید به نام Partition Key رنج بندی دیتا را انجام میدهد تا بداند هر شاردی، چه رنج دیتایی را شامل میشود.
رپلیکیشن: اگر در زمینه بانک‌های اطلاعاتی، چه رابطه‌ای و چه nosql فعالیت کرده باشید، میدانید که رپلیکیشن به معنی انتقال و جابجایی داده‌ها، بین سرورهای مختلف در مکانهای مختلف میباشد و این عمل باید ضمانت یکپارپگی و یکسان سازی دیتا را در همه سرورها تضمین کند. اینگونه، بار بین سرورها کاهش پیدا کرده و کاربران راه دور نیازی نیست فاصله زیادی با سرور داشته باشند و میشود از نزدیک‌ترین سرور، داده‌ها را درخواست کنند و از آنجا که بانک‌های nosql در مبحث توزیع پذیری همانند یک قهرمان رفتار میکنند، پس اولین اصطلاحی که باید با آن آشنایی داشته باشید، همین عملیات رپلیکیشن میباشد.
Sharding : یک خوشه شاردینگ(Sharded Cluster) در واقع مجموعه‌ای از همین سرورهای ریپلیکیشن میباشد که ماموریتشان توزیع یکسان بار، بر روی سرورهاست که به ما امکان مدیریت داده‌های حجیم و توسعه و به روزرسانی افقی سرورها (Horizontally Scale) را میدهد.
از این پس میدانیم که ریپلیکیشن‌ها شامل داده‌های یکسانی بوده و شاردینگ‌ها، تقسیم بندی دیتا را صورت میدهند و هر شارد میتواند شامل رپلیکشن‌های متفاوتی باشد.
اصلی‌ترین هدف این خوشه شاردینگ‌ها عبارتند از:
1- مقیاس پذیری: توزیع بار پردازشی بر روی سرورهای مختلف.
2- موازنه سازی لود دیتا: دیتا به طور خودکار در بین شاردهای مختلف توزیع میشود. موازنه‌گر تصمیم میگیرد که چگونه دیتا انتقال داده شده و به چه سروری منتقل شود و از طریق یک کلید به نام Partition Key رنج بندی دیتا را انجام میدهد تا بداند هر شاردی، چه رنج دیتایی را شامل میشود.
تصویر بالا به شما نشان میدهد که کلاینت‌ها ابتدا به مسیریاب‌ها متصل می‌شوند. این مسیریاب‌ها بر اساس فایل‌های پیکربندی که مدیر سیستم آماده کرده است و شامل تنظیمات موازنه گر میباشد، کلاینت‌ها را به شاردینگ‌های‌ها مورد نظر متصل میکنند و بعد از آن هم انتخاب سرور از رپلیکیشن.
عملیات
Chunk یا قطعه سازی فایل‌ها، بر اساس همین تعداد شاردینگ‌های مختلف میباشد
که به صورت انتزاعی یا مفهومی ایجاد شده‌است و شامل دیتای اصلی نمیشود؛
بلکه شامل اطلاعاتی برای هر قطعه از دیتاها میشود که شامل یک کلید به نام
SharedKey میباشد و دو مقدار Min و Max را برای هر رنج دیتا شامل میشود.
بعد از اینکه Chunkهای یک فایل مشخص شد، مونگو برای حفظ موازنه و بالانس شاردینگ‌ها، شروع به تقسیم این چانک‌ها میکند. به عنوان مثال تعدادی چانک، بین این شاردینگ و تعدادی دیگر برای شاردینگ‌های دیگر. جدول زیر نحوه توزیع 4 چانک را نشان میدهد:
| شارد | نهایت مقدار Max | حداقل مقدار Min | شناسه یا Id چانک |
| “shard” : “shard0001” | “max” : { “x” : 8000 } | “min” : { “x” : 7000 } | “_id” : “testdb.presplit-x_7000.0” |
| “shard” : “shard0001” | “max” : { “x” : 9000 } | “min” : { “x” : 8000 } | “_id” : “testdb.presplit-x_8000.0” |
|
“shard” : “shard0002” | “max” : { “x” : 10000 } | “min” : { “x” : 9000 } | “_id” : “testdb.presplit-x_9000.0” |
| “shard” : “shard0002” | “max” : { “x” : 11000 } | “min” : { “x” : 10000 } | “_id” : “testdb.presplit-x_10000.0” |
| تعداد چانک ها | میزان تفاوت |
| کمتر از 20 عدد | 2 |
| 20 تا 79 | 4 |
| از 79 عدد بیشتر | 8 |
برای درک این مسئله، فرض کنید ما 2 عدد شارد داریم و 31 عدد چانک. اگر 17 عدد از چانک‌ها به شارد 1 برسد و 14 تای باقی مانده به شارد شماره 2 برسد، اختلاف این تعداد شاردها سه میباشد که طبق جدول تا 4 عدد جا دارد. پس بالانسی بین شاردها بر قرار است. موقعی که فایلی به مقدار مشخص شده‌ی برای چانک برسد که به طور پیش فرض 64 مگابایت میشود، شروع به چانک گذاری کرده و برای حفظ بالانس و موازنه سازی، این چانک‌ها را بین شاردهای مختلف توزیع میکند و چانک را از سروری که شامل چانک‌های زیاد است، به سروری که شامل چانک‌های کمتر است منتقل میکند.
مقدمه :
زمانیکه هدفمان تولید سامانه‌ی نرم افزاری باشد که تعداد بسیار زیادی از کاربران با آن سرو کار دارند و اتفاقاً این سامانه قرار است عملیات بسیار حساسی (نظیر عملیات بانکی و مالی، مخابراتی و ...) را انجام دهد و عدم سرویس دهی مناسب آن قابل تحمل نبوده و باعث خسارات مالی، نارضایتی و ... گردد می‌بایست از روش‌های خاصی برای توسعه‌ی این گونه سیستم‌ها استفاده نمود. این نرم افزار‌ها برای اینکه بتوانند به تعداد درخواست‌های بسیار زیاد همزمان پاسخگو باشند و سرویس خود را با کیفیت مناسب ارائه دهند، می‌بایست دارای ویژگی‌های خاصی نظیر مقیاس پذیری (scalable) و تحمل پذیری در مقابل خطا (fault tolerance) باشند.
خوب حالا که صورت مسئله مشخص شد، یکی از راه حل‌های موجود را که مدل Actor Based است، بررسی می‌کنیم.
مدل Actor Based یکـی از مـدل هـای اسـتاندارد بـرای توسـعه‌ی نـرم افزارهـایی بـا قابلیـت اطمینـان بسـیار بالا، تحمل پذیر درمقابـل خطـا و پاسـخ دهـی بسـیار سـریع مـی باشـد. در ایـن مـدل، وظـایف نـرم افـزار بـه مجموعــه‌ای از Actor هــا تقســیم (توزیع) گردیـده و هــر یــک از Actor هــا بــه صــورتی کــاملاً ایزولـه، در نــخ(thread) خـاص خودشـان اجـرا شـده و بخشـی از وظـایف سیسـتم را انجـام مـی دهنـد. سـپس بـا اتصـال Actor هـا بـه یکـدیگر، یـک خـط لولـه (Pipeline) تشـکیل شـده و بـا اسـتفاده از مکـانیزم هـای ارسـال و دریافت پیـام، امکـان همکـاری و برقـراری ارتبـاط بـین Actor هـا فـراهم شـده و در نتیجـه وظیفـه‌ی اصـلی و کلی نرم افـزار بـا حرکـت در یـک خـط لولـه و عبـور از Actor هـای مختلـف بـه صـورت مـوازی و همزمـان انجام خواهد شد. با توجه بـه اینکـه هـر یـک از پیـام‌هـای وارده بـه یـک Actor در یـک thread جداگانـه اجـرا مـی‌شـود، امکــان اینکــه در یــک لحظــه چنــدین Thread در یــک Actor در حــال اجــرا باشـنـد و جــود دارد و درنتیجه باید مکانیزم‌هایی وجود داشته باشد کـه تضـمین کنـد پیـام هـای وارد شـده بـه خـط لولـه، بـه ترتیـب معین شده، اجـرا و از خط لوله خارج می‌شوند.
در این مدل هر یک از Actor هـا مـی تواننـد بـه صـورت توزیـع شـده و بـر روی سـروری مجزا اجـرا شـوند. خوشـبختانه فریمـورک هـای متفـاوت و بسـیار قـوی جهـت توسـعه بـه روش Actor Base وجـود دارند؛ بـه عنـوان مثال TPL DataFlow در Net. یکـی از نمونه‌های ساده آن بـوده کـه در سـال 2012 توسط Microsoft معرفـی شـد و Akka هم یک نمونه‌ی بسیار پخته‌تر و در بستر جاوا مطرح میباشد که پیاده سازی دات نتی آن هم با نام Akka.net موجود است. Erlang نیز محصول Ericsson بوده و دنیای خاص خود را دارد.
در این روش وظیفه توسعه دهنده این است که اولاً یک خط لوله از اکتور‌ها را تشکیل داده (کانفیگ) و یک عمل بزرگ را به چندین عمل کوچک‌تر تقسیم نموده و هر کدام را به یک اکتور جهت اجرا ارسال نماید. تصویر نمونه زیر یک خط لوله متشکل از 4 اکتور را نشان میدهد که از طریق ارسال پیام با یکدیگر در ارتباط هستند تا با همکاری یکدیگر عملی را انجام دهند. این ساختار، Pipeline یا خط لوله نامیده میشود.
در قسمت بعدی با جزئیات بیشتر و با نمونه‌های عملی این روش را بررسی می‌کنیم.
Same-Origin Policy یک سازوکار امنیتی در مرورگرها هستش که ارتباط مستندات (Documents) و Scriptها رو از یک Origin با یک Origin دیگه، محدود میکنه و برای اون‌ها قانون وضع میکنه. این سازوکار کمک میکنه که مستندات آلوده ایزوله باشن و از حملات احتمالی جلوگیری بشه. به این صورت که مرورگر اجازه نمیده که یک Origin محتوایی از Origin دیگه‌ای بخونه و یا به اون دسترسی داشته باشه.
- نکات مطلب «چه زمان‌هایی یک برنامه‌ی ASP.NET ری استارت میشود؟» را بررسی کنید.
- همچنین اگر هاست نامبرده تمام سایت‌ها را با یک Application pool مدیریت میکند، کرش یکی از چند ده سایت دیگر میتواند سبب ری‌استارت شدن سایت شما هم بشود؛ چون برنامه‌ها از همه ایزوله نشده‌اند. راه حل آن ایجاد یک Application pool مجزا به ازای هر سایت هست (توسط هاست‌دار).
- همچنین اگر هاست نامبرده تمام سایت‌ها را با یک Application pool مدیریت میکند، کرش یکی از چند ده سایت دیگر میتواند سبب ری‌استارت شدن سایت شما هم بشود؛ چون برنامه‌ها از همه ایزوله نشده‌اند. راه حل آن ایجاد یک Application pool مجزا به ازای هر سایت هست (توسط هاست‌دار).
نه الزاما. نیازهای سخت افزاری آنچنانی ندارد و این موارد روی سیستم‌های حداقل از 7 سال قبل به این طرف موجود هستند (من روی یک ماشین مجازی، با حداقل‌هایی کمتر از موارد عنوان شده توسط مایکروسافت هم نصبش کردم).
We Thank the Stack Overflow Community for Ranking Docker the #1 Most-Used Developer Tool
Docker is deleting Open Source organisations - what you need to know
.NET Core 2.1 container images will be deleted from Docker Hub
Rider 2021.1: Updates to Docker and C# Support, Scaffolding in ASP.NET, and More!
