بررسی کوئری‌ها
در صورتی که وضعیت کلی کلاستر خوب باشد. ممکن است پاسخ به برخی از کوئری‌های کند باشد و در عمل کارایی مناسب نداشته باشند.
استخراج کوئری‌های ارسال شده به کلاستر
در حالت عادی کوئری‌های الستیک به صورت مستقیم در کدهای
c#
تولید می‌شود و به کلاستر ارسال می‌شود.
در لاگ‌های پرفورمنس فعلی امکان مشاهده‌ی زمان کل درخواست از دید سرویس
DW
در کلید
details.response_time
قابل مشاهده است.
زمان پاسخ کوئری که در پاسخ کلاستر وجود دارد و مستقل از پهنای باند و گلوگاه‌های شبکه‌ای است در کلید
details.took
قابل مشاهده است.
تعداد نتایجی که در کوئری واکشی می‌شوند در کلید
details.fetch_count
مشخص می‌شود. در برخی از کوئری‌های فقط
Aggregation
ها اهمیت دارند و چون به خود سندها نیاز نیست اندازه و تعداد اسناد واکشی شده
0
است.
در صورتی که برای درخواست‌هایی که
تعداد کمی سند واکشی کرده‌اند، اختلاف زمان بین
details.response_time
و
details.took
زیاد باشد به معنی اختلال شبکه‌ای بین سرویس و کلاستر الستیک است و در این حالت شبکه گلوگاه شده است.
در درخواست‌هایی که تعداد زیادی سند واکشی می‌کنند این اختلاف به دلیل زمان ارسال اطلاعات در شبکه قابل تفسیر است.
مشاهده‌ی دقیق کوئری ارسال شده
برای مشاهده‌ی متن کوئری
در سرویس انبارداده ستاره لازم است کانفیگ
LogLevel
را در فایل
LADW.config
به مقدار
Trace
تغییر داده شود.
بعد از این تغییر و ریست کردن سرویس تمام کوئری هایی که به الستیک‌سرچ ارسال می‌شود به صورت کامل در لاگ‌های پرفورمنس در کلید
details.debugInforamtion_query
ثبت می‌شود.
با بررسی دقیق کوئری می‌توان نابهینگی‌های احتمالی را شناسایی کرد و نتایج را بررسی کرد.
استفاده از Query profiler برای بررسی دقیق علت کندی
در صورتی که یک کوئری داشته باشیم و بخواهیم دقیقا دلیل کندی و اینکه روی کدام شارد اجرای این کوئری طولانی است را تشخیص دهیم از ابزار Query profiler استفاده می‌شود.
توضیحات کلی این ویژگی در کیبانا در این آدرس قابل مشاهده است.
زمانی که Build scorer زیاد است
در صورتی که در یک شارد تعداد اسناد ذخیره شده زیاد باشد. (در این مورد منظور از زیاد بیش‌از 100 میلیون سن د است) بررسی و امتیازدهی به همه‌ی سندها در یک شارد ممکن است بسیار طولانی بشود و کندی‌های زیادی ایجاد کند.
در این حالت لازم است کوئری‌ها به صورت بهینه‌تری تغییر کند که باعث بهبود عملکرد می‌شود و کندی‌های زیاد را کاهش می‌دهد.
استفاده از کوئری Filter به جای Must
همان‌طور که در این آدرس توضیح داده شده است استفاده از Filter به دلیل عدم امتیازدهی به اسناد بهینه‌تر است.
نابهینگی کوئری Terms
یکی از کوئری‌هایی که در الستیک‌سرج مطرح است
Terms query
طبق تست‌های انجام شده این کوئری در زمانی که تعداد اسناد یک شارد خیلی زیاد می‌شود بهینه نیست و بهتر است از
Term query
استفاده شود. و در صورت نیاز انتخاب چند مقدار از
Bool query
و عبارت
Should
استفاده شود.
در انبارداده ستاره
برای مواجه با این مشکل کانفیگی برای تغییر منطق کوئری ایجاد شده است. در صورتی که تعداد منابع مورد نظر در یک کوئری کم‌تر از مقدار کانفیگ
RecordWarehouseIdQueryThreshold
باشد.
کوئری با ساختار
Bool query
و لیستی از
Should ها
قرار می‌گیرد.
در صورتی که تعداد منابع خیلی زیاد شود برای جلوگیری از زیاد شدن تعداد کلازها و عدم مواجه با خطای
max clause
الستیک‌سرچ کوئری‌ها به صورت
Terms
ساخته می‌شود.