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

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

فیلترهای محدوده و نابرابری روی چندین فیلد

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

نسخه وب ۹ ماژولار 

const q = query(
    collection(db, "cities"),
    where('population', '>', 1000000),
    where('density', '<', 10000),
  );

سویفت 

let query = db.collection("cities")
  .whereField("population", isGreaterThan: 1000000)
  .whereField("density", isLessThan: 10000)

هدف-سی 

FIRQuery *query =
 [[[[self.db collectionWithPath:@"cities"]
queryWhereField:@"population" isGreaterThan:@1000000]
   queryWhereField:@"density" isLessThan:@10000];

جاوا اندروید 

Query query = db.collection("cities")
 .whereGreaterThan("population", 1000000)
 .whereLessThan("density", 10000);

کاتلین+KTX اندروید 

val query = db.collection("cities")
 .whereGreaterThan("population", 1000000)
 .whereLessThan("density", 10000)

برو 

   query := client.Collection("cities").
      Where("population", ">", 1000000).
      Where("density", "<", 10000)

جاوا 

db.collection("cities")
  .whereGreaterThan("population", 1000000)
  .whereLessThan("density", 10000);

نود جی اس 

db.collection("cities")
  .where('population', '>', 1000000),
  .where('density', '<', 10000)

پایتون 

from google.cloud import firestore

db = firestore.Client()
query = db.collection("cities")
.where("population", ">", 1000000)
.where("density", "<", 10000)

پی اچ پی 

$collection = $db->collection('samples/php/cities');
$chainedQuery = $collection
    ->where('population', '>', 1000000)
    ->where('density', '<', 10000);

query_filter_compound_multi_ineq.php

سی شارپ 

CollectionReference citiesRef = db.Collection("cities");
Query query = citiesRef
    .WhereGreaterThan("Population", 1000000)
    .WhereLessThan("Density", 10000);
QuerySnapshot querySnapshot = await query.GetSnapshotAsync();
foreach (DocumentSnapshot documentSnapshot in querySnapshot)
{
    var name = documentSnapshot.GetValue<string>("Name");
    var population = documentSnapshot.GetValue<int>("Population");
    var density = documentSnapshot.GetValue<int>("Density");
    Console.WriteLine($"City '{name}' returned by query. Population={population}; Density={density}");
}
Program.cs

روبی 

query = cities_ref.where("population", ">", "1000000")
                  .where("density", "<", 10000)

سی++ 

CollectionReference cities_ref = db->Collection("cities");
Query query = cities_ref.WhereGreaterThan("population", FieldValue::Integer(1000000))
                       .WhereLessThan("density", FieldValue::Integer(10000));

وحدت 

CollectionReference citiesRef = db.Collection("cities");
Query query = citiesRef.WhereGreaterThan("population", 1000000)
                      .WhereLessThan("density", 10000);

دارت 

final citiesRef = FirebaseFirestore.instance.collection('cities')
final query = citiesRef.where("population", isGreaterThan: 1000000)
                  .where("density", isLessThan: 10000);

ملاحظات نمایه‌سازی

قبل از اجرای کوئری‌هایتان، درباره کوئری‌ها و مدل داده Cloud Firestore مطالعه کنید.

در Cloud Firestore ، عبارت ORDER BY در یک پرس‌وجو تعیین می‌کند که کدام ایندکس‌ها می‌توانند برای ارائه پرس‌وجو استفاده شوند. برای مثال، یک پرس‌وجوی ORDER BY a ASC, b ASC به یک ایندکس مرکب روی فیلدهای a ASC, b ASC نیاز دارد.

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

فرض کنید می‌خواهید در مجموعه‌ای از کارمندان جستجو کنید و کارمندانی از ایالات متحده را پیدا کنید که حقوق آنها بیش از ۱۰۰۰۰۰ دلار و تعداد سال‌های تجربه آنها بیشتر از ۰ باشد. بر اساس درک شما از مجموعه داده‌ها، می‌دانید که محدودیت حقوق نسبت به محدودیت تجربه گزینشی‌تر است. شاخص ایده‌آلی که تعداد اسکن‌های شاخص را کاهش می‌دهد، (salary [...], experience [...]) خواهد بود. بنابراین، پرس‌وجویی که سریع و مقرون‌به‌صرفه باشد، salary قبل از experience مرتب می‌کند و به شکل زیر خواهد بود:

جاوا 

db.collection("employees")
  .whereGreaterThan("salary", 100000)
  .whereGreaterThan("experience", 0)
  .orderBy("salary")
  .orderBy("experience");

نود جی اس 

db.collection("employees")
  .where("salary", ">", 100000)
  .where("experience", ">", 0)
  .orderBy("salary")
  .orderBy("experience");

پایتون 

db.collection("employees")
  .where("salary", ">", 100000)
  .where("experience", ">", 0)
  .order_by("salary")
  .order_by("experience");

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

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

فیلدهای فهرست را بر اساس تساوی‌ها مرتب کنید و به دنبال آن، انتخابی‌ترین محدوده یا فیلد نابرابری را قرار دهید.

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

برای اطلاعات بیشتر در مورد ایجاد شاخص‌های کارآمد، به ویژگی‌های شاخص مراجعه کنید.

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

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

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

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

جاوا 

db.collection("employees")
  .whereGreaterThan("salary", 100000)
  .orderBy("salary")
  .get()
  .addOnSuccessListener(new OnSuccessListener<QuerySnapshot>() {
        @Override
        public void onSuccess(QuerySnapshot queryDocumentSnapshots) {
          // Order results by `experience`
        }
    });;

نود جی اس 

const querySnapshot = await db.collection('employees')
                              .where("salary", ">", 100000)
                              .orderBy("salary")
                              .get();

// Order results by `experience`

پایتون 

results = db.collection("employees")
            .where("salary", ">", 100000)
            .order_by("salary")
            .stream()

// Order results by `experience`

اگرچه اضافه کردن مرتب‌سازی بر اساس experience به پرس‌وجو، همان مجموعه اسناد را به دست می‌دهد و از مرتب‌سازی مجدد نتایج روی کلاینت‌ها جلوگیری می‌کند، اما پرس‌وجو ممکن است ورودی‌های شاخص نامربوط بیشتری نسبت به پرس‌وجوی قبلی بخواند. دلیل این امر آن است که Cloud Firestore همیشه شاخصی را ترجیح می‌دهد که پیشوند فیلدهای شاخص آن با عبارت order by پرس‌وجو مطابقت داشته باشد. اگر experience به عبارت order by اضافه شود، Cloud Firestore شاخص (experience [...], salary [...]) برای محاسبه نتایج پرس‌وجو انتخاب می‌کند. از آنجایی که هیچ محدودیت دیگری بر روی experience وجود ندارد، Cloud Firestore قبل از اعمال فیلتر salary برای یافتن مجموعه نتیجه نهایی، تمام ورودی‌های شاخص مجموعه employees را می‌خواند. این بدان معناست که ورودی‌های شاخصی که فیلتر salary را برآورده نمی‌کنند، همچنان خوانده می‌شوند و در نتیجه تأخیر و هزینه پرس‌وجو افزایش می‌یابد.

قیمت‌گذاری

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

برای اطلاعات دقیق، به صفحه قیمت‌گذاری مراجعه کنید.

محدودیت‌ها

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

  • پرس‌وجوهایی با فیلترهای محدوده یا نابرابری در فیلدهای سند و فقط محدودیت‌های برابری در کلید سند (__name__) پشتیبانی نمی‌شوند.
  • Cloud Firestore تعداد فیلدهای محدوده یا نابرابری را به 10 محدود می‌کند. این کار برای جلوگیری از پرهزینه شدن اجرای پرس‌وجوها انجام می‌شود.

قدم بعدی چیست؟