انواع ایندکس در Cloud Firestore

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

این صفحه دو نوع ایندکس که Cloud Firestore از آنها استفاده می‌کند، ایندکس‌های خودکار و ایندکس‌های دستی را شرح می‌دهد.

تعریف و ساختار شاخص

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

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

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

یک فهرست پشت هر پرس و جو

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

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

Cloud Firestore شامل ویژگی‌هایی است که میزان زمانی را که باید برای مدیریت ایندکس صرف کنید، کاهش می‌دهد. ایندکس‌های مورد نیاز برای ابتدایی‌ترین کوئری‌ها به طور خودکار برای شما ایجاد می‌شوند. همزمان با استفاده و آزمایش برنامه، Cloud Firestore به شما کمک می‌کند تا ایندکس‌های اضافی مورد نیاز برنامه خود را شناسایی و ایجاد کنید .

انواع شاخص

Cloud Firestore از دو نوع ایندکس استفاده می‌کند: خودکار و دستی . ایندکس‌های دستی و خودکار در نحوه مدیریت آنها متفاوت هستند.

ایندکس‌های خودکار

به طور پیش‌فرض، Cloud Firestore به طور خودکار برای هر فیلد موجود در اسناد یک مجموعه، ایندکس می‌سازد. این ایندکس‌های تک فیلدی به شما امکان می‌دهند بسیاری از پرس‌وجوهای اساسی را انجام دهید. شما می‌توانید ایندکس‌های خودکار را با پیکربندی تنظیمات ایندکس‌گذاری خودکار پایگاه داده و معافیت‌های ایندکس مدیریت کنید.

پیش‌فرض‌های خودکار ایندکس

Cloud Firestore از تنظیمات پیش‌فرض زیر برای ایندکس‌های خودکار استفاده می‌کند:

  • برای هر فیلد غیر آرایه‌ای و غیر نقشه‌ای، Cloud Firestore دو شاخص دامنه مجموعه تعریف می‌کند، یکی در حالت صعودی و دیگری در حالت نزولی.

  • برای هر فیلد نقشه، Cloud Firestore موارد زیر را ایجاد می‌کند:

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

  • برای هر فیلد آرایه در یک سند، Cloud Firestore موارد زیر را ایجاد می‌کند:

    • یک اندیس صعودی در محدوده مجموعه برای کل مقدار آرایه
    • یک اندیس نزولی در محدوده مجموعه برای کل مقدار آرایه
    • یک اندیس شامل آرایه با دامنه مجموعه.

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

معافیت‌های خودکار شاخص

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

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

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

برای ایجاد و مدیریت معافیت‌های خودکار شاخص، به مدیریت شاخص‌ها مراجعه کنید.

شاخص‌های دستی

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

Cloud Firestore از ایندکس‌های دستی برای پشتیبانی از پرس‌وجوهایی که قبلاً توسط ایندکس‌های خودکار پشتیبانی نمی‌شوند، استفاده می‌کند.

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

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

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

حالت‌های فهرست‌بندی و دامنه‌های پرس‌وجو

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

حالت‌های فهرست

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

حالت فهرست توضیحات
صعودی_به_سمت_بالا از عبارات کوئری < ، <= ، == ، >= > != ، in و not-in در فیلد پشتیبانی می‌کند و از مرتب‌سازی نتایج به ترتیب صعودی بر اساس مقدار این فیلد پشتیبانی می‌کند.
نزولی_به‌سمت پایین از عبارات پرس‌وجوی < ، <= ، == ، >= > != ، in و not-in در فیلد پشتیبانی می‌کند و از مرتب‌سازی نتایج به ترتیب نزولی بر اساس مقدار این فیلد پشتیبانی می‌کند.
آرایه شامل از عبارات پرس‌وجوی array-contains و array-contains-any در فیلد پشتیبانی می‌کند.
بردار از عبارت‌های کوئری FindNearest در فیلد پشتیبانی می‌کند.

دامنه‌های پرس‌وجو

هر ایندکس به یک مجموعه یا یک گروه از مجموعه‌ها محدود می‌شود. این به عنوان محدوده پرس‌وجوی ایندکس شناخته می‌شود:

دامنه مجموعه
Cloud Firestore به طور پیش‌فرض ایندکس‌هایی با دامنه مجموعه ایجاد می‌کند. این ایندکس‌ها از کوئری‌هایی پشتیبانی می‌کنند که نتایج را از یک مجموعه واحد برمی‌گردانند.

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

ترتیب پیش‌فرض و فیلد __name__

علاوه بر مرتب‌سازی اسناد بر اساس حالت‌های شاخص مشخص شده برای هر فیلد (صعودی یا نزولی)، شاخص‌ها مرتب‌سازی نهایی را بر اساس فیلد __name__ هر سند اعمال می‌کنند. مقدار فیلد __name__ برابر با مسیر کامل سند تنظیم می‌شود. این بدان معناست که اسناد موجود در مجموعه نتایج با مقادیر فیلد یکسان، بر اساس مسیر سند مرتب می‌شوند.

به طور پیش‌فرض، فیلد __name__ در همان جهت آخرین فیلد مرتب‌شده در تعریف اندیس مرتب می‌شود. برای مثال:

مجموعه فیلدهای ایندکس شده دامنه پرس و جو
شهرها نام ، __name__ مجموعه
شهرها حالت ، __name__ مجموعه
شهرها کشور ، جمعیت ، __name__ مجموعه

برای مرتب‌سازی نتایج بر اساس جهت غیر پیش‌فرض __name__ ، باید آن اندیس را ایجاد کنید.

ویژگی‌های شاخص

شاخصی که امکان اجرای پرس‌وجو را با بیشترین کارایی فراهم می‌کند، با ویژگی‌های زیر تعریف می‌شود:

  • فیلدهای مورد استفاده در فیلترهای برابری
  • فیلدهای مورد استفاده در مرتب‌سازی
  • فیلدهای مورد استفاده در فیلترهای محدوده و نابرابری (که از قبل در ترتیب مرتب‌سازی لحاظ نشده‌اند)
  • فیلدهای مورد استفاده در تجمیع‌ها (که از قبل در مرتب‌سازی‌ها و فیلترهای دامنه و نابرابری گنجانده نشده‌اند)

