داشتم بلاگ Uber Engineering رو نگاه میکردم رسیدم به یه مقاله ی جالب بنام (این مقاله توی سال 2016 نوشته شده):

Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL

خب خلاصش میشه اینکه اوبر اومده یه دیتابیس Schemaless اختصاصی خودش ایجاد کرده که پاسخگوی نیاز هاش باشه

یکی از چیز هایی که خیلی براشون مهم بوده دسترسی بالا (highly-available) توی عملیات نوشتن توی دیتابیس بوده.

این امر به سختی قابل دستیابی بود...

... چونکه تمام Writes ها به نود اصلی (Leader Node) میرفتند

و در این حالت نمیشه high availability رو تضمین کرد

We needed write availability. We had previously implemented a simple buffer mechanism with Redis, so if the write to Postgres failed we could retry later since the trip had been stored in Redis in the interim. But while in Redis, the trip could not be read from Postgres and we lost functionality like billing.

اینا اومده بودن یه مکانیسم بافر ساده رو با Redis پیاده سازی کرده بودند، پس اگه موقع عملیات write توی Postgres مشکلی پیش میومد،‌ چونکه اطلاعات سفر توی Redis ذخیره شده بوده میتونستند برای اجرای مجدد عملیات write بعدا دوباره امتحان کنند، ولی از طرفیم چون اطلاعات سفر توی Postgres ثبت نشده بود، توی اجرای‌ فانکشن هایی مثل صورتحساب به مشکل میخوردند. با گذشت زمان که اوبر رشد میکنه راه حل مبتنی بر Redis اشون Scale نمیشه پس دیتابیسشون باید یه مکانیزم مشابه Redis رو پشتیبانی میکرد اما write نسبت به read مهم تر بود

اوبر با استفاده از یک تکنیک درخشان به نام Buffered Writes این امر را ممکن کرد.

به طور خلاصه، Buffered Writes به این معنیه که هر درخواست نوشتن حداقل در دو Node ذخیره میشه: نود اصلی (Primary Leader) و نود ثانویه (Secondary Leader).

نحوه عملکردشم اینجوریه که:

👈 کلاینت درخواستی رو به request handler ارسال میکنه.

👈 سپس request handler درخواست های write رو به نود ثانویه ارسال میکنه. داده ها در یک جدول بافر (Buffer Table) خاص در نود ثانویه ذخیره میشن.

👈 سپس، درخواست نوشتن رو هم به نود اصلی ارسال می کنه. فقط در صورتی که هر دو write موفقیت آمیز باشن، کلاینت تأییدیه write موفقیت آمیز دریافت میکنه.

👈 وظیفه نود اصلی تکثیر داده هاست.

👈 اما اگه نود اصلی قبل از موفقیت آمیز بودن async replication از کار بیوفته، نود ثانویه به عنوان یک نسخه پشتیبان موقت از داده ها عمل میکنه.

👈 یه Background Worker به دنبال کننده اصلی (Primary Follower) نظارت میکنه تا ببینه آیا رکورد بعد از replication ظاهر میشه یا نه.

👈 هنگامی که رکورد در Primary Follower ظاهر میشه، Background Worker جلو میره و رکورد رو از Buffer Table حذف می کنه.

چند نکته مهم که باید به آنها توجه داشت:

✅ تعداد نود ثانویه قابل پیکربندیه.
✅ نود ثانویه به طور تصادفی انتخاب میشه.
✅ عملیات Buffered writes از idempotency پشتیبانی میکنه. اگه چندین write با همون identifying fields وجود داشته باشه، مهم نیست که درخواست چند بار ارسال بشه.

🆔 @MdDaily

توی این گیف عملیات Buffered Writes به صورت تصویری نشون داده شده

🆔 @MdDaily

🎧 پلی لیست #موزیک مناسب برای زمان برنامه نویسی (Deep Programming)

🎵 Tracklist

► 00:00 AHO.H - Trouvaille

► 04:47 Vale, Weirenz - Pure Noise

► 07:24 Condition.ruined - Archive

► 10:44 Echo - Nightfall

► 16:30 Homeomorphic - Hypnotizing

► 21:08 Lazarus Moment - Vagrant

► 27:34 Fox3r - Dive

► 31:00 Shibiremusic, Hurricvne - Inside Your Mind

► 34:36 Eenspire - Flow of Thoughts

► 37:19 Fyze - Lost in Time

