آموزش ۵۰۰+ سوال و جواب مصاحبه الاستیک‌سرچ (Elasticsearch) ۲۰۲۶ - آخرین آپدیت

پوشش جامع حوزه‌های آزمون

این مخزن تست‌های تمرینی دقیقاً به گونه‌ای ساختاریافته است که توزیع فنی دنیای واقعی در مصاحبه‌های مهندسی جستجو و Elasticsearch در سطح سازمانی را منعکس کند.

• مبانی الاستیک‌سرچ (۲۰٪): معماری کلاستر، نقش نودها (Master, Data, Ingest, Coordinate)، استراتژی‌های شاردینگ، ایجاد ایندکس و جریان اجرای جستجوی توزیع‌شده.

• ایندکس‌گذاری و کوئری‌ها (۱۸٪): مدیریت چرخه عمر ایندکس (ILM)، تحلیل متن، توکنایزرها، آنالایزرهای سفارشی، مکانیسم‌های فیلترینگ عمیق، نکات مرتب‌سازی و روش‌های صفحه‌بندی عمیق (Scroll API در مقابل search_after).

• مدل‌سازی و تحلیل داده‌ها (۱۵٪): پیکربندی‌های Mapping (دینامیک در مقابل سخت‌گیرانه)، روابط Parent-Child، آبجکت‌های Nested، قالب‌های ایندکس، قالب‌های کامپوننت و متدیک‌های پیچیده Aggregation.

• مدیریت و نگهداری کلاستر (۱۲٪): فرآیندهای Bootstrap کلاستر، پروتکل‌های Discovery، فیلترینگ تخصیص شارد، کاهش اثرات Split-brain، پشتیبان‌گیری و بازیابی از طریق Snapshot API و مانیتورینگ وضعیت کلاستر.

• جستجو و بازیابی (۱۰٪): کوئری‌های Full-text در مقابل کوئری‌های Term-level، امتیازدهی اسکریپتی، سفارشی‌سازی معیارهای مرتبط بودن با پارامترهای BM25 و تنظیم دقت (Precision) و فراخوانی (Recall).

• Elastic Stack و یکپارچه‌سازی (۸٪): خط لوله‌های ورود داده با Logstash، ارسال‌کننده‌های سبک Beats، یکپارچه‌سازی داشبوردهای Kibana، نماهای داده (Data Views) و ایمن‌سازی کلاستر با ویژگی‌های X-Pack.

• مباحث پیشرفته الاستیک‌سرچ (۷٪): کوئری‌های Geo-point و Geo-shape، فیلدهای Dense Vector برای جستجوی معنایی، جستجوی بین-کلاستری (CCS)، تعامل با پلاگین‌های سفارشی و بهینه‌سازی عملکرد برای حجم‌های بالای نوشتن.

• عیب‌یابی و بهینه‌سازی (۱۰٪): تفسیر Slow Logها، تشخیص استثناهای Circuit Breaker، رفع مشکل شاردهای تخصیص‌نیافته (Unassigned Shards)، مدیریت Garbage Collection و تنظیم دقیق تنظیمات دینامیک ایندکس.

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

موفقیت در مصاحبه‌های مهندسی پلتفرم جستجو یا زیرساخت داده‌های مدرن، نیازمند چیزی بیش از دانستن APIهای ساده CRUD است؛ این امر مستلزم درک عمیق معماری مدیریت وضعیت توزیع‌شده و بهینه‌سازی عملکرد کوئری‌هاست. اپلیکیشن‌های سازمانی در مقیاس بالا بر کلاسترهایی تکیه دارند که باید میلیون‌ها سند را در ثانیه پردازش کرده و در عین حال تجمعی‌های (Aggregations) زیر-ثانیه‌ای ارائه دهند. من این بانک سوالات جامع را طراحی کردم تا فاصله بین اجرای کوئری‌های ساده در محیط لوکال و مسائل معماری سطح Production که مصاحبه‌کنندگان ارشد از شما می‌پرسند را پر کنم.

با ۵۵۰ سوال بسیار دقیق و دست اول، این منبع از تست‌های سطحی سینتکس فاصله گرفته است. من الگوهای واقعی JSON Query DSL، لاگ‌های تشخیص کلاستر، سناریوهای عدم تعادل شاردها و گلوگاه‌های Aggregation سنگین را کالبدشکافی کرده‌ام. هر سوال با یک تحلیل فنی جامع همراه است که توضیح می‌دهد چرا یک پیکربندی خاص موفق می‌شود و چرا جایگزین‌های دیگر تحت ترافیک شدید ایندکس‌گذاری یا جستجو شکست می‌خورند. چه به دنبال جایگاه مهندس جستجو باشید، چه برای مراحل معماری پلتفرم داده آماده شوید و چه بخواهید رفتار مقیاس‌پذیری کلاستر را پیش از یک بررسی فنی داخلی مرور کنید، این منبع تمرینات سخت‌گیرانه‌ای را فراهم می‌کند تا در اولین تلاش، با اطمینان کامل از مراحل فنی عبور کنید.

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

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