Cloud Firestore نتایج جستجوها را به شرح زیر محاسبه می‌کند:

  1. ایندکس مربوط به مجموعه، ویژگی‌های فیلتر، عملگرهای فیلتر و ترتیب مرتب‌سازی کوئری را شناسایی می‌کند.
  2. موقعیت اندیس را که اسکن از آن شروع می‌شود، مشخص می‌کند. موقعیت شروع با فیلترهای برابری پرس‌وجو پیشوند شده و با فیلترهای محدوده و نابرابری در اولین فیلد orderBy پایان می‌یابد.
  3. شروع به اسکن فهرست می‌کند و هر سندی را که تمام فیلترها را برآورده می‌کند، برمی‌گرداند تا زمانی که فرآیند اسکن یکی از موارد زیر را انجام دهد:
    • با سندی مواجه می‌شود که شرایط فیلتر را ندارد و تأیید می‌کند که هیچ سند بعدی هرگز به طور کامل شرایط فیلتر را برآورده نخواهد کرد.
    • به انتهای شاخص می‌رسد.
    • حداکثر تعداد نتایج درخواستی توسط پرس و جو را جمع آوری می کند.

مثال نمایه‌سازی

با ایجاد خودکار ایندکس‌های تک فیلدی برای شما، Cloud Firestore به برنامه شما اجازه می‌دهد تا به سرعت از ابتدایی‌ترین کوئری‌های پایگاه داده پشتیبانی کند. ایندکس‌های تک فیلدی به شما امکان می‌دهند کوئری‌های ساده‌ای را بر اساس مقادیر فیلد و مقایسه‌کننده‌های < ، <= ، == ، >= ، > و in انجام دهید. برای فیلدهای آرایه‌ای، به شما امکان می‌دهند کوئری‌های array-contains و array-contains-any را انجام دهید.

برای روشن شدن موضوع، مثال‌های زیر را از نقطه نظر ایجاد شاخص بررسی کنید. قطعه کد زیر چند سند city را در یک مجموعه cities ایجاد می‌کند و فیلدهای name ، state ، country ، capital ، population و regions را برای هر سند تنظیم می‌کند:

وب 
var citiesRef = db.collection("cities");

citiesRef.doc("SF").set({
    name: "San Francisco", state: "CA", country: "USA",
    capital: false, population: 860000,
    regions: ["west_coast", "norcal"] });
citiesRef.doc("LA").set({
    name: "Los Angeles", state: "CA", country: "USA",
    capital: false, population: 3900000,
    regions: ["west_coast", "socal"] });
citiesRef.doc("DC").set({
    name: "Washington, D.C.", state: null, country: "USA",
    capital: true, population: 680000,
    regions: ["east_coast"] });
citiesRef.doc("TOK").set({
    name: "Tokyo", state: null, country: "Japan",
    capital: true, population: 9000000,
    regions: ["kanto", "honshu"] });
citiesRef.doc("BJ").set({
    name: "Beijing", state: null, country: "China",
    capital: true, population: 21500000,
    regions: ["jingjinji", "hebei"] });

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

مجموعه فیلد ایندکس شده دامنه پرس و جو
شهرها نام مجموعه
شهرها حالت مجموعه
شهرها کشور مجموعه
شهرها سرمایه مجموعه
شهرها جمعیت مجموعه
شهرها مناطق مجموعه
شهرها نام مجموعه
شهرها حالت مجموعه
شهرها کشور مجموعه
شهرها سرمایه مجموعه
شهرها جمعیت مجموعه
شهرها مناطق مجموعه
شهرها array-contains نواحی است مجموعه

پرس‌وجوهای پشتیبانی‌شده توسط ایندکس‌های تک‌فیلدی

با استفاده از این ایندکس‌های تک فیلدی که به صورت خودکار ایجاد می‌شوند، می‌توانید کوئری‌های ساده‌ای مانند موارد زیر را اجرا کنید:

وب 
const stateQuery = citiesRef.where("state", "==", "CA");
const populationQuery = citiesRef.where("population", "<", 100000);
const nameQuery = citiesRef.where("name", ">=", "San Francisco");

شما همچنین می‌توانید in تساوی مرکب ( == ) ایجاد کنید:

وب 
citiesRef.where('country', 'in', ["USA", "Japan", "China"])

// Compound equality queries
citiesRef.where("state", "==", "CO").where("name", "==", "Denver")
citiesRef.where("country", "==", "USA")
         .where("capital", "==", false)
         .where("state", "==", "CA")
         .where("population", "==", 860000)

اگر نیاز به اجرای یک کوئری ترکیبی دارید که از مقایسه‌ی دامنه ( < ، <= ، > یا >= ) استفاده می‌کند، یا اگر نیاز به مرتب‌سازی بر اساس فیلد متفاوتی دارید، باید یک فهرست دستی برای آن کوئری ایجاد کنید.

اندیس array-contains به شما امکان می‌دهد تا فیلد آرایه regions را جستجو کنید:

وب 
citiesRef.where("regions", "array-contains", "west_coast")
// array-contains-any and array-contains use the same indexes
citiesRef.where("regions", "array-contains-any", ["west_coast", "east_coast"])

پرس‌وجوهای پشتیبانی‌شده توسط ایندکس‌های دستی

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

وب 
citiesRef.where("country", "==", "USA").orderBy("population", "asc")
citiesRef.where("country", "==", "USA").where("population", "<", 3800000)
citiesRef.where("country", "==", "USA").where("population", ">", 690000)
// in and == clauses use the same index
citiesRef.where("country", "in", ["USA", "Japan", "China"])
         .where("population", ">", 690000)