► 42:21 Etsu, Diedlonеly - Lost

► 45:37 Spaceouters - Ma

► 49:49 Tiikk - The Sky Keeps Moving

► 54:24 F0x3r - Answer

► 57:36 Craset, Nega Beats - Have a chance

► 1:01:30 OGLΛK, Phelian - Broken

► 1:07:20 Deffyme - Hazel Eyes

► 1:10:20 Zyphyr - Mystеry

► 1:14:03 Vonnboyd - Immersion


🆔 @MdDaily

Vscode is FREEE.

شاید در نگاه اول این جمله به نظر برسه که یه مشکل نوشتاری داره ولی اینطور نیست :) نه این جمله به معنای رایگان بودن ویرایشگر متن محبوب وی اس کد هست و نه Typo داره.

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

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

اگه چیزی رایگان عه احتمالا شما محصول هستید.

خب برگردیم به جمله ی اصلی: Vscode is FREEE. آیا واقعا Vscode رایگانه؟ جواب کوتاه: نه! مایکروسافت یه سیاستی رو دنبال میکنه که به اختصار بهش میگن:
EEE (Embrace, extend, and extinguish)
اما دقیقا این سیاست یعنی چی؟

استراتژی و عبارت "Embrace, extend, and extinguish" برای اولین بار در خارج از مایکروسافت در یک مقاله سال ۱۹۹۶ در نیویورک تایمز با عنوان "فردا، وب جهانی! مایکروسافت، پادشاه رایانه شخصی، می‌خواهد بر اینترنت حکومت کند" توصیف شد، که در آن نویسنده جان مارکوف گفت: "به جای اینکه صرفاً اینترنت را در آغوش بگیرد و گسترش دهد، منتقدان این شرکت اکنون می‌ترسند، مایکروسافت قصد دارد آن را در خود فرو ببرد."

مرحله اول: در آغوش گرفتن (Embrace)

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

مرحله دوم: گسترش دادن (extend)

بعد از اینکه مایکروسافت با استاندارد یا محصول رقیب سازگار شد، شروع میکنه به گسترشش. یعنی ویژگی های جدیدی بهش اضافه میکنه که در استاندارد یا محصول اصلی نباشه. مثلاً مایکروسافت اومد توی IE ویژگی های جدیدی مثل پشتیبانی از فلش یا ویدیو اضافه کرد.

مرحله سوم: خاموش کردن (extinguish)

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


به زبان ساده تر

استراتژی مایکروسافت میگه: "اول استاندارد یا محصول رقیب رو قبول می کنیم، بعدش ویژگی های جدیدی بهش اضافه می کنیم که رقبا نمی تونن اضافه کنن، و در نهایت استاندارد یا محصول جدید رو به استاندارد واقعی تبدیل می کنیم و رقبا رو حذف می کنیم."

این استراتژی باعث شد که مایکروسافت بتونه در دهه ۹۰ میلادی به قدرتمندترین شرکت نرم افزاری دنیا تبدیل بشه.

چنتا مثال دیگه:

-مرورگرها: مایکروسافت در گذشته از کنترل‌های ActiveX در مرورگر اینترنت اکسپلورر استفاده می‌کرد. این کنترل‌ها با مرورگرهای دیگه سازگار نبودن و باعث می‌شدن که اسناد وب در مرورگرهای دیگه به خوبی نمایش داده نشن.

-تلاش برای انحصار در Java: مایکروسافت قصد داشت که سیاست EEE رو توی جاوا هم پیاده کنه و از با حذف JNI از جاوا قابلیت اجرا شدن روی لینوکس و مک رو بگیره که در نهایت با شکایت شاکیان پرونده ضد انحصارطلبی مایکروسافت در ژانویه 2001 مبلغ 20 میلیون دلار آمریکا به Sun Microsystems پرداخت کرد.

-اسناد آفیس: مایکروسافت در گذشته از ویژگی‌های اختصاصی در اسناد آفیس استفاده می‌کرد. این ویژگی‌ها باعث می‌شدن که اسناد آفیس در نرم‌افزارهای متن‌پرداز دیگه به خوبی نمایش داده نشن.

- نرم افزار ویرایشگر متن: مایکروسافت با معرفی Vscode و حذف رقبایی مثل Atom درنهایت موفق شد که استراژی EEE رو در مورد VScode اجرا کنه

