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

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

ولی خب کلی منابع دیگه هم وجود داره.

آموزش های
Neetcode - System Design for Beginners
Neetcode - System Design Interview
رو چند وقتی هست که تموم کردم. و باید بگم که از آموزش هایی بود، که دیدم رو از سیستم های توزیع شده عوض کرد.

تا حالا فکر کردید که یوتیوب، ایکس (توییتر سابق 😂)، دیسکورد و سرویس های عظیم دیگه چطوری به این همه کاربر در سراسر جهان سرویس دهی میکنن.

پشت اینا مهندسی های پیچیده وجود داره که نیاز نیست همش رو بدونید.
اما باید یه تصویر کامل از نحوه برخورد و دیزاین چنین سیستم هایی داشته باشید (اگر میخواید شرکت خفنی استخدام بشید یا پروژه های بزرگی رو انجام بدید)

به این میگن System Design. و یکی از بخش های خیلی مهم ساخت یک سیستم هست.
چون اگر در طراحی چنین سیستم ها اشتباه کنید جبرانش بسیار سخت و پرهزینه هست.
اما باگ ها و کدنویسی رو میشه درست کرد.

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

لینک تورنت تمام آموزش ها داخل کانال پین شده هست.
فقط سرچ کنید چون فایل یا لینک تورنته شامل آموزش های Algoexpert و همینطور ساحتمان داده و طراحی الگوریتم هست (که من آموزش دیگه ای رو برای اون موضوع دنبال کردم).

در ضمن یه ویدیو آخر System Design for Beginners داره به اسم MapReduce که نتونستم از اینترنت پیدا کنم.

مباحثی که تو بخش اول کاور میشه:
Neetcode - System Design for Beginners

1. معماری کامپیوتر (Computer Architecture)
ساختمان کامپیوتر نمونه کوچکی از سیستم های توزیع شده هست. و تو این بخش به بررسی سرعت هر کدوم از این قطعه ها میپردازیم.

2. معماری برنامه (Application Architecture):
اینجا پروسه از توسعه تا استفاده و کاربرد برنامه توضیح داده میشه.
هر برنامه بزرگی شامل بخش های مختلفی میتونه باشه از جمله Load Balancer, Database, Servers, Metrics, Message Queue, Logging و ...

3. نیاز های طراحی (Design Requirements):
این یکی از مهم ترین بخش های طراحی سیستم هست.
اینکه پایداری (Availability) سیستم ما چقدر هست.
چقدر تحمل خطا (Fault Tolerance) داره.
دیتابیس یا سرور های ما چقدر توان عملیاتی (Throughput) دارند.
و تاخیر (Latency) ما چقدر هست.

4. اصول اولیه شبکه (Networking Basics):
عمیق راجب شبکه بحث نمیشه ولی یک سری اصول هایی که برای طراحی سیستم باید بدونیم بحث میشه.
راجب IP و Header ها و پروتکل های TCP و UDP و پورت ها و ... صحبت میشه.

5. پروتکل های لایه انتقال (TCP and UDP):
اینجا هم راجب دو پروتکل معروف TCP و UDP به طور مختصر صحبت میشه.

6. دی ان اس (Domain Name System):
وقتی که میخوایم وارد سایت بشیم چه اتفاقی میفته که از URL میرسیم به یه سرور.

7. پروتکل های برنامه بخش اول:
راجب RPC و اینکه چی هست صحبت میشه.
راجب HTTP و اینکه درخواست های ما در این لایه به چه صورت هستن و کد های برگشتی که باید بدونیم صحبت میشه.
همینطور اشاره ای هم به WebSockets و SSL میشه.
کلا این بخش بیس و پایه برای کار با API ها هست.

8. پروتکل های برنامه بخش دوم:
خب بخش باحال از اینجا شروع میشه.
اینجا بیشتر راجب WebSockets و اینکه چرا به وجود اومد صحبت میشه.
باید بدونید که همین چت Twitch از این پروتکل در حال حاظر استفاده میکنه.
به پروتکل های دیگه هم مختصر اشاره میشه.

9. پارادایم API ها:
با سه نوع REST, GraphQL و gRPC آشنا میشید که هر کدومشون مزایا و معایب خودشون رو دارن و یاد میگیرید که کجا استفاده کنید.