این کوئری‌ها به اندیس زیر نیاز دارند. از آنجایی که کوئری از تساوی ( == یا in ) برای فیلد country استفاده می‌کند، می‌توانید از حالت اندیس صعودی یا نزولی برای این فیلد استفاده کنید. به طور پیش‌فرض، عبارات نامساوی، ترتیب مرتب‌سازی صعودی را بر اساس فیلد موجود در عبارت نامساوی اعمال می‌کنند.

مجموعه فیلدهای ایندکس شده دامنه پرس و جو
شهرها کشور، جمعیت ( ) مجموعه

برای اجرای همان کوئری‌ها اما با ترتیب مرتب‌سازی نزولی، به یک اندیس اضافی در جهت نزولی برای population نیاز دارید:

وب 
citiesRef.where("country", "==", "USA").orderBy("population", "desc")

citiesRef.where("country", "==", "USA")
         .where("population", "<", 3800000)
         .orderBy("population", "desc")

citiesRef.where("country", "==", "USA")
         .where("population", ">", 690000)
         .orderBy("population", "desc")

citiesRef.where("country", "in", ["USA", "Japan", "China"])
         .where("population", ">", 690000)
         .orderBy("population", "desc")
مجموعه فیلدهای ایندکس شده دامنه پرس و جو
شهرها کشور ، جمعیت مجموعه
شهرها کشور ، جمعیت مجموعه

برای جلوگیری از افت عملکرد ناشی از ادغام شاخص‌ها ، توصیه می‌کنیم یک شاخص ایجاد کنید تا یک پرس‌وجوی array-contains یا array-contains-any را با عبارات اضافی ترکیب کند:

وب 
citiesRef.where("regions", "array-contains", "east_coast")
         .where("capital", "==", true)

// array-contains-any and array-contains use the same index
citiesRef.where("regions", "array-contains-any", ["west_coast", "east_coast"])
         .where("capital", "==", true)
مجموعه فیلدهای ایندکس شده دامنه پرس و جو
شهرها آرایه-شامل برچسب‌ها، (یا ) با حروف بزرگ مجموعه

پرس‌وجوهای پشتیبانی‌شده توسط ایندکس‌های گروه‌های مجموعه

برای نمایش یک فهرست با محدوده گروه مجموعه، یک زیرمجموعۀ landmarks به برخی از اسناد city اضافه کنید:

وب 
var citiesRef = db.collection("cities");

citiesRef.doc("SF").collection("landmarks").doc().set({
    name: "Golden Gate Bridge",
    category : "bridge" });
citiesRef.doc("SF").collection("landmarks").doc().set({
    name: "Golden Gate Park",
    category : "park" });

citiesRef.doc("DC").collection("landmarks").doc().set({
    name: "National Gallery of Art",
    category : "museum" });
citiesRef.doc("DC").collection("landmarks").doc().set({
    name: "National Mall",
    category : "park" });

با استفاده از فهرست تک فیلدی زیر با دامنه مجموعه، می‌توانید بر اساس فیلد category ، از مجموعه landmarks یک شهر پرس‌وجو کنید:

مجموعه فیلدهای ایندکس شده دامنه پرس و جو
نقاط دیدنی دسته بندی (یا ) مجموعه
وب 
citiesRef.doc("SF").collection("landmarks").where("category", "==", "park")
citiesRef.doc("SF").collection("landmarks").where("category", "in", ["park", "museum"])

اگر مثلاً می‌خواهید از مکان‌های دیدنی در تمام شهرها پرس‌وجو کنید، این پرس‌وجو را روی گروه مجموعه‌ای که شامل تمام مجموعه‌های landmarks است، اجرا می‌کنید. همچنین باید یک فهرست تک‌فیلدی landmarks با دامنه گروه مجموعه‌ای فعال کنید:

مجموعه فیلدهای ایندکس شده دامنه پرس و جو
نقاط دیدنی دسته بندی (یا ) گروه جمع‌آوری

با فعال بودن این فهرست، می‌توانید از گروه مجموعه landmarks پرس‌وجو کنید:

وب 
var landmarksGroupRef = db.collectionGroup("landmarks");

landmarksGroupRef.where("category", "==", "park")
landmarksGroupRef.where("category", "in", ["park", "museum"])

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

برای مثال، می‌توانید کوئری گروه‌بندی مجموعه زیر را بدون فعال کردن یک اندیس اضافی اجرا کنید:

وب 
db.collectionGroup("landmarks").get()

ورودی‌های فهرست

شاخص‌های پیکربندی‌شده‌ی پروژه‌ی شما و ساختار یک سند، تعداد ورودی‌های شاخص برای یک سند را تعیین می‌کنند. ورودی‌های شاخص، به سمت محدودیت تعداد ورودی‌های شاخص، شمارش می‌شوند.

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

سند

/cities/SF

city_name : "San Francisco"
temperatures : {summer: 67, winter: 55}
neighborhoods : ["Mission", "Downtown", "Marina"]

ایندکس‌های خودکار

  • نام شهر ASC
  • نام شهر نزولی
  • محله‌های ASC
  • محله‌ها DESC
  • دماهای ASC
  • دما نزولی
  • دما.تابستان ASC
  • دما.تابستان DESC
  • دما.زمستان ASC
  • دما.زمستان DESC
  • آرایه شامل محله‌ها است

شاخص‌های دستی

  • نام شهر ASC، آرایه محله‌ها
  • نام شهر DESC، محله‌ها ARRAY

ورودی‌های فهرست

این پیکربندی نمایه‌سازی منجر به ورودی‌های نمایه زیر برای سند می‌شود:

