fa: improve translation
Hadi Sinaee
parent
6738de3f69
commit
4d94f8a5fc
369
README-fa.md
369
README-fa.md
|
|
@ -393,9 +393,9 @@
|
|||
|
||||
## مباحث طراحی سیستم: از اینجا شروع کنید
|
||||
|
||||
> تازه با طراحی سیستم آشنا شدید؟
|
||||
تازه با طراحی سیستم آشنا شدید؟
|
||||
|
||||
در ابتدا لازمه که یک سری اصول اولیه را یادبگیرید که شامل اینن که این اصول چی هستند، چه شکلی استفاده میشن و مزایا و معایبشون چیه
|
||||
در ابتدا لازمه که یک سری اصول اولیه رو یاد بگیرید که شامل این هستن که این اصول چین، چه شکلی استفاده میشن و مزایا و معایبشون چیه
|
||||
|
||||
### قدم ۱ ویدیوهایی درمورد مقیاس پذیری رو ببینید
|
||||
|
||||
|
|
@ -405,9 +405,9 @@
|
|||
* Vertical scaling | مقایس پذیری عمودی
|
||||
* Horizontal scaling | مقایس پذیری افقی
|
||||
* Caching | کش کردن
|
||||
* Load balancing | توزیع بار
|
||||
* Database replication | تکرار پایگاه داده
|
||||
* Database partitioning | قطعه‌سازی پایگاه داده
|
||||
* Load balancing | لودبالانسینگ یا توزیع بار
|
||||
* Database replication | ریپلیکِیشن در پایگاه داده
|
||||
* Database partitioning | پارتیشن کردن در پایگاه داده
|
||||
|
||||
### قدم ۲ مقاله‌های مربوط به مقایس پذیری رو ببینید
|
||||
|
||||
|
|
@ -421,7 +421,7 @@
|
|||
|
||||
### قدم‌های بعدی
|
||||
|
||||
در قدم بعدی، ما به ترید-آف های سطح بالاتری میپردازیم مانند:
|
||||
در قدم بعدی، به ترید-آف های سطح بالاتری میپردازیم مثل:
|
||||
|
||||
* **کارایی** دربرابر **مقایس پذیری**
|
||||
* **تاخیر** دربرابر **بازدهی**
|
||||
|
|
@ -429,18 +429,20 @@
|
|||
|
||||
یادتون باشه که **همه چیز یک ترید-آف هست**
|
||||
|
||||
در ادامه ما به مباحث زیر میپردازیم:
|
||||
در ادامه به مباحث زیر میپردازیم:
|
||||
|
||||
DNS, CDNs, load balancers.
|
||||
|
||||
## کارایی در برابر مقایس پذیری
|
||||
|
||||
یک سرویس رو **مقایس پذیر** میگیم وقتی که متناسب با منابعی که به سیستم اضافه میکنیم **کارایی** اون هم افزایش پیدا بکنه. به طورکلی منظور از افزایش کارایی اینه که تعداد کاربیشتری رو انجام بدیم اما ممکنه که بتونه کارهای باحجم بزرگتر هم بتونه هندل کنه مثل زمانی که مجموعه داده هامون زیاد میشه و رشد میکنه<sup><a href=http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html>1</a></sup>
|
||||
> Scalable: مقایس پذیر , Performance: کارایی
|
||||
|
||||
یک سرویس رو **مقایس پذیر** میگیم وقتی که متناسب با منابعی که به سیستم اضافه میکنیم **کارایی** اون هم افزایش پیدا بکنه. به طورکلی منظور از افزایش کارایی اینه که تعداد کار بیشتری رو انجام بدیم اما ممکنه که کارهای باحجم بزرگتر هم بتونه هندل کنه مثل زمانی که مجموعه داده هامون زیاد میشه و رشد میکنه<sup><a href=http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html>1</a></sup>
|
||||
|
||||
یه روش دیگه برای نگاه به قضیه کارایی و مقایس پذیری به صورت زیر هست:
|
||||
|
||||
* اگر شما مشکل کارایی دارید، سیستم شما برای یک کاربر کند کار میکنه
|
||||
* اگر شما مشکل مقیاس پذیری دارید، سیستم شما برای یک کاربر سریعه ولی برای بار زیاد کند عمل میکنه
|
||||
* اگر شما مشکل مقیاس پذیری دارید، سیستم شما برای یک کاربر سریعه ولی برای بار زیاد، کُند عمل میکنه
|
||||
|
||||
### منابع برای مطالعه بیشتر
|
||||
|
||||
|
|
@ -449,7 +451,11 @@ DNS, CDNs, load balancers.
|
|||
|
||||
## تاخیر در برابر بازدهی
|
||||
|
||||
**تاخیر** زمانی هست که باید *کاری* انجام بشه یا نتیجه‌ای ایجاد بشه. **بازدهی** میزان تعداد همین کارها هست که باید توی یک واحد زمانی انجام بشه.
|
||||
> Latency: تاخیر, Throughput: بازدهی
|
||||
|
||||
**تاخیر** مدت زمانی هست که باید *کاری* انجام بشه یا نتیجه‌ای تولید بشه.
|
||||
|
||||
**بازدهی** میزان تعداد همین کارهای انجام شده یا نتیجه‌های گرفته شده هست که باید توی واحد زمان انجام بشه.
|
||||
|
||||
به طور کلی شما باید برای **بیشترین بازدهی** به همراه **تاخیر قابل قبول** برنامه ریزی کنید.
|
||||
|
||||
|
|
@ -459,6 +465,8 @@ DNS, CDNs, load balancers.
|
|||
|
||||
## دسترس پذیری دربرابر یکپارچگی
|
||||
|
||||
> Availability: دسترس‌پذیری, Consistency: یکپارچگی, Partition Tolerance: تحمل پارتیشن
|
||||
|
||||
### CAP تئوری
|
||||
|
||||
<p align="center">
|
||||
|
|
@ -469,23 +477,23 @@ DNS, CDNs, load balancers.
|
|||
|
||||
در سیستمهای توزیع شده کامپیوتری شما تنها میتونید که ۲ تا از گارانتی‌های زیر رو تضمین کنید:
|
||||
|
||||
* **یکپارچگی** - هر عملیات خواندن نزدیکترین داده‌ای که تازه نوشته شده رو میگیره یا با خطا مواجه میشه
|
||||
* **یکپارچگی** - هر عملیات خواندن، نزدیکترین داده‌ای که تازه نوشته شده رو میگیره یا با خطا مواجه میشه
|
||||
* **دسترس پذیری** - هر درخواست یک پاسخ میگیره، بدون هیچ تضمینی که جدیدترین نسخه از اطلاعات رو بگیره.
|
||||
* **تحمل پارتیشن** - سیستم میتونه به عملیات خودش ادامه علی رغم اینکه به خاطر خطاهای شبکه مجبور به پارتیشن بنده شده باشه
|
||||
|
||||
*شبکه ها قابل اتکا نیستن، بنابریان لازمه که شما تحمل پارتیشن رو پشتیبانی کنید. بنابراین باید بین یکپارچگی و دسترس پذیری یک ترید-آف انجام بدیدی و یکی رو انتخاب کنید*
|
||||
*شبکه ها قابل اتکا و اطمینان نیستن، بنابریان لازمه که شما تحمل پارتیشن رو پشتیبانی کنید و داشته باشید. بنابراین باید بین یکپارچگی و دسترس پذیری یک ترید-آف انجام بدید و یکی رو انتخاب کنید*
|
||||
|
||||
#### CP یکپارچگی و تحمل پارتیشن
|
||||
|
||||
> Atomic: اتمیک, Timeout: تایم-اوت
|
||||
|
||||
انتظار برای گرفتن جواب از یک نود پارتیشن شده ممکنه باعث بشه تا تایم-اوت بگیریم. این مدل یک انتخاب مناسبه اگر سیستم شما نیاز داره که به صورت اتمیک بخونه و بنویسیه.
|
||||
صبر و انتظار برای گرفتن جواب از یک نود پارتیشن شده ممکنه باعث بشه تا تایم-اوت بگیریم.اگر سیستم شما نیاز داره که به صورت اتمیک بخونه و بنویسیه ، این مدل یک انتخاب مناسبه
|
||||
|
||||
#### AP دسترس پذیری و تحمل پارتیشن
|
||||
|
||||
پاسخهایی که دریافت میشه جدیدترین نسخه از داده روی اون نود رو برمیگردونه. نوشتن ممکنه نیاز به زمان داشته باشه تا در کل سیستم اعمال بشه
|
||||
پاسخهایی که دریافت میشه حاوی جدیدترین نسخه از داده است که روی اون نود وجود داره. نوشتن ممکنه نیاز به زمان داشته باشه تا در کل سیستم اعمال بشه
|
||||
|
||||
این مدل انتخاب خوبیه اگر شما نیاز به [یکپارچگی موکول](#یکپارچگی-موکول) نیاز دارید یا زمانی که سیستم نیاز داره که مستقل از خطاهای خارج از خودش به علمکردش ادامه بده
|
||||
این مدل انتخاب خوبیه اگر شما نیاز به [یکپارچگی موکول](#یکپارچگی-موکول) دارید یا سیستم نیاز داره که مستقل از خطاهای خارج از خودش(خطاهای خارجی) به علمکردش ادامه بده
|
||||
|
||||
### منابع برای مطالعه بیشتر
|
||||
|
||||
|
|
@ -495,23 +503,23 @@ DNS, CDNs, load balancers.
|
|||
|
||||
## الگوهای یکپارچگی
|
||||
|
||||
زمانی که تعدادی کپی از داده‌های یکسان داریم، یک سری انتخاب داریم که چطوری کلاینت‌ها رو سینکرون نگه داریم تا همه یک نمای یکسان از داده داشته باشند. با توجه به تعریف یکپارچگی از [تئوری کپ](#CAP-تئوری) - هر عملیات خوندن داده نزدیک ترین نسخه از داده نوشته شده رو میگیره یا خطا میگیره.
|
||||
زمانی که تعدادی کپی از داده‌های یکسان داریم، با مجموعه‌ای از انتخاب‌ها درباره این که چطوری کلاینت‌ها رو سینکرون نگه داریم موجه می‌شیم تا همه یک نمای یکسان از داده داشته باشند. با توجه به تعریف یکپارچگی از [تئوری کپ](#CAP-تئوری) - هر عملیات خوندن، نزدیک ترین نسخه از داده نوشته شده رو می‌گردونه یا خطا میده.
|
||||
|
||||
### یکپارچگی ضعیف
|
||||
|
||||
بعد از این که یک عملیات نوشتن انجام شد، عملیات خوندن ممکنه دیده بشه یا نشه. بهترین روش برای خوندن انتخاب میشه.
|
||||
بعد از این که یک عملیات نوشتن انجام شد، عملیات خوندن ممکنه اونو ببینه یا نبینه. بهترین روش برای خوندن انتخاب میشه.
|
||||
|
||||
این روش در سیستمهای نظیر مِم-کش دیده میشه. یکپارچگی ضعیف در سیستمهای با نیاز بلادرنگ نظیر وویپ، ویدیو چت و بازی‌های بلادرنگ چندنفره کاربرد داره. برای مثال، اگر شما پشت تلفن باشید و چند ثانیه ارتباط قطع بشه و بعد دوباره وصل بشید، اون چیزی که گفته شده رو دیگه از دست دادید.
|
||||
این روش در سیستمهای نظیر مِم-کش-دی دیده میشه. یکپارچگی ضعیف در سیستمهای با نیاز بلادرنگ مثل وویپ، ویدیو چت و بازی‌های بلادرنگ چندنفره کاربرد داره. برای مثال، اگر شما پشت تلفن باشید و چند ثانیه ارتباط قطع بشه و بعد دوباره وصل بشید، اون چیزی که گفته شده رو دیگه از دست دادید.
|
||||
|
||||
### یکپارچگی موکول
|
||||
|
||||
بعد از یک عملیات نوشتن، عملیاتهای خوندن معمولا در میزان چند میلی ثانیه میتونن اونو ببینن. داده به صورت ناهمگام در جاهای دیگه کپی میشه
|
||||
بعد از اینکه یک عملیات نوشتن انجام شد، عملیاتهای خوندن نهایتا(در حد چند میلی ثانیه) اونو میبینن. داده به صورت ناهمگام در جاهای دیگه کپی و تکرار میشه
|
||||
|
||||
این روش در سیستم‌هایی نظیر دی-اِن-اِس و ایمیل دیده میشه. این مدل در سیستمهای با دسترس پذیری بالا به خوبی کار میکنه.
|
||||
این روش در سیستم‌هایی نظیر دی-اِن-اِس و ایمیل دیده میشه. در سیستمهای با دسترس پذیری بالا به خوبی کار میکنه.
|
||||
|
||||
### یکپارچگی قوی
|
||||
|
||||
بعد از عملیات نوشتن، عملیاتهای خوندن اونو میبینن. داده به صورت همگام کپی میشود.
|
||||
بعد از اینکه عملیات نوشتن انجام شد، عملیاتهای خوندن اونو میبینن. داده به صورت همگام کپی و تکرار میشه.
|
||||
|
||||
این روش معمولا در فایل سیستم‌ها و مدیریت پایگاه داده‌رابطه‌ای دیده میشه. در سیستم‌هایی که نیاز به تراکنش دارند این مدل به خوبی عمل میکنه.
|
||||
|
||||
|
|
@ -531,33 +539,33 @@ DNS, CDNs, load balancers.
|
|||
|
||||
#### Active-passive
|
||||
|
||||
در این مدل، هارت-بیت بین سرور فعال و غیر فعال که درحالت آماده باشه رد و بدل میشه. اگر هارت-بیت قطع بشه سرور غیرفعال آی-پی سرور فعال رو دراختیار میگیره و درخواستها رو هندل میکنه.
|
||||
در این مدل، هارت-بیت بین سرور فعال و سرور غیر فعال که درحالت آماده باشه، رد و بدل میشه. اگر هارت-بیت قطع بشه سرور غیرفعال آی-پی سرور فعال رو دراختیار میگیره و درخواستها رو هندل میکنه.
|
||||
|
||||
طول زمان پایین بودن به ۲ صورت مشخص میشه. سرور غیر فعال از به صورت هات لود میشه یا زا شرایط لود سرد اصطلاحا فعال میشه. فقط سرور فعال ترافیک رو هندل میکنه.
|
||||
طول زمان پایین بودن به دو نوع معین میشه، یا اینکه سرور غیر فعال در حالت به اصطلاح هات در انتظاره یا نیاز داره از حالت به اصطلاح سرد شروع به کار کنه. فقط سرور فعال ترافیک رو هندل میکنه.
|
||||
|
||||
این مدل رو مستر-اِسلِیو هم میگن
|
||||
|
||||
#### Active-active
|
||||
|
||||
در این حالت هر دو سرور ترافیک رو هندل میکنه و بار بین این دو تقسیم میشه.
|
||||
در این حالت هر دو سرور ترافیک رو هندل میکنن و بار بین این دو تقسیم میشه.
|
||||
|
||||
اگر سرورها به صورت عمومی روی اینترنت باشن، دی-اِن-اِس باید آی-پی هر دو سرور رو بدونه. اگر سرورها در شبکه داخلی باشن، لایه برنامه باید از حضور این دو سرور آگاهی داشه باشه.
|
||||
اگر سرورها به صورت عمومی روی اینترنت قابل دسترسی باشن، دی-اِن-اِس باید آی-پی هر دو سرور رو بدونه. اگر سرورها در شبکه داخلی باشن، لایه برنامه باید از حضور این دو سرور آگاهی داشه باشه.
|
||||
|
||||
این مدل به عنوان مستر-مستر هم شناخته میشه.
|
||||
|
||||
### معایب این الگو
|
||||
### معایب Fail-over
|
||||
|
||||
* این الگو نیاز به سخت افزار بیشتر هست و پیچیدگی رو هم افزایش میده
|
||||
* اگر یک سیستم فعال فِیل بشه قبل از این که داده جدید نوشته بتونه کپی بشه توی سرور غیرفعال، امکان از دست رفتن داده هست.
|
||||
* این الگو نیاز به سخت افزار بیشتری داره و پیچیدگی رو هم افزایش میده
|
||||
* اگر یک سیستم فعال فِیل بشه و فرصت نشه تا داده جدیدی که تازه نوشته شده، بتونه کپی بشه توی سرور غیرفعال، امکان از دست رفتن داده هست.
|
||||
|
||||
### تکرارکردن
|
||||
### Replication
|
||||
|
||||
#### مستر-اسلیو و مستر-مستر
|
||||
#### Master-Slave و Master-Master
|
||||
|
||||
این موضوع در بخش [پایگاه داده](#پایگاه‌داده) بررسی شده
|
||||
این موضوع در بخش [پایگاه داده](#پایگاه-داده) بررسی شده
|
||||
|
||||
* [تکرارکردن مستر-اسلیو](#تکرار-مستر-اسلیو)
|
||||
* [تکرارکردن-مستر-مستر](#تکرارکردن-مستر-مستر)
|
||||
* [تکرارکردن مستر-اسلیو](#master-slave-replication)
|
||||
* [تکرارکردن-مستر-مستر](#master-master-replication)
|
||||
|
||||
## سیستم نام دامنه DNS
|
||||
|
||||
|
|
@ -569,11 +577,11 @@ DNS, CDNs, load balancers.
|
|||
<i><a href=http://www.slideshare.net/srikrupa5/dns-security-presentation-issa>Source: DNS security presentation</a></i>
|
||||
</p>
|
||||
|
||||
سیستم نام دامنه یا همان دی-اِن-اِس نام یک یک دامنه را به آی-پی آن ترجمه میکند.
|
||||
سیستم نام دامنه یا همان دی-اِن-اِس، نام یک دامنه را به آی-پی آن ترجمه میکند.
|
||||
|
||||
www.example.com -> IP address.
|
||||
|
||||
دی-اِن-اِس به صورت سلسله مراتبی هست و تعداد کمی سرور اصلی در لایه‌های بالا وجود داره. روتر یا آی-اِس-پی شما اطلاعات مربوط به دی-ان-اس هایی که برای جستجو استفاده میشن رو در اختیار شما میزارن. دی-ان-اس های لایه پایین‌تر معمولا این نگاشت بین نام دامنه و آی-پی رو کش میکنن که ممکنه بعد از مدتی اعتبار این نگاشت‌ها از بین بره به خاطر این که انتشار تغییرات در دی-ان-اس کنده. نتایجی که از دی-ان-اس برای شما میاد ممکنه که در مرورگر یا سیستم عامل کش برای مدت مشخصی کش بشه، به این مدت مشخص تایم-تو-لیو گفته میشه
|
||||
دی-اِن-اِس به صورت سلسله مراتبی هست و تعداد کمی سرور اصلی در لایه‌های بالا وجود داره. روتر یا آی-اِس-پی شما اطلاعات مربوط به دی-ان-اس هایی که برای جستجو استفاده میشن رو در اختیار شما میزارن. دی-ان-اس های لایه پایین‌تر معمولا این نگاشت بین نام دامنه و آی-پی رو کش میکنن به خاطر این که انتشار تغییرات در دی-ان-اس کنده، که ممکنه بعد از مدتی اعتبار این نگاشت‌ها از بین بره . نتایجی که از دی-ان-اس برای شما میاد ممکنه که در مرورگر یا سیستم عامل برای مدت مشخصی کش بشه، به این مدت مشخص تایم-تو-لیو گفته میشه
|
||||
|
||||
> [time to live (TTL)](https://en.wikipedia.org/wiki/Time_to_live) : تایم-تو-لیو
|
||||
|
||||
|
|
@ -587,11 +595,11 @@ www.example.com -> IP address.
|
|||
|
||||
* > example.com -> www.example.com
|
||||
|
||||
سرویسهای نظیر سرویس های زیر سرویسهای دی-ان-اس مدیریت شده رو ارائه میکنن
|
||||
سرویسهای نظیر سرویس های زیر سرویس دی-ان-اس مدیریت شده رو ارائه میکنن
|
||||
|
||||
[CloudFlare](https://www.cloudflare.com/dns/) و [Route 53](https://aws.amazon.com/route53/)
|
||||
|
||||
بعضی از سرویسهای دی-ان-اس میتونن ترافیک رو از راه‌های مختلفی ارسال کنند:
|
||||
بعضی از سرویسهای دی-ان-اس میتونن ترافیک رو با روش‌های مختلفی، مثل روش‌های زیر، ارسال کنند:
|
||||
|
||||
* [Weighted round robin](http://g33kinfo.com/info/archives/2657)
|
||||
* از ارسال ترافیک به سرورهایی که در حال نگهداری هستند خودداری میکنه
|
||||
|
|
@ -600,7 +608,7 @@ www.example.com -> IP address.
|
|||
* Latency-based |براساس تاخیر
|
||||
* Geolocation-based | براساس موقعیت جغرافیایی
|
||||
|
||||
### معایب دی-ان-اس
|
||||
### معایب: دی-ان-اس
|
||||
|
||||
* دسترسی به سرور دی-ان-اس یک تاخیری رو موجب میشه که با استفاده از کشینگ گفته شده برطرف میشه.
|
||||
|
||||
|
|
@ -608,7 +616,7 @@ www.example.com -> IP address.
|
|||
|
||||
* > [governments, ISPs, and large companies](http://superuser.com/questions/472695/who-controls-the-dns-servers/472729).
|
||||
|
||||
* سرویس دی-ان-اس اخیرا مورد حمله دی-داس قرارگرفته و باعث شده تا کاربران نتونن به وب سایتها دسترسی پیدا کنن، وب سایت‌هایی نظیر توییتر - از طریق اینکه آی-پی توییتر رو نمیتونستن پیدا کنن
|
||||
* سرویس دی-ان-اس اخیرا مورد حمله دی-داس قرارگرفته و باعث شده تا دسترسی کاربران به وب سایتها قطع بشه، وب سایت‌هایی نظیر توییتر - به اینصورت که کاربرا آی-پی توییتر رو نمیتونستن پیدا کنن
|
||||
|
||||
* > [DDoS attack](http://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/)
|
||||
|
||||
|
|
@ -628,34 +636,36 @@ www.example.com -> IP address.
|
|||
<i><a href=https://www.creative-artworks.eu/why-use-a-content-delivery-network-cdn/>Source: Why use a CDN</a></i>
|
||||
</p>
|
||||
|
||||
یک شبکه توزیع محتوا یا سی-دی-ان یک شبکه توزیع شده از پروکسی سرورهاست که محتوا را از مکان‌هایی که به کاربر نزدیکتره به دستش میرسونه. به طور کلی فایل‌های ایستا مثل اچ-تی-ام-ال، جاوااسکریپت و سی-اس-اس، عکس، ویدیو از طریق سی-دی-ان به کاربر داده میشه. با این حال سی-دی-ان هایی نظیر کلود-فرانت که برای شرکت آمازون است محتوای غیر ایستا یا داینامیک رو هم پشتیبانی میکنه. عملیات گرفتن دی-ای-اس سایت میگه به کاربر که باید به کدوم سرور متصل بشه.
|
||||
> HTML: اِچ-تی-اِم-اِل, CSS: سی-اِس-اِس , Javascript: جاوااسکریپت
|
||||
|
||||
انتشار محتوا از طریق سی-دی-ان ها میتونه باعث افزایش کارایی چشمگیری بشه. این افزایش به خاطر ۲ علت زیر هست:
|
||||
یک شبکه توزیع محتوا یا سی-دی-ان یک شبکه توزیع شده از پروکسی سرورهاست که محتوا را از مکان‌هایی که به کاربر نزدیکتره به دستشون میرسونه. به طور کلی فایل‌های ایستا مثل اِچ-تی-اِم-اِل، جاوااسکریپت و سی-اِس-اِس، عکس، ویدیو از طریق سی-دی-ان به کاربر داده میشه. با این حال سی-دی-ان هایی نظیر کلود-فرانت که برای شرکت آمازون است محتوای غیر ایستا یا داینامیک رو هم پشتیبانی میکنه. عملیات سوال از دی-ان-اس برای یه سایت به کاربر میگه که باید به کدوم سرور متصل بشه.
|
||||
|
||||
* کاربران محتوا را از مرکزداده‌ای که بهشون نزدیکه میگیرن.
|
||||
* سرورهای شما احتیاجی نیست که به درخواستی پاسخ بدن که سی-دی-ان میتونه پاسخ بده
|
||||
انتشار محتوا از طریق سی-دی-ان ها میتونه باعث افزایش کارایی چشمگیری بشه. این افزایش به خاطر ۲ علت زیره:
|
||||
|
||||
* کاربران محتوا را از دیتاسنتری که بهشون نزدیکه میگیرن.
|
||||
* سرورهای شما احتیاجی نیست که به درخواستی پاسخ بدن که سی-دی-اِن میتونه پاسخ بده
|
||||
|
||||
### Push CDNs
|
||||
|
||||
پوش سی-دی-ان زمانی که سرورشما تغییر روی محتوا داشته باشه، تغییرات رو میگیره. در این حالت شما مسوول تهیه محتوا برای سی-دی-ان هستید، باید محتوا رو آپلود مستقیم اپلود کنید روی سی-دی-ان و یو-آر-ال ها رو دوباره نویسی کنید که به سی-دی-ان اشاره کنه. شما میتونید تظیم کنید که چه زمانی محتوایی که گذاشتید مدت استفادش از بین بره و چه زمانی آپدیت بشه. محتوا زمانی آپلود میشه که یا جدید باشه یا تغییر پیدا کرده باشه که باعث کاهش ترافیک میشه ولی افزایش میزان حافظه هم هست.
|
||||
پوش سی-دی-ان زمانی که سرورشما تغییری روی محتوا داشته باشه، تغییرات رو میگیره. در این حالت، شما مسوول آماده کردن محتوا برای سی-دی-ان هستید، باید محتوا رو مستقیم آپلود کنید روی سی-دی-اِن و یو-آر-اِل ها رو دوباره نویسی کنید که به سی-دی-ان اشاره کنه. میتونید تنظیم کنید که چه زمانی محتوایی که گذاشتید مدت استفادش از بین بره و چه زمانی آپدیت بشه. محتوا زمانی آپلود میشه که یا جدید باشه یا تغییر پیدا کرده باشه. اینکار باعث کاهش ترافیک میشه ولی افزایش میزان حافظه هم داره.
|
||||
|
||||
سایت‌هایی که ترافیک کمی دارند یا محتوایی دارند که آپدیت نمیشن اغلب اوقات با این مدل پوش سی-دی-ان به خوبی کار میکنن. محتواها یکبار در سی-دی-ان گذاشته میشن به جای اینکه طی یه بازه‌ی مشخصی همینطوری از سرور آورده بشن توی سی-دی-ان
|
||||
سایت‌هایی که ترافیک کمی دارند یا محتوایی دارند که آپدیت نمیشه اغلب اوقات با این مدل پوش سی-دی-ان به خوبی کار میکنن. به جای اینکه طی یه بازه‌ی مشخصی همینطور از سرور محتوا آورده بشه توی سی-دی-اِن، محتوا یکبار در سی-دی-ان گذاشته میشه
|
||||
|
||||
### Pull CDNs
|
||||
|
||||
پول سی-دی-ان محتوای جدید رو از سرور شما میگیره وقتیکه کاربر اول درخواست برای اون محتوا رو میده. شما محتوا رو میزارید روی سرورتون و یو-آر-ال ها روی سی-دی-ان میزارید. این کار باعث میشه که درخواستها کندتر بشن البته تا وقتی که محتوا روی سی-دی-ان کش بشه.
|
||||
وقتیکه کاربر اولین درخواست برای یک محتوای جدید رو میده، پول سی-دی-ان اون محتوا جدید رو از سرور شما میگیره . شما محتوا رو روی سرورتون میزارید و یو-آر-ال هاش روی سی-دی-ان تنظیم می‌کنید. تا وقتی که محتوا روی سی-دی-ان کش بشه، این کار باعث میشه درخواستها کندتر بشن .
|
||||
|
||||
یک تایم-تو-لیو برای اینکه چه مدت زمانی محتوا باید کش بشه رو مشخص میکنه. پول سی-دی-ان میزان استورج رو کم میکنه روی سی-دی-ان اما میتونه ترافیک اضافی هم ایجاد کنه اگر فایل‌ها قبل از این که به سی-دی-ان بیان کش اونها منتقضی بشه.
|
||||
یک تایم-تو-لیو مدت زمانی که محتوا باید کش بشه رو مشخص میکنه. پول سی-دی-اِن میزان استورج روی سی-دی-اِن رو کم میکنه اما میتونه ترافیک اضافی هم ایجاد کنه اگر فایل‌ها قبل از این که به سی-دی-اِن بیان مدت کش اونها منتقضی بشه.
|
||||
|
||||
> [time-to-live (TTL)](https://en.wikipedia.org/wiki/Time_to_live): تایم-تو-لیو
|
||||
|
||||
سایتهای با ترافیک سنگین خیلی خوب بای این مدل پول سی-دی-ان کار میکنن چون که با آخرین درخواست برای محتوای تازه خواسته شده روی سی-دی-ان مواجه میشه، ترافیک به صورت یکسان پخش میشه.
|
||||
سایتهای با ترافیک سنگین خیلی خوب با این مدل پول سی-دی-ان کار میکنن چون که با آخرین درخواست برای محتوای تازه درخواست شده روی سی-دی-اِن مواجه میشه، ترافیک به صورت یکسان پخش میشه.
|
||||
|
||||
### معایب سی-دی-ان
|
||||
### معایب: CDN
|
||||
|
||||
* هزینه ها خیلی وابسته به ترافیکه که وجود داره با این حال این رو هم مد نظر بگیرید که این هزینه ها رو درکنار هزینه‌های استفاده نکردن از سی-دی-ان ببینید.
|
||||
* محتوا ممکنه قبل از این که تایم-تو-لیو اون تموم بشه منقضی بشه
|
||||
* سی-دی-ان ها باید برای اینکه محتوای ایستا به سی-دی-ان اشاره کنن یو-آر-ال هاش رو تغییر بده.
|
||||
* هزینه‌ها خیلی وابسته به ترافیکیه که وجود داره با این حال این این هزینه ها رو درکنار هزینه‌های استفاده نکردن از سی-دی-ان درکنار هم ببینید.
|
||||
* محتوا ممکنه قبل از این که تایم-تو-لیو اون تموم بشه، منقضی بشه
|
||||
* برای محتوای ایستا یو-آر-ال ها باید تغییر کنه و به سی-دی-اِن اشاره کنه.
|
||||
|
||||
### منابع برای مطالعه بیشتر
|
||||
|
||||
|
|
@ -671,13 +681,13 @@ www.example.com -> IP address.
|
|||
<i><a href=http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html>Source: Scalable system design patterns</a></i>
|
||||
</p>
|
||||
|
||||
لودبالانسرها درخواست هایی که از سمت کاربران میاد رو بین منابع محاسبانی که هست مثل اپلیکیشن سرورها یا پایکاه دهده‌ها توزیع میکنه. در هر کدوم از این حالات لودبالانسر پاسخ درخواست رو از اون منبع محاسباتی به کاربر برمیگردونه. لودبالانسر ها در مورد زیر موثر هستند:
|
||||
لودبالانسرها درخواست هایی که از سمت کاربران میاد رو بین منابع محاسباتی که هست مثل اپلیکیشن سرورها یا پایگاه داده‌ها توزیع میکنه. در هر کدوم از این حالات، لودبالانسر پاسخ درخواست رو از اون منبع محاسباتی به کاربر برمیگردونه. لودبالانسر ها در مورد زیر موثر هستند:
|
||||
|
||||
* از رفتن درخواست ها به سرورهایی که سالم نیستن جلوگیری میکنه
|
||||
|
||||
* از زیربار رفتن بیش از اندازه منابع جلوگیری میکنه
|
||||
|
||||
* کمک میکنه که سیستم از شکست نقطه‌ای رنجنبرهHelping eliminate single points of failure
|
||||
* کمک میکنه که سیستم از شکست نقطه‌ای آسیب پذیره نباشه
|
||||
|
||||
* > Single Point of Failure: شکست نقطه‌ای
|
||||
|
||||
|
|
@ -685,15 +695,15 @@ www.example.com -> IP address.
|
|||
|
||||
> HAProxy
|
||||
|
||||
مزایای دیگه هم داره به طور مثال:
|
||||
مزایای دیگه هم داره، به طور مثال:
|
||||
|
||||
* **SSL termination** - درخواست هایی که از سمت کاربر میاد را رمزگشایی میکنه و جوابهایی که باید سرور بده رو هم رمزنگاری میکنه بنابراین سرورهای لازم نیست تا این عملیاتهای سنگین محاسباتی رو انجام بدن
|
||||
* **SSL termination** - درخواست هایی که از سمت کاربر میاد را رمزگشایی میکنه و جوابهایی که باید سرور بده رو هم رمزنگاری میکنه بنابراین سرورها لازم نیست تا این عملیاتهای سنگین محاسباتی رو انجام بدن
|
||||
* از نصب گواهی‌های ایکس.۵۰۶ روی هر سرور جلوگیری میکنه
|
||||
|
||||
* > [X.509 certificates](https://en.wikipedia.org/wiki/X.509)
|
||||
* **Session persistence** - کوکی ست میکنه و ترافیک مربوط به درخواست یک کاربر رو به یک سرور یکسان میده هر بار اگر وب اپ سِشِ نگه نداره
|
||||
* **Session persistence** - اگر برنامه وب سِشِن نگه نداره، کوکی سِت میکنه و هربار ترافیک مربوط به درخواست یک کاربر رو به یک سرور یکسان میده
|
||||
|
||||
برای جلوگیری از شکست سیستم، یک کاری که مرسومه اینه که چندتا لودبالانسر تنظیم میشه که بد دو مود زیر میتونه باشه
|
||||
برای جلوگیری از فِیل سیستم، یک کاری که مرسومه اینه که چندتا لودبالانسر تنظیم میشه که با دو مود زیر میتونه باشه
|
||||
|
||||
> [active-passive](#active-passive) , [active-active](#active-active) .
|
||||
|
||||
|
|
@ -702,24 +712,28 @@ www.example.com -> IP address.
|
|||
* Random
|
||||
* Least loaded
|
||||
* Session/cookies
|
||||
* [Round robin or weighted round robin](http://g33kinfo.com/info/archives/2657)
|
||||
* [Layer 4](#layer-4-load-balancing)
|
||||
* [Layer 7](#layer-7-load-balancing)
|
||||
* [Round robin یا weighted round robin](http://g33kinfo.com/info/archives/2657)
|
||||
* [لایه ۴](#توزیع-بار-لایه-۴)
|
||||
* [لایه ۷](#توزیع-بار-لایه-۷)
|
||||
|
||||
### توزیع بار لایه ۴
|
||||
|
||||
> Packet: پکت
|
||||
|
||||
لودبالانسرهای لایه ۴ به اطلاعاتی که در لایه‌ی ترسنپورت است نگاه میکنند و تصمیم میگیردن که چهطوری درخواستها رو توزیع کنند. به طورکلی یعنی نگاه به اطلاعتی نظیر مبدا درخواست، آی-پی مقصد و پورت هایی که در هدر وجود دارد اما به محتوای پکتی که ارسال میشود نگاهی نمیشود این نوع لودبالانسرها پکت‌های شبکه را به سرورهای بالادستی ارسال و یا از پکت‌های شبکه را دریافت میکنن که به صورت عملیات ترجمه آدرس شبکه انجام میشه.
|
||||
لودبالانسرهای لایه ۴ به اطلاعاتی که در لایه‌ی ترسنپورت است نگاه میکنند و تصمیم میگیرن که چهطوری درخواستها رو پخش کنند. به طورکلی یعنی نگاه به اطلاعاتی نظیر مبدا درخواست، آی-پی مقصد و پورت هایی که در هدر وجود دارد، اما به محتوای پکتی که ارسال میشود نگاهی نمیشود. این نوع لودبالانسرها پکت‌های شبکه را به سرورهای بالادستی ارسال و یا از آنها دریافت میکنن که به این صورت عملیات ترجمه آدرس شبکه انجام میشه.
|
||||
|
||||
> [transport layer](#communication): لایه ترنسپورت
|
||||
> [transport layer](#ارتباط): لایه ترنسپورت
|
||||
> [Network Address Translation (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/): ترجمه آدرس شبکه
|
||||
|
||||
### توزیع بار لایه ۷
|
||||
|
||||
لودبالانسرهای لایه ۷ به لایه‌ی برنامه نگاه میکنند و تصمیم میگیرند که چهطوری درخواست ها رو توزیع کنند. این کار میتونی با استفاده از داده هایی که در هدر، محتوای پیام و کوکی‌هاست صورت بپذیره. این لودبالانسرها ترافیک شبکه رو تموم میکنه، پیام رو میخونه و یک تصمیم برای توزیع بار میگیره و بعدش یک کانکشن به سروری که حاصل تصمیمش هست ایجاد میکنه. برای مثال، یه لود بالانسر لایه ۷ میتونه ترافیک‌های مربوط به ویدیو رو به یک سرور بفرسته درحالیکه ترافیک‌های مربوط به قبض‌های پرداختی میشه رو به یک سرور دیگه ای که از نظر امنیتی قوی تر هست بفرسته.
|
||||
> Upstream: بالادستی
|
||||
|
||||
با احتساب هزینه‌ای که بابت انعطاف پذیری در نظر بگیریم، لودبالانسینگ لایه ۴ نیاز به منابع و زمان کمتری داره نسبت به لایه ۷ با این حال کاراییش روی سیستمهای مدرن معمولی میتونه کم اثر باشه.
|
||||
لودبالانسرها میتونن کمکی باشن برای اسکیل کردن افقی و باعث افزایش کارایی و دسترس پذیری بشن. اسکیل کردن
|
||||
|
||||
لودبالانسرهای لایه ،۷ به لایه‌ی برنامه نگاه میکنند و تصمیم میگیرند که چهطوری درخواست ها رو پخش کنند. این کار میتونه با استفاده از داده هایی که در هدر، محتوای پیام و کوکی‌هاست صورت بپذیره. این لودبالانسرها ترافیک شبکه رو تموم میکنه یعنی تا تهش میگیره، پیام رو میخونه و یک تصمیم برای توزیع بار میگیره و بعدش یک کانکشن به سروری که حاصل تصمیمش هست ایجاد میکنه. برای مثال، یه لود بالانسر لایه ۷ میتونه ترافیک‌های مربوط به ویدیو رو به یک سرور بفرسته درحالیکه ترافیک‌هایی که مربوط به قبض‌های پرداختی میشه رو به یک سرور دیگه ای که از نظر امنیتی قوی تر هست بفرسته.
|
||||
|
||||
با احتساب هزینه‌ای که بابت انعطاف پذیری، لودبالانسینگ لایه ۴ نیاز به منابع و زمان کمتری داره نسبت به لایه ۷ ، با این حال کاراییش روی سیستمهای مدرن معمولی میتونه کم اثر باشه.
|
||||
|
||||
### مقایس پذیری افقی
|
||||
|
||||
|
|
@ -727,7 +741,7 @@ www.example.com -> IP address.
|
|||
|
||||
لودبالانسرها میتونن کمکی باشن برای اسکیل کردن افقی و باعث افزایش کارایی و دسترس پذیری بشن. اسکیل کردن با استفاده از سیستمهای عادی تر(تعداد ماشین‌ها رو زیاد کنیم) خیلی از نظر هزینه به صرفه تره و باعث میشه تا دسترس پذیری بیشتری داشته باشیم تا این که بیایم یک سرور رو از نظر سخت افزاری ارتقا بدیم که معمولا گرون میشه، که بهش میگن **مقیاس کردن عمودی**. همینطور کار با یک سیستم عادی خیلی آسونتره واسه آدما تا اینکه بخوان با سیستمهای تخصصی شده برای کارای سطح کلان کار کنن.
|
||||
|
||||
#### معایب مقایس پذیری افقی
|
||||
#### معایب: مقایس پذیری افقی
|
||||
|
||||
* مقیاس پذیری افقی باعث پیچیدگی میشه و باید سرورهای کلون شده ایجاد کنید.
|
||||
|
||||
|
|
@ -735,12 +749,12 @@ www.example.com -> IP address.
|
|||
|
||||
* سشن‌ها میتونن توی یک مرکز ذخیره سازی داده مرکزی ذخیره بشن مثلا پایگاه داده یا یک کش با قابلیت نگهدارندگی دائمی
|
||||
|
||||
* > [پایگاه‌داده](#پایگاه‌داده) (SQL, NoSQL)
|
||||
> [کش](#کش) (Redis, Memcached)
|
||||
* > [پایگاه‌داده](#پایگاه-داده) (SQL, NoSQL)
|
||||
> [کش](#cache) (Redis, Memcached)
|
||||
|
||||
* سرورهایی که معمولا ترافیک دانلودشوندگی دارند مثلا کشها یا پایگاه‌داده‌ها نیازدارند که تعداد کانکشن‌های همزمان بیشتری رو نسب به سرورهای بالادستی هندل کنن
|
||||
|
||||
### معایب لود بالانسر
|
||||
### معایب: لود بالانسر
|
||||
|
||||
* لودبالانسر میتونه گلوگاه مشکل کارایی باشه اگر منابع لازم به اندازه کافی نداشته باشه یا اگر اینکه به درستی تنظیم نشده باشه
|
||||
* با استفاده از لودبالانسر مشکل شکست نقطه‌ای از بین میره ولی میزان پیچیدگی رو زیاد میکنه
|
||||
|
|
@ -765,7 +779,7 @@ www.example.com -> IP address.
|
|||
<br/>
|
||||
</p>
|
||||
|
||||
یک پروکسی معکوس یک وب سروی هست که سرویس‌ها داخلی رو تجمیع میکنه و باعث میشه که از بیرون به یک واسط یکارچه دسترسی داشته باشید. درخواستها از کلاینت‌ها فوروارد میشن به سروری که میتونه درخواست رو جواب بده قبل از اینکه پروکسی معکوس جواب رو به کاربر برگردونه.
|
||||
یک پروکسی معکوس، یک وب سروی هست که سرویس‌ها داخلی رو تجمیع میکنه و باعث میشه که از بیرون به یک واسط یکارچه دسترسی داشته باشید. درخواستها از کلاینت‌ها فوروارد میشن به سروری که میتونه درخواست رو جواب بده قبل از اینکه پروکسی معکوس جواب رو به کاربر برگردونه.
|
||||
|
||||
مزایای بیشترش شامل موارد زیر میشه:
|
||||
|
||||
|
|
@ -787,13 +801,13 @@ www.example.com -> IP address.
|
|||
|
||||
* اگر تعداد سرور زیادی دارید استفاده از لودبالانسر بهتره. معمولا لودبالانسر ترافیک رو بین سرورهایی که یک کار مشابه انجام میدن توزیع میکنه.
|
||||
|
||||
* پروکسی معکوس‌ها هم حتی زمانی که شما یه دونه وب سرور یا اپلیکیشن سرور دارید مفید باشن. مزایی که قبلا اشاره شد رو برای شما فراهم میکنن.
|
||||
* پروکسی معکوس‌ها، حتی زمانی که شما یه دونه وب سرور یا اپلیکیشن سرور دارید میتونن مفید باشن. مزایی که قبلا اشاره شد رو برای شما فراهم میکنن.
|
||||
|
||||
* برنامه‌های زیر هر دو میتونن که لودبالانسینگ انجام بدن و هم پروکسی معکوس لایه ۷
|
||||
* برنامه‌های زیر هر دو میتونن که لودبالانسینگ و پروکسی معکوس لایه ۷ انجام بدن
|
||||
|
||||
* > NGINX و HAProxy
|
||||
|
||||
### معایب پروکسی معکوس
|
||||
### معایب: پروکسی معکوس
|
||||
|
||||
* باعث افزایش پیچیدگی میشه
|
||||
* یک دونه پروکسی معکوس میتونه یه شکست نقطه‌ای باشه و با تنظیم کردن چندتا از این پروکسی سرورها(به عنوان مثال به صورت [فِیل-اُوِر](https://en.wikipedia.org/wiki/Failover)) باعث افزایش پیچیدگی میشه.
|
||||
|
|
@ -817,9 +831,9 @@ www.example.com -> IP address.
|
|||
|
||||
جداسازی لایه وب از لایه برنامه(که بعضا به عنوان لایه پلتفرم هم شناخته میشه) به شما این امکان رو میده که هر دو لایه رو مستقل از هم دیگه اسکیل کنید. اضافه کردن یک اِی-پی-آی جدید به لایه‌ی برنامه مستقل از اینکه به وب سرور بخواید چیزی اضافه کنید انجام میشه.
|
||||
|
||||
**اصل تک مسولیتی** به دنبال این هست که سرویسهای کوچک و خودمختاری رو داشته باشکه بتونن باهم کار کنن. تیم‌های کوچیک با سرویسهای کوچیک میتونن خیلی سریع‌تر و قوی‌تر برای رشد برنامه ریزی کنند.
|
||||
**اصل تک مسولیتی** به دنبال این هست که سرویسهای کوچک و خودمختاری رو داشته باشه که بتونن باهم کار کنن. تیم‌های کوچیک با سرویسهای کوچیک میتونن خیلی سریع‌تر و قوی‌تر برای رشد برنامه ریزی کنند.
|
||||
|
||||
وُرکرهایی که در لایه برنامه هستند باعث میشن تا قابلیت [ناهمگامی](#ناهمگامی) رو بتونیم داشته باشیم.
|
||||
وُرکرهایی که در لایه برنامه هستند باعث میشن تا قابلیت [ناهمگامی](#asynchronism) رو بتونیم داشته باشیم.
|
||||
|
||||
### میکروسرویس ها
|
||||
|
||||
|
|
@ -831,7 +845,7 @@ www.example.com -> IP address.
|
|||
|
||||
### کشف سرویس
|
||||
|
||||
سیستم هایی نظیر کنسول، ای-تی-سی-دی و زووکیپر به وسیله‌ی نگهداشتن اطلاعات در مورد اسم‌ها و آدرس‌ها و پورت‌های سرویس‌ها کمک کنن تا سرویس‌ها بتونن همدیگه رو پیدا کنند.
|
||||
سیستم هایی نظیر کنسول، ای-تی-سی-دی و زووکیپر با نگهداشتن اطلاعات در مورد اسم‌ها و آدرس‌ها و پورت‌های سرویس‌ها کمک کنن تا سرویس‌ها بتونن همدیگه رو پیدا کنند.
|
||||
|
||||
> [Consul](https://www.consul.io/docs/index.html): کنسول, [Etcd](https://coreos.com/etcd/docs/latest): ای-تی-سی-دی, [Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper): زوو-کیپر
|
||||
|
||||
|
|
@ -839,13 +853,13 @@ www.example.com -> IP address.
|
|||
|
||||
> [Health checks](https://www.consul.io/intro/getting-started/checks.html): چک-سلامت [HTTP](#hypertext-transfer-protocol-http) endpoint: اِند-پوینت اچ-تی-تی-پی
|
||||
|
||||
هر دو سرویس کنسول و ای-تی-سی-دی یک ذخیره کلید-مقدار در درون خودشون دارند که برای مواردی مثل ذخیره کردن کانفیگ ها و یا داده‌هایی که باید به اشتراک باشن میتونه مفید باشه.
|
||||
هر دو سرویس کنسول و ای-تی-سی-دی یک ذخیره‌ساز کلید-مقدار در درون خودشون دارند که برای مواردی مثل ذخیره کردن کانفیگ ها و یا داده‌هایی که باید به اشتراک باشن، میتونه مفید باشه.
|
||||
|
||||
> [key-value store](#key-value-store): ذخیره کلید-مقدار
|
||||
|
||||
### مقایب لایه برنامه
|
||||
### معایب: لایه برنامه
|
||||
|
||||
* اضافه کردن لایه برنامه که به صورت کمترین وابستگی باشه نیاز داره که در سطح معماری، عملیات و فرآیند راهکار متفاوتی اتخاذ بشه(در برابر حالت سیستم یکدست(
|
||||
* اضافه کردن لایه برنامه‌ای که کمترین وابستگی رو داشته باشه نیاز داره که در سطح معماری، عملیات و فرآیند، راهکار متفاوتی رو اتخاذ بکنه(در برابر حالت سیستم یکدست(
|
||||
* میکروسرویس‌ها میتونن در دیپلوی کردن و عملیات مربوطه پیچیدگی اضافه کنن
|
||||
|
||||
### منابع برای مطالعه بیشتر
|
||||
|
|
@ -866,7 +880,7 @@ www.example.com -> IP address.
|
|||
|
||||
### مدیریت رابطه‌ای پایگاه داده RDBMS
|
||||
|
||||
یک پایگاه‌داده رابطه‌ای مثل اس-کیو-اِل مجموعه‌ای از داده‌هاس ایت که در جداول قرار گرفتند.
|
||||
یک پایگاه‌داده رابطه‌ای مثل اس-کیو-اِل مجموعه‌ای از داده‌هاس که در جداول قرار گرفتند.
|
||||
|
||||
**اسید** مجموعه‌ای از ویژگی‌های هست که برای تراکنش‌های پایگاه داده رابطه‌ای استفاده میشه.
|
||||
|
||||
|
|
@ -883,7 +897,7 @@ www.example.com -> IP address.
|
|||
|
||||
#### Master-slave replication
|
||||
|
||||
مستر هم عملیات خواندن و هم نوشتن رو انجام میده، نوشتنها رو برای ۱ یا تعداد بیشتری از اسلیوها تکرار میکنه، اسلیوها فقط عملیات خواندن رو انجام میدن. اسلیوها هم میتونن خودشون به صورت درختی یک سری اسلیو دیگه رو مثل خودشون تکرار کنن. اگر نود مستر خاموش بشه یا کلا از دسترس خارج بشه، سیستم کار خودش رو ادامه به صورت حالت فقط-خواندنی ادامه تا زمانی که یکی از این نودهای اسلیو بشه مستر یا یه مستر دیگه آماده بشه.
|
||||
مستر هم عملیات خواندن و هم نوشتن رو انجام میده، نوشتنها رو برای ۱ یا تعداد بیشتری از اسلیوها تکرار میکنه، اسلیوها فقط عملیات خواندن رو انجام میدن. اسلیوها هم میتونن خودشون به صورت درختی یک سری اسلیو دیگه رو مثل خودشون تکرار کنن. اگر نود مستر خاموش بشه یا کلا از دسترس خارج بشه، سیستم کار خودش رو به صورت حالت فقط-خواندنی ادامه تا زمانی که یکی از این نودهای اسلیو تبدیل بشه به مستر یا یه مستر دیگه اضافه بشه.
|
||||
|
||||
<p align="center">
|
||||
<img src="http://i.imgur.com/C9ioGtn.png">
|
||||
|
|
@ -911,13 +925,13 @@ www.example.com -> IP address.
|
|||
|
||||
##### معایب: master-master replication
|
||||
|
||||
* شما به یک لودبالانسر نیاز دارید یا اینکه باید در لایه برنامه‌تون تغییراتی ایجاد کنید که مشخص کنه که کجا بنویسه.
|
||||
* شما نیاز به یک لودبالانسر دارید یا اینکه باید در لایه برنامه‌تون تغییراتی ایجاد کنید که مشخص کنه کجا بنویسه.
|
||||
|
||||
* بیشتر سیستمهای مستر-مستر به صورت ناهمگون-ضعیف هستند(که مخالف اصل اَسید هس) یا اینکه باعث میشه که تاخیر عملیات نوشتن به خاطر نیاز به همگامسازی افزایش پیدا کنه.
|
||||
* بیشتر سیستمهای مستر-مستر به صورت یکپارچه-ضعیف هستند(که مخالف اصل اَسید هست) یا باعث میشه که تاخیر عملیات نوشتن به خاطر نیاز به همگامسازی افزایش پیدا کنه.
|
||||
|
||||
* > ACID: اَسید, Synchronization: همگامسازی, Loosely-Consistent: ناهمگون-ضعیف
|
||||
|
||||
* رفع تداخل بیشتر اتفاق میوفته اگر تعداد نودهای نوشتن بیشتر بیشتر بشه و همینطور میزان تاخیرهم زیاد میشه.
|
||||
* اگر تعداد نودهای نوشتن بیشتر و بیشتر بشه، رفع تداخل بیشتر اتفاق میوفته و همینطور میزان تاخیرهم زیاد میشه.
|
||||
|
||||
* قسمت زیر رو ببنید چرا که نکات مشترک هستند برای مستر-مستر و مستر-اسلیو
|
||||
|
||||
|
|
@ -925,13 +939,13 @@ www.example.com -> IP address.
|
|||
|
||||
##### معایب replication
|
||||
|
||||
* اگر نود مستر قبل از اینکه عملیات نوشتنی که به تازگی اتفاق افتاده رو نتونه رو نودهای دیگه تکرارکنه و در این حین پایین بیاد یا فِیل بشه، امکان این هست که داده‌ها از بین برن.
|
||||
* عملیات نوشتن روی نودهای خواندن دوباره اعمال میشه. اگر تعداد نوشتنها خیلی زیاد بشه نودهای خواندن به خاطر تکرار عملیات نوشتن هنگ میکنن و نمیتونن تعداد عملیاتهای خواندن زیادی انجام بدن
|
||||
* اگر نود مستر، قبل از اینکه عملیات نوشتنی که به تازگی اتفاق افتاده، نتونه رو نودهای دیگه تکرارکنه و در این حین پایین بیاد یا فِیل بشه، امکان این هست که داده‌ها از بین برن.
|
||||
* عملیاتهای نوشتن روی نودهای خواندن تکرار میشه. اگر تعداد نوشتنها خیلی زیاد بشه نودهای خواندن به خاطر تکرار عملیات نوشتن هنگ میکنن و نمیتونن تعداد عملیاتهای خواندن زیادی انجام بدن
|
||||
* هرچه تعداد نودهای اسلیو برای خواندن بیشتر باشه،باید تعداد بیشتری عملیات رو روی این نودها تکرار کنید که این خودش باعث میشه که شما یک لگ برای عملیات تکرار کردن داشته باشید
|
||||
* روی بعضی سیستم ها نوشتن روی مستر میتونه به صورت ایجاد چند تِرِد برای نوشتن موازی انجام بگیره اما روی نودهای خواندنی فقط یک تِرِد میتونه عملیات نوشتن رو انجام بده که اونم به صورت پشت سرهم انجام میشه.
|
||||
* ریپلیکیشن باعث میشه تا سخت افزار بیشتری اضافه بشه و پیچیدگی رو افزایش میده.
|
||||
|
||||
##### منابع برای مطالعه بیشتر
|
||||
##### منابع برای مطالعه بیشتر: replication
|
||||
|
||||
* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
|
||||
* [Multi-master replication](https://en.wikipedia.org/wiki/Multi-master_replication)
|
||||
|
|
@ -944,7 +958,7 @@ www.example.com -> IP address.
|
|||
<i><a href=https://www.youtube.com/watch?v=vg5onp8TU6Q>Source: Scaling up to your first 10 million users</a></i>
|
||||
</p>
|
||||
|
||||
فِدِرِیشن ( یا تقسیم عملکردی) پایگاه داده‌ها رو براساس کاری که انجام میدن تکه تکه میکنه. برای مثال بهجای یک پایگاه‌داده یک-تکه، شما میتونید ۳ تا پایگاه داده داشته باشید. **انجمنها**،**کاربران** و **محصولات** که باعث میشه تا تعداد عملیاتهای خواندن و نوشتن کم بشه و در نتیجه لگی که به خاطر عملیات ریپلیکیشن هست کاهش پیدا کنه. پایگاه‌داده‌های کوچک‌تر باعث میشن تا داده‌های بیشتری بتونه توی رم قراربگیره و این باعث میشه تا نتایج بیشتری در کش پیدابشن به خاطر اصل محلی بودن. بدون داشتن یک نود مستر مرکزی برای انجام عملیات نوشتن ها میتونید که تعداد نوشتنها رو به صورت موازی انجام بدید که این باعث میشه تا بازدهی بیشتری داشته باشید.
|
||||
فِدِرِیشن ( یا تقسیم عملکردی) پایگاه داده‌ها رو براساس کاری که انجام میدن تکه تکه میکنه. برای مثال به جای یک پایگاه‌داده یک-تکه، شما میتونید ۳ تا پایگاه داده داشته باشید. **انجمن ها**،**کاربران** و **محصولات** باعث میشه تا تعداد عملیاتهای خواندن و نوشتن کم بشه و در نتیجه لگی که به خاطر عملیات ریپلیکیشن هست کاهش پیدا کنه. پایگاه‌داده‌های کوچک‌تر باعث میشن تا داده‌های بیشتری بتونه توی رم قراربگیره و این باعث میشه تا نتایج بیشتری، به خاطر اصل محلی بودن، در کش پیدابشن . بدون داشتن یک نود مستر مرکزی برای انجام عملیاتهای نوشتن میتونید تعداد نوشتنها رو به صورت موازی انجام بدید که این باعث میشه تا بازدهی بیشتری داشته باشید.
|
||||
|
||||
##### معایب: federation
|
||||
|
||||
|
|
@ -958,7 +972,7 @@ www.example.com -> IP address.
|
|||
|
||||
* باعث افزایش سخت افزار و افزودن پیچیدگی میشه
|
||||
|
||||
##### منابع بیشتربرای مطالعه
|
||||
##### منابع بیشتربرای مطالعه : federation
|
||||
|
||||
* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=vg5onp8TU6Q)
|
||||
|
||||
|
|
@ -970,23 +984,23 @@ www.example.com -> IP address.
|
|||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Source: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
شاردینگ داده‌ها رو در پایگاه داده‌های مختلفی توزیع میکنه این توزیع به این صورت هست که هر پایگاه داده فقط بخشی از داده اصلی رو در خودش داره. به عنوان مثال پایگاه داده مربوط به کاربران رو در نظر بگیرید، هرچه تعداد کاربران افزایش پیدا کنه تعداد شارد‌هایی که باید اضافه بشه به کلاستر هم افزایش پیدا میکنه.
|
||||
شاردینگ داده‌ها رو در پایگاه داده‌های مختلفی توزیع میکنه. این توزیع به این صورت هست که هر پایگاه داده فقط بخشی از داده اصلی رو در خودش داره. به عنوان مثال پایگاه داده مربوط به کاربران رو در نظر بگیرید، هرچه تعداد کاربران افزایش پیدا کنه تعداد شارد‌هایی که باید اضافه بشه به کلاستر هم افزایش پیدا میکنه.
|
||||
|
||||
مشابه مزیت‌هایی مربوط [فدریشن](#federation) ، شاردینگ باعث میشه تا تعداد ترافیک خواندن و نوشتن کم بشه و ریپلیکیشن رو هم کم کنه و وجود داده در کش رو هم افزایش میده. سایز ایندکس‌ها هم کم میشه که بهطورکلی باعث میشه تا کارایی رو افزایش بده و سرعت کوئری ها رو زیاد کنه. اگر یک شاردی بیاد پایین، بقیه‌ی شاردها هنوز کار میکنن با این حال شما باید یه فرآیند ریپلیکیشن اضافه کنید که داده از بین نره. شبیه فدریشن، هیچ نودمرکزی برای نوشتن به صورت پشت سرهم وجود نداره و باعث میشه تا نوشتن به صورت موازی صورت بگیره و بازدهی افزایش پیدا کنه.
|
||||
|
||||
راه‌های عمومی که برای شارد کردن جدول کاربران وجود داره هم براساس اسم فامیلی کاربر میشه هم براساس اسم کوچیکشون یا موقعیت جغرافیاییشون.
|
||||
راه‌های عمومی برای شارد کردن جدول کاربران وجود داره، هم براساس اسم فامیلی کاربر میشه، هم براساس اسم کوچیکشون یا موقعیت جغرافیاییشون.
|
||||
|
||||
##### معایب: sharding
|
||||
|
||||
* باید منطق لایه برنامه رو تغییر بدید تا بتونه با شاردها کارکنه که این باعث میشه تا کوئری های اس-کیو-ال پیچیده بشن.
|
||||
* توزیع داده ها میتونه نامتوازن باشن توی یه شارد. برای مثال یه مجموعه ای از کاربران روی یک شارد باعث بشن که لود روی اون بیشتر از بقیه بشه.
|
||||
* دوباره بالانس کردن باعث میشه تا پیچیدگی رو افزایش بده. یک تابع شاردینگ که براساس یک تابع نگاشت استوار میتونه میزان انتقال داده‌ها رو کاهش بشده.
|
||||
* دوباره بالانس کردن باعث میشه تا پیچیدگی رو افزایش بده. یک تابع شاردینگ براساس یک تابع نگاشت استوار میتونه میزان انتقال داده‌ها رو کاهش بشده.
|
||||
|
||||
* > [consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html): نگاشت-استوار
|
||||
* جوین داده‌ها از چندتا شارد خیلی پیچیده میشه
|
||||
* باعث افزایش سخت افزار و افزودن پیچیدگی میشه
|
||||
|
||||
##### منابع برای مطالعه بیشتر
|
||||
##### منابع برای مطالعه بیشتر : sharding
|
||||
|
||||
* [The coming of the shard](http://highscalability.com/blog/2009/8/6/an-unorthodox-approach-to-database-design-the-coming-of-the.html)
|
||||
* [Shard database architecture](https://en.wikipedia.org/wiki/Shard_(database_architecture))
|
||||
|
|
@ -994,19 +1008,19 @@ www.example.com -> IP address.
|
|||
|
||||
#### Denormalization
|
||||
|
||||
دی-نرمالایزکردن سعی میکنه که باعث افزایش کارایی خواندن بشه در ازای افزایش چند عملیات نوشتن. یه سری کپی از داده‌ها توی جدول‌های مختلف نوشته میشه تا از سربار سنگین جوین جلوگیری کنه. بعضی از آر-دی-بی-اِم-اِس ها مثل [پوست-گِرِس](https://en.wikipedia.org/wiki/PostgreSQL) و اوراکل از [ویو-متریالایز](https://en.wikipedia.org/wiki/Materialized_view) پشتیبانی میکنن که کمک میکنه که اطلاعات اضافی رو ذخیره کنید و کپی داده‌ها رو با هم سازگار نگه دارید.
|
||||
دی-نرمالایزکردن در ازای افزایش چند عملیات نوشتن، سعی میکنه که باعث افزایش کارایی خواندن بشه . یه سری کپی از داده‌ها توی جدول‌های مختلف نوشته میشه تا از سربار سنگین جوین جلوگیری کنه. بعضی از آر-دی-بی-اِم-اِس ها مثل [پوست-گِرِس](https://en.wikipedia.org/wiki/PostgreSQL) و اوراکل از [ویو-متریالایز](https://en.wikipedia.org/wiki/Materialized_view) پشتیبانی میکنن که کمک میکنه که اطلاعات اضافی رو ذخیره کنید و کپی داده‌ها رو با هم سازگار نگه دارید.
|
||||
|
||||
زمانی که داده‌ها به روش [فدریشن](#federation) و [شاردینگ](#sharding) توزیع میشن مدیریت جوین‌ها بین دیتا سنترهای باعث میشه که پیچیدگی خیلی زیاد بشه. دی-نرمالایزیشن شاید باعث بشه که این نیاز به این نوع جوین ها رو از ببره.
|
||||
|
||||
دربیشتر سیستم‌ها عملیات خوندن میتونه به نسبت ۱۰۰:۱ یا حتی ۱۰۰۰:۱ نسبت به عملیات خواندن باشه. عملیات خواندنی که باعث بشه تا جوین پیچیده پایگاه‌داده انجام بشه میتونه خیلی سنگین باشه و مدت زمان قابل توجی روی عملیات دیسک سپری بشه.
|
||||
دربیشتر سیستم‌ها عملیات خوندن میتونه به نسبت ۱۰۰:۱ یا حتی ۱۰۰۰:۱ نسبت به عملیات نوشتن بیشتر باشه. عملیات خوندنی که حاصل یک جوین پیچیده پایگاه‌داده باشه، میتونه خیلی سنگین باشه و مدت زمان قابل توجی روی عملیاتهای مربوط به دیسک سپری کنه.
|
||||
|
||||
##### معایب: denormalization
|
||||
|
||||
* داده‌ها چندجا یکسان کپی میشن و تکراری داریم
|
||||
* محدودیت ها میتونه کمک کنه که کپی‌های داده ها با هم سینک بمونن که این کار باعث میشه تا طراحی پایگاه داده رو پیچیده کنی
|
||||
* پایگاه‌داده دی-نرمالایز شده زیر عملیات سنگین نوشتن ممکنه کارایی خیلی بدی داشته باشه نسبت به مشابه نرمالایز شدش
|
||||
* محدودیت ها میتونه کمک کنه که کپی‌های داده ها با هم سینک بمونن، که این کار باعث میشه تا طراحی پایگاه داده رو پیچیده کنید
|
||||
* پایگاه‌داده دی-نرمالایز شده، زیر عملیاتهای سنگین نوشتن ممکنه کارایی خیلی بدی داشته باشه نسبت به مشابه نرمالایز شدش
|
||||
|
||||
###### منابع بیشتر برای مطالعه
|
||||
###### منابع بیشتر برای مطالعه :denormalization
|
||||
|
||||
* [Denormalization](https://en.wikipedia.org/wiki/Denormalization)
|
||||
|
||||
|
|
@ -1017,7 +1031,7 @@ www.example.com -> IP address.
|
|||
خیلی مهمه که شما **بنچمارک** و **پروفایل** کنید تا بتونید چالش‌های دیده نشده رو شبیه سازی کنید و پیداشون کنید
|
||||
|
||||
* **Benchmark** - شبیه‌سازی شرایط لود زیاد با ابزارهایی مثل [اِی-بی](http://httpd.apache.org/docs/2.2/programs/ab.html)
|
||||
* **Profile** - استفاده از ابزارهایی مثل [لاگ کوئری‌های کند](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) برای ترک درن مشکلات کارایی
|
||||
* **Profile** - فعال کردن ابزارهایی مثل [لاگ کوئری‌های کُند](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) برای پیدا کردن مشکلات کارایی
|
||||
|
||||
بنچمارک کردن و پروفایل کردن ممکنه که شما رو به سمت بهینه سازی های زیر برسونه
|
||||
|
||||
|
|
@ -1053,7 +1067,7 @@ www.example.com -> IP address.
|
|||
|
||||
* In some cases, the [query cache](http://dev.mysql.com/doc/refman/5.7/en/query-cache) could lead to [performance issues](https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/).
|
||||
|
||||
##### منابع برای مطالعه بیشتر
|
||||
##### منابع برای مطالعه بیشتر : SQL tuning
|
||||
|
||||
* [Tips for optimizing MySQL queries](http://20bits.com/article/10-tips-for-optimizing-mysql-queries-that-dont-suck)
|
||||
* [Is there a good reason i see VARCHAR(255) used so often?](http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l)
|
||||
|
|
@ -1066,34 +1080,36 @@ www.example.com -> IP address.
|
|||
|
||||
**key-value store**, **document-store**, **wide column store**, **graph database**
|
||||
|
||||
داده ها دی-نرمالایز میشن و جوین های معمولا در لایه ی برنامه انجام میشن. بیشتر نو-اس-کیو-ال ها از اصل **اَسید** برای تراکنش های پشتیبانی نمیکنن و [یکپارچگی موکول](#eventual-consistency) رو به این اصل ترجیح میدن
|
||||
داده ها دی-نرمالایز میشن و جوین های معمولا در لایه ی برنامه انجام میشن. بیشتر نو-اس-کیو-ال ها از اصل **اَسید** برای تراکنش های پشتیبانی نمیکنن و [یکپارچگی موکول](#یکپارچگی-موکول) رو به این اصل ترجیح میدن
|
||||
|
||||
**بِیس** معمولا برای توصیف ویژگی‌های پایگاه داده های نو-اس-کیو-ال استفاده میشد. در مقایسه با تئوری کپ ، بِیس دسترس پذیری رو بر یکپارچگی ترجیح میده.
|
||||
**بِیس** معمولا برای توصیف ویژگی‌های پایگاه داده های نو-اس-کیو-ال استفاده میشه. در مقایسه با تئوری کپ ، بِیس دسترس پذیری رو بر یکپارچگی ترجیح میده.
|
||||
|
||||
> [تئوری CAP](#CAP-تئوری)
|
||||
> Consistent: استوار
|
||||
> Consistent: سازگار
|
||||
|
||||
* **Basically available** - سیستم دسترس‌پذیری رو تضمین
|
||||
* **Basically available** - سیستم دسترس‌پذیری رو تضمین میکنه
|
||||
* **Soft state** - وضعیت سیستم ممکنه که بدون گرفتن ورودی در طول زمان دچار تغییر بشه.
|
||||
* **Eventual consistency** - سیستم در طول یک مدت زمانی استوار میشه با این شرط که در طول این مدت ورودی نگیره
|
||||
* **Eventual consistency** - سیستم در طول یک مدت زمان سازگار میشه با این شرط که در طول این مدت ورودی نگیره
|
||||
|
||||
علاوه براین که باید انتخاب کنید که [اس-کیو-ال یا نو-اس-کیو-ال](sql-or-nosql#) بدنیست که پایگاه داده های نو-اس-کیو-ال رو انواعش رو بشناسید و اونی که بهترین فیت برای کاربردتون هست را انتخاب کنید. ما در ادامه موارد زیر روبررسی میکنیم.
|
||||
علاوه براین که باید انتخاب کنید که [اس-کیو-ال یا نو-اس-کیو-ال](#SQL-یا-NoSQL) بد نیست انواع پایگاه داده های نو-اس-کیو-ال رو بشناسید و اونی که بهترین انتخاب برای کاربردتون هست را انتخاب کنید. ما در ادامه موارد زیر روبررسی میکنیم.
|
||||
|
||||
**key-value stores**, **document-stores**, **wide column stores**, **graph databases**
|
||||
|
||||
#### Key-value store
|
||||
|
||||
> Abstraction: hash table
|
||||
>
|
||||
> O(1): اُ-۱, SSD: اِس-اِس-دی
|
||||
|
||||
یک ذخیره سازی کلید-مقدار به طور عمومی به شما این امکان رو میده که از عملیات خوندن و نوشتن رو با اُ(۱) انجام بدید و معمولا توسط حافظه‌های اس-اس-دی و رم پشتیبانی میشن. این ذخیره کننده‌های داده میتونن کلیدها رو به [به ترتیب الفبایی](#https://en.wikipedia.org/wiki/Lexicographical_order) مرتب نگه دارن که باعث میشه تا بازیابی کلیدها به صورت بازه‌ای بهینه تر و به صرفه‌تر بشه.
|
||||
یک ذخیره ساز کلید-مقدار به طور عمومی به شما این امکان رو میده که از عملیات خوندن و نوشتن رو با اُ(۱) انجام بدید و معمولا توسط حافظه‌های اِس-اِس-دی و رَم پشتیبانی میشن. این ذخیره کننده‌های داده میتونن کلیدها رو به [به ترتیب الفبایی](https://en.wikipedia.org/wiki/Lexicographical_order) مرتب نگه دارن که باعث میشه تا بازیابی کلیدها به صورت بازه‌ای، بهینه تر و به صرفه‌تر بشه.
|
||||
|
||||
این ذخیره‌کننده ها معمولا با کارایی بالاهستند و برای مدل‌های داده‌ای ساده یا داده‌هایی که خیلی سریع تغییر میکنند مثل داده‌هایی که توی کش هستند مورد استفاده قرار میگیرند.
|
||||
این ذخیره‌کننده ها معمولا با کارایی بالاهستند و برای مدل‌های داده‌ای ساده یا داده‌هایی که خیلی سریع تغییر میکنند مثل داده‌هایی که توی کش هستند مورد استفاده قرار میگیرند.
|
||||
|
||||
یک مخزن کلید-مقدار معمولا پایه‌ای اصلی برای سیستمهای پیچیده‌ای مانند ذخیره‌ساز های اسنادی و در بعضی موردها پایگاه‌داده‌های گرافی،مورد استفاده قرار میگیرد.
|
||||
یک ذخیره‌ساز کلید-مقدار معمولا پایه‌ای اصلی برای سیستمهای پیچیده‌ای مثل ذخیره‌ساز های اَسنادی و در بعضی موردها پایگاه‌داده‌های گرافی،مورد استفاده قرار میگیرد.
|
||||
|
||||
> Document Store: ذخیره ساز اسنادی
|
||||
|
||||
##### منابع برای مطالعه بیشتر
|
||||
##### منابع برای مطالعه بیشتر : key-value store
|
||||
|
||||
* [Key-value database](https://en.wikipedia.org/wiki/Key-value_database)
|
||||
* [Disadvantages of key-value stores](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
|
||||
|
|
@ -1104,15 +1120,15 @@ www.example.com -> IP address.
|
|||
|
||||
> Abstraction: key-value store with documents stored as values
|
||||
|
||||
یک ذخیره‌ساز اسنادی حول اسناد شکل میگیره(مانند ایکس-ام-ال، جیسان، باینری و ...) که در اینجا یک سند تمام اطلاعات مربوط به یک شی رو در اون ذخیره میکنه. ذخیره‌سازهای اسنادی ای-پی-آی ها یا زبان‌های کوئری در اختیار قرار میدهند تا بتونیم براساس این روش‌ها ساختار داخلی خود سند رو مورد جستجو قرار بدیم. به یاد داشته باشید که خیلی از ذخیره‌سازهای کلید-مقدار شامل ویژگی‌هایی هستند که میتونه با متادیتاهای مربوط به مقدارهای یک کلید هم کارکنه که باعث میشه که مرز بین این ذخیره‌سازها رو کمرنگتر میکنه از لحاظ نوع محل ذخیره‌سازی.
|
||||
یک ذخیره‌ساز اسنادی حول ایده اسناد شکل میگیره(مانند ایکس-ام-ال، جِیسان، باینری و ...) که در اینجا یک سند تمام اطلاعات مربوط به یک شی رو در خودش ذخیره میکنه. ذخیره‌سازهای اسنادی، اِی-پی-آی ها یا زبان‌های کوئری در اختیار قرار میدهند تا بتونیم ساختار داخلی خود سند رو مورد جستجو و کوئری قرار بدیم. به یاد داشته باشید که خیلی از ذخیره‌سازهای کلید-مقدار شامل ویژگی‌هایی هستند که میتونه با متادیتاهای مربوط به مقدارهای یک کلید هم کارکنه، که باعث میشه که مرز بین این ذخیره‌سازها از لحاظ نوع محل ذخیره‌سازی با یکدیگه کمرنگتر بشه .
|
||||
|
||||
براساس پیاده‌سازی های زیرساختی ، اسناد هم به صورت تگها، کالکشن‌ها، متادیتاها یا پرونده‌ها سازماندهی میشن. باوجوداینکه اسناد میتونن باهم دیگه گروه بشن یا توی یه دسته سازماندهی بشن،با اینحال میتونن هرکدوم فیلدهای مخصوص خودشون رو داشته باشند که در بقیه موجود نباشه.
|
||||
|
||||
بعضی از این ذخیره‌سازها مثل [مونگو-دی-بی](https://www.mongodb.com/mongodb-architecture#) و [کوچ-دی-بی](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/#) زبان‌هایی شبیه اس-کیو-ال برای انجام کوئری‌های پیچیده فراهم کردند. [داینامو-دی-بی](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf#) هر دو نوع کلید-مقدار و اسنادی رو پشتیبانی میکنه.
|
||||
|
||||
ذخیره‌ساز های اسنادی انعطاف زیادی رو میدن و معمولا جاهایی که تغییرات داد مکرر اتفاق میوفته استفاده میشه.
|
||||
ذخیره‌ساز های اسنادی انعطاف زیادی رو میدن و معمولا جاهایی که تغییرات داده مکرر اتفاق میوفته استفاده میشه.
|
||||
|
||||
##### منابع برای مطالعه بیشتر
|
||||
##### منابع برای مطالعه بیشتر : document store
|
||||
|
||||
* [Document-oriented database](https://en.wikipedia.org/wiki/Document-oriented_database)
|
||||
* [MongoDB architecture](https://www.mongodb.com/mongodb-architecture)
|
||||
|
|
@ -1129,17 +1145,15 @@ www.example.com -> IP address.
|
|||
|
||||
> Abstraction: nested map `ColumnFamily<RowKey, Columns<ColKey, Value, Timestamp>>`
|
||||
|
||||
المان اصلی و پایه‌ای برای ذخیره‌ساز واید-کالم یک ستون(یک جفت اسم/مقدار) است. یه ستون میتونه توی دسته بندی گروهی خاصی(مثل همون جدول توی اس-کیو-ال) دسته بندی بشه. ابر گروه‌های ستونی به صورت دسته بندی گروهی برخی از این گروه‌ها استفاده میشن. شما میتونید به هر ستونی که میخواید با استفاده از کلید اون سطر به صورت مستقل دسترسی داشته باشید و ستونها با یک کلید سطر مشابه یه سطر رو تشکلی میدن. هر مقدار شامل یک استمپ-زمانی برای ورژنگذاری و رفع تداخل است.
|
||||
> Super Column Family: اَبَر-ستون-خانوادگی, Column Family ستون-خانوادگی: , Row Key: کلید سطر
|
||||
|
||||
> Super Column Family: ابرگروه ستونی, Column Family گروه ستونی: , Row Key: کلید سطر
|
||||
المان اصلی و پایه‌ای برای ذخیره‌ساز واید-کالِم، ستون(یک جفت اسم/مقدار) است. یه ستون میتونه توی ستون‌های-خانوادگی (مثل همون جدول توی اس-کیو-ال) دسته بندی بشه. اَبَر-ستون‌های-خانوادگی به صورت دسته‌ای از ستون‌های-خانوادگی هستند. شما میتونید به هر ستونی که میخواید، با استفاده از کلید اون سطر، به صورت مستقل دسترسی داشته باشید. ستونها با یک کلید سطر مشابه، یه سطر رو تشکلی میدن. هر مقدار شامل یک استمپ-زمانی برای ورژنگذاری و رفع تداخل است.
|
||||
|
||||
|
||||
|
||||
گوگل [بیگ-تیبل](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) رو به عنوان اولین ذخیره‌ساز ستونی معرفی کرد که روی [اچ-بیس](https://www.mapr.com/blog/in-depth-look-hbase-architecture) متن باز که در اکوسیستم هدوپ استفاده میشه و یا [کاساندرا](http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/architecture/architectureIntro_c.html) که برای فیسبوک است، مورد استفاده قرار بگیره. ذخیره‌سازهایی مثل بیگ-تیبل،اچ-بیس و کاساندرا کلیدها رو بهصورت مرتب الفبایی نگهداری میکنن که باعث میشه که بازیابی براساس یک رنج از کلیدها به صورت موثر تر و بهینه تر باشد.
|
||||
گوگل [بیگ-تیبل](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) رو به عنوان اولین ذخیره‌ساز ستونی معرفی کرد که در [اچ-بیس](https://www.mapr.com/blog/in-depth-look-hbase-architecture)، که متن باز است و در اکوسیستم هدوپ استفاده میشه، و یا [کاساندرا](http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/architecture/architectureIntro_c.html)، که برای فیسبوک است، مورد استفاده قرار گرفته. ذخیره‌سازهایی مثل بیگ-تیبل،اچ-بیس و کاساندرا کلیدها رو بهصورت الفبایی-مرتب نگهداری میکنن که باعث میشه که بازیابی براساس یک رنج از کلیدها به صورت موثر تر و بهینه تر باشه
|
||||
|
||||
ذخیره‌سازهای ستونی دسترس‌پذیری بالا و قابلیت اسکیل شدن بالا رو دراختیار قرار میدن. معمولا برای مجموعه داده‌های خیلی بزرگ مورد استفاده قرار میگیرند.
|
||||
|
||||
##### منابع برای مطالعه بیشتر
|
||||
##### منابع برای مطالعه بیشتر : wide column store
|
||||
|
||||
* [SQL & NoSQL, a brief history](http://blog.grio.com/2015/11/sql-nosql-a-brief-history.html)
|
||||
* [Bigtable architecture](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf)
|
||||
|
|
@ -1156,17 +1170,17 @@ www.example.com -> IP address.
|
|||
|
||||
> Abstraction: graph
|
||||
|
||||
در یک پایگاه داده گرافی هر نود یک رکورد است و هر یال یک رابطه بین دو نود. پایگاه‌داده‌های گرافی برای نمایش رابطه‌های پیچیده مورد استفاده قرار میگیرند که معمولا تعداد کلید خارجی زیادی دارند یا رابطه‌های چند-به-چند زیادی دارند.
|
||||
در یک پایگاه داده گرافی هر نود یک رکورد است و هر یال یک رابطه بین دو نود. پایگاه‌داده‌های گرافی برای نمایش رابطه‌های پیچیده مورد استفاده قرار میگیرند که معمولا تعداد کلید خارجی زیاد یا رابطه‌های چند-به-چند زیادی دارند.
|
||||
|
||||
پایگاه‌داده های گرافی دارای کارایی بالا هستند و برای مدل‌های داده‌ای که روابط پیچیده دارند مورد استفاده قرار میگیرند مانند شبکه‌های اجتماعی. این دسته از پایگاه‌داده‌ها تقریبا جدید هستند و خیلی مورد استفاده قرار نگرفته اند،معمولا پیدا کردن منابع و یا ابزار برای این دست از پایگاه‌داده ها دشواره. خیلی از پایگاه داده های گرافی معمولا از طریق [رِست ای-پی-آی](#representational-state-transfer-rest) قابل دسترسی هستند.
|
||||
|
||||
##### منابع برای مطالعه بیشتر در مورد پایگاه‌داده گرافی
|
||||
##### منابع برای مطالعه بیشتر : graph
|
||||
|
||||
* [Graph database](https://en.wikipedia.org/wiki/Graph_database)
|
||||
* [Neo4j](https://neo4j.com/)
|
||||
* [FlockDB](https://blog.twitter.com/2010/introducing-flockdb)
|
||||
|
||||
#### منابع بیشتر برای مطالعه نو-اس-کیو-ال‌ها
|
||||
#### منابع بیشتر برای مطالعه : NoSQL
|
||||
|
||||
* [Explanation of base terminology](http://stackoverflow.com/questions/3342497/explanation-of-base-terminology)
|
||||
* [NoSQL databases a survey and decision guidance](https://medium.com/baqend-blog/nosql-databases-a-survey-and-decision-guidance-ea7823a822d#.wskogqenq)
|
||||
|
|
@ -1184,7 +1198,7 @@ www.example.com -> IP address.
|
|||
|
||||
|
||||
|
||||
دلایلی که باید **ازاس-کیو-ال** باید استفاده کرد:
|
||||
دلایلی که باید از **اس-کیو-ال** باید استفاده کرد:
|
||||
|
||||
* داده‌ها دارای ساختار هستند
|
||||
* شِمای مورد استفاده خیلی قطعی و مشخص
|
||||
|
|
@ -1203,17 +1217,17 @@ www.example.com -> IP address.
|
|||
* نیاز به جوین های پیچیده ندارید
|
||||
* حجم داده‌ها در حد ترابایت یا پتا بایت هست
|
||||
* حجم‌کاریتون خیلی داده محور هست
|
||||
* میزان بازدهی بالا برای تعداد آی-اُ بر ثانیه
|
||||
* میزان بازدهی بالا براساس آی-اُ بر ثانیه
|
||||
|
||||
نمونه‌هایی از مواردی که برای نو-اس-کیو-ال خیلی مناسبه:
|
||||
|
||||
* حجم‌زیاد داده‌های مربوط به لاگ یا کلیک کردن‌ها
|
||||
* لیدربوردها در بازی ها مثلا یا داده‌های مربوط به امتیاز
|
||||
* لیدربوردها در بازی ها یا داده‌های مربوط به امتیاز
|
||||
* داده‌های موقت مثل اطلاعات کارت‌های خرید
|
||||
* جداولی که تعداد درخواست برای داده‌های اون زیاده
|
||||
* جداولی که برای متادیتا هست یا برای جستوجو استفاده میشن
|
||||
|
||||
##### منابع بیشتر برای مطالعه
|
||||
##### منابع بیشتر برای مطالعه : SQL or NoSQL
|
||||
|
||||
* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=vg5onp8TU6Q)
|
||||
* [SQL vs NoSQL differences](https://www.sitepoint.com/sql-vs-nosql-differences/)
|
||||
|
|
@ -1226,13 +1240,13 @@ www.example.com -> IP address.
|
|||
<i><a href=http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html>Source: Scalable system design patterns</a></i>
|
||||
</p>
|
||||
|
||||
کش کردن باعث میشه تا زمان لود صفحه بهبود پیدا کنه و میتونه لود روی سرور شما و یا پایگاه داده رو کم کنه. در این مدل دیسپچر اول داخل کش رو نگاه میکنه اگر که درخواست قبلا داده شده بود و نتیجش بود اونجا، برمیگردونه که باعث میشه که زمان واقعی اجرا رو صرفه جونیی کنه.
|
||||
کش کردن باعث میشه تا زمان لود صفحه بهبود پیدا کنه و میتونه لود روی سرور شما و یا پایگاه داده رو کم کنه. در این مدل دیسپچر اول داخل کش رو نگاه میکنه اگر که درخواست قبلا داده شده بود و نتیجش بود اونجا، برمیگردونه به کاربر که باعث میشه زمان واقعی اجرا رو صرفه جویی کنه.
|
||||
|
||||
پایگاه داده‌ها معمولا از یک توزیع یکنواختی از خواندن ها یا نوشتنها توی پارتیشن بهره میگرن. آیتم‌هایی که خیلی مورد استفاده هستند میتونن این توزیع رو دچار چلگی کنن که باعث میشه که ما باتلنک داشته باشیم. استفاده از کش در جلوی پایگاه داده میتونه کمک کنه که این توزیع غیر یکنواخت رو بعضا دارای پیک ترافیک رو جلوش رو بگیره.
|
||||
پایگاه داده‌ها معمولا از یک توزیع یکنواختی از خواندن ها یا نوشتنها توی پارتیشن بهره میگرن. آیتم‌هایی که خیلی مورد استفاده هستند میتونن این توزیع رو دچار چلگی کنن که باعث میشه که ما باتِلنِک داشته باشیم. استفاده از کش در جلوی پایگاه داده میتونه کمک کنه که این توزیع غیر یکنواخت و پیک‌های ترافیک رو جلوشو بگیره.
|
||||
|
||||
### کش سمت کلاینت
|
||||
|
||||
کشها میتونن که در بخش کلاینت (مثل مرورگر یا سیستم عامل) قرار بگیرند یا در [سمت سرور](#پروکسی-معکوس) باشن یا کلا یک لایه کش جدا وجود دارشته باشه
|
||||
کشها میتونن که در بخش کلاینت (مثل مرورگر یا سیستم عامل) قرار بگیرند یا در [سمت سرور](#وب-سرور-پروکسی-معکوس) باشن یا کلا یک لایه کش جدا وجود دارشته باشه
|
||||
|
||||
### CDN کش در
|
||||
|
||||
|
|
@ -1244,22 +1258,22 @@ www.example.com -> IP address.
|
|||
|
||||
### کش پایگاه داده
|
||||
|
||||
پایگاه‌داده شما معمولا شامل یک سری لایه کش به صورت پیش‌فرض در تنظیماتش هست که برای کاربرادهای عمومی‌تر مورد استفاده است. تغییر این تنظیمات برای یک کاربرد خاص میتونه این افزایش کارایی رو حتی بیشتر هم بکنه.
|
||||
پایگاه‌داده شما معمولا شامل یک سری لایه کش به صورت پیش‌فرض در تنظیماتش هست که برای کاربرادهای عمومی‌تر مورد استفاده فرار میگیره. تغییر این تنظیمات برای یک کاربرد خاص میتونه این افزایش کارایی رو حتی بیشتر هم بکنه.
|
||||
|
||||
### کش در برنامه
|
||||
|
||||
کشها داخل حافظه مثل مِمکش و رِدیس ذخیره‌سازهای کلید-مقدار هستند که بین برنامه شما و منبع نگه داری داده شما قرار میگیره. از اونجایی که داده ها داخل رم نگه داری میشه، سرعت بیشتری نسبت به پایگاه داده های معمولی داره چرا که توی اونا داده روی دیسک ذخیره میشه. رم نسبت دیسک محدودتره بنابراین الگوریتم‌های [غیر معتبر کردن کش](https://en.wikipedia.org/wiki/Cache_algorithms) مثل [آخرین نزدیکترین استفاده - اِل-آر-یو](https://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used) میتونه کمک کنه که آیتم‌های سرد رو غیر معتبر کنه و داده‌ها داغ‌تر رو توی رم نگه داره.(منظور از داغ بیشتر مورد استفاده است و منظور از سر برعکس داغ)
|
||||
کش‌های داخل-حافظه مثل مِمکش و رِدیس ذخیره‌سازهای کلید-مقداری هستند که بین برنامه شما و منبع نگه داری داده شما قرار میگیرن. از اونجایی که داده ها داخل رم نگه داری میشه، سرعت بیشتری نسبت به پایگاه داده های معمولی داره چرا که توی پایگاه‌داده، داده روی دیسک ذخیره میشه. رم نسبت به دیسک محدودتره بنابراین الگوریتم‌های [غیر معتبر کردن کش](https://en.wikipedia.org/wiki/Cache_algorithms) مثل [آخرین نزدیکترین استفاده - اِل-آر-یو](https://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used) میتونه کمک کنه که آیتم‌های سرد رو غیر معتبر کنه و داده‌ها داغ‌تر رو توی رم نگه داره.(منظور از داغ، بیشتر مورد استفاده است و منظور از سرد، برعکس داغ)
|
||||
|
||||
رِدیس ویژگی‌ها بیشتر زیر رو هم داره:
|
||||
|
||||
* امکان دائمی کردن داده
|
||||
* داده‌اسختارهای درونی مثل مجموعه‌های مرتب و لیست‌ها
|
||||
* امکان دائمی کردن داده روی دیسک
|
||||
* داده‌ساختارهای درونی مثل مجموعه‌های مرتب و لیست‌ها
|
||||
|
||||
سطح‌های مختلفی وجود دارند که میتونید کش کردن رو انجام بدید که به دو دسته کلی تقسیم میشن: **کوئری‌های پایگاه‌داده** و **اشیا**
|
||||
|
||||
* در سطح سطری
|
||||
* در سطح سطر
|
||||
* در سطح کوئری
|
||||
* اشیای که سریالایز شدن به طور کامل
|
||||
* Fully-formed serializable objects
|
||||
* صفحات اچ-تی-ام-ال که به صور کامل رندر شدن
|
||||
|
||||
به طورکلی، شما بهتره که از کش کردن به صورت فایلی دوری کنین چرا که اسکیل-کردن خودکار و کلون کردن رو خیلی سخت میکنه.
|
||||
|
|
@ -1299,7 +1313,7 @@ www.example.com -> IP address.
|
|||
|
||||
> Storage: اِستورج
|
||||
|
||||
برنامه مسول نوشتن و خواندن از کش اِستورج هست. کش با خود استورج به صورت مستقیم در ارتباط نیست. برنامه کارهای زیر رو انجام میده:
|
||||
برنامه مسول نوشتن و خواندن از اِستورج هست. کش با خود استورج به صورت مستقیم در ارتباط نیست. برنامه کارهای زیر رو انجام میده:
|
||||
|
||||
* دنبال یک آیتم خاص توی کش میگرده، که نتیجش این میشه که آیتم داخل کش نیست
|
||||
* اون آیتم رو از پایگاه داده لود میکنه
|
||||
|
|
@ -1319,9 +1333,9 @@ def get_user(self, user_id):
|
|||
|
||||
[مِم-کش-دی](https://memcached.org/) معمولا به این حالت ازش استفاده میشه
|
||||
|
||||
عملیاتهای خواندنی که در ادامه میاد که مربوط به همون داده ای هست که توی کش نوشته شده سریع‌تر انجام میشه. کش-اِساید به تحت عنوان بارگذاری تنبل هم گفته میشه. تنها داده‌ای که درخواست داده میشه کش میشه که این باعث میشه تا کش با داده‌هایی که درخواست داده نشدن پر نشه.
|
||||
عملیاتهای خواندن که بعد از این میاد، و مربوط به همون داده ای هست که توی کش نوشته شده، سریع‌تر انجام میشه. کش-اِساید به تحت عنوان بارگذاری تنبل هم گفته میشه. فقط داده‌ای که درخواست داده میشه، کش میشه که این باعث میشه تا کش با داده‌هایی که درخواست داده نشدن پر نشه.
|
||||
|
||||
##### معایب
|
||||
##### معایب : cache-aside
|
||||
|
||||
* هر نبودن در کش باعث میشه تا ۳ مسیر طی بشه که این خودش باعث میشه که تاخیر قابل توجهی ایجاد بشه.
|
||||
* داده میتونه غیرمعتبر بشه اگر که داخل پایگاه داده تغییر کرده باشه. این مشکل با ست کردن یک تام-تو-لیو برطرف میشه به اینصورت که کش مجبوره بعد این مدت اپدیت بشه. یا با استفاده از روش رایت-ثُرو میشه این مشکل رو برطرف کرد.
|
||||
|
|
@ -1355,9 +1369,9 @@ def set_user(user_id, values):
|
|||
cache.set(user_id, user)
|
||||
```
|
||||
|
||||
این روش با توجه به عملیات نوشتنی که داره به طور کلی کند هست اما عملیاتهای خوندنی که در ادامه اتفاق میوفته خیلی سریع هستند. کاربران معمولا زمانی که میخوان به روز رسانی داده‌هاشون رو انجام بدن خیلی نسبت تاخیر واکنش نشون نمیدن نسبت به زمانی که قصد دارن داده‌ها رو بخونن. داده‌ها داخل کش غیرمعتبر نمیشن
|
||||
این روش با توجه به عملیات نوشتنی که داره، به طور کلی کُند هست اما عملیاتهای خوندنی که در ادامه اتفاق میوفته خیلی سریع هستند. کاربران معمولا زمانی که میخوان به روز رسانی داده‌هاشون رو انجام بدن خیلی نسبت تاخیر واکنش نشون نمیدن نسبت به زمانی که قصد دارن داده‌ها رو بخونن. داده‌ها داخل کش غیرمعتبر نمیشن
|
||||
|
||||
##### معایب
|
||||
##### معایب : write-through
|
||||
|
||||
* وقتی نود جدید درست میشه به خاطر اسکیل کردن یا فِیل شدن، نود جدید آیتم‌ها رو کش نمیکنه تا زمانیکه در پایگاه داده به روز رسانی بشن. استفاده از روش کش-اِساید با این روش میتونه این مشکل رو برطرف کنه.
|
||||
* بیشتر داده‌هایی که نوشته میشن تو کش ممکنه خونده نشن که البته میتونه با استفاده از تای-تو-لیو این تاثیر رو کم کرد..
|
||||
|
|
@ -1375,7 +1389,7 @@ def set_user(user_id, values):
|
|||
* یک آیتم به کش اضافه میکنه یا آپدیت میکنه
|
||||
* به صورت ناهمگام آیتم رو توی اون منبع ذخیره مینویسه که باعث میشه تا کارایی سیستم بهبود پیدا کنه
|
||||
|
||||
##### معایب
|
||||
##### معایب : write-behind
|
||||
|
||||
* اگر قبل از اینکه محتوای داخل کش مورد استفاده قرار بگیره، کش پایین بیاد ممکنه که داده‌ها رو از دست بدیم.
|
||||
* پیاده سازی این روش نسبت به روش های کش-اساید و یا رایت-ثُرو پیچیده‌تر هست.
|
||||
|
|
@ -1390,16 +1404,16 @@ def set_user(user_id, values):
|
|||
|
||||
شما میتونید کش رو طوری تنظیم کنید که به صورت خودکار هر آیتم داخل کش که اخیر مورد استفاده قرار گرفته رو قبل از زمان انقضاش رِفرِش کنید
|
||||
|
||||
این روش میتونه باعث بشه که تاخیر کاهش پیداکند نسبت حال رید-ثُرو اگر کش بتونه به دقت تشخیص بده که کدوم آیتم احتمالا در آینده مورد نیاز خواهد بود.
|
||||
اگر کش بتونه به دقت تشخیص بده که کدوم آیتم احتمالا در آینده مورد نیاز خواهد بود، این روش میتونه باعث بشه که تاخیر کاهش پیداکند نسبت حالت رید-ثُرو .
|
||||
|
||||
##### معایب
|
||||
##### معایب : refresh-ahead
|
||||
|
||||
* اگر پیش‌بینی اینکه کدوم آیتم در آینده مورد نیاز خواهد بود به خوبی انجام نشه باعث میشه تا کارایی کاهش پیدا کنه نسبت به حالتی که از این مود استفاده نشه.
|
||||
|
||||
### معایب کش
|
||||
### معایب : Cache
|
||||
|
||||
* نیاز داره سازگاری بین کشها و منابع درستیشون مثل پایگاه داده‌ها به وسیله‌ی [غیرمعتبرسازی کش](https://en.wikipedia.org/wiki/Cache_algorithms) تامین بشه.
|
||||
* نیاز داره که تغییراتی در برنامه ایجاد بشه مثل اضافه کردن رِدیس یا مِم-کش-دی
|
||||
* نیاز داره سازگاری بین کشها و منابع درستیشون، مثل پایگاه داده‌ها، به وسیله‌ی [غیرمعتبرسازی کش](https://en.wikipedia.org/wiki/Cache_algorithms) تامین بشه.
|
||||
* نیاز داره که تغییراتی در برنامه ایجاد بشه، مثل اضافه کردن رِدیس یا مِم-کش-دی
|
||||
* غیرمعتبرسازی کش مشکل دشواری هست و یه پیچیدگی در مورد زمان آپدیت کش به وجود میاره.
|
||||
|
||||
### منابع برای مطالعه بیشتر
|
||||
|
|
@ -1426,30 +1440,30 @@ def set_user(user_id, values):
|
|||
|
||||
### Message queues
|
||||
|
||||
صفهای پیام، پیام‌ها را میگرند،نگه میدارن و بعد میرسونن. اگر یه عملیاتی برای اجرای همگام خیلی کند باشه میتونید از یه صف با جریان کاری زیر استفاده کنید:
|
||||
صفهای پیام، پیام‌ها را میگیرند،نگه میدارن و بعد میرسونن. اگر یه عملیاتی برای اجرای همگام خیلی کُند باشه میتونید از یه صف با جریان کاری زیر استفاده کنید:
|
||||
|
||||
* یک برنامه یک کار رو به صف اضافه میکنه، بعد به کاربر از وضعیت کاری که فرستاده اطلاع میده.
|
||||
* یک وُرکر کار رو از صف بر میداره پردازش میکنه و بعد سیگنالی مبنی بر این که کار تموم شده ارسال میکنه.
|
||||
|
||||
روند اجرایی کاربر بلاک نمیشه و کار در پسزمینه در حال انجامه. در این مدت کلاینت میتونه یه پردازش خیلی کمی انجام بده که نشون بده که اون کار تموم شده(به کاربر). برای مثال، اگر پستی رو توییت میشه، پست میتونه همون لحظه به تامیلاینتون اضافه بشه اما ممکنه یکم زمان ببره تا قبل از اینکه به تمام فالورهای شما برسه.
|
||||
روند اجرایی کاربر بلاک نمیشه و کار در پسزمینه در حال انجامه. در این مدت کلاینت میتونه یه پردازش خیلی کمی انجام بده و نشون بده که اون کار تموم شده(به کاربر). برای مثال، اگر پستی توییت میشه، پست میتونه همون لحظه به تامیلاینتون اضافه بشه اما ممکنه یکم زمان ببره تا قبل از اینکه به تمام فالورهای شما برسه.
|
||||
|
||||
**ردیس** یک بروکر پیام ساده و کاربردی است اما پیام‌ها میتونن گم بشن داخلش.
|
||||
|
||||
**ربیت-اِم-کیو** معروفه اما باید از پروتکل اِی-اِم-کیو-پی استفاده کنید و نودهای خودتون رو مدیریت کنید.
|
||||
**رَبیت-اِم-کیو** معروفه اما باید از 'پروتکل اِی-اِم-کیو-پی' استفاده کنید و نودها رو خودتون رو مدیریت کنید.
|
||||
|
||||
**آمازون اِس-کیو-اِس** به صورت هاست شده هست اما ممکنه که تاخیر زیادی داشته باشه و امکان داره که پیام ۲ بار دریافت بشه.
|
||||
**آمازون اِس-کیو-اِس** به صورت هاست شده هست اما ممکنه که تاخیر زیادی داشته باشه و امکان داره که یک پیام ۲ بار دریافت بشه.
|
||||
|
||||
### Task queues
|
||||
|
||||
صفهای تسک‌ها تسک‌های و داده‌های مربوط به اون رو میگیره، اجراشون میکنه بعد نتایجش رو برمیگردونه. تسک‌ها میتونن زمانبندی رو پشتیبانی کنن و میتونه به برای کارهایی که از نظر محاسباتی خیلی سنگینه استفاده بشه که در پسزمینه اجرا بشن.
|
||||
صف تسک‌ها، تسک‌ها و داده‌های مربوط به اون رو میگیره، اجراشون میکنه بعد نتایجش رو برمیگردونه. تسک‌ها میتونن زمانبندی رو پشتیبانی کنن و میتونه به برای کارهایی که از نظر محاسباتی خیلی سنگینه استفاده بشه و در پسزمینه اجراشون بکنه.
|
||||
|
||||
**سِلِری** پشتیبانی برای زمانبندی داره و به صورت رسمی از پایتون پشتیبانی میکنه.
|
||||
|
||||
### Back pressure
|
||||
|
||||
اگر صف‌ها شروع به رشد زیادی بکنه، سایز صف میتونه از میزان حافظه بیشتر بشه، باعث بشه که داده‌ها توی کش پیدا نشن، باعث بشه خواندن از دیسک زیاد بشه و حتی کارایی رو کمتر میکنه. [بک-پِرِشِر](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) میتونه با محدودیت گذاشتن روی سایز صف، نرخ بازدهی بالا و زمان پاسخگویی مناسبی برای کارهایی که در داخل صف هستند رو باعث میشه. زمانی که صف پر میشه، کلاینت های جوابی مبنی بر این که سرور مشغوله یا کد اچ-تی-تی-پی ۵۰۳ میگیرن تا بعدا دوباره درخواست رو بفرستن و امتحان کنن. کلاینت ها میتونن درخواست رو بعدا تکرار کنه شاید با [بک-آف نمایی](https://en.wikipedia.org/wiki/Exponential_backoff) .
|
||||
اگر صف‌ها شروع به رشد زیادی بکنه، سایز صف میتونه از میزان حافظه بیشتر بشه، باعث بشه که داده‌ها توی کش پیدا نشن، باعث بشه خواندن از دیسک زیاد بشه و حتی کارایی رو کمتر میکنه. [بک-پِرِشِر](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) میتونه با محدودیت گذاشتن روی سایز صف، نرخ بازدهی بالا و زمان پاسخگویی مناسبی برای کارهایی که در داخل صف هستند رو باعث بشه. زمانی که صف پر میشه، کلاینت های جوابی مبنی بر این که سرور مشغوله یا کد اچ-تی-تی-پی ۵۰۳ میگیرن تا بعدا دوباره درخواست رو بفرستن و امتحان کنن. کلاینت ها میتونن درخواست رو بعدا تکرار کنن، شاید با یک [بک-آف نمایی](https://en.wikipedia.org/wiki/Exponential_backoff) .
|
||||
|
||||
### معایب ناهمگام
|
||||
### معایب : asynchronism
|
||||
|
||||
* کاربردهایی که نیاز به محاسبات سنگین و جریان کاری بلادرنگ نداره بهتره تا از مدل‌های اجرایی همگام استفاده کنه چون که استفاده از صف باعث میشه که پیچیدگی و تاخیر زیاد بشه.
|
||||
|
||||
|
|
@ -1470,7 +1484,7 @@ def set_user(user_id, values):
|
|||
|
||||
### Hypertext transfer protocol (HTTP)
|
||||
|
||||
اچ-تی-تی-پی یک روش برای کدگذاری داده برای انتقال داده بین کلاینت و سرور است. این متد یک پروتکل درخواست/پاسخ هست، یعنی: کلاینت ها درخواستشون رو میفرستند و سرورها جواب‌هاشونو با محتوا و استاتوس، که وضعیت کامل شدن درخواست هست، رو به اونها میدن. اچ-تی-تی-پی خود-شامل هست یعنی اینکه اجازه میده که درخواستها و پاسخها از روترهای میانی مسیر و سروهای سرراه بگذره درحالی که این لایه‌های میانی باعث میشن که لودبالانسینگ، کش کردن، رمزنگاری، و فشرده سازی اتفاق بیوفته.
|
||||
اچ-تی-تی-پی یک روش برای کدگذاری داده برای انتقال داده بین کلاینت و سرور است. این متد یک پروتکل درخواست/پاسخ هست، یعنی: کلاینت ها درخواستشون رو میفرستند و سرورها جواب‌هاشونو با محتوا و استاتوس، که وضعیت کامل شدن درخواست هست، به اونها میدن. اچ-تی-تی-پی خود-شامل هست یعنی اینکه اجازه میده که درخواستها و پاسخها از روترهای میانی مسیر و سروهای سرراه بگذره درحالی که این لایه‌های میانی باعث میشن که لودبالانسینگ، کش کردن، رمزنگاری، و فشرده سازی اتفاق بیوفته.
|
||||
|
||||
یک درخواست ساده اچ-تی-تی-پی شامل یک فعل(متد) و یک ریسورس یا منبع(اِند-پوینت) هست. در ادامه افعال رایج در اچ-تی-تی-پی آورده شده:
|
||||
|
||||
|
|
@ -1490,7 +1504,7 @@ def set_user(user_id, values):
|
|||
|
||||
> TCP: تی-سی-پی, UDP: یو-دی-پی
|
||||
|
||||
#### منابع برای مطالعه بیشتر
|
||||
#### منابع برای مطالعه بیشتر : HTTP
|
||||
|
||||
* [What is HTTP?](https://www.nginx.com/resources/glossary/http/)
|
||||
* [Difference between HTTP and TCP](https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol)
|
||||
|
|
@ -1504,20 +1518,20 @@ def set_user(user_id, values):
|
|||
<i><a href=http://www.wildbunny.co.uk/blog/2012/10/09/how-to-make-a-multi-player-game-part-1/>Source: How to make a multiplayer game</a></i>
|
||||
</p>
|
||||
|
||||
تی-سی-پی یک پروتکل ارتباط-محور روی یک [شبکه آی-پی](https://en.wikipedia.org/wiki/Internet_Protocol) هست. ایجاد و خاتمه یک کانکشن با استفاده از یک [هندشِیک](https://en.wikipedia.org/wiki/Handshaking) انجام میشه. تمام پکت‌هایی که ارسال میشن تضمین میشن که به ترتیب به مقصد برسه و بدون اختلال از طریق موارد زیر:
|
||||
تی-سی-پی یک پروتکل ارتباط-محور روی یک [شبکه آی-پی](https://en.wikipedia.org/wiki/Internet_Protocol) هست. ایجاد و خاتمه یک کانکشن با استفاده از یک [هندشِیک](https://en.wikipedia.org/wiki/Handshaking) انجام میشه. تمام پکت‌هایی که ارسال میشن تضمین میشن که به ترتیب و بدون اختلال به مقصد برسه و از طریق موارد زیر:
|
||||
|
||||
* شماره سیکوئنس و [فیلدهای چِک-سام](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation) برای هر پکِت
|
||||
* پکِت‌های [تایید](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks)) و دوباره ارسال‌هایی که به صورت خودکار انجام میشن.
|
||||
|
||||
اگر ارسال کننده یک پاسخ درست دریافت نکند، دوباره پکِت‌ها را میفرستد. اگر تعداد متعددی تایم-اُوت اتفاق بویفتد، کانکشن قطع میشه. تی-سی-پی [کنترل جریان](https://en.wikipedia.org/wiki/Flow_control_(data)) و [کنترل ازدحام](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control) اجرا میکنه. این تضمین‌ها باعث میشه تا تاخیر به وجود بیاد و به طور کلی باعث بشه تا نسبت به انتقال به روش یو-دی-پی کمتر بهینه باشه.
|
||||
اگر ارسال کننده پاسخ درست دریافت نکند، دوباره پکِت‌ها را میفرستد. اگر تعداد متعددی تایم-اُوت اتفاق بویفته، کانکشن قطع میشه. تی-سی-پی [کنترل جریان](https://en.wikipedia.org/wiki/Flow_control_(data)) و [کنترل ازدحام](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control) رو اجرا میکنه. این تضمین‌ها باعث میشه تا تاخیر به وجود بیاد و به طور کلی باعث بشه تا نسبت به انتقال به روش یو-دی-پی، کمتر بهینه باشه.
|
||||
|
||||
برای اطمینان از نرخ بازدهی بالا، وب سرورها تعداد زیادی کانکشن تی-سی-پی رو باز نگه میدارن، که این باعث میشه تا میزان مصرف حافظه زیاد بشه. تعداد کانکشن باز زیاد بین تِرِدهای یک وب سرور و به عنوان مثال یک سرور [مِم-کش-دی](#memcached) میتونه پرهزینه باشه. [کانکشن پولینگ](https://en.wikipedia.org/wiki/Connection_pool) میتونه زمانیکه امکانش هست به یو-دی-پی سويیچ انجام بشه.
|
||||
برای اطمینان از نرخ بازدهی بالا، وب سرورها تعداد زیادی کانکشن تی-سی-پی رو باز نگه میدارن، که این باعث میشه تا میزان مصرف حافظه زیاد بشه. تعداد کانکشن بازِ زیاد بین تِرِدهای یک وب سرور و به عنوان مثال یک سرور [مِم-کش-دی](#memcached) میتونه پرهزینه باشه. [کانکشن پولینگ](https://en.wikipedia.org/wiki/Connection_pool) میتونه زمانیکه امکانش هست به یو-دی-پی سويیچ انجام بده.
|
||||
|
||||
تی-سی-پی برای کارهایی که نیاز به اطمینان بالایی هست و از نظر زمانی حساس نیست مناسبه. بعضی مثال‌هاش شمال وب سرورها، اطلاعات پایگاه داده، اِس-اِم-تی-پی، اِف-تی-پی، و اِس-اِس-اِچ هست.
|
||||
تی-سی-پی برای کارهایی که نیاز به اطمینان بالایی هست و از نظر زمانی حساس نیست مناسبه. بعضی مثال‌هاش شامل وب سرورها، اطلاعات پایگاه داده، اِس-اِم-تی-پی، اِف-تی-پی، و اِس-اِس-اِچ هست.
|
||||
|
||||
> SMTP: اِس-اِم-تی-پی ,FTP: اِف-تی-پی, SSH: اِس-اِس-اِچ
|
||||
|
||||
زمان‌هایی تی-سی-پی باید به جای یو-دی-پی استفاده بشه:
|
||||
زمان‌هایی که تی-سی-پی باید به جای یو-دی-پی استفاده بشه:
|
||||
|
||||
* قصد دارید که داده‌ها دست نخورده برسن
|
||||
* قصد بهترین تخمین از بازدهی شبکه را داشته باشید
|
||||
|
|
@ -1534,9 +1548,9 @@ def set_user(user_id, values):
|
|||
|
||||
یو-دی-پی کانکشن-لِس هست. دیتاگرام‌ها(مشابه پکِت‌ها) فقط در سطح دیتاگرام تضمین میشن. دیتا گرام‌ها ممکنه که خارج از ترتیبشون به مقصد برسن یا کلا نرسن. یو-دی-پی از کنترل ازدحام پشتیبانی نمیکنه. مستقل از تضمین‌هایی که تی-سی-پی پشتیبانی میکنه، یو-دی-پی به طور کلی بهینه‌تر هست.
|
||||
|
||||
یو-دی-پی میتونه برادکست کنه، دیتا گرام‌ها رو به تمام دیوایس‌ها روی سابنت بفرسته. این امکان برای [دی-اِچ-سی-پی]() خوبه چرا که کلاینت هنوز آدرس آی-پی نگرفتن، بنابراین یک راه برای جلوگیری از این که تی-سی-پی بدون آدرس آی-پی شروع به ارسال کنه هست.
|
||||
یو-دی-پی میتونه برادکست کنه، دیتا گرام‌ها رو به تمام دیوایس‌های روی سابنت بفرسته. این امکان برای [دی-اِچ-سی-پی]() خوبه چرا که کلاینت هنوز آدرس آی-پی نگرفته، بنابراین یک راه برای جلوگیری کردن از اینه که تی-سی-پی بدون آدرس آی-پی شروع به ارسال کنه.
|
||||
|
||||
یو-دی-پی کمتر قابل اطمینان هست ما برای مواردی که نیاز بلادرنگ دارند مثل وُیپ، چت تصویری، استریم کردن، و بازی‌های بلادرنگ چند نفره به خوبی عمل میکنه.
|
||||
یو-دی-پی کمتر قابل اطمینانه ما برای مواردی که نیاز بلادرنگ دارند مثل وُیپ، چت تصویری، استریم کردن، و بازی‌های بلادرنگ چند نفره به خوبی عمل میکنه.
|
||||
|
||||
> VoIP: وُیپ, Streaming: استریم کردن , Realtime: بلادرنگ
|
||||
|
||||
|
|
@ -1546,7 +1560,7 @@ def set_user(user_id, values):
|
|||
* دیر رسیدن دیتا از گم شدنش خیلی بدتره
|
||||
* میخواید اصلاح خطای خودتون رو پیاده سازی کنید
|
||||
|
||||
#### منابع بیشتر برای مطالعه تی-سی-پی و یو-دی-پی
|
||||
#### منابع بیشتر برای مطالعه : TCP و UDP
|
||||
|
||||
* [Networking for game programming](http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/)
|
||||
* [Key differences between TCP and UDP protocols](http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/)
|
||||
|
|
@ -1588,7 +1602,7 @@ POST /anotheroperation
|
|||
}
|
||||
```
|
||||
|
||||
تمرکز آر-پی-سی روی بیان رفتارهاست. آر-پی-سی‌ها معمولا برای دلایلی مثل کارایی برای ارتباطات داخلی استفاده میشند، همینطور که شما میتونید از فراخوانی‌های نِیتیو که انجام میدید و مناسب کاربردتون هست استفاده کنید.
|
||||
تمرکز آر-پی-سی روی بیان رفتارهاست. آر-پی-سی‌ها معمولا برای دلایلی مثل کارایی برای ارتباطات داخلی استفاده میشن، همینطور شما میتونید از فراخوانی‌های نِیتیو که انجام میدید و مناسب کاربردتون هست استفاده کنید.
|
||||
|
||||
> Native Calls: , Internal Communication: ارتباطات داخلی
|
||||
|
||||
|
|
@ -1601,7 +1615,7 @@ POST /anotheroperation
|
|||
|
||||
اِی-پی-آی‌های اچ-تی-تی-پی که از **رِست** پیروی میکنن بیشتر برای اِی-پی-آی‌های عمومی مورد استفاده قرار میگیرن.
|
||||
|
||||
#### معایب RPC
|
||||
#### معایب: RPC
|
||||
|
||||
* کلاینت‌های آر-پی-سی خیلی وابسته میشن به پیاده سازی سرویس‌ها
|
||||
|
||||
|
|
@ -1609,13 +1623,12 @@ POST /anotheroperation
|
|||
|
||||
* دیباگ کردن آر-پی-سی میتونه دشوار باشه
|
||||
|
||||
* ممکنه شما نتونید از تکنولوژی‌هایی که درحال حاضر هستند استفاده کنید. برای مثال، ممکنه نیاز باشه تا تلاش بیشتری بکنید تا مطمئن بشد که [فراخوانی‌های آر-پی-سی به درستی کش شدن](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) روی سرورهای کش مثل [اِس-کویید](http://www.squid-cache.org/)
|
||||
* ممکنه شما نتونید از تکنولوژی‌هایی که درحال حاضر هستند استفاده کنید. برای مثال، ممکنه نیاز باشه تا تلاش بیشتری بکنید تا مطمئن بشید که [فراخوانی‌های آر-پی-سی به درستی کش شدن](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) روی سرورهای کش، مثل [اِس-کویید](http://www.squid-cache.org/)
|
||||
|
||||
|
||||
|
||||
### Representational state transfer (REST)
|
||||
|
||||
رِست یک نوع استایل معماری هست که مدل کلاینت/سرور رو ایجاب میکنه جایی که کلاینت‌ها روی یک سری ریسورس که سرور مدیرتش میکنه قراره کاری انجام بدن. سرور یک نمایشی از ریسورس‌ها رو ارائه میکنه و همچنین عملکرد‌هایی که میتونه هم تغییر ایجاد کنه یا یک نمایش جدیدی از ریسورس رو بده. تمام ارتباطات باید بدون حالت و قابل کش کردن باشه.
|
||||
رِست یک نوع استایل معماری هست که در جایی که کلاینت‌ها روی یک سری ریسورس که سرور مدیرتش میکنه قراره کاری انجام بدن، مدل کلاینت/سرور رو ایجاب میکنه . سرور یک نمایشی از ریسورس‌ها رو ارائه میکنه و همچنین عملکرد‌هایی که میتونه هم تغییر ایجاد کنه یا یک نمایش جدیدی از ریسورس رو بده. تمام ارتباطات باید بدون حالت و قابل کش کردن باشه.
|
||||
|
||||
چهار کیفیت از یک واسط رِست-فول وجود داره:
|
||||
|
||||
|
|
@ -1635,17 +1648,17 @@ PUT /someresources/anId
|
|||
{"anotherdata": "another value"}
|
||||
```
|
||||
|
||||
رِست تمرکزش روی نمایش داده است. این معماری وابستگی بین کلاینت/سرور رو کم میکنه و معمولا برای اِی-پی-آی‌های اچ-تی-تی-پی عمومی مورد استفاده قرار میگیره. رِست یه روش کلی‌تری و یکدست‌تری برای به نمایش گذاشتن ریسورس‌ها استفاده میکنه که از طریق یو-آر-آی، [نمایش از طریق هِدِرها](https://github.com/for-GET/know-your-http-well/blob/master/headers.md) ، و اکشن‌ها که به واسطه فعل‌هایی مثل گِت، پُست، پوت، دیلیت و پَچ است. با توجه به این که فاقد حالت هست، رِست برای اسکیل کردن افقی و پاتیشن‌بندی خیلی مناسبه.
|
||||
رِست تمرکزش روی نمایش داده است. این معماری وابستگی بین کلاینت/سرور رو کم میکنه و معمولا برای اِی-پی-آی‌های اچ-تی-تی-پی عمومی مورد استفاده قرار میگیره. رِست یه روش کلی‌تری و یکدست‌تری برای به نمایش گذاشتن ریسورس‌ها استفاده میکنه، که از طریق یو-آر-آی، [نمایش از طریق هِدِرها](https://github.com/for-GET/know-your-http-well/blob/master/headers.md) ، و اکشن‌ها که به واسطه فعل‌هایی مثل گِت، پُست، پوت، دیلیت و پَچ است. با توجه به این که فاقد حالته، رِست برای اسکیل کردن افقی و پاتیشن‌بندی خیلی مناسبه.
|
||||
|
||||
> GET: گِت, POST: پُست , PUT: پوت , DELETE: دیلیت , PATCH: پَچ
|
||||
> Stateless: فاقد حالت
|
||||
|
||||
#### معایب REST
|
||||
#### معایب : REST
|
||||
|
||||
* باتوحه به این که تمرکز رِست روی به نمایش گذاشتن داده‌هاس، برای ریسورس‌هایی که به صورت معمولی و سلسله مراتبی مدیرت میشن مناسب نیست. برای مثال، برگردوندن لیست آپدیت‌های رکوردها توی رنج ۱ ساعت پیش که با یک سری رخ‌دادهای خاص مِچ شده باشه چیزی نیست که بشه به صورت مسیر اونو به راحتی نشون داد. در صورت استفاده از رِست،باید این کار به وسیله ترکیبی از یو-آر-آی‌ها، کوئری پارامتر‌ها و احتمالا با یک ریکوست بادی پیاده سازی بشه.
|
||||
* رِست معمولا روی چندتا فعل محدود(گِت، پُست، پوت، دیلیت و پَچ) تمرکز داره که بعضی وقتا برای کاربرد شما مناسب نیست. برای مثال، انتقال مستنداتی که دیگه منتقضی شدن به فولدری آرشیو ممکنه که خیلی تر و تمیز با این فعل‌ها نشه بیانش کرد.
|
||||
* گرفتن ریسورس های پیچیده با ساختار سلسله مراتبی تودرتو احتیاج داره که تعداد رفت و برگشت زیاده رو بین کلاینت و سرور شاهد باشیم تا سرور یک صفحه تنها رو نمایش بده به عنوان مثال، گرفتن محتوای یک پست از بلاگ و کامنت هایی که روی اونه. برای برنامه های موبایل در شرایطی که باید بین شبکه‌های مختلفی کار کنند این رفت و برگشت ها خیلی مورد علاقه نیست.
|
||||
* به مرورزمان، تعداد فیلدهای بیشتری ممکنه که به پاسخ اِی-پی-آی اضافه بشه و کلاینت‌های قدیمی فیلدهای جدید رو هم میگیرن حتی اون دسته از فیلدهایی که بدردشون نمیخوره که این باعث میشه سایز پی-لود زیاد بشه و این خودش یعنی افزایش تاخیر.
|
||||
* باتوحه به این که تمرکز رِست روی به نمایش گذاشتن داده‌هاس، برای ریسورس‌هایی که به صورت معمولی و سلسله مراتبی مدیرت میشن مناسب نیست. برای مثال، برگردوندن لیست آپدیت‌های رکوردها توی رنج ۱ ساعت پیش که با یک سری رخ‌دادهای خاص مَچ شده باشه چیزی نیست که بشه به صورت مسیر، توی یو-آر-اِل اچ-تی-تی-پی، اونو به راحتی نشون داد. در صورت استفاده از رِست،باید این کار به وسیله ترکیبی از یو-آر-آی‌ها، کوئری پارامتر‌ها و احتمالا با یک ریکوست بادی پیاده سازی بشه.
|
||||
* رِست معمولا روی چندتا فعل محدود(گِت، پُست، پوت، دیلیت و پَچ) تمرکز داره که بعضی وقتا برای کاربرد شما مناسب نیست. برای مثال، انتقال مستنداتی که دیگه منتقضی شدن به فولدر آرشیو ممکنه که خیلی تر و تمیز با این فعل‌ها نشه بیانش کرد.
|
||||
* گرفتن ریسورس های پیچیده با ساختار سلسله مراتبی تودرتو احتیاج داره که تعداد رفت و برگشت زیاده رو بین کلاینت و سرور شاهد باشیم تا سرور فقط یک صفحه رو نمایش بده به عنوان مثال، گرفتن محتوای یک پست از بلاگ و کامنت هایی که روی اونه. برای برنامه های موبایل در شرایطی که باید بین شبکه‌های مختلفی کار کنند، این رفت و برگشت ها خیلی مورد علاقه نیست.
|
||||
* به مرورزمان، تعداد فیلدهای بیشتری ممکنه که به پاسخ اِی-پی-آی اضافه بشه و کلاینت‌های قدیمی فیلدهای جدید رو هم میگیرن حتی اون دسته از فیلدهایی که بدردشون نمیخوره که این باعث میشه سایز بدنه ارسالی زیاد بشه و این خودش یعنی افزایش تاخیر.
|
||||
|
||||
### مقایسه فراخوانی‌های آر-پی-سی و رِست
|
||||
|
||||
|
|
@ -1663,7 +1676,7 @@ PUT /someresources/anId
|
|||
<i><a href=https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/>Source: Do you really know why you prefer REST over RPC</a></i>
|
||||
</p>
|
||||
|
||||
#### منابع بیشتر برای مطالعه: آر-پی-سی و رِست
|
||||
#### منابع بیشتر برای مطالعه : RPC و REST
|
||||
|
||||
* [Do you really know why you prefer REST over RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/)
|
||||
* [When are RPC-ish approaches more appropriate than REST?](http://programmers.stackexchange.com/a/181186)
|
||||
|
|
@ -1676,7 +1689,7 @@ PUT /someresources/anId
|
|||
|
||||
## امنیت
|
||||
|
||||
این قسمت ممکنه شامل یه سری به روز رسانی ها بشه. قسمت [همکاری](#contributing) بررسی کنید.
|
||||
این قسمت ممکنه شامل یه سری به روز رسانی ها بشه. قسمت [همکاری](#همکاری) رو بررسی کنید.
|
||||
|
||||
امنیت یک مبحث گسترده‌ای هست. احتمالا نیازی ندارید که بیشتر از مسايل پایه‌ای رو در مورد امنیت بدونید مگر اینکه تجربه‌ی خوبی در این زمینه یا پیش‌زمینه امنیت داشته باشید و یا قصد دارید که برای پوزیشنی که نیاز به دانش امینت داره برید:
|
||||
|
||||
|
|
@ -1692,7 +1705,7 @@ PUT /someresources/anId
|
|||
|
||||
## پیوست
|
||||
|
||||
بعضا از شما میخوان که یه سری محاسبات سریعی رو انجام بدید. برای مثال ممکنه نیاز داشته داشته بدونید که چقدر زمان نیازه تا ۱۰۰ تصویر ثامب-نِیل از روی دیسک تولید بشه یا اینکه چقدر حافظه یک ساختمان داده خاص نیاز داره. **جدول اعداد توان ۲** و **اعداد تاخیری که هر برنامه نویسی باید بدونه** یه منبع مناسب هست برای این کار.
|
||||
ممکنه از شما بخوان که یه سری محاسبات سریعی رو انجام بدید. برای مثال ممکنه نیاز داشته داشته بدونید که چقدر زمان نیازه تا ۱۰۰ تصویر ثامب-نِیل از روی دیسک تولید بشه یا اینکه چقدر حافظه یک ساختمان داده خاص نیاز داره. **جدول اعداد توان ۲** و **اعداد تاخیری که هر برنامه نویسی باید بدونه** یه منبع مناسب هست برای این کار.
|
||||
|
||||
### جدول اعداد توان ۲
|
||||
|
||||
|
|
@ -1794,7 +1807,7 @@ Notes
|
|||
|
||||
### معماری های دنیای واقعی
|
||||
|
||||
> مقاله‌هایی در مورد اینکه سیستمهای دنیای واقعی به صورتی طراحی شده‌اند
|
||||
> مقاله‌هایی در مورد اینکه سیستمهای دنیای واقعی به چه‌صورتی طراحی شده‌اند
|
||||
|
||||
<p align="center">
|
||||
<img src="http://i.imgur.com/TcUo2fw.png">
|
||||
|
|
|
|||
Loading…
Reference in New Issue