10. طراحی API:
چطوری یک API رو طراحی میکنن و مثال هایی از Twitter زده میشه که API اش چطوری هست.

11. ذخیره موقت (Caching):
بخش مورد علاقه خودم. با انواع cache آشنا میشید مثل Redis یا حتی خود مرورگرتون.
الگوریتم های cache مثل write-back, write-around, write-through.
همینطور الگوریتم های اخراج مثل LRU, LFU.

12. سرویس های CDN:
یکی از کار هایی که میتونیم انجام بدیم تا بار رو از روی سرورامون برداریم اینه که از CDN استفاده کنیم.
اینطوری از هر نقطه جهان که باشیم به محتوا ها میتونیم سریع دسترسی پیدا کنیم.
همینطور با انواع مختلف CDN یعنی push و pull آشنا میشید.

13. پروکسی ها و Load Balancer:
با انوع پروکسی ها که شامل Forward و Reverse هستن آشنا میشید.
همینطور Load Balancer و انواع الگوریتم های بالانس لود رو یاد میگیرید.

14. هش های مداوم (Consistent Hashing):
یکی از مشکلات Load Balancing دقیقا همین هست که بهش برمیخورید و یاد میگیرید که این مفهوم چطوری تو مثال Load Balancing پیاده میشه.
فقط برای سرور نیست، بلکه برای cache و دیتابیس ها و حتی CDN ها استفاده میشه.

15. دیتابیس SQL:
هیچ آموزش سیستم دیزاین بدون SQL معنا نداره.
راجب نحوه کارکرد SQL یاد میگیرید و مزایا و معایبی که داره.
که از مهم ترین معایبش scale هست. یعنی برای دیتابیس های عظیم دست مارو میبنده.
همینطور راجب قاعده ACID که دقیقا مزایای SQL رو توضیح میده آشنا میشید.

16. دیتابیس NoSQL:
دیتابیس هایی که SQL نیستن. که انواع زیادی دارن.
از جمله
key-value store
document store
wide column
graph db
و مزایا و معایبش رو یاد میگیرید و تفاوتش رو با SQL بهتر متوجه میشید.

17. تکثیر یا تقسیم دیتابیس (Replication and Sharding):
اینجاست که سیستم دیزاین خیلی خودش رو نشون میده.
تو این بخش با این دو قاعده آشنا میشید. انواع تکثیر دیتابیس رو یاد میگیرید.
و همینطور تقسیم دیتابیس و چرا SQL برای اینکار مناسب نیست و NoSQL مناسبه.
بحث consistent hashing هم اینجا بدرد میخوره.

18. تئوری CAP:
اینکه دیتابیس ها وقتی توزیع میشن روی چند کامپیوتر چالش هایی برای ثبات دیتا و همگام سازی دیتابیس ها پیش میاد.

19. ذخیره اطلاعات باینری (Object Storage):
اطلاعات باینری نباید تو دیتابیس ذخیره بشن چون سرعت دسترسی رو کاهش میدن.
سر همین باید از Object Storage استفاده کنیم.

20. صف پیام (Message Queue):
وقتی که عملیاتی قرار نیست همون موقع انجام بشه و جواب به کاربر برگردونده بشه.
یعنی عملیات زمانبر هست و در پیش زمینه اجرا میشه نیاز به Message Queue داریم.

حالا یه سوال مهم پیش میاد.
آیا نیازه که سیستم دیزاین یاد بگیرم؟

اگر شرکت های بزرگی قراره مصاحبه انجام بدید یا پروژه کلانی انجام بدید یا حتی ریموت کار کنید (البته نه همه ریموت کاری ها بلکه بخشی از اونها، بستگی به job denoscription داره).

همینطور تو شرکت های FAANG (Facebook, Amazon, Apple, Neflix, Google) که قطعا چنین نیازمندی رو دارن و یه سری شرکت های خفن دیگه.

ولی خب واسه جایی جز این فکر نکنم نیاز پیدا کنید.

ولی خب یاد بگیرید که به بلایایی مثل سامانه آموزشیار دانشگاه آزاد دچار نشیم.

فارغ از اینکه فرانت کارید، بک اند کارید یا حتی هوش مصنوعی کار میکنید.
این دانش بدردتون میخوره و توصیه میشه.