فهرست داده‌های فهرست‌بندی شده
ورودی‌های خودکار فهرست
نام شهر ASC city_name: "سانفرانسیسکو"
نام شهر نزولی city_name: "سانفرانسیسکو"
محله‌های ASC محله‌ها: ["ماموریت"، "مرکز شهر"، "مارینا"]
محله‌ها DESC محله‌ها: ["ماموریت"، "مرکز شهر"، "مارینا"]
دماهای ASC دما: {تابستان: ۶۷، زمستان: ۵۵}
دما نزولی دما: {تابستان: ۶۷، زمستان: ۵۵}
دما.تابستان ASC دما.تابستان: ۶۷
دما.تابستان DESC دما.تابستان: ۶۷
دما.زمستان ASC دما.زمستان: ۵۵
دما.زمستان DESC دما.زمستان: ۵۵
آرایه شامل محله‌ها است محله‌ها: «ماموریت»
آرایه شامل محله‌ها است محله‌ها: «مرکز شهر»
آرایه شامل محله‌ها است محله‌ها: "مارینا"
ورودی‌های فهرست دستی
نام شهر ASC، آرایه محله‌ها نام شهر: "سانفرانسیسکو"، محله‌ها: "ماموریت"
نام شهر ASC، آرایه محله‌ها city_name: "سانفرانسیسکو", neighborhoods: "مرکز شهر"
نام شهر ASC، آرایه محله‌ها نام شهر: "سانفرانسیسکو"، محله‌ها: "مارینا"
نام شهر DESC، محله‌ها ARRAY نام شهر: "سانفرانسیسکو"، محله‌ها: "ماموریت"
نام شهر DESC، محله‌ها ARRAY city_name: "سانفرانسیسکو", neighborhoods: "مرکز شهر"
نام شهر DESC، محله‌ها ARRAY نام شهر: "سانفرانسیسکو"، محله‌ها: "مارینا"

شاخص‌ها و قیمت‌گذاری

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

استفاده از ادغام ایندکس

اگرچه Cloud Firestore برای هر پرس‌وجو از یک شاخص استفاده می‌کند، اما لزوماً به یک شاخص برای هر پرس‌وجو نیاز ندارد. برای پرس‌وجوهایی با چندین عبارت تساوی ( == ) و به صورت اختیاری، یک عبارت orderBy ، Cloud Firestore می‌تواند از شاخص‌های موجود دوباره استفاده کند. Cloud Firestore می‌تواند شاخص‌ها را برای فیلترهای تساوی ساده ادغام کند تا شاخص‌های مورد نیاز برای پرس‌وجوهای تساوی بزرگتر را بسازد.

شما می‌توانید با شناسایی موقعیت‌هایی که می‌توانید از ادغام شاخص استفاده کنید، هزینه‌های شاخص‌گذاری را کاهش دهید. برای مثال، در یک مجموعه restaurants برای یک برنامه رتبه‌بندی رستوران:

  • رستوران‌ها

    • برگر تایم

      name : "Burger Thyme"
      category : "burgers"
      city : "San Francisco"
      editors_pick : true
      star_rating : 4

این برنامه از کوئری‌هایی مانند زیر استفاده می‌کند. این برنامه از ترکیبی از عبارات تساوی برای category ، city و editors_pick استفاده می‌کند و در عین حال مرتب‌سازی را همیشه بر اساس star_rating صعودی انجام می‌دهد:

وب 
db.collection("restaurants").where("category", "==", "burgers")
                            .orderBy("star_rating")

db.collection("restaurants").where("city", "==", "San Francisco")
                            .orderBy("star_rating")

db.collection("restaurants").where("category", "==", "burgers")
                            .where("city", "==", "San Francisco")
                            .orderBy("star_rating")

db.collection("restaurants").where("category", "==", "burgers")
                            .where("city", "==", "San Francisco")
                            .where("editors_pick", "==", true )
                            .orderBy("star_rating")

شما می‌توانید برای هر کوئری یک اندیس ایجاد کنید:

مجموعه فیلدهای ایندکس شده دامنه پرس و جو
رستوران‌ها رده ، رتبه‌بندی ستاره‌ای مجموعه
رستوران‌ها شهر ، رتبه‌بندی ستاره مجموعه
رستوران‌ها رده ، شهر ، رتبه‌بندی ستاره مجموعه
رستوران‌ها رده‌بندی ، شهر ، انتخاب ویرایشگر ، رتبه‌بندی ستاره مجموعه

به عنوان یک راه حل بهتر، می‌توانید با بهره‌گیری از قابلیت Cloud Firestore در ادغام شاخص‌ها برای بندهای تساوی، تعداد شاخص‌ها را کاهش دهید:

مجموعه فیلدهای ایندکس شده دامنه پرس و جو
رستوران‌ها رده ، رتبه‌بندی ستاره‌ای مجموعه
رستوران‌ها شهر ، رتبه‌بندی ستاره مجموعه
رستوران‌ها ویرایشگران، رتبه‌بندی مجموعه

این مجموعه از ایندکس‌ها نه تنها کوچک‌تر است، بلکه از یک پرس‌وجوی اضافی نیز پشتیبانی می‌کند:

وب 
db.collection("restaurants").where("editors_pick", "==", true)
                            .orderBy("star_rating")

محدودیت‌های نمایه‌سازی

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

حد جزئیات
حداکثر تعداد شاخص‌های مرکب برای یک پایگاه داده
حداکثر تعداد پیکربندی‌های تک فیلدی برای یک پایگاه داده

یک پیکربندی سطح فیلد می‌تواند شامل چندین پیکربندی برای یک فیلد باشد. برای مثال، یک معافیت نمایه‌سازی تک فیلدی و یک سیاست TTL در یک فیلد، به عنوان یک پیکربندی فیلد در محدوده‌ی مجاز محاسبه می‌شوند.

حداکثر تعداد ورودی‌های فهرست برای هر سند

۴۰،۰۰۰

تعداد ورودی‌های فهرست، مجموع موارد زیر برای یک سند است:

  • تعداد ورودی‌های فهرست تک فیلدی
  • تعداد ورودی‌های فهرست ترکیبی

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

حداکثر تعداد فیلدها در یک فهرست مرکب ۱۰۰
حداکثر اندازه یک ورودی فهرست

۷.۵ کیلوبایت

برای دیدن نحوه محاسبه اندازه ورودی شاخص Cloud Firestore ، به اندازه ورودی شاخص مراجعه کنید.

حداکثر مجموع اندازه‌های ورودی‌های فهرست یک سند

۸ مگابایت

