Ringkasan antarmuka kueri
Halaman ini menjelaskan berbagai antarmuka yang tersedia untuk mengakses data dalam database Firestore dalam mode Native.
Antarmuka operasi
Mode native mendukung dua antarmuka untuk mengakses data:
Operasi Pipeline
Antarmuka kueri yang lebih baru untuk Firestore. Operasi Pipeline mendukung sintaksis composable berbasis tahap. Anda membuat operasi dengan menentukan serangkaian tahap berurutan yang dieksekusi secara sistematis. Hal ini memungkinkan operasi yang kompleks, seperti memfilter hasil agregasi, yang sebelumnya tidak dapat dilakukan di antarmuka asli (operasi Core).
Operasi Pipeline hanya tersedia di edisi Firestore Enterprise.
Operasi Core
Operasi Core adalah antarmuka asli untuk Firestore.
Operasi Core menggunakan sintaksis penggabungan metode (.where(), .orderBy(), .get()) pada referensi dokumen atau koleksi untuk mengambil dokumen. Pengurutan tahap kueri dilakukan secara otomatis dan operasi agregasi bersifat terbatas.
Operasi Core tersedia di edisi Enterprise dan Standard, tetapi default indeks untuk kedua edisi sangatlah berbeda. Lihat bagian berikutnya untuk detail lebih lanjut.
Perbedaan antarmuka antar-edisi
Dengan diperkenalkannya dukungan mode Native di edisi Enterprise, operasi Firestore Core dan Pipeline kini telah tersedia. Saat menggunakan operasi Core di edisi Enterprise, perilaku indeks dan model penetapan harga baru menyediakan kemampuan yang lebih banyak daripada di edisi Standard.
| Fitur | Edisi standar | Edisi perusahaan |
| Operasi yang Didukung | Hanya operasi Firestore Core. | Mendukung operasi Firestore Core dan Pipeline, serta operasi Firestore dengan kompatibilitas MongoDB. |
| Persyaratan Pengindeksan | Semua kueri memerlukan indeks. | Kueri tidak memerlukan indeks. |
| Pembuatan Indeks | Indeks otomatis dibuat untuk setiap kolom. Anda dapat membuat indeks komposit secara manual. | Tidak ada indeks otomatis yang dibuat. Indeks harus dikelola secara manual. |
| Kolom Terindeks | Kolom __name__ tambahan otomatis ditambahkan ke kolom terindeks jika belum ada. | __name__ tidak otomatis ditambahkan ke kolom terindeks. Anda harus menentukan __name__ secara eksplisit di kolom terindeks jika kolom tersebut penting untuk aplikasi Anda. |
| Kerapatan Indeks | Semua indeks bersifat sparse. Entri indeks hanya ada jika semua kolom yang ditentukan dalam indeks ada dalam dokumen. | Defaultnya adalah dense, dengan entri indeks ada meskipun tidak ada kolom yang ditentukan dalam indeks yang ada dalam dokumen.
Selain itu, indeks sparse dapat diaktifkan, dengan entri indeks ada jika setidaknya satu kolom dalam indeks ada dalam dokumen. |
| Normalisasi Urutan Pengurutan | Klausul pengurutan kueri dinormalisasi dengan menambahkan kolom ketidaksetaraan dan kolom __name__ di akhir (jika belum ada). Hal ini menjamin pengurutan hasil yang unik dan deterministik, terlepas dari kolom lain yang ada dalam klausul pengurutan. | Tidak ada normalisasi urutan pengurutan. Urutan pengurutan seperti sort a ASC hanya menjamin bahwa hasil diurutkan berdasarkan kolom a. Firestore akan menggunakan indeks yang ada untuk menampilkan hasil dalam urutan yang paling efisien. Oleh karena itu, jika a tidak unik di antara kumpulan hasil, urutan hasil dapat bervariasi dari kueri ke kueri, bergantung pada konfigurasi indeks, strategi eksekusi, dll. Untuk menjamin pengurutan hasil yang unik dan deterministik, Anda harus menambahkan kolom unik seperti __name__ ke urutan pengurutan. |
| Performa &Biaya Kueri | Kueri umumnya berperforma baik karena adanya persyaratan indeks. | Mengoptimalkan performa dan biaya kueri dengan membuat indeks. Anda dapat mengidentifikasi indeks yang tidak ada menggunakan Query Explain dan Query Insights.
Kueri tanpa indeks berisiko menjadi berperforma buruk dan mahal seiring pertumbuhan set data sehingga memerlukan pemantauan dan penyesuaian. |
| Biaya Overhead Pengindeksan | Tidak ada biaya untuk penulisan indeks karena indeks bersifat otomatis. | Menulis entri indeks memakai unit tulis saat dokumen terkait ditulis (1 unit tulis per 1 KiB ukuran entri indeks). Anda dapat menghemat biaya penyimpanan karena tidak membuat entri indeks untuk setiap kolom. |
| Model Penagihan (Pembacaan/Penulisan/Penghapusan) | Dikenai biaya per pembacaan, penulisan, dan penghapusan dokumen. | Dikenai biaya per pembacaan dan penulisan (porsi). Pembacaan dikenai biaya untuk setiap Unit Baca (porsi 4 KiB). Penulisan dan penghapusan digabungkan menjadi Unit Tulis (porsi 1 KiB). |
| Harga Dasar (per Juta)
Harga yang ditampilkan adalah untuk region us-central1 |
Pembacaan: $0,03 per 100.000 dokumen (atau $0,30 per juta).
Penulisan: $0,09 per 100.000 dokumen (atau $0,90 per juta). Penghapusan: $0,01 per 100.000 dokumen (atau $0,10 per juta) |
Unit Baca: $0,05 per 1 juta unit baca.
Unit Tulis: $0,26 per 1 juta unit tulis. Pada umumnya, harga lebih rendah jika dokumen berukuran di bawah 4 KiB dibandingkan dengan biaya Pembacaan Standar. |
| Pembaruan Real-Time
Harga yang ditampilkan adalah untuk region us-central1 |
Pembaruan real-time dikenai biaya sebagai Pembacaan sebesar $0,03 per 100.000 dokumen. | Pembaruan real-time memiliki SKU terpisah baru (Unit Pembaruan Real-time), yang dikenai biaya per porsi 4 KiB. Pembaruan real-time memakan biaya $0,30 per satu juta unit baca. |