بهینه سازی عملکرد پرس و جو

برای عیب‌یابی کوئری‌های کند، از Query Explain برای به دست آوردن طرح اجرای کوئری و پروفایل اجرای زمان اجرا استفاده کنید. بخش زیر مراحلی را که می‌توانید برای بهینه‌سازی عملکرد کوئری بسته به پروفایل اجرا انجام دهید، شرح می‌دهد:

محدود کردن تعداد نتایج

از فیلد رکوردهای برگردانده شده در درخت اجرا برای شناسایی اینکه آیا پرس‌وجو اسناد زیادی را برمی‌گرداند یا خیر، استفاده کنید. محدود کردن تعداد اسناد برگردانده شده با استفاده از مرحله limit(...) را در نظر بگیرید. این کار اندازه بایت سریالی نتایج را هنگام بازگشت به کلاینت‌ها از طریق شبکه کاهش می‌دهد. در مواردی که گره Limit قبل از یک گره MajorSort قرار دارد، موتور پرس‌وجو می‌تواند گره‌های Limit و MajorSort را با هم ادغام کند و یک مرتب‌سازی و تحقق کامل در حافظه را با یک مرتب‌سازی TopN جایگزین کند و نیاز حافظه برای پرس‌وجو را کاهش دهد.

محدود کردن اندازه سند نتیجه

محدود کردن اندازه سند برگردانده شده را با استفاده از select(...) برای برگرداندن فقط فیلدهای مورد نیاز یا remove_fields(...) برای حذف فیلدهای بیش از حد بزرگ در نظر بگیرید. این به کاهش هزینه محاسباتی و حافظه پردازش نتایج میانی و اندازه بایت سریالی نتایج هنگام برگرداندن به کلاینت‌ها از طریق شبکه کمک می‌کند. در مواردی که تمام فیلدهای ارجاع شده در پرس و جو توسط یک فهرست معمولی پوشش داده می‌شوند، این امر همچنین به پرس و جو اجازه می‌دهد تا به طور کامل توسط اسکن فهرست پوشش داده شود و از نیاز به واکشی اسناد از حافظه اصلی جلوگیری شود.

استفاده از شاخص‌ها

برای تنظیم و بهینه‌سازی ایندکس‌ها از دستورالعمل‌های زیر استفاده کنید.

تشخیص اینکه آیا پرس‌وجو از یک شاخص استفاده می‌کند یا خیر

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

شناسایی یک شاخص بهتر

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

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

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

ایجاد ایندکس‌ها

برای ایجاد شاخص‌ها، مستندات مدیریت شاخص را دنبال کنید. برای اطمینان از اینکه پرس‌وجوی شما می‌تواند از شاخص‌ها استفاده کند، شاخص‌های معمولی (نه چندکلیدی) با فیلدهایی به ترتیب زیر ایجاد کنید:

1. تمام فیلدهایی که در عملگرهای تساوی استفاده خواهند شد. برای به حداکثر رساندن احتمال استفاده مجدد در بین پرس‌وجوها، فیلدها را به ترتیب نزولی وقوع فیلدها در عملگرهای تساوی در بین پرس‌وجوها مرتب کنید.
2. تمام فیلدهایی که بر اساس آنها مرتب‌سازی انجام خواهد شد (به همان ترتیب).
3. فیلدهایی که در عملگرهای برد یا نابرابری به ترتیب نزولی انتخاب محدودیت پرس و جو استفاده خواهند شد.
4. فیلدهایی که به عنوان بخشی از یک پرس‌وجو در فهرست بازگردانده می‌شوند: گنجاندن چنین فیلدهایی در فهرست به فهرست اجازه می‌دهد تا پرس‌وجو را پوشش دهد و از واکشی سند از حافظه اصلی جلوگیری کند.

اسکن اجباری فهرست یا جدول

وقتی از Cloud Firestore کوئری می‌گیرید، به طور خودکار از هر ایندکسی که احتمالاً کوئری را کارآمدتر می‌کند، استفاده می‌کند. در نتیجه، نیازی به تعیین ایندکس برای کوئری‌های خود ندارید. با این حال، برای کوئری‌هایی که برای حجم کاری شما حیاتی هستند، توصیه می‌کنیم برای عملکرد پایدارتر از گزینه forceIndex استفاده کنید.

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