حجم کل، مجموع موارد زیر برای یک سند است:

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

    ۱۵۰۰ بایت

    مقادیر فیلدهای بالای ۱۵۰۰ بایت کوتاه می‌شوند. پرس‌وجوهایی که شامل مقادیر فیلد کوتاه‌شده هستند ممکن است نتایج متناقضی را برگردانند.

    بهترین شیوه‌های نمایه‌سازی

    برای اکثر برنامه‌ها، می‌توانید برای مدیریت فهرست‌های خود به نمایه‌سازی خودکار و پیوندهای پیام خطا اعتماد کنید. با این حال، ممکن است بخواهید در موارد زیر استثنائات نمایه‌سازی خودکار را اضافه کنید:

    مورد توضیحات
    میدان‌های رشته‌ای بزرگ

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

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

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

    برای مثال، در یک مورد استفاده از اینترنت اشیا با نرخ نوشتن بالا، مجموعه‌ای شامل اسنادی با فیلد مهر زمانی ممکن است به مرز ۵۰۰ نوشتن در ثانیه برسد.

    فیلدهای TTL

    اگر از سیاست‌های TTL (زمان زنده ماندن) استفاده می‌کنید، توجه داشته باشید که فیلد TTL باید یک مهر زمانی باشد. نمایه‌سازی در فیلدهای TTL به طور پیش‌فرض فعال است و می‌تواند در نرخ‌های ترافیک بالاتر بر عملکرد تأثیر بگذارد. به عنوان بهترین روش، معافیت‌های نمایه‌سازی خودکار را برای فیلدهای TTL خود اضافه کنید.

    فیلدهای آرایه‌ای یا نقشه‌ای بزرگ

    فیلدهای آرایه یا نقشه بزرگ می‌توانند به مرز ۴۰،۰۰۰ ورودی فهرست در هر سند برسند. اگر بر اساس یک فیلد آرایه یا نقشه بزرگ پرس‌وجو نمی‌کنید، باید آن را از فهرست‌بندی معاف کنید.

    اگر از پرس‌وجوهایی با عملگرهای دامنه و نابرابری در چندین فیلد استفاده می‌کنید، به ملاحظات نمایه‌سازی که باید برای بهینه‌سازی عملکرد و هزینه پرس‌وجوهای Cloud Firestore در نظر بگیرید، مراجعه کنید.

    برای اطلاعات بیشتر در مورد نحوه حل مشکلات ایندکس‌گذاری (خطاهای مربوط به تعداد نمایش ایندکس، INVALID_ARGUMENT ) به صفحه عیب‌یابی مراجعه کنید.

    ،

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

    این صفحه دو نوع ایندکس که Cloud Firestore از آنها استفاده می‌کند، ایندکس‌های خودکار و ایندکس‌های دستی را شرح می‌دهد.

    تعریف و ساختار شاخص

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

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

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

    یک فهرست پشت هر پرس و جو

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

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

    Cloud Firestore شامل ویژگی‌هایی است که میزان زمانی را که باید برای مدیریت ایندکس صرف کنید، کاهش می‌دهد. ایندکس‌های مورد نیاز برای ابتدایی‌ترین کوئری‌ها به طور خودکار برای شما ایجاد می‌شوند. همزمان با استفاده و آزمایش برنامه، Cloud Firestore به شما کمک می‌کند تا ایندکس‌های اضافی مورد نیاز برنامه خود را شناسایی و ایجاد کنید .

    انواع شاخص

    Cloud Firestore از دو نوع ایندکس استفاده می‌کند: خودکار و دستی . ایندکس‌های دستی و خودکار در نحوه مدیریت آنها متفاوت هستند.

    ایندکس‌های خودکار

    به طور پیش‌فرض، Cloud Firestore به طور خودکار برای هر فیلد موجود در اسناد یک مجموعه، ایندکس می‌سازد. این ایندکس‌های تک فیلدی به شما امکان می‌دهند بسیاری از پرس‌وجوهای اساسی را انجام دهید. شما می‌توانید ایندکس‌های خودکار را با پیکربندی تنظیمات ایندکس‌گذاری خودکار پایگاه داده و معافیت‌های ایندکس مدیریت کنید.

    پیش‌فرض‌های خودکار ایندکس

    Cloud Firestore از تنظیمات پیش‌فرض زیر برای ایندکس‌های خودکار استفاده می‌کند:

    • برای هر فیلد غیر آرایه‌ای و غیر نقشه‌ای، Cloud Firestore دو شاخص دامنه مجموعه تعریف می‌کند، یکی در حالت صعودی و دیگری در حالت نزولی.

    • برای هر فیلد نقشه، Cloud Firestore موارد زیر را ایجاد می‌کند:

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

    • برای هر فیلد آرایه در یک سند، Cloud Firestore موارد زیر را ایجاد می‌کند:

      • یک اندیس صعودی در محدوده مجموعه برای کل مقدار آرایه
      • یک اندیس نزولی در محدوده مجموعه برای کل مقدار آرایه
      • یک اندیس شامل آرایه با دامنه مجموعه.

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

    معافیت‌های خودکار شاخص

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

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

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

    برای ایجاد و مدیریت معافیت‌های خودکار شاخص، به مدیریت شاخص‌ها مراجعه کنید.

    شاخص‌های دستی

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

    Cloud Firestore از ایندکس‌های دستی برای پشتیبانی از پرس‌وجوهایی که قبلاً توسط ایندکس‌های خودکار پشتیبانی نمی‌شوند، استفاده می‌کند.

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

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

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

    حالت‌های فهرست‌بندی و دامنه‌های پرس‌وجو

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

    حالت‌های فهرست

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

    حالت فهرست توضیحات
    صعودی_به_سمت_بالا از عبارات کوئری < ، <= ، == ، >= > != ، in و not-in در فیلد پشتیبانی می‌کند و از مرتب‌سازی نتایج به ترتیب صعودی بر اساس مقدار این فیلد پشتیبانی می‌کند.
    نزولی_به‌سمت پایین از عبارات پرس‌وجوی < ، <= ، == ، >= > != ، in و not-in در فیلد پشتیبانی می‌کند و از مرتب‌سازی نتایج به ترتیب نزولی بر اساس مقدار این فیلد پشتیبانی می‌کند.
    آرایه شامل از عبارات پرس‌وجوی array-contains و array-contains-any در فیلد پشتیبانی می‌کند.
    بردار از عبارت‌های کوئری FindNearest در فیلد پشتیبانی می‌کند.

    دامنه‌های پرس‌وجو

    هر ایندکس به یک مجموعه یا یک گروه از مجموعه‌ها محدود می‌شود. این به عنوان محدوده پرس‌وجوی ایندکس شناخته می‌شود:

    دامنه مجموعه
    Cloud Firestore به طور پیش‌فرض ایندکس‌هایی با دامنه مجموعه ایجاد می‌کند. این ایندکس‌ها از کوئری‌هایی پشتیبانی می‌کنند که نتایج را از یک مجموعه واحد برمی‌گردانند.

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

    ترتیب پیش‌فرض و فیلد __name__

    علاوه بر مرتب‌سازی اسناد بر اساس حالت‌های شاخص مشخص شده برای هر فیلد (صعودی یا نزولی)، شاخص‌ها مرتب‌سازی نهایی را بر اساس فیلد __name__ هر سند اعمال می‌کنند. مقدار فیلد __name__ برابر با مسیر کامل سند تنظیم می‌شود. این بدان معناست که اسناد موجود در مجموعه نتایج با مقادیر فیلد یکسان، بر اساس مسیر سند مرتب می‌شوند.

    به طور پیش‌فرض، فیلد __name__ در همان جهت آخرین فیلد مرتب‌شده در تعریف اندیس مرتب می‌شود. برای مثال:

    مجموعه فیلدهای ایندکس شده دامنه پرس و جو
    شهرها نام ، __name__ مجموعه
    شهرها حالت ، __name__ مجموعه
    شهرها کشور ، جمعیت ، __name__ مجموعه

    برای مرتب‌سازی نتایج بر اساس جهت غیر پیش‌فرض __name__ ، باید آن اندیس را ایجاد کنید.

    ویژگی‌های شاخص

    شاخصی که امکان اجرای پرس‌وجو را با بیشترین کارایی فراهم می‌کند، با ویژگی‌های زیر تعریف می‌شود:

    • فیلدهای مورد استفاده در فیلترهای برابری
    • فیلدهای مورد استفاده در مرتب‌سازی
    • فیلدهای مورد استفاده در فیلترهای محدوده و نابرابری (که از قبل در ترتیب مرتب‌سازی لحاظ نشده‌اند)
    • فیلدهای مورد استفاده در تجمیع‌ها (که از قبل در مرتب‌سازی‌ها و فیلترهای دامنه و نابرابری گنجانده نشده‌اند)

    Cloud Firestore نتایج جستجوها را به شرح زیر محاسبه می‌کند:

    1. ایندکس مربوط به مجموعه، ویژگی‌های فیلتر، عملگرهای فیلتر و ترتیب مرتب‌سازی کوئری را شناسایی می‌کند.
    2. موقعیت اندیس را که اسکن از آن شروع می‌شود، مشخص می‌کند. موقعیت شروع با فیلترهای برابری پرس‌وجو پیشوند شده و با فیلترهای محدوده و نابرابری در اولین فیلد orderBy پایان می‌یابد.
    3. شروع به اسکن فهرست می‌کند و هر سندی را که تمام فیلترها را برآورده می‌کند، برمی‌گرداند تا زمانی که فرآیند اسکن یکی از موارد زیر را انجام دهد:
      • با سندی مواجه می‌شود که شرایط فیلتر را ندارد و تأیید می‌کند که هیچ سند بعدی هرگز به طور کامل شرایط فیلتر را برآورده نخواهد کرد.
      • به انتهای شاخص می‌رسد.
      • حداکثر تعداد نتایج درخواستی توسط پرس و جو را جمع آوری می کند.

    مثال نمایه‌سازی

    با ایجاد خودکار ایندکس‌های تک فیلدی برای شما، Cloud Firestore به برنامه شما اجازه می‌دهد تا به سرعت از ابتدایی‌ترین کوئری‌های پایگاه داده پشتیبانی کند. ایندکس‌های تک فیلدی به شما امکان می‌دهند کوئری‌های ساده‌ای را بر اساس مقادیر فیلد و مقایسه‌کننده‌های < ، <= ، == ، >= ، > و in انجام دهید. برای فیلدهای آرایه‌ای، به شما امکان می‌دهند کوئری‌های array-contains و array-contains-any را انجام دهید.

    برای روشن شدن موضوع، مثال‌های زیر را از نقطه نظر ایجاد شاخص بررسی کنید. قطعه کد زیر چند سند city را در یک مجموعه cities ایجاد می‌کند و فیلدهای name ، state ، country ، capital ، population و regions را برای هر سند تنظیم می‌کند:

    وب 
    var citiesRef = db.collection("cities");