یه سریا مثل من با همین بهونه و حتی علاقه شخصی یادش گرفتن.

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

یک کامنتی برای این پست خواستم بگذارم که مسائل رو شفاف تر کنم.

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

یکی عمودی (Vertical) که تو این نوع شما سخت افزار رو قوی میکنید که کاهش بازده داره نسبت به قیمتی که باید صرف کنید.
و قطعا به یه جایی میرسید که دیگه سخت افزار قوی تری نمیتونید بگیرید.

نوع دوم افقی (Horizontal) که شما میاید و به چند ها سرور تقسیم میکنید. هر سروری یک مسئولیت داره.
حتی در مواردی دیتابیس رو هم روی یک سری سرور ها تکثیر میکنید یا حتی اگر خیلی دیتا سنگین بشه تقسیم کنید.

دید و تئوری کلی مبحث System Design همینه.
کلی جزییات هم داره که در سطوح back-end قطعا باید اطلاع داشته باشن ولی فرانت اند کار صرفا باید بینشش رو داشته باشه و همین کافیه.

در بخش 15 و 16 که از SQL و NoSQL صحبت میشه.
دوستان فکر نکنن که SQL قدیمی شده. درسته که scale کردن سیستم ها با SQL خیلی سخت هست.
ولی زمانی که سیستم ما نیاز به کل ساختار ACID داشته باشه خیلی SQL حیاتیه.

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

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

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

جدا از اون تو بخش 19 که راجب Object Storage صحبت میشه.
منظور از دیتا باینری همون عکس، فیلم و هر چیزی که نوشتاری نباشه هست.
البته که واسه استفاده های ساده همون داخل دیسک ذخیره کنید و آدرس رو فقط داخل دیتابیس ذخیره داشته باشید کافیه.
(البته باز این موضوع باز قابل بحث هست و راه حل های بهتری هم میتونه وجود داشته باشه)

سرویس های Object Storage مثل Amazon S3 و Google Cloud Storage هستن.
که قطعا هزینه هنگفتی دارن و واسه استفاده های بزرگ طراحی شدن. (حالا پروسه خریدش بماند)
تو ایران هم یه چند تایی داریم که یکیشون احتمالا خودتون میدونید. :)

راه حل های اوپن سورس و self-hosted هم داریم.
اما هیچ کدوم رو امتحان نکردم.

خیلی وقته که دیگه فرانت اند یا بک اند کار خام معنا نداره.

الان باید یا باید فرانت اند کار باشی گه راجب بک اند هم به مقدار خوبی میدونه.
یا بک اند کار که راجب فرانت اند به مقدار خوبی میدونه.

ویدیو آخر آموزش System Design for Beginners که اسمش MapReduce بود رو پیدا کردم و تو کانال پین شده قرار دادم.

Have fun ;)

خب بیاید راجب ACID صحبت کنیم.
این مفهوم پایه همه دیتابیس های رابطه ای یا همون SQL هست.

1. همه چی یا هیچ چیز (Atomicity):
هر تراکنش یا کامل میشه و ثبت میشه یا اصلا کامل نمیشه.
اگر وسط تراکنش برق بره هیچ دیتایی تغییر نکرده.
منطور از تراکنش هر موقعی هست که شما commit رو میزنید.
اگر کامیت نکنید در واقع چیزی ثبت نشده.
ممکنه یک تراکنش حاوی چند دستور SQL باشه.

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

اطلاعات بیشتر

2. ثبات دیتا (Consistency):
تمام قید و شروط جدول ها از جمله کلید های خارجی و ... برای هر تراکنش بررسی میشن.
برای بعضی از سیستم ها این خیلی اهمیت داره. (شما موجودی منفی بانک رو دوست ندارید قطعا)
تو NoSQL کلید خارجی نداریم ولی جایگزین هایی وجود دارن (ریفرنس).
حتی قید هایی هم برای دیتا ها داخل NoSQL وجود داره اما کمتر از SQL هست.

اطلاعات بیشتر

