آموزش ۵۰۰+ سوال و جواب مصاحبه MongoDB سال ۲۰۲۶ - آخرین آپدیت

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

پوشش دقیق حوزه‌های آزمون

این بانک سوالات جامع به طور سیستماتیک به حوزه‌های اصلی معماری و عملیاتی MongoDB تقسیم شده است که دقیقاً با معیارهای ارزیابی مصاحبه‌کنندگان سازمانی مطابقت دارد.

• دانش پایه MongoDB (۲۰٪): تسلط بر Collections، اسناد ساختاری JSON، عملیات پیشرفته CRUD، انواع داده‌های BSON و جزئیات زبان کوئری JSON.

• مهارت‌های پیشرفته MongoDB (۲۵٪): ایجاد ایندکس‌های بهینه، ساخت خط لوله‌های Aggregation چند مرحله‌ای، پیکربندی Replication Sets، طراحی استراتژی‌های Sharding افقی و نوشتن عملیات Map-Reduce.

• مدل‌سازی داده‌ها و طراحی شما (۱۵٪): ساختارهای سند، مدیریت سلسله‌مراتب سازماندهی داده‌ها، طراحی کالکشن‌های پویا و بهینه، و ارزیابی زمان استفاده از اسناد Embedded در مقابل Referenced (طراحی نرمال و دنورمال).

• بهینه‌سازی عملکرد و مقیاس‌پذیری (۱۰٪): تنظیم دقیق پیکربندی‌های دیتابیس، اجرای پروتکل‌های مقیاس‌پذیری افقی، تشخیص محدودیت‌های مقیاس‌پذیری عمودی، مدیریت معماری‌های Sharding و تنظیم اندازه Oplog در Replication.

• پردازش و تجمیع داده‌ها (۱۰٪): ساخت فریم‌ورک‌های پیچیده Aggregation، تسلط بر اپراتورهای Pipeline، تبدیل جریان داده‌ها و اجرای تحلیل‌های داده‌ای بلادرنگ با کارایی بالا.

• امنیت و کنترل دسترسی (۵٪): پیاده‌سازی کنترل دسترسی مبتنی بر نقش (RBAC)، برپایی احراز هویت کاربر و مجوزهای داخلی، مدیریت رمزنگاری در حالت استراحت و انتقال، و تنظیم لیست‌های کنترل دسترسی.

• کاربردهای دنیای واقعی و Use Caseها (۵٪): تحلیل معماری‌های پیچیده عملیاتی، پیروی از بهترین تجربیات تایید شده صنعت، سازگاری با الگوهای بار واقعی و نظارت بر روندهای مدرن داده‌ها.

• عیب‌یابی و نگهداری (۱۰٪): مدیریت پیشرفته خطاها، مدیریت لاگ‌های تشخیصی، برپایی زیرساخت نظارتی بلادرنگ و سازماندهی توالی‌های بی‌نقص پشتیبان‌گیری و بازیابی.

درباره این دوره

موفقیت در مراحل فنی دیتابیس مدرن مستلزم فراتر رفتن از سینتکس‌های ساده کوئری است. اپلیکیشن‌های توزیع شده با نرخ تراکنش بالا به معماری‌های NoSQL وابسته هستند که منعطف، دارای مدل‌سازی دقیق و به طور صریح برای مقیاس‌پذیری بهینه شده باشند. من این مخزن گسترده سوالات را برای شبیه‌سازی دقیق عمق، موارد خاص (Edge Cases) و نقاط اصطکاک معماری طراحی کردم که مدیران ارشد مهندسی و مدیران دیتابیس برای ارزیابی کاندیداها از آن‌ها استفاده می‌کنند.