citiesRef.doc("SF").set({
    name: "San Francisco", state: "CA", country: "USA",
    capital: false, population: 860000,
    regions: ["west_coast", "norcal"] });
citiesRef.doc("LA").set({
    name: "Los Angeles", state: "CA", country: "USA",
    capital: false, population: 3900000,
    regions: ["west_coast", "socal"] });
citiesRef.doc("DC").set({
    name: "Washington, D.C.", state: null, country: "USA",
    capital: true, population: 680000,
    regions: ["east_coast"] });
citiesRef.doc("TOK").set({
    name: "Tokyo", state: null, country: "Japan",
    capital: true, population: 9000000,
    regions: ["kanto", "honshu"] });
citiesRef.doc("BJ").set({
    name: "Beijing", state: null, country: "China",
    capital: true, population: 21500000,
    regions: ["jingjinji", "hebei"] });

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

    مجموعه فیلد ایندکس شده دامنه پرس و جو
    شهرها نام مجموعه
    شهرها حالت مجموعه
    شهرها کشور مجموعه
    شهرها سرمایه مجموعه
    شهرها جمعیت مجموعه
    شهرها مناطق مجموعه
    شهرها نام مجموعه
    شهرها حالت مجموعه
    شهرها کشور مجموعه
    شهرها سرمایه مجموعه
    شهرها جمعیت مجموعه
    شهرها regions مجموعه
    شهرها array-contains regions مجموعه

    Queries supported by single-field indexes

    Using these automatically created single-field indexes, you can run simple queries like the following:

    وب 
    const stateQuery = citiesRef.where("state", "==", "CA");