3. جدایی تراکنش ها (Isolation):
اگر با multi threading آشنا هستید احتمالا میدونید که منظورم چیه.
یعنی قابلیت پردازش همزمان تراکنش ها بدون اینکه یک تراکنشی تراکنش دیگه رو تحت تاثیر قرار بده.
تو multi threading شما از Mutex یا Semaphore استفاده میکنید.
داخل دیتابیس از Lock (Shared, Exclusive) استفاده میکنید.
هر بار که سطری میخواد تغییر کنه قفل میشه.
بعد از انجام شدن باز میشه تا در صورت نیاز تغییرات دیگه اعمال بشه.
از اونجایی که تراکنش ها تو صف هستن سر همین هر وقت که سطری آزاد بود اعمال میشن.

اطلاعات بیشتر

4. ماندگاری (Durability):
تراکنش های ذخیره شده برای همیشه در حافظه سخت میمونن و با قطع برق از بین نمیرن.
ولی خب وقتی یک صف از تراکنش باشه که در انتظار پردازش باشه قطعا باید مکانی برای ذخیره سریع این تراکنش ها باشه که از بین نرن.

بله. به بحث logging خوش اومدید.
یه چیزی داخل دیتابیس ها داریم به اسم Fast Transaction Log که تراکنش هارو به سرعت بالایی ذخیره میکنه (چون append-only هست. سر همین زیاد دیسک درگیر نمیشه).

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

اطلاعات بیشتر

خب دوستان گفتم یه خبری بدم که چه میگذره.

دارم دوره PySide6 میبینم.
کتابخونه گرافیکی هست که یه wrapper (یا لایه ارتباط) برای Qt به زبان پایتون عه.
و تمام قابلیت های Qt رو داره و از شرکت Qt توزیع شده.
اینو اختصاصی برای کارایه خودم دارم میبینم و چیزی نیست که بخواید سمتش برید و یاد بگیرید.
خیلی هم نمونده که تموم بشه.
(دوره اش هم خیلی عمیق نیست و کیفیت عالی نداره ولی کارو جواب میده و نسخه کوچک ترش هم تو freecodecamp هست)

و اما بخش مهم:

جدا از اون دارم OOP Design Pattern هم یاد میگیرم.
اگر تو پروژه ای هستید که به شدت با شی گرایی سروکار دارید
(مثل من که با framework گرافیکی کار میکنم).
این دوره جزو دوره های مهمی محسوب میشه.

در غیر اینصورت سمتش نیاز نیست برید.
چون تو اولویت اول نیست.

در نهایت دوره ای که پلن دارم تو آینده نزدیک نگاه کنم PyTorch هست.

واستون لینک و فایل تورنت همشون رو داخل کانال پین شده گذاشتم.

سلام دوستان.

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

آموزش OOP Design Pattern neetcode و همینطور PySide6 تموم شدن و در حال حاظر مشغول دیدن آموزش PyTorch هستم.

ممنون که با من همراه هستید.

دو روز دیگه میخوام یه پست راجب دوره System Design Interviews بزارم (یادم نرفته بود، صرفا فرصت نشد).

همینطور یک نقد مثبتی از OOP و Design Pattern.

و در نهایت یه نقد منفی از OOP و تجربه های خودم در این زمینه.

خب. راجب Neetcode System Design Interview:

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

همه مصاحبه های سیستم دیزاین شامل چهار بخش میشن.

Background
پیش زمینه های مورد نیاز راجب سیستم رو توضیح میدید. اینکه چی هست، چه چیزی به کاربران ارائه میده.
البته تو ویدیو های NeetCode این بخش با Non-Functional Requirements ممکنه کمی قاطی بشه.

Functional Requirements
سیستمی که میخوایم طراحی کنیم چطور کار میکنه. فیچر هایی که سیستممون باید داشته باشه.
مثلا تو مثال توییتر مثل news feed یا like یا dislike. هر چیزی که مرتبط با کاربر هست.

Non-Functional Requirements
هر چیزی که Functional Requirements نیست. ولی خب دقیق تر بخوام بگم.
هر چیزی که مربوط به scalability هست. مثلا چقدر سرویس ما یوزر خواهد داشت. هم تو لانچ و همینطور در آینده (باید آینده نگر باشیم تا اگر نیاز شد مقیاس سیستم ما بالاتر بره بدون مشکل ارتقا رو انجام بدیم).
دیتابیس ما چقدر read یا write انجام میده و نسبتشون چقدره؟
چقدر فضای ذخیره سازی نیاز داریم؟ چقدر availability (دسترسی پذیری) میخوایم؟
سرویسمون چقدر تاخیرش باید پایین باشه.
نکته: معمولا تو محاسبات تخمین زده میشه. بنابراین لازم نیست دقیق بدست بیارید.