با ۵۵۰ سوال اصلی و سناریو-محور، این دوره از تعاریف ساده فاصله گرفته است. در عوض، شما را مستقیماً در محیط‌های عملیاتی واقعی قرار می‌دهم تا گلوگاه‌های کوئری‌های بدون ایندکس را دیباگ کنید، Replica Setهای خراب را تعمیر کنید، مراحل شکست‌خورده Aggregation را اصلاح کنید و استراتژی‌های صحیح Shard Key را برای توزیع جهانی انتخاب کنید. هر سوال شامل یک تحلیل فنی جامع در سطح عملیاتی است که توضیح می‌دهد چرا گزینه صحیح موفق است و دقیقاً چرا جایگزین‌های معماری دیگر تحت بار شدید شکست می‌خورند. چه یک توسعه‌دهنده Backend باشید که به دنبال تثبیت دانش لایه داده‌های خود است، چه یک مهندس داده که برای مراحل پیچیده Aggregation آماده می‌شود یا یک DBA که هدفش عبور از پنل‌های فنی سخت‌گیرانه است، این مخزن تست‌های تمرینی، تمرین عمیق و هدفمندی را فراهم می‌کند که برای قبولی در مصاحبه فنی شما در اولین تلاش لازم است.

نمونه سوالات تمرینی

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

سوال ۱: انتخاب ایندکس و تحلیل پلن کوئری در کالکشن‌های با تراکنش بالا

یک توسعه‌دهنده کوئری find را اجرا می‌کند که شامل فیلتر روی فیلدهای { status: "A", age: { $gt: 30 } } است و بر اساس { joiningDate: -1 } مرتب شده است. کالکشن دارای یک ایندکس ترکیبی (Compound) به صورت { status: 1, joiningDate: 1, age: 1 } است. هنگام بررسی آمار اجرا از طریق explain("executionStats")، توسعه‌دهنده متوجه می‌شود که اجرای کوئری کندتر از حد انتظار است و یک مرتب‌سازی در حافظه (In-memory sort) انجام می‌دهد. نقص ساختاری در این طراحی ایندکس چیست؟

• الف) ترتیب کلیدها در ایندکس ترکیبی قانون Equality, Sort, Range (ESR) را نقض می‌کند.

• ب) ایندکس ترکیبی نامعتبر است زیرا MongoDB نمی‌تواند اپراتورهای تساوی و بازه (Range) را در یک بلوک ایندکس ترکیب کند.

• ج) جهت فیلد مرتب‌سازی ایندکس باید دقیقاً با جهت آرایه فیلتر کوئری find مطابقت داشته باشد.

• د) ایندکس‌های ترکیبی تمام کارایی جستجو را زمانی که اپراتور بازه یک فیلد عدد صحیح را ارزیابی می‌کند، از دست می‌دهند.

• ه) موتور اجرا هرگاه دستور explain در کنار فیلدهای مرتب‌سازی فعال اجرا شود، به صورت پیش‌فرض اسکن کامل کالکشن را انجام می‌دهد.

• و) MongoDB نمی‌تواند از ایندکس‌های ترکیبی برای کوئری‌هایی که بیش از یک پارامتر فیلترینگ مجزا دارند استفاده کند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: الف

• چرا درست است: برای اینکه ایندکس‌های ترکیبی با حداکثر کارایی عمل کنند، دستورالعمل‌های MongoDB حکم می‌کنند که قانون Equality, Sort, Range (ESR) رعایت شود. در کوئری توسعه‌دهنده، status تطبیق تساوی (Equality)، joiningDate فیلد مرتب‌سازی (Sort) و age تطبیق بازه (Range) است. ایندکس باید به صورت { status: 1, joiningDate: 1, age: 1 } تعریف می‌شد (با رعایت ترتیب ESR). اما چون کوئری درخواست مرتب‌سازی بر اساس joiningDate را دارد در حالی که ایندکس ترتیب را به درستی رعایت نکرده یا age را قبل از آن قرار داده است، MongoDB نمی‌تواند از ایندکس برای ارضای ترتیب مرتب‌سازی استفاده کند و مجبور به اجرای یک مرتب‌سازی مسدودکننده و گران‌قیمت در حافظه می‌شود.

• چرا گزینه‌های دیگر غلط هستند:

  • گزینه ب غلط است: MongoDB به طور بومی از ترکیب شرایط تساوی و بازه در یک ایندکس ترکیبی پشتیبانی می‌کند.

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

  • گزینه د غلط است: اپراتورهای بازه روی اعداد، تاریخ‌ها و رشته‌ها به طور کامل و درست عمل می‌کنند.

  • گزینه ه غلط است: دستور explain صرفاً استراتژی داخلی انتخاب شده توسط بهینه‌ساز کوئری را گزارش می‌کند و مسیریابی کوئری را تغییر نمی‌دهد.

  • گزینه و غلط است: ایندکس‌های ترکیبی دقیقاً برای مدیریت بهینه چندین معیار فیلتر مجزا طراحی شده‌اند.