و مثال های دیگه که میتونید توی ویکی پیدا پیداشون کنید.

نتیجه گیری:

خلاصه اینکه این استراتژی از طرف هر کسی میتونه باشید، نه فقط مایکروسافت، چونکه شرکت‌ها صرفاً برای کسب درآمد وجود دارند و تقریباً هر کاری را برای رسیدن به این هدف انجام می‌دن، در نهایت هدف این پست معرفی استراتژی EEE بود و هدفش تخریب شرکت یا محصولی نبود :)


🆔 @MdDaily

چطور یه برنامه بسازیم که بشه با بقیه همزمان داده ها رو آپدیت کنیم؟

بیایید از Notion یاد بگیریم.

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

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

هر چیزی که تو ویرایشگر Notion می سازید یه Block عه.

و هر Block یه چرخه ی عمر 3 مرحله ای داره:

👈 ایجاد یه Block جدید
👈 ذخیره Block روی سرور
👈 رندر کردن Block روی صفحه بقیه

💡 توی تصویر پست این سه مرحله به صورت تصویری نشون داده شده

اما، این سه مرحله در مجموع یازده مرحله رو با اتفاقات جالب شامل میشه

بیایید به طور خلاصه بررسیشون کنیم 👇👇👇

👈 مرحله 1 - ایجاد یک بلوک جدید

اتفاقات زیر در این مرحله میوفتند:

1 - کاربر یک بلوک جدید در رابط کاربری ایجاد می کند.
2 - بلوک در فضای ذخیره سازی داخلی(in-memory storage) یا چیزی مثل IndexedDB ذخیره میشه.
3 - رابط کاربری دوباره رندر میشه و بلوک در صفحه کاربر نمایش داده میشه.
4 - داده ها هم در TransactionQueue ذخیره میشن.

🆔 @MdDaily

تووی TransactionQueue یک صف از تغییرات که هنوز به پایگاه داده اصلی ارسال نشدند وجود داره تا از تداخل داده ها جلوگیری کنه.

👈 مرحله 2 - ذخیره بلوک در سرور

5 - داده ها serialized شده و به API بک اند ارسال میشن.

6 - ای پی ای (API) کارش رو انجام میده و داده ها رو در پایگاه داده اصلی ذخیره میکنه.

7 - ای پی ای (API) بک اند همچنین سرویس MessageStore را در مورد تغییرات مطلع میکنه.

سرویس MessageStore یک سرویس ارتباطی در Notion عه که برای ارسال اعلان‌های تغییرات به کاربران استفاده میشه

👈 مرحله ۳ - رندر کردن بلوک در صفحه بقیه

8 - یک وب سوکت از سمت کلاینت ایجاد میشه و وصل میشه به سرویس MessageStore تا تغییرات را دریافت کنه.
9 - حالا MessageStore اعلان (notification) تغییرات رو به Websocket ارسال می کنه.
10 - کلاینت اعلان‌های به‌روزرسانی نسخه رو دریافت می‌کنه.
11 - بر اساس داده‌های اعلان، کلاینت API بک اند را فراخوانی میکنه تا آخرین رکوردها را از پایگاه داده دریافت کنه و رابط کاربری بقیه هم با داده های بروز رندر بشن.

💡 توی تصویر پست کل پروسه ای که داره انجام میشه به صورت تصویری نشون داده شده

🆔 @MdDaily

#معرفی

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

سایت‌هایی که شماره‌های یکبار مصرف برای تأیید پیامک ارائه می‌کنن:

1) http://hs3x.com
2) http://smsget.net
3) https://sms-online.co
4) https://catchsms.com
5) http://sms-receive.net
6) http://sms.sellaite.com
7) http://receivefreesms.net
8) https://receive-a-sms.com
9) http://receivesmsonline.in
10) http://receivefreesms.com
11) http://receivesmsonline.me
12) https://smsreceivefree.com
13) https://smsreceiveonline.com
14) https://receive-sms-online.com
15) https://receivesmsonline.net
16) https://temp-mails.com/number
17) https://freeonlinephone.org
18)https://getfreesmsnumber.com

سایت‌هایی که ایمیل‌های یکبار مصرف برای تأیید ایمیل ارائه می‌کنن:

1) https://maildrop.cc
2) https://tempr.email
3) https://tempmail.net
4) https://temp-mail.org
5) https://moakt.com
6) https://tempmailo.com [ New ]
7) https://emailondeck.com
8) https://guerrillamail.com
9) https://smailpro.com (+ temp Gmail) (این سایت هم شماره و هم جیمیل موقت بهتون میده)