High Level Design
طولانی ترین بخش مصاحبه این بخش هست.
تو این بخش تمام اطلاعات قبل رو به کار میبندید تا یک دیزاین مناسب این سیستم ارائه بدید.
یادتون باشه که مصاحبه گر دنبال پاسخ خاصی نیست.
مصاحبه گر میخواد بدونه که شما توانایی تحلیل یک سیستم رو دارید؟

تو این مرحله از هر جایی که صلاح دیدید شروع میکنید.
یک شمای کلی از سیستم.
نه لازم نیست UML بکشید. صرفا واسه نشون دادن اینه که چه چیزایی میخواید تو سیستمتون بکار ببرید.

اول راجب سرور یا API سرور صحبت میکنید اگر بخش مهم یا اصلی سرویستون هست.
اینکه چه endpoint هایی رو برای اون بخشی که طراحی میکنید در نظر گرفتید. قاعدتا مصاحبه گر ازتون نمیخواد کل توییتر رو تویه 45 دقیقه طراحی کنید (اگر خواست یعنی مصاحبه گره مشکل داره).
معمولا یکی یا دو تا فیچر رو ازتون میخوان. سر همین هستش که حتما با پرسش مسئله رو شفاف تر کنید.

همینطور انتخاب دیتابیس هم مهم هست. SQL باشه یا NoSQL. حتی NoSQL ها هم با هم متفاوت ان. مثلا Cassandra دیتابیسی مخصوص سرعت write بالا هست (از اونجایی که از LSM-Tree و SSTables استفاده میکنه).

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

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

تو مثال هایی هم استفاده از WebSocket خیلی سرعت رو بالا میبره و تاخیر رو پایین میاره.
تو دیسکورد مثلا از WebSocket برای ارسال پیام و نوتیفیکیشن هاش استفاده میکنه.

یادتون باشه شما Domain Expert نیستید تو همه اینا.
قطعا از شما نمیخوان که از جزییات همه این بخش ها سر دربیارید.
شما فقط دارید سیستم طراحی میکنید.

حال راجب تک تک ویدیو هاش و نکات جالبش صحبت میکنم.

1. How to Approach:
تو ویدیو اولش راجب اینکه چطوری مصاحبه های سیستم دیزاین رو هندل باید بکنید صحبت میشه.
تو پست قبلی راجب این موضوع هم خودم صحبت کردم.

2. Design a Rate Limiter:
راجب دیزاین یک Rate Limiter صحبت میشه. در واقع Rate Limiter ای که دیزاین میشه جنریک هست. یعنی برای هر سیستمی با هر مقیاسی در نظر گرفته میشه.
و اینکه بله. Rate Limiter میتونه یه سیستم با چندین کامپیوتر باشه. برای منم جالب بود.

یک جایی Rule ها ذخیره میشن (دیتابیس). یک بخشی هم Memory Store (Cache) باشه.

همینطور الگوریتم های مختلفی که یک Rate Limiter میتونه داشته باشه مثل Fixed Window یا Sliding Window.

3. Design TinyUrl:
در نگاه اول فکر میکنید که دیزاین این موضوع خیلی خنده دار و ساده هست.
اما کامل در اشتباهید. وقتی که scale بالا بره هر چیز ساده ای تبدیل به چالش میشه ;)
تو این سرویس read به شدت بالا هست و سر همین دیتابیس کاملا درگیره. سر همین باید لینک هایی که آزاد برای استفاده هست رو یک جای دیگه ذخیره کنید و ...
تازه یه worker هم باید برای حذف لینک های منقضی شده هم باید گذاشت.

4. Design Twitter:
بخش Feed هر کسی میتونه با یه سرویس Message Queue ساخته شه که شامل Cluster هایی هستن که feed ما رو جنریت میکنن و داخل یه Cache بزرگ ذخیره میکنن.

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