const populationQuery = citiesRef.where("population", "<", 100000);
const nameQuery = citiesRef.where("name", ">=", "San Francisco");

    You can also create in and compound equality ( == ) queries:

    وب 
    citiesRef.where('country', 'in', ["USA", "Japan", "China"])

// Compound equality queries
citiesRef.where("state", "==", "CO").where("name", "==", "Denver")
citiesRef.where("country", "==", "USA")
         .where("capital", "==", false)
         .where("state", "==", "CA")
         .where("population", "==", 860000)

    If you need to run a compound query that uses a range comparison ( < , <= , > , or >= ) or if you need to sort by a different field, you must create a manual index for that query.

    The array-contains index lets you query the regions array field:

    وب 
    citiesRef.where("regions", "array-contains", "west_coast")
// array-contains-any and array-contains use the same indexes
citiesRef.where("regions", "array-contains-any", ["west_coast", "east_coast"])

    Queries supported by manual indexes

    Create manual indexes to support compound queries not already supported by automatic single-field indexes. For example, you would need a manual index for the following queries:

    وب 
    citiesRef.where("country", "==", "USA").orderBy("population", "asc")
citiesRef.where("country", "==", "USA").where("population", "<", 3800000)
citiesRef.where("country", "==", "USA").where("population", ">", 690000)
// in and == clauses use the same index
citiesRef.where("country", "in", ["USA", "Japan", "China"])
         .where("population", ">", 690000)

    These queries require the following index. Since the query uses an equality ( == or in ) for the country field, you can use an ascending or descending index mode for this field. By default, inequality clauses apply an ascending sort order based on the field in the inequality clause.

    مجموعه Fields indexed Query scope
    شهرها (or ) country, population مجموعه

    To run the same queries but with a descending sort order, you need an additional index in the descending direction for population :

    وب 
    citiesRef.where("country", "==", "USA").orderBy("population", "desc")

citiesRef.where("country", "==", "USA")
         .where("population", "<", 3800000)
         .orderBy("population", "desc")

citiesRef.where("country", "==", "USA")
         .where("population", ">", 690000)
         .orderBy("population", "desc")

citiesRef.where("country", "in", ["USA", "Japan", "China"])
         .where("population", ">", 690000)
         .orderBy("population", "desc")
    مجموعه Fields indexed Query scope
    شهرها country, population مجموعه
    شهرها country , population مجموعه

    To avoid performance loss caused by index merging , we recommend that you create an index to combine an array-contains or array-contains-any query with additional clauses:

    وب 
    citiesRef.where("regions", "array-contains", "east_coast")
         .where("capital", "==", true)

// array-contains-any and array-contains use the same index
citiesRef.where("regions", "array-contains-any", ["west_coast", "east_coast"])
         .where("capital", "==", true)
    مجموعه Fields indexed Query scope
    شهرها array-contains tags, (or ) capital مجموعه

    Queries supported by collection group indexes

    To demonstrate an index with collection group scope, add a landmarks sub-collection to some of the city documents:

    وب 
    var citiesRef = db.collection("cities");

citiesRef.doc("SF").collection("landmarks").doc().set({
    name: "Golden Gate Bridge",
    category : "bridge" });
citiesRef.doc("SF").collection("landmarks").doc().set({
    name: "Golden Gate Park",
    category : "park" });

citiesRef.doc("DC").collection("landmarks").doc().set({
    name: "National Gallery of Art",
    category : "museum" });
citiesRef.doc("DC").collection("landmarks").doc().set({
    name: "National Mall",
    category : "park" });

    Using the following single-field index with collection scope, you can query a single city's landmarks collection based on the category field:

    مجموعه Fields indexed Query scope
    نقاط دیدنی (or ) category مجموعه
    وب 
    citiesRef.doc("SF").collection("landmarks").where("category", "==", "park")
citiesRef.doc("SF").collection("landmarks").where("category", "in", ["park", "museum"])

    If you're interested in querying the landmarks across all cities, for example, you run this query on the collection group that consists of all landmarks collections. You must also enable a landmarks single-field index with collection group scope:

    مجموعه Fields indexed Query scope
    نقاط دیدنی (or ) category Collection group

    With this index enabled, you can query the landmarks collection group:

    وب 
    var landmarksGroupRef = db.collectionGroup("landmarks");