🆔 @MdDaily

🎧 پلی لیست #موزیک مناسب برای زمان تمرکز و پروداکتیویتی (Electronic Music)

🎵 Tracklist

► 00:00 Vonnboyd - Discover

► 03:50 Honeyruin - We Could Have Been

► 07:46 Blurred, Heartmath2 - Dawning (Creepa Remix)

► 12:19 Andy Leech - Solar Fields

► 17:09 AK - 23.01.2018

► 20:34 VonnBoyd - Broken Heart

► 26:08 AK - Autumn Is Here

► 29:38 Koda - Staying

► 33:56 Tim Schaufert, AK - From Place Еo Place

► 36:57 AK - Wanderlust

► 40:38 4Lienetic - The Fog Ahead

► 45:05 Hands - Thinking About You

► 48:20 H3ndo - Fathom

► 53:43 Arnyd - Truth

► 57:25 Ambient Light - Norwegian Valley

► 1:00:56 Ponkie - Falling Stars

► 1:04:36 Randloev - Patience

► 1:09:08 Artic Desert - Enigma

► 1:12:49 Many Miles - Look Down

► 1:16:45 Onycs - Timeless

► 1:20:58 Samuke - Haze

► 1:23:51 Homeomorphic - Imaginary

► 1:26:53 Kasper Klick - Salvation

► 1:31:14 Homeomorphic - Awareness

► 1:34:52 Bythewvve - Return

► 1:37:54 Rusez1 - Aftermath

🆔 @MdDaily

دوره های #ام_دی_کورس ای که تا الان توی کانال منتشر شدند:

🔗 الگوریتم و فلو چارت

🔗 دانش پایه Exif Data و سعی در ادیت کردن Exif Byte Order عکس با Golang

🔗 آموزش پروژه ی هوش مصنوعی پرسشو پاسخ بر اساس متن و مستندات با استفاده از مدل Llama 7b و Longchain

🔗 آموزش دریافت اشتراک Tabnine Pro به صورت رایگان و قانونی

🔗 کرش کورس DNS

🔗 معماری Monolith یا Microservice؟

🔗 کرش کورس داکر

🔗 کرش کورس Bash noscript

🔗 ساخت Load Balancer در گولنگ

🔗 چطوری پی‌پل با استفاده از فقط 8 ماشین مجازی به یک میلیارد تراکنش روزانه رسید

🔗 ساخت ربات دانلودر اسپاتیفای با گولنگ

🔗 ۷ حمله امنیتی رایج فرانت اند

🔗 اپیزود دواپس با سید مهدی

🔗 چطوری اوبر با ۱ میلیون درخواست در ثانیه رانندگان نزدیک رو پیدا می کنه؟

🔗 سوال مصاحبه System Design: طراحی کوتاه کننده URL

این پیام با انتشار دوره ی جدید آپدیت میشود

🆔 @MdDaily

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

❓تا الان چیشده؟

تقریبا اوایل سال 2022 که مدل GPT-3.5 منتشر شد تا الان شاهد ظهور ابزار های جدید، تحولات تازه و اخبار مختلف توی این حوزه بودیم. گوگل Bard رو معرفی کرد،‌ AI به سرچ انجین ها و ابزار های مختلف اضافه شد و میتونیم بگیم که کارهامون به قبل از عمومی شدن و بعدش تقسیم میشن :)


❓از OpenAI چه خبر؟

این شرکت هم تا اینجای کار حواشی کم نداشته. طبق آمار ChatGPT عملکردش توی پاسخ به سوالات کاهش پیدا کرده. مدیر عامل و بنیان گذارش سم آلتمن رو از شرکت اخراج کردند و بعد از اینکه دیدن اوضاع خرابه و ۵۰۰ تا ۷۰۰ کارمند OpenAI درخواست استعفا دادن، قبل از اینکه شرکت به سمت فروپاشی بره مجدد سم آلتمن به OpenAI برگشت. این مجموعه تا اینجای کار با معرفی GPT3.5 Turbo, GPT4, GPT4-V و ... باعث ایجاد تحولات زیادی شده. با فعال شدن ویژگی مکالمه در ChatGPT برای همه ی کاربران توی اپش الان میتونید باهاش صحبت کنید و به شما به صورت ویس جواب بده. خبر خوب اینکه ویژگی مکالمه اش از زبان فارسی هم پشتیبانی میکنه و حتی به فارسی هم با شما صحبت میکنه. برای یادگیری زبان بهترین گزینس