جدا از اون دیتابیس توییتر جای NoSQL میتونه GraphDB باشه. البته که من شخصا راجب محدودیت های GraphDB اطلاعات ندارم ولی خب آپشنی هست که میتونه بررسی بشه.

5. Design Discord:
اینجاست که WebSocket میدرخشه و اینکه اونقدر نسبت write به read بالاست که حتی دیتابیس های NoSQL معمول هم جواب نمیدن.
باید سمت دیتابیس های مخصوص write بالا رفت. مثل Cassandra یا حتی ScyllaDB که سال پیش روی اون سویچ کردن.

البته که دیسکورد قبل از اینکه روی Cassandra سویچ کنه از MongoDB استفاده میکرد. بنابراین همون اول هم نیاز نیست مقیاس عظیم بسازید. اول زنده بمونید و راه رو برای مقیاس های بزرگ تر باز بزارید.

6. Design YouTube:
قاعدتا یوتیوب نیاز به Object Storage داره. در غیر اینصورت چطور میخواد این همه ویدیو سنگین رو ذخیره کنه؟
جدا از اون نیاز به یه لشکر worker عظیم و Message Queue داره که ویدیو ها رو انکود کنه و باز داخل Object Storage ذخیره کنه. و خود ویدیو های هم روی CDN باید باشن که دسترسی بهشون خیلی سریع باشه.

تو این سیستم از WebSocket استفاده نکردن و صرفا ویدیو ها رو قطعه قطعه میفرستن.

و راجب دیتابیس هم واقعا از NoSQL استفاده نمیکنن. بلکه از MySQL استفاده میکنن و شاید بپرسید چطور؟ با اون دیتای عظیمی که دارن دیتابیس رو چطوری shard میکنن؟
با استفاده از ابزار خودشون. و قبل از این هم منطق sharding رو روی بخش کد های سرورشون پیاده میکردن.

7. Design Google Drive
دو حالت واسه دیزاینمون داریم. یکیش Distributed File System و دیگری Object Storage.
با Distributed File System دیزاین خیلی پیچیده تر میشه و به اندازه Object Storage مقایس پذیری نداره.
ولی خب تو این آموزش چون بخش ادیت در نظر گرفته نشده سراغ Distributed File System نمیره. ولی خب خواستید بررسی کنید ابزار هایی مثل Apache Hadoop هست.
جدا از اون اگر بخوایم با Object Storage بریم باید دیتا رو بلوک بندی کنیم و همین به ما اجازه deduplication میده. یعنی میتونیم فایل های تکراری یا بخش های تکراری رو فقط یک بار ذخیره کنیم.
واسه حذف هم یه سرویس Garbage Collection میتونیم بزاریم که یه بار میگرده و بخش هایی که استفاده نمیشن رو حذف میکنه.

8. Google Maps:
اینجا متوجه میشید که چقدر domain knowledge مهم هست تو دیزاین سیستم ها.
الگوریتم های مسیریابی، نحوه ذخیره سازی نقشه ها. اطلاعاتی مرتبط با نقشه و ...
سرویس مسیریابی و مکان یابی جدا ان و بخش مکان یابی میتونه برای ارائه گزارشی از ترافیک های محل از یه Message Queue استفاده کنه و پردازش رو روی دیتا های محل کاربران انجام بده و داخل دیتابیسی به اسم ترافیک ذخیره کنه.

9. Design a Key-Value Store:
اینجا قشنگ با مفاهیم پیچیده بمبارون میشید.
به قولی ادامه مباحث NoSQL تو آموزش قبلی هست ولی در فرمت مصاحبه.

10. Distributed Message Queue:
یه Message Queue ساده که روی یک کامپیوتر پیاده میشه بلاخره محدودیت هایی داره.
ولی بیشتر وقتی معماری رو توزیع شده بسازیم میتونیم محدودیت ها رو دور بزنیم.

بخش Discussion اضافه شد.
Have fun ;) and behave

سلام دوستان.
چند وقت پیش میخواستم راجب OOP و Design Pattern و کلاً معایب و مزایای OOP پست بزارم.
ولی خب گفتم که شاید دوستان با مفاهیم درگیر و پیرامون OOP آشنایی کامل نداشته باشن.

همینطور بنده هم با وجود اینکه با این مفاهیم آشناییت دارم ولی توضیح دادن بدون پیش‌زمینه ای راجب مفاهیم OOP سخت هست.