landmarksGroupRef.where("category", "==", "park")
landmarksGroupRef.where("category", "in", ["park", "museum"])

    To run a collection group query that returns filtered or ordered results, you must enable a corresponding index with collection group scope. Collection group queries that don't filter or order results, however, don't require any additional index definitions.

    For example, you can run the following collection group query without enabling an additional index:

    وب 
    db.collectionGroup("landmarks").get()

    Index entries

    Your project's configured indexes and the structure of a document determine the number of index entries for a document. Index entries count towards the index entry count limit .

    The following example demonstrates the index entries of a document.

    سند

    /cities/SF

    city_name : "San Francisco"
    temperatures : {summer: 67, winter: 55}
    neighborhoods : ["Mission", "Downtown", "Marina"]

    Automatic indexes

    • city_name ASC
    • city_name DESC
    • neighborhoods ASC
    • neighborhoods DESC
    • temperatures ASC
    • temperatures DESC
    • temperatures.summer ASC
    • temperatures.summer DESC
    • temperatures.winter ASC
    • temperatures.winter DESC
    • neighborhoods Array Contains

    Manual indexes

    • city_name ASC, neighborhoods ARRAY
    • city_name DESC, neighborhoods ARRAY

    Index entries

    This indexing configuration results in the following index entries for the document:

    فهرست Indexed data
    Automatic index entries
    city_name ASC city_name: "San Francisco"
    city_name DESC city_name: "San Francisco"
    neighborhoods ASC neighborhoods: ["Mission", "Downtown", "Marina"]
    neighborhoods DESC neighborhoods: ["Mission", "Downtown", "Marina"]
    temperatures ASC temperatures: {summer: 67, winter: 55}
    temperatures DESC temperatures: {summer: 67, winter: 55}
    temperatures.summer ASC temperatures.summer: 67
    temperatures.summer DESC temperatures.summer: 67
    temperatures.winter ASC temperatures.winter: 55
    temperatures.winter DESC temperatures.winter: 55
    neighborhoods Array Contains neighborhoods: "Mission"
    neighborhoods Array Contains neighborhoods: "Downtown"
    neighborhoods Array Contains neighborhoods: "Marina"
    Manual index entries
    city_name ASC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Mission"
    city_name ASC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Downtown"
    city_name ASC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Marina"
    city_name DESC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Mission"
    city_name DESC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Downtown"
    city_name DESC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Marina"

    Indexes and pricing

    Indexes contribute to the storage costs of your application. For more information about how to calculate storage size for indexes, see Index entry size .

    Use index merging

    Although Cloud Firestore uses an index for every query, it doesn't necessarily require one index per query. For queries with multiple equality ( == ) clauses and, optionally, an orderBy clause, Cloud Firestore can re-use existing indexes. Cloud Firestore can merge the indexes for simple equality filters to build the indexes needed for larger equality queries.

    You can reduce indexing costs by identifying situations where you can use index merging. For example, in a restaurants collection for a restaurant rating app:

    • restaurants

      • burgerthyme

        name : "Burger Thyme"
        category : "burgers"
        city : "San Francisco"
        editors_pick : true
        star_rating : 4

    This app uses queries like the following. The app uses combinations of equality clauses for category , city , and editors_pick while always sorting by ascending star_rating :

    وب 
    db.collection("restaurants").where("category", "==", "burgers")
                            .orderBy("star_rating")

db.collection("restaurants").where("city", "==", "San Francisco")
                            .orderBy("star_rating")

db.collection("restaurants").where("category", "==", "burgers")
                            .where("city", "==", "San Francisco")
                            .orderBy("star_rating")

db.collection("restaurants").where("category", "==", "burgers")
                            .where("city", "==", "San Francisco")
                            .where("editors_pick", "==", true )
                            .orderBy("star_rating")

    You could create an index for each query:

    مجموعه Fields indexed Query scope
    رستوران‌ها category, star_rating مجموعه
    رستوران‌ها city, star_rating مجموعه
    رستوران‌ها category, city, star_rating مجموعه
    رستوران‌ها category, city, editors_pick, star_rating مجموعه

    As a better solution, you can reduce the number of indexes by taking advantage of Cloud Firestore 's ability to merge indexes for equality clauses:

    مجموعه Fields indexed Query scope
    رستوران‌ها category, star_rating مجموعه
    رستوران‌ها city, star_rating مجموعه
    رستوران‌ها editors_pick, star_rating مجموعه

    Not only is this set of indexes smaller, it also supports an additional query:

    وب 
    db.collection("restaurants").where("editors_pick", "==", true)
                            .orderBy("star_rating")

    Indexing limits

    The following limits apply to indexes. For more information about quotas and limits, see Quotas and Limits .

    حد جزئیات
    Maximum number of composite indexes for a database
    Maximum number of single-field configurations for a database

    One field level configuration can contain multiple configurations for the same field. For example, a single-field indexing exemption and a TTL policy on the same field count as one field configuration towards the limit.

    Maximum number of index entries for each document

    ۴۰،۰۰۰

    The number of index entries is the sum of the following for a document:

    • The number of single-field index entries
    • The number of composite index entries

    To see how Cloud Firestore turns a document and a set of indexes into index entries, see this index entry count example .

    Maximum number of fields in a composite index ۱۰۰
    Maximum size of an index entry

    7.5 KiB

    To see how Cloud Firestore calculates index entry size, see index entry size .

    Maximum sum of the sizes of a document's index entries

    8 MiB

    The total size is the sum of the following for a document:

  • The sum of the size of a document's single-field index entries
  • The sum of the size of a document's composite index entries
    • Maximum size of an indexed field value

    1500 bytes

    Field values over 1500 bytes are truncated. Queries involving truncated field values may return inconsistent results.

    Indexing best practices

    For most apps, you can rely on automatic indexing and the error message links to manage your indexes. However, you may want to add automatic indexing exemptions in the following cases:

    مورد توضیحات
    Large string fields

    If you have a string field that often holds long string values that you don't use for querying, you can cut storage costs by exempting the field from indexing.

    High write rates to a collection containing documents with sequential values

    If you index a field that increases or decreases sequentially between documents in a collection, like a timestamp, then the maximum write rate to the collection is 500 writes per second. If you don't query based on the field with sequential values, you can exempt the field from indexing to bypass this limit.

    In an IoT use case with a high write rate, for example, a collection containing documents with a timestamp field might approach the 500 writes per second limit.

    TTL fields

    If you use TTL (time-to-live) policies , note that the TTL field must be a timestamp. Indexing on TTL fields is enabled by default and can affect performance at higher traffic rates. As a best practice, add automatic indexing exemptions for your TTL fields.

    Large array or map fields

    Large array or map fields can approach the limit of 40,000 index entries per document. If you are not querying based on a large array or map field, you should exempt it from indexing.

    If you are using queries with range and inequality operators on multiple fields, see the indexing considerations that you should consider to optimize the performance and cost of Cloud Firestore queries.

    For more information about how to resolve indexing issues (index fanout, INVALID_ARGUMENT errors) see the troubleshooting page .