سوال ۲: محدودیت‌های حافظه و سرریز دیسک در خط لوله‌های پیچیده Aggregation

یک اپلیکیشن تحلیلی، کالکشنی با حجم بالا را از طریق یک خط لوله Aggregation چند مرحله‌ای پردازش می‌کند. این خط لوله از یک مرحله $match، سپس یک مرحله $group و در نهایت یک مرحله $sort برای مرتب‌سازی داده‌های تجمیع شده استفاده می‌کند. در هنگام اجرا روی یک مجموعه داده عملیاتی بزرگ، خط لوله با خطایی متوقف می‌شود که بیان می‌کند حداکثر آستانه حافظه exceeded شده است. کدام گزینه پیکربندی این شکست اجرایی را برطرف می‌کند؟

• الف) خط لوله باید به فراخوان‌های متوالی و مجزای متد .find() که در حلقه‌های اپلیکیشن پیچیده شده‌اند، تبدیل شود.

• ب) دستور aggregation باید گزینه { allowDiskUse: true } را ارسال کند تا اجازه دهد مراحل به فایل‌های ذخیره‌سازی موقت در دیسک سرریز شوند.

• ج) توسعه‌دهنده باید یک مرحله $project را در انتهای مطلق خط لوله اضافه کند تا تخصیص‌های حافظه Heap فعال آزاد شوند.

• د) خط لوله aggregation باید به مدل قدیمی Map-Reduce تبدیل شود تا به طور خودکار محدودیت‌های داخلی کلاستر را دور بزند.

• ه) اسناد داده‌های زیربنایی باید قبل از ورود به فریم‌ورک aggregation به بلوک‌های متنی JSON خام فشرده شوند.

• و) کالکشن باید به یک Capped Collection تبدیل شود تا رکوردهایی که از محدودیت حافظه فراتر می‌روند به طور خودکار حذف شوند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• چرا درست است: به طور پیش‌فرض، مراحل خط لوله aggregation دارای محدودیت حافظه سخت‌گیرانه ۱۰۰ مگابایت RAM برای هر مرحله هستند. هنگام پردازش مجموعه داده‌های عظیم، اپراتورهای متکی به حافظه مانند $group یا $sort به راحتی از این مرز عبور کرده و منجر به توقف کوئری می‌شوند. ارسال { allowDiskUse: true } به موتور دیتابیس اجازه می‌دهد تا از فایل‌های موقت در فضای دیسک برای پردازش بلوک‌های داده‌ای که از سقف RAM فراتر می‌روند، استفاده کند.

• چرا گزینه‌های دیگر غلط هستند:

  • گزینه الف غلط است: مدیریت تجمیع‌های سنگین در منطق اپلیکیشن سمت کلاینت، سربار شبکه عظیمی ایجاد کرده و عملکرد زیرساخت را تخریب می‌کند.

  • گزینه ج غلط است: قرار دادن مرحله projection در انتها هیچ کمکی به مراحل قبلی مانند $group یا $sort که قبلاً هنگام پردازش داده‌های حجیم کرش کرده‌اند، نمی‌کند.

  • گزینه د غلط است: عملیات Map-Reduce نیز با محدودیت‌های شدید حافظه داخلی مواجه است و کندتر و ناکارآمدتر است و تا حد زیادی به نفع فریم‌ورک aggregation کنار گذاشته شده است.

  • گزینه ه غلط است: داده‌های BSON نمی‌توانند در میانه خط لوله به آرایه‌های متنی ساده تبدیل شوند؛ فریم‌ورک aggregation به پردازش باینری BSON وابسته است.

  • گزینه و غلط است: Capped Collectionها اندازه فایل را با بازنویسی اسناد قدیمی محدود می‌کنند که باعث تخریب رکوردهای اپلیکیشن عملیاتی می‌شود.

سوال ۳: Sharding پویا و شکست‌های مربوط به Cardinality کلید Shard

یک مدیر دیتابیس یک کلاستر Sharded MongoDB را برای مقیاس‌پذیری افقی یک اپلیکیشن SaaS چند مستاجری (Multi-tenant) مستقر می‌کند. مدیر، فیلد tenantCountry را به عنوان Shard Key انتخاب می‌کند. پس از چند ماه جذب سریع مشتری، کلاستر فشار نوشتاری شدیدی را روی یک Shard واحد نشان می‌دهد، در حالی که سایر Shardها کاملاً بیکار می‌مانند. چه اشتباه ساختاری باعث این توزیع نامتعادل بار شده است؟

• الف) معماری‌های Sharding تنها زمانی ترافیک را به طور یکنواخت توزیع می‌کنند که از یک Object ID باینری بومی به عنوان کلید Shard واحد استفاده شود.

• ب) کلید Shard انتخاب شده دارای Cardinality پایین است و Chunkهای عظیم و غیرقابل تقسیمی ایجاد می‌کند که نمی‌توانند بین نودهای کلاستر جابجا شوند.

• ج) فاکتور Replication در Shardهای بیکار، بالاتر از نود دیتابیس Primary فعال پیکربندی شده بود.

• د) MongoDB الزام می‌کند که تمام کلیدهای Shard از فرمت تاریخ نزولی برای توزیع یکنواخت مسیرهای نوشتاری استفاده کنند.

• ه) فرآیند Balancer به طور خودکار مسیریابی رکوردها را متوقف می‌کند اگر کالکشن‌های مجزا بیش از ۱۰۰ سند کل داشته باشند.

• و) کلید Shard انتخاب شده باید همیشه با نام کاربری ادمین کلاستر دیتابیس مطابقت داشته باشد تا تعادل صحیح برقرار شود.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• چرا درست است: فیلد tenantCountry دارای Cardinality بسیار پایینی است زیرا تعداد کشورهای جهان محدود است. اگر میلیون‌ها سند مقدار کشور یکسانی داشته باشند، MongoDB مجبور است همه آن‌ها را در یک "Chunk" منطقی واحد ذخیره کند. از آنجایی که یک Chunk واحد نمی‌تواند تقسیم شده یا بین چندین Shard جابجا شود، یک Shard تمام بار نوشتاری آن کشور را به عهده می‌گیرد که منجر به ایجاد Hot Spot شده و مقیاس‌پذیری افقی را بی‌فایده می‌کند.

• چرا گزینه‌های دیگر غلط هستند:

  • گزینه الف غلط است: Object IDها برای کلیدهای با افزایش یکنواخت عالی هستند، اما فیلدهای ترکیبی یا Hashed نیز می‌توانند مسیرهای نوشتاری را به همان اندازه موثر توزیع کنند.

  • گزینه ج غلط است: Replica Setها در دسترس‌پذیری بالا (High-Availability) در داخل یک Shard واحد مدیریت می‌کنند و بر توزیع افقی داده‌ها بین Shardهای مجزا تاثیر ندارند.

  • گزینه د غلط است: استفاده از کلید با افزایش یا کاهش یکنواخت (مانند تاریخ‌های خام) بدون Hashing در واقع باعث ایجاد Hot Spot در جدیدترین Chunk مربوط به Shard می‌شود.

  • گزینه ه غلط است: Balancer داخلی به طور مداوم روی کالکشن‌هایی حاوی میلیون‌ها سند فعال کار می‌کند.

  • گزینه و غلط است: کلیدهای Shard کاملاً بر اساس فیلدهای داده‌های ساختاری سند عمل می‌کنند و هیچ ارتباطی با اعتبارنامه‌های مدیریت دسترسی کاربر ندارند.

چه انتظاراتی داشته باشید

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

• شما می‌توانید هر تعداد بار که بخواهید در آزمون‌ها شرکت کنید.

• این یک بانک سوالات عظیم و اورجینال است.

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح دقیق است.

• با اپلیکیشن Udemy سازگار با موبایل است.

امیدواریم تا الان متقاعد شده باشید! و سوالات بسیار بیشتری در داخل دوره وجود دارد.