❓این همه ابزار وجود داره، کدوم ابزار برای چه کاری مناسبه؟

💻 توی چند ماهه گذشته ابزار های زیادی رو تست کردم که ببینم کدوم برای کمک به فرایند برنامه نویسی و توسعه مناسب تر هستند. ابزار هایی که تست کردم :‌ GitHub Copilot - Tabnine Pro - Codeium - Chat GPT - Google Bard - Claude - Bing AI و ...

نتیجه؟

طبق تجربه ی من ابزار هایی مثل Google Bard یا Bing که به اینترنت متصل هستند برای برنامه نویسی مناسب نیستند! احتمال تولید کد اشتباه،‌ عدم درک دقیق مشکل و عدم ارائه ی راه حل مناسب توی این ابزار ها به شدت بالاس. توی تمام ابزار هایی که تست کردم میتونم بگم در حال حاضر بهترین هاشون برای حل مسائل برنامه نویسی کمک به شما Codeium و Claude هستند.

برای نسخه ی تحت وب میتونید از codeium live استفاده کنید، چونکه داده هاش برای تکنولوژی های مثل React, Numpy.و ... آپدیته و تمرین داده شده که فقط به سوالات شما توی برنامه نویسی جواب بده. توی IDE یا ویرایشگر متنی که ازش استفاده می کنید هم میتونید از پلاگین Codeium استفاده کنید و مزیتی که Codeium داره اینکه وقتی ازش سوال می پرسید میره توی بقیه فایل های پروژتونم جستجو میکنه و دقیق ترین جواب رو به شما میده. تا الان Codeium با وجود اینکه کاملا رایگانه عملکرد خیلی بهتر و قوی تری به نسبت Tabnine Pro طبق تجربه ی من داشته.

برخلاف تبلیغاتی که توی تبدیل عکس به کد برای Bard یا Bing شده این ها هنوز خیلی تو این مورد ضعیفن و GPT4-V عملکرد خیلی بهتر و قوی تری داره

👈 درنهایت ابزار ها را میتوینم به این صورت دسته بندی کنیم:

💫 جستجو در اینترنت |‌ ترجمه | حل مسائل ریاضی |‌ تحقیق | چت و تولید مقاله به زبان فارسی | دستیار شخصی => Google Bard

💫 دستیار برنامه نویسی‌ | تکنولوژی => codeium و codeium live

💫 مکالمه به صورت ویس مناسب برای یادگیری زبان و ... => اپلیکیشن چت چی پی تی (Android - IOS)

💫 تولید تصویر و لوگو => leonardo.ai و Bing AI

💫 خلاصه سازی وب سایت ها و جستجو در اینترنت=> Bing AI و perplexity.ai

💫 عمومی => claude.ai و Chat GPT

این تجربه ی من بود از تست ابزار ها از زمان معرفی GitHub Copilot تا الان :)

🆔 @MdDaily

شما هم اگه ابزاری میشناسید که اینجا بهش اشاره نشده و یا تجربه ی متفاوتی داشتید خوشحال میشم توی کامنت های پست به اشتراک بگذاریدش :)

چطوری اینستاگرام با تنها 3 مهندس به 14 میلیون کاربر رسید! (قسمت اول)


چند وقتی بود داشتم مقالات instagram engineering رو میخوندم و نکات خیلی جالبی میشه از تجربه ی مهندسانی که روی اینستاگرام کار کردند یاد گرفت. توی این پست نگاهی میندازیم به اینکه اینستاگرام چطوری از اکتبر 2010 تا دسامبر 2011 از 0 به 14 میلیون کاربر در یک سال رسید و اونها این کار رو فقط با 3 مهندس انجام دادن.

اصولی که تیم توسعه اینستاگرام بهش پایبند بود:

👈 ساده نگه داشتن همه چیز
👈 اختراع نکردن دوباره ی چرخ
👈 استفاده از تکنولوژی هایی که ثابت شدند و قابل اطمینان هستند

زیرساخت اولیه اینستاگرام در AWS اجرا می شد و از EC2 با Ubuntu Linux استفاده می کرد. EC2 سرویس آمازونه که به توسعه دهندگان اجازه میده رایانه های مجازی اجاره کنند.

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