از طرفی هم نمیتونم بگم که تجربه زیادی دارم حتی با وجود اینکه با Qt یا PySide6 و لایبرری های کاملا OOP محور کار کردم باز فکر میکنم خیلی جا برای یادگیری دارم.

سر همین تو پست بعدی اول به مفاهیم مهم دنیای OOP میپردازم مثل SOLID و همینطور OOP Design Pattern هایی که تو آموزش neetcode یاد گرفتم رو مختصرانه توضیح میدم و سپس نقد رو انجام میدم.

و حال در این مدت چه گذشت.

یادتون بود راجب آموزش PyTorch صحبت کرده بودم که استارتش رو زدم. تقریباً تا ½ اش رو تموم کردم. نزدیک 340 قسمت هست ولی خب بخوام نظرم رو راجب این دوره بگم. اگر میخواید سمت یادگیری عمیق برید. صد در صد اینو پیشنهاد میکنم.

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

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

جدا از اون یک آموزش گیت هم دیدم. از SuperSimpleDev.
نه اینکه گیت بلد نبودم (هر روز rebase و reflog انجام میدم از بس که خرابکاری میکنم و درست میکنم) ولی خب میخواستم که یه مروری بر مفاهیم اولیه بشه و از اونجایی که تو ویدیو سومش به feature branch workflow اشاره میشه سر همین گفتم حتماً ببینمش.

خیلیا git رو یاد میگیرن و ذهنیت گیت ندارن. همش داخل یه برنچ کامیت میکنن و نمیدونن چه وقتی باید برنچ بزنن.
همینطور رفع conflict های PR به صورت لوکال رو هم بخش خیلی جالبی بود که نمیدونستم ممکنه.
اگر گیت بلد نیستید این بهترین آموزش برای شروع هست.

خلاصه از git غفلت نکنید.

آموزش PyTorch تو کانال پین شده هست

از بدو شروع OOP همه در حال تئوری پردازی راجب نحوه کدنویسی بودن. اینکه چطوری کدی بنویسن که گیج‌کننده نباشه، تو آینده قابلیت انعطاف و گسترش داشته باشه و با مشکلات و باگ های کمتری مواجه بشه.

دلیلش هم این بود که OOP انعطاف بالایی تو طراحی و دیزاین سیستم‌ها میده و این انعطاف میتونه به ضرر افراد کم تجربه تموم بشه.

سر همین قواعدی به وجود اومد به اسم SOLID که کد های OOP باید رعایت کنند. و این قواعد تو بیشتر کد های OOP که امروزه میبینیم جا افتاده.

اسم SOLID کوتاه شده 5 قانون هست که به ترتیب:

1. Single Responsibility Principle
2. Open-Closed Principle
3. Liskov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

Uncle Bob’s SOLID Principles Made Easy 🍀 - In Python!

The SOLID Principles of Object-Oriented Programming Explained in Plain English

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

#OOP
#SOLID

1. Single Responsibility Principle:

هر کلاسی باید تنها یک نقشی رو داشته باشه و یک دلیل برای تغییر داشته باشه.
تشخیص این موضوع همیشه ساده نیست ولی خب با تمرین و خوندن سورس کد متوجه میشید که بقیه چطوری کلاساشون رو جدا میکنن و به مرور زمان جدا میکنید.

چرا اینکارو انجام میدیم؟ اولین فایده‌اش اینه که کدبیسمون ماژولار تر و تمیز تر میشه و امکان تغییر بدون خرابکاری کمتر میشه. که برای یک تیم خیلی مهمه.

دوم اینکه تو سیستم کنترل نسخه مثل گیت راحت‌تر میشه تغییرات رو بررسی کرد. مثلاً میخواید git blame بزنید گیج نمیشید چون که این بخش از برنامه فقط برای یک دلیل و فقط توسط یک نفر تغییر کرده.

ممکنه که همون اول کلاستون یک متد داشته باشه و یکم حرکت عجیب غریبی باشه. ممکنه حتی دیتا هم نداشته باشه. ولی اگر دلیل خوبی داشته باشید میبینید که برنامه تمیز تر و بهتر میشه.

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

#OOP
#SOLID