سوال ۱: رفع استثناهای حافظه و تخلفات Circuit Breaker در حین Aggregationهای سنگین

یک مهندس داده یک Aggregation از نوع terms (والد-فرزندی تودرتو) را روی مجموعه‌ای از داده‌ها شامل صدها میلیون رشته کلیدواژه منحصر‌به‌فرد اجرا می‌کند. نودی که درخواست را پردازش می‌کند، ناگهان عملیات را متوقف کرده و یک CircuitBreakingException برمی‌گرداند با این پیام که بار داده‌ها برای field data cache از حد حافظه پیکربندی شده فراتر رفته است. موثرترین رویکرد برای حل دائمی این خطا در حالی که قابلیت‌های کوئری حفظ شود، چیست؟

• الف) جایگزینی مکانیسم پیش‌فرض Garbage Collection با یک بازه sweep کوتاه‌تر در فایل jvm.options.

• ب) تغییر ساختار field data برای استفاده از doc values با اطمینان از اینکه فیلد به عنوان keyword مپ شده یا doc_values آن فعال است.

• ج) افزایش آستانه indices.breaker.fielddata.limit به ۹۵٪ از کل فضای تخصیص یافته JVM heap.

• د) اجبار به Refresh جهانی کلاستر با استفاده از API مربوط به POST /_refresh بلافاصله قبل از اجرای Aggregation.

• ه) ایندکس مجدد مجموعه داده با پیکربندی تک-شارد اولیه (Single Primary Shard) برای جلوگیری از سربار هماهنگی حافظه توزیع‌شده.

• و) پیاده‌سازی یک قالب ایندکس که تمام فیلدهای رشته ورودی را مجبور به استفاده از آرایه‌های Dynamic Runtime Mapping کند.

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

• پاسخ صحیح: ب

• چرا صحیح است: Fielddata برای فیلدهای متنی در فضای حافظه JVM heap ساخته می‌شود تا عملیات Aggregation یا مرتب‌سازی انجام شود. برای رشته‌های تحلیل‌نشده (keyword)، الاستیک‌سرچ به طور پیش‌فرض از doc values استفاده می‌کند که ساختارهای داده‌ای مبتنی بر دیسک و نزدیک به حافظه هستند و از اتمام حافظه heap جلوگیری می‌کنند. اگر یک فیلد متنی نیاز به Aggregation داشته باشد، به‌روزرسانی مپینگ‌ها به keyword یا فعال کردن doc_values، سربار حافظه را از JVM heap به کش سیستم فایل سیستم‌عامل منتقل کرده و خطاهای Circuit Breaker مربوط به fielddata را حذف می‌کند.

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

  • گزینه الف نادرست است: تغییر پارامترهای GC مانع از آن نمی‌شود که یک کوئری فعال در زمان اجرا از آستانه حافظه فراتر رود.

  • گزینه ج نادرست است: بالا بردن حد breaker به ۹۵٪ خطرناک است؛ این کار حفاظ‌های ایمنی را دور می‌زند و احتمالاً باعث کرش کامل نود با خطای OutOfMemoryError می‌شود.

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

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

  • گزینه و نادرست است: فیلدهای Runtime می‌توانند در فضای ذخیره‌سازی صرفه‌جویی کنند اما تاخیر پردازشی قابل توجهی ایجاد می‌کنند و محدودیت‌های بنیادی fielddata در حافظه را برای فیلدهای متنی تحلیل‌شده حل نمی‌کنند.

سوال ۲: تحلیل علت‌های ریشه‌ای برای شاردهای Replica تخصیص‌نیافته در یک کلاستر چند-نودی

پس از یک قطع اتصال شبکه کوتاه در یک کلاستر عملیاتی شامل سه نود Master-eligible و پنج نود Data، وضعیت سلامت کلاستر به yellow تغییر می‌کند. اجرای API مربوط به GET /_cluster/allocation/explain نشان می‌دهد که چندین شارد Replica در وضعیت UNASSIGNED باقی مانده‌اند و دلیل آن NODE_CONCURRENT_RECOVERIES ذکر شده است. مدیر سیستم چگونه باید این مشکل را برطرف کند؟

• الف) فراخوانی دستی دستور POST /_cluster/reroute با دستور لغو سخت‌گیرانه روی تمام مکان‌های شارد اولیه.

• ب) تنظیمات تخصیص را با افزایش موقت cluster.routing.allocation.node_concurrent_recoveries تغییر دهد تا انتقال‌های همزمان شاردهای بیشتری مجاز شود.

• ج) خاموش کردن نود Master برای تحریک یک چرخه انتخاب کلاستر کاملاً جدید در لایه‌های Data Plane.

• د) حذف رکوردهای Replica تخصیص‌نیافته با استفاده از Endpoint حذف سند برای اجبار به یک توالی مقداردهی اولیه تمیز.

• ه) تغییر تنظیمات دائمی ایندکس برای کاهش تعداد کل Replicaها به صفر و سپس تغییر فوری آن به دو.

• و) افزایش ظرفیت ذخیره‌سازی فیزیکی دیسک در نودهای Master برای رفع محدودیت‌های آستانه High-watermark دیسک.

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

• پاسخ صحیح: ب

• چرا صحیح است: وضعیت NODE_CONCURRENT_RECOVERIES نشان می‌دهد که کلاستر می‌داند شارد‌های Replica را کجا تخصیص دهد، اما برای محافظت از شبکه نود و I/O دیسک در برابر فشار بیش از حد، فرآیند بازیابی (Recovery) را محدود (Throttle) کرده است. افزایش موقت مقدار cluster.routing.allocation.node_concurrent_recoveries اجازه می‌دهد شاردهای بیشتری به طور همزمان و ایمن همگام‌سازی شوند و سرعت بازگشت به وضعیت سلامت Green افزایش یابد.

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

  • گزینه الف نادرست است: لغو شاردهای اولیه می‌تواند باعث حذف دائمی داده‌ها شود؛ در اینجا شاردهای اولیه سالم هستند و فقط Replicaها منتظر جایگاه تخصیص هستند.

  • گزینه ج نادرست است: اجبار به انتخاب Master، سربار محاسباتی غیرضروری به وضعیت کلاستر اضافه کرده و کارهای بازیابی فعال را به تاخیر می‌اندازد.

  • گزینه د نادرست است: شاردها را نمی‌توان با استفاده از APIهای حذف سند تغییر داد یا حذف کرد؛ این کار باعث خطای پارسینگ ساختاری می‌شود.

  • گزینه ه نادرست است: در حالی که تنظیم Replicaها روی صفر وضعیت yellow را پاک می‌کند، اما تمام نسخه‌های پشتیبان موجود را حذف می‌کند و کلاستر را مجبور می‌کند بعداً Replicaها را از ابتدا بسازد که باعث جهش غیرضروری در I/O دیسک می‌شود.

  • گزینه و نادرست است: شاردها به نودهای Data تخصیص می‌یابند، نه نودهای Master. واترمارک‌های دیسک برای حجم‌های ذخیره‌سازی اعمال می‌شوند که شاردهای داده در آن‌ها قرار دارند.

سوال ۳: انتخاب بهینه‌ترین روش برای صفحه‌بندی عمیق (Deep Pagination) در سرویس‌های جستجوی با حجم بالا

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

• الف) استفاده از صفحه‌بندی استاندارد با پارامترهای from و size با مقدار offset بالای from.

• ب) پیاده‌سازی یک کوئری تخصصی match_all ترکیبی با اجرای سریع توالی Scroll API.

• ج) پیکربندی یک کوئری جستجو با استفاده از پارامتر search_after همراه با یک توکن Point-in-Time (PIT).

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

• ه) قرار دادن کوئری در یک درخواست Profile برای حذف دینامیک محاسبات امتیازدهی در حین فیلترینگ استاندارد اسناد.

• و) بهره‌گیری از یک بلوک Multi-search API که محدوده‌های هدف ردیابی ایندکس را بر اساس فیلدهای متادیتای Timestamp سند بخش‌بندی می‌کند.

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

• پاسخ صحیح: ج

• چرا صحیح است: برای صفحه‌بندی عمیق در مجموعه‌های نتایج عظیم، استفاده از search_after به همراه شناسه Point-in-Time (PIT) مدرن‌ترین و بهینه‌ترین الگوی حافظه است. این روش به سیستم اجازه می‌دهد تکه‌های متوالی را به طور ایمن بخواند بدون اینکه مانند Scroll API قدیمی، Contextهای باز جستجو را نگه دارد و همچنین از محدودیت‌های حافظه from + size (که در ۱۰,۰۰۰ سند از طریق index.max_result_window به بن‌بست می‌رسد) جلوگیری می‌کند.

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

  • گزینه الف نادرست است: محاسبات استاندارد from + size مقیاس‌پذیری ضعیفی دارند؛ واکشی اسناد در عمق ایندکس، کلاستر را مجبور می‌کند تمام اسناد قبلی را در حافظه بارگذاری و مرتب کند که منجر به خطاهای ایمنی می‌شود.

  • گزینه ب نادرست است: Scroll API برای خروجی گرفتن (Export) کاربرد دارد اما برای اپلیکیشن‌های Real-time توصیه نمی‌شود، زیرا Contextهای وضعیت منجمد را باز نگه می‌دارد و در صورت افزایش درخواست‌های کاربر، منابع سنگین Heap را مصرف می‌کند.

  • گزینه د نادرست است: جابجایی کلیدهای Routing تغییری در نحوه ردیابی کرسرهای صفحه‌بندی روی بردار‌های مرتب شده در شاردهای مجزا ایجاد نمی‌کند.

  • گزینه ه نادرست است: پروفایل کردن کوئری‌ها سربار عیب‌یابی سنگینی اضافه می‌کند و محدودیت‌های ردیابی داده در صفحات نتایج عمیق را حل نمی‌کند.

  • گزینه و نادرست است: دسته‌های Multi-search کوئری‌های جداگانه را اجرا می‌کنند اما یک استراتژی کرسر یکپارچه و بدون تکرار را برای مجموعه‌های عظیم سند فراهم نمی‌کنند.

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

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

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

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

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

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

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

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