📍کاربر اینستاگرام رو باز میکنه

اینستاگرام ابتدا در سال 2010 به عنوان یک برنامه iOS عرضه شد. از آنجایی که Swift در سال 2014 منتشر شد، احتمالا اینستاگرام با استفاده از Objective-C و ترکیبی از چیزهای دیگر مانند UIKit نوشته شده.

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

تمام درخواست ها به اینستاگرام به load balancer میرفت بعد به سرور اصلی. اوایل کار اینا اومده بودن دوتا NGINX گذاشته بودن و از DNS Round-Robin استفاده میکردن ولی یه مشکلی وجود داشت! موقع بروزرسانی DNS باید یکی از NGINX ها را خارج میکردن و ترافیک تقسیم نمیشد. پس اومدن توزیع کننده بارشون رو بردن روی سرویس Elastic Load Balancer آمازون که 3 تا NGINX داشتند که که ترافیک بین اینا تقسیم میشد.

📍 درخواست از load balancer به بکند ارسال میشه

بکند اینستاگرام با جنگو نوشته شده و روی ماشین‌های Amazon High-CPU Extra-Large اجرا می شدند. وقتی مصرفشون رفت بالا به صورت horizontally scale تعداد سرور هایی که از آمازون گرفته بودن رو به 25 تا افزایش دادن. به خاطر اینکه پردازش اصلی روی CPU بود نه رم از ماشین هایی با High-CPU Extra-Large استفاده می کردن

اینستاگرام خیلی از پایتون استفاده ی بهینه میکنه و حتی Cpython رو فورک کردند و یه نسخه ی بهینه شده ازش رو استفاده میکنند که تو یه پست دیگه راجبش مینویسم :)

از gunicorn عنوان سرور WSGI استفاده کردن که قبلش روی mod_wsgi و Apache بودن، اما متوجه شدن که Gunicorn پیکربندی بسیار آسان‌تر داره مصرف CPU اشم کمتره. برای اجرای دستورات در بسیاری از نمونه‌ها به طور همزمان (مانند استقرار کد)، از Fabric استفاده کردن که یک حالت موازی(parallel) مفید داره، بنابراین استقرارها در چند ثانیه انجام میشده.

📍 ذخیره سازی داده های عمومی

خب حالا سرور برنامه میبینه که درخواست نیاز به داده برای صفحه ی خانه (main feed) داره. فرض کنید به این داده ها نیاز داره:

👈 آخرین شناسه های عکس مرتبط (latest relevant photo IDs)
👈 عکس‌های واقعی که با آن شناسه‌های عکس مطابقت دارن (the actual photos that match those photo IDs)
👈 داده‌های کاربری برای عکس‌ها (user data for those photos)

📍پایگاه داده: Postgres

وقت اینکه سرور ID عکس ها رو از دیتابیس Postgres بگیره.

سرور برنامه داده ها را از PostgreSQL استخراج می کرد که بیشتر داده های اینستاگرام مانند کاربران و متا دیتا های عکس رو ذخیره می کرد.
اتصالات بین Postgres و Django با استفاده از Pgbouncer انجام می شد.

اینستاگرام به دلیل حجم زیادی که دریافت می‌کرد (بیش از ۲۵ عکس و ۹۰ لایک در ثانیه) داده‌هاش رو تقسیم کرد. اونها از کد برای map کردن چندین هزار logical shards به چند physical shards استفاده کردن. (میتونید جزئیات فنی و دقیق ترش رو توی این مقاله بخونید)


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

👈 41 بیت برای زمان بر حسب میلی‌ثانیه (با یک دوره سفارشی، 41 سال شناسه به ما میده)
👈 13 بیت که نشان دهنده شناسه خرد کننده منطقیه (logical shard ID)
👈 10 بیت که یک auto-incrementing sequence رو نشون میده, modulus 1024. یعنی که میتونیم 1024 شناسه در هر shard در هر میلی ثانیه ایجاد کنیم.
(جزئیات بیشتر در اینجا .)

با تشکر از شناسه های قابل مرتب‌سازی بر اساس زمان در Postgres، سرور برنامه با موفقیت آخرین شناسه‌های عکس مرتبط رو دریافت می کرد.

ادامه در پست بعدی....

🆔 @MdDaily

چطوری اینستاگرام با تنها 3 مهندس به 14 میلیون کاربر رسید! (قسمت دوم)

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

📍ذخیره سازی عکس: S3 و Cloudfront

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

چندین ترابایت عکس در Amazon S3 ذخیره شده بود. این عکس ها به سرعت با استفاده از Amazon CloudFront یا همون CDN آمازون به کاربران ارائه شدن که استفده از CDN به زمان بارگذاری تصویر برای کاربران در سراسر جهان (مانند ژاپن، دومین کشور محبوبشون) کمک بزرگی کرد.

📍کش: Redis و Memcached

برای دریافت داده‌های کاربر از Postgres، سرور برنامه (Django) شناسه‌های عکس رو با استفاده از Redis با شناسه‌های کاربر مطابقت میده.

اینستاگرام از Redis برای ذخیره(store) نگاشت(mapping) حدود 300 میلیون عکس به شناسه کاربری که اون هارو ایجاد کرده استفاده کرد تا بدونه وقت دریافت عکس برای فید اصلی، فید فعالیت(activity) و غیره کدوم بخش رو باید جستجو کنه. تمام داده های Redis در حافظه ذخیره شد تا زمان تأخیر را کاهش بده و در چندین دستگاه تقسیم(sharded) شد.

💫 با کمی هش(hashing) هوشمندانه، Instagram تونست 300 میلیون key mappings رو در کمتر از 5 گیگابایت ذخیره کنه.

این key-value mapping شناسه عکس به شناسه کاربر برای فهمیدن اینکه کدوم Shard Postgres رو باید پرس و جو کنه و کوئری بزنه مورد نیاز بود.

به لطف کش کردن کارآمد با استفاده از Memcached، دریافت داده‌های کاربر از Postgres سریع بود چونکه پاسخ اخیراً کش شده بود.

برای ذخیره سازی عمومی، اینستاگرام از Memcached استفاده کرد. اونا تو اون زمان 6 نمونه Memcached داشتند.

نکته جالب: 2 سال بعد، در سال 2013، فیس بوک مقاله ای منتشر کرد که نشون می داد چطوری Memcached رو مقیاس کرده اند تا بهشون در رسیدگی به میلیاردها درخواست در ثانیه کمک کنه.

🔗 Scaling Memcache at Facebook

💡 در نهایت کاربر فید اصلی یا همون صفحه ی خانه را میبینه که با آخرین تصاویر افرادی که دنبال کرده پر شده.

📍 تنظیم Master-Replica

هم Postgres و هم Redis در یک master-replica setup اجرا شدن و از snapshotting Amazon EBS برای گرفتن بکاپ های مکرر از سیستم ها استفاده کردن.

ادامه در پست بعدی....

🆔 @MdDaily

چطوری اینستاگرام با تنها 3 مهندس به 14 میلیون کاربر رسید! (قسمت سوم)

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

📍پوش نوتیفیکیشن و وظایف غیرهمزمان(Async Tasks)

🔔 حالا، فرض کنید کاربر اپ رو میبنده، ولی بعدش یه نوتیفیکیشن دریافت میکنه که یک دوست عکسی منتشر کرده.

این نوتیفیکیشن با استفاده از pyapns ارسال شده، همراه با بیش از میلیارد نوتیفیکیشن دیگه ای که اینستاگرام قبلاً ارسال کرده. Pyapns یک ارائه‌دهنده خدمات نوتیفیکیشن یکپارچه و متن باز برای سرویس نوتیفیکیشن اپل (APNS) است.

🖼 خب حالا کاربر روی نوتیفیکیشن میزنه و از عکسی که دوستش منتشر کرده خوشش میاد! پس تصمیم میگیره که توی X (توئیتر سابق) پستش کنه.

در بک‌اند، کار به Gearman (ریپوی گیت هاب) سپرده میشه، یک صف وظایف (task queue) که کار را به ماشین‌های مناسب‌تر تخصیص میده. اینستاگرام حدود 200 ورکر(workers) پایتون داشت که صف وظایف Gearman رو استفاده می‌کردند.


ابزار Gearman برای چندین وظیفه غیر همزمان(asynchronous)، مانند ارسال فعالیت‌ها (مانند یک عکس جدید) به همه دنبال‌کنندگان یک کاربر استفاده می‌شد (به این کار fanout گفته می‌شود).

📍مانیتورینگ (Monitoring)

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

اینستاگرام از Sentry برای نظارت بر خطاهای Python به صورت بلادرنگ(Real-time) استفاده کرد.

همچنین از ابزار Munin برای ترسیم نمودار متریک‌های سیستمی (system-wide metrics) و هشدار دادن به ناهنجاری‌ها استفاده شد. اینستاگرام تعدادی پلاگین Munin سفارشی برای ردیابی متریک‌های سطح برنامه(application-level metrics)، مانند عکس‌های ارسال شده در هر ثانیه، داشت.

از ابزار Pingdom برای نظارت بر خدمات خارجی و PagerDuty برای مدیریت حوادث و اعلان ها استفاده می شد.

ادامه در پست بعدی....
🆔 @MdDaily

چطوری اینستاگرام با تنها 3 مهندس به 14 میلیون کاربر رسید! (قسمت چهارم و پایانی)

توی قسمت قبلی در نهایت با همه ی بخش ها آشنا شدیم و توی این دیاگرام میتونید نمایی از معماری اینستاگرام رو ببینید

💡 از تجربه ی اینستاگرام چه چیز هایی میتونیم یاد بگیریم؟

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

👈 برای بهبود عملکرد پروژه هاتون از یک لایه کش استفاده کنید. اینستاگرام از Redis و Memcached برای سیستم کشینگش استفاده میکرد تا بتونه با تاخیر کم تری پاسخگوی نیاز کاربران باشه.

👈 زیرساختتون رو به دقت نظارت کنید. اینستاگرام از Sentry، Munin، Pingdom و PagerDuty برای نظارت بر زیرساختش استفاده کرد. این بهشون کمک کرد تا مشکلات را به سرعت شناسایی و حل کنند.

ادامه در پست بعدی....
🆔 @MdDaily

📌 منابعی که برای آماده سازی مجموعه پست (ٰچطوری اینستاگرام با تنها 3 مهندس به 14 میلیون کاربر رسید!) استفاده شدند:

🔗 What Powers Instagram: Hundreds of Instances, Dozens of Technologies

🔗 Storing hundreds of millions of simple key-value pairs in Redis

🔗 Sharding & IDs at Instagram

🔗 Instagram Engineering

🔗 How Instagram scaled to 14 million users with only 3 engineers


🆔 @MdDaily

📌 چطوری اینستاگرام با تنها 3 مهندس به 14 میلیون کاربر رسید

💡 فهرست مطالب:

- قسمت اول
- قسمت دوم
- قسمت سوم
- قسمت چهارم و پایانی
- منابع

🆔 @MdDaily

#فان
وقتی بعد از ساعت ها بهینه کردن کدت میبینی از کد اصلی کند تر اجرا میشه:

🆔 @MdDaily

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

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

توی پست الگوریتم و فلو چارت‌ خیلی خلاصه راجبش نوشتم و برای شروع راهنمای خوبی میتونه باشه

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

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

ولی وقتی هدف مشخص باشه! مثلا اون شخص به سوالات بالا اینطوری جواب میده:
- میخوام برنامه نویس موبایل بشم - هدفم اینکه بتونم اپلیکیشن خودمو بنویسم

الان باید زبان و ابزار مناسب معرفی کرد که مخاطب ما بدونه نتیجه ی کارش قرار چی بشه ؛) و موقع یاد گیری توی لوپ سردرگمی گیر نکنه. بدونه اگه داره این وقتو میذاره این هزینه و انرژی رو صرف کنه مسیرش مشخصه . مثلا میره دارت یادمیگیره،‌ بعد میره سراغ فلاتر یا هم میره کاتلین یاد میگیره یا ...

یه مثال دیگه:
- میخوام درس های دانشگاهی رو پاس میکنم - هدفم اینکه بتونم تمرین های برنامه نویسی دانشگاه رو حل کنم

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

خلاصه اینکه:

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


🆔 @MdDaily

پایگاه داده vector چیه؟

وکتور یه آرایه از اعداده که موقعیت یه نقطه رو توی فضای چند بعدی نشون میده. مثلاً وکتور {12، 13، 19، 8، 9} یه نقطه رو توی 5 بعد قرار میده. وکتور ها این امکان رو فراهم می کنن که داده رو به صورت هندسی نمایش بدیم و مقایسه های ریاضی بین نقاط داده رو انجام بدیم.

ادامه در پست بعدی...

🆔 @MdDaily