شما می‌توانید از گزینه forceIndex در هر مرحله ورودی در عملیات Pipeline برای لغو طرح پرس‌وجوی پیش‌فرض Cloud Firestore و تعیین یک شاخص برای استفاده یا برای اسکن اجباری جدول استفاده کنید.

یک شاخص خاص را اجباری کنید

برای اینکه کوئری را مجبور به استفاده از یک اندیس خاص کنید، شناسه اندیس را به صورت رشته به گزینه forceIndex ارائه دهید. می‌توانید شناسه اندیس را از کنسول یا از پیام‌های خطا پیدا کنید.

مثال زیر برنامه‌ریز را مجبور می‌کند از اندیس با شناسه CICAgOi36pgK استفاده کند:

// Force Planner to use Index ID CICAgOi36pgK
await db.pipeline()
  .collectionGroup({ collectionId: "customers", forceIndex: "CICAgOi36pgK" })
  .limit(100)
  .execute();
test.firestore.js

// Force Planner to use Index ID CICAgOi36pgK
Pipeline.Snapshot results1 =
    firestore.pipeline()
      .collectionGroup("customers", new CollectionGroupOptions()
          .withHints(new CollectionHints().withForceIndex("CICAgOi36pgK")))
      .limit(100)
      .execute().get();
PipelineSnippets.java

// Force Planner to use Index ID CICAgOi36pgK
snapshot1 := client.Pipeline().
	CollectionGroup("customers", firestore.WithForceIndex("CICAgOi36pgK")).
	Limit(100).
	Execute(ctx)
pipeline_snippets_general.go

در اینجا چند مورد استفاده برای اعمال یک شاخص خاص آورده شده است:

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

اگر اندیس مشخص شده پیدا نشود، پرس و جو با شکست مواجه می‌شود.

اسکن جدول را اجباری کنید

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

مثال زیر اسکن جدول را اجباری می‌کند:

// Force Planner to only do a Full-Table Scan
db.pipeline()
  .collectionGroup({ collectionId: "customers", forceIndex: "primary" })
  .limit(100)

شما می‌توانید در موارد زیر از اسکن جدول استفاده کنید:

• برای مجموعه‌های بسیار کوچک که سربار فهرست‌بندی توجیه‌پذیر نیست.
• برای پرس‌وجوهایی که به اکثر اسناد موجود در یک مجموعه دسترسی دارند.
• برای اشکال‌زدایی و مقایسه عملکرد.

استفاده از forceIndex با توضیح پرس و جو

شما می‌توانید از Query Explain ، به خصوص با گزینه analyze ، برای مشاهده اثرات forceIndex استفاده کنید:

• با بررسی گره‌های برگ درخت اجرا برای شناسه شاخص، تأیید کنید که Cloud Firestore از شاخص مشخص شده در forceIndex استفاده کرده است.
• هنگام استفاده از forceIndex: "primary" تأیید کنید که یک گره TableScan در طرح ظاهر می‌شود.
• معیارهای عملکرد - مانند تأخیر، اسناد اسکن شده و ورودی‌های ایندکس شده اسکن شده - را با و بدون forceIndex مقایسه کنید تا عملکرد پرس و جو را به طور دقیق تنظیم کنید.

بهترین شیوه‌ها برای forceIndex

در حالی که forceIndex کنترل بیشتری بر اجرای پرس‌وجو ارائه می‌دهد، بهینه‌ساز پرس‌وجوی Cloud Firestore عموماً برای اکثر موارد استفاده کارآمد است. هنگام استفاده از forceIndex ، بهترین شیوه‌های زیر را در نظر بگیرید:

• forceIndex با احتیاط استفاده کنید. اگر با طرح پرس‌وجوی پیش‌فرض، عملکرد نامطلوبی مشاهده کردید، قبل از اعمال یک شاخص، از Query Explain برای تشخیص مشکل استفاده کنید.
• هنگام استفاده از forceIndex ، حتماً کوئری‌های خود را با حجم داده‌های واقعی آزمایش کنید تا عملکرد و ویژگی‌های هزینه آنها را درک کنید.
• از استفاده از forceIndex: "primary" در مجموعه‌های بزرگ در محیط‌های عملیاتی خودداری کنید.