Buka konsol

Praktik terbaik untuk Cloud Firestore

Gunakan praktik terbaik yang tercantum di sini sebagai referensi cepat ketika membuat aplikasi yang menggunakan Cloud Firestore.

Lokasi database

Saat Anda membuat instance database, pilih lokasi database yang terdekat dengan pengguna dan resource penghitungan. Hop jaringan yang dapat menjangkau jauh lebih rentan terhadap kesalahan dan meningkatkan latensi kueri.

Untuk memaksimalkan ketersediaan dan ketahanan aplikasi Anda, pilih lokasi multi-region dan tempatkan resource penghitungan kritis di minimal dua region.

Pilih lokasi regional untuk biaya yang lebih rendah, latensi tulis yang lebih rendah jika aplikasi Anda sensitif terhadap latensi, atau untuk untuk berbagi lokasi dengan resource GCP lainnya.

ID dokumen

  • Hindari ID dokumen . dan ...
  • Hindari menggunakan garis miring ke depan / di ID dokumen.
  • Jangan gunakan ID dokumen yang meningkat secara monoton, seperti:

    • Customer1, Customer2, Customer3, ...
    • Product 1, Product 2, Product 3, ...

    ID berurutan seperti itu dapat menyebabkan hotspot yang memengaruhi latensi.

Nama Kolom

  • Hindari karakter berikut dalam nama kolom karena membutuhkan pelepasan tambahan:

    • . titik
    • [ kurung siku kiri
    • ] kurung siku kanan
    • * tanda bintang
    • ` kutip tunggal terbalik

Indeks

  • Hindari menggunakan terlalu banyak indeks. Jumlah indeks yang berlebihan dapat meningkatkan latensi tulis dan meningkatkan biaya penyimpanan untuk entri indeks.

  • Perlu diketahui bahwa kolom pengindeksan dengan nilai yang meningkat secara monoton, seperti stempel waktu, dapat menyebabkan hotspot yang memengaruhi latensi untuk aplikasi dengan tingkat baca dan tulis yang tinggi.

Pengecualian indeks

Untuk sebagian besar aplikasi, Anda dapat mengandalkan pengindeksan otomatis serta link pesan error apa pun untuk mengelola indeks Anda. Namun, Anda mungkin ingin menambahkan pengecualian kolom tunggal dalam kasus berikut:

Kasus Deskripsi
Kolom string berukuran lebar

Jika Anda memiliki kolom string yang biasanya memuat nilai string yang panjang, yang tidak digunakan untuk mengirim kueri, Anda dapat menghemat biaya penyimpanan dengan mengecualikan kolom itu dari pengindeksan.

Tingkat operasi tulis yang tinggi ke koleksi yang berisi dokumen dengan nilai berurutan

Jika Anda mengindeks kolom yang naik atau turun secara berurutan di antara dokumen dalam koleksi, seperti stempel waktu, maka tingkat operasi tulis maksimum untuk koleksi itu adalah 500 per detik. Jika Anda tidak mengirim kueri berdasarkan kolom yang memuat nilai berurutan, Anda dapat mengecualikan kolom itu dari pengindeksan untuk mengabaikan batas ini.

Dalam kasus penggunaan IoT dengan tingkat operasi tulis yang tinggi, misalnya, koleksi yang berisi dokumen dengan kolom stempel waktu mungkin akan mendekati batas 500 operasi tulis per detik.

Kolom peta atau array berukuran lebar

Kolom array atau peta berukuran lebar dapat mendekati batas entri indeks sebesar 40.000 per dokumen. Jika Anda tidak mengirim kueri berdasarkan kolom peta atau array berukuran lebar, sebaiknya Anda mengecualikannya dari pengindeksan.

Operasi baca dan tulis

  • Hindari penulisan ke dokumen lebih dari sekali per detik. Untuk mengetahui informasi lebih lanjut, lihat Pembaruan pada satu dokumen.

  • Gunakan operasi batch untuk operasi tulis dan hapus, bukan operasi tunggal. Operasi batch lebih efisien karena melakukan beberapa operasi dengan overhead yang sama seperti operasi tunggal.

  • Gunakan panggilan asinkron jika ada, bukan panggilan sinkron. Panggilan asinkron meminimalkan dampak latensi. Misalnya, pertimbangkan aplikasi yang membutuhkan hasil pencarian dokumen dan hasil kueri sebelum merender respons. Jika pencarian dan kueri tidak memiliki dependensi data, tidak perlu menunggu secara sinkron sampai pencarian selesai sebelum memulai kueri.

  • Jangan gunakan offset. Sebagai gantinya, gunakan kursor. Penggunaan offset hanya akan menghindari menampilkan dokumen yang terlewati di aplikasi Anda, tetapi dokumen tersebut masih diambil secara internal. Dokumen yang terlewati memengaruhi latensi kueri dan aplikasi Anda akan dikenai biaya untuk operasi baca yang diperlukan untuk mengambil dokumen tersebut.

Upaya coba lagi transaksi

Cloud Firestore SDK dan library klien secara otomatis mencoba lagi transaksi yang gagal untuk menangani error sementara. Jika aplikasi Anda mengakses Cloud Firestore melalui REST atau RPC API secara lansung tidak melalui SDK, aplikasi Anda harus mengimplementasikan upaya coba lagi transaksi untuk meningkatkan keandalan.

Update realtime

Untuk performa pemroses snapshot terbaik, jaga ukuran dokumen Anda tetap kecil dan kontrol kecepatan baca klien Anda. Rekomendasi berikut menyediakan panduan untuk memaksimalkan performa. Melebihi batas dari rekomendasi ini dapat menyebabkan peningkatan latensi notifikasi.

Rekomendasi Detail
Kurangi kecepatan churn pemroses snapshot

Hindari listener yang sering kali churning, terumata jika database Anda dalam beban penulisan yang signifikan

Idealnya, aplikasi Anda harus menyiapkan semua pemroses snapshot yang diperlukan segera setelah membuka koneksi ke Cloud Firestore. Setelah menyiapkan pemroses snapshot di awal, sebaiknya jangan menambahkan atau menghapus pemroses snapshot dalam koneksi yang sama.

Untuk memastikan konsistensi data, Cloud Firestore perlu mengutamakan setiap pemroses snapshot baru dari data sumbernya lalu mengikuti perubahan yang baru. Bergantung pada kecepatan tulis database Anda, hal ini dapat menjadi operasi yang mahal.

Listener snapshot Anda dapat mengalami latensi yang meningkat jika Anda menambahkan atau menghapus listener snapshot ke referensi. Secara umum, listener yang terus terhubung akan melakukan performa lebih baik dibandingkan menghubungkan dan memutuskan listener pada lokasi tersebut untuk jumlah data yang sama. Untuk kinerja terbaik, listener snapshot harus memiliki durasi 30 detik atau lebih. Jika Anda menemukan masalah kinerja listener di aplikasi, coba melacak listen dan unlisten untuk menentukan apakah ini terlalu sering terjadi.

Batasi pemroses snapshot per klien

100

Pertahankan jumlah pemroses snapshot per klien di bawah 100.

Batasi kecepatan tulis koleksi

1.000 operasi/detik

Pertahankan kecepatan operasi tulis untuk setiap koleksi di bawah 1.000 operasi/detik.

Batasi setiap kecepatan push klien

1 dokumen/detik

Pertahankan kecepatan dokumen yang di-push database ke setiap klien di bawah 1 dokumen/detik.

Batasi kecepatan push klien global

1.000.000 dokumen/detik

Pertahankan kecepatan dokumen yang di-push database ke semua klien di bawah 1.000.000 dokumen/detik.

Batasi setiap payload dokumen

10 KiB/detik

Pertahankan ukuran dokumen maksimum yang didownload oleh setiap klien di bawah 10 KiB/detik.

Batasi payload dokumen global

1 GiB/detik

Pertahankan ukuran dokumen maksimum yang didownload di semua klien di bawah 1 GiB/detik.

Batasi jumlah kolom per dokumen

100

Dokumen Anda harus memiliki kurang dari 100 kolom.

Pahami batas standar Cloud Firestore

Perlu diperhatikan bahwa batas standar untuk Cloud Firestore, terutama batas 1 penulisan per detik untuk dokumen dan batas 1.000.000 koneksi serentak per database.

Merancang untuk penskalaan

Praktik terbaik berikut menjelaskan cara menghindari situasi yang membuat masalah pertentangan.

Pembaruan untuk satu dokumen

Anda tidak boleh memperbarui satu dokumen lebih dari sekali per detik. Jika Anda memperbarui dokumen terlalu cepat, aplikasi Anda akan mengalami pertentangan, termasuk latensi yang lebih tinggi, waktu tunggu, dan error lainnya.

Kecepatan baca, tulis, dan hapus yang tinggi untuk rentang dokumen yang sempit

Hindari kecepatan baca atau tulis yang tinggi untuk menutup dokumen secara leksikografis atau aplikasi Anda akan mengalami error pertentangan. Masalah ini dikenal sebagai hotspotting dan aplikasi Anda dapat mengalami hotspotting jika terjadi salah satu hal berikut:

  • Membuat dokumen baru dengan kecepatan yang sangat tinggi dan mengalokasikan ID-nya sendiri yang meningkat secara monoton.

    Cloud Firestore mengalokasikan ID dokumen menggunakan algoritme sebar. Anda tidak boleh mengalami hotspotting pada penulisan jika membuat dokumen baru menggunakan ID dokumen otomatis.

  • Membuat dokumen baru dengan kecepatan tinggi dalam koleksi dengan beberapa dokumen.

  • Membuat dokumen baru dengan kolom yang meningkat secara monoton, seperti stempel waktu, dengan kecepatan yang sangat tinggi.

  • Menghapus dokumen dalam koleksi dengan kecepatan tinggi.

  • Menulis ke database dengan kecepatan yang sangat tinggi tanpa terjadi traffic yang meningkat secara bertahap.

Meningkatkan traffic

Anda secara bertahap harus meningkatkan traffic ke koleksi baru atau menutup dokumen secara leksikografis untuk memberikan cukup waktu bagi Cloud Firestore agar dapat menyiapkan dokumen untuk peningkatan traffic. Sebaiknya mulai dengan maksimum 500 operasi per detik ke koleksi baru, lalu tingkatkan traffic sebesar 50% setiap 5 menit. Misalnya, Anda dapat menggunakan jadwal kenaikan ini untuk meningkatkan traffic baca Anda menjadi 740 ribu operasi per detik setelah 90 menit. Anda juga dapat meningkatkan traffic tulis Anda, tetapi perhatikan Batas Standar Cloud Firestore. Pastikan bahwa operasi didistribusikan relatif merata di semua rentang kunci. Ini disebut dengan aturan "500/50/5".

Memigrasikan traffic ke koleksi baru

Kenaikan bertahap sangat penting jika Anda memigrasi traffic aplikasi dari satu koleksi ke koleksi lainnya. Cara sederhana untuk menangani migrasi ini adalah dengan membaca dari koleksi lama dan jika dokumen tidak ada, baca dari koleksi baru. Namun, hal ini dapat menyebabkan peningkatan traffic secara tiba-tiba untuk menutup dokumen secara leksikografis dalam koleksi baru. Cloud Firestore mungkin tidak dapat secara efisien menyiapkan koleksi baru untuk peningkatan traffic, terutama jika berisi beberapa dokumen.

Masalah serupa dapat terjadi jika Anda mengubah ID dari banyak dokumen dalam koleksi yang sama.

Strategi terbaik untuk memigrasi traffic ke koleksi baru tergantung pada model data Anda. Di bawah ini adalah contoh strategi yang disebut operasi baca paralel. Anda perlu menentukan apakah strategi ini efektif untuk data Anda atau tidak, dan pertimbangan pentingnya adalah dampak biaya operasi paralel selama migrasi.

Operasi baca paralel

Untuk menerapkan operasi baca paralel saat Anda memigrasi traffic ke koleksi baru, baca dari koleksi lama terlebih dahulu. Jika dokumen tidak ada, baca dari koleksi baru. Kecepatan baca yang tinggi dari dokumen yang tidak ada dapat menyebabkan hotspotting. Jadi, pastikan untuk secara bertahap meningkatkan pemuatan ke koleksi baru. Strategi yang lebih baik adalah menyalin dokumen lama ke koleksi baru, lalu menghapus dokumen lama. Tingkatkan operasi baca paralel secara bertahap untuk memastikan bahwa Cloud Firestore dapat menangani traffic ke koleksi baru.

Strategi yang memungkinkan untuk secara bertahap meningkatkan operasi baca atau tulis ke koleksi baru adalah dengan menggunakan hash deterministik ID pengguna untuk memilih persentase acak dari pengguna yang mencoba menulis dokumen baru. Pastikan bahwa hasil hash ID pengguna tidak meleset oleh fungsi Anda atau perilaku pengguna.

Sementara itu, jalankan tugas batch yang menyalin semua data Anda dari dokumen lama ke koleksi baru. Tugas batch Anda harus menghindari penulisan ke ID dokumen berurutan untuk mencegah hotspot. Ketika tugas batch selesai, Anda hanya dapat membaca dari koleksi baru.

Penyempurnaan strategi ini adalah memigrasikan sejumlah kecil pengguna sekaligus. Tambahkan kolom ke dokumen pengguna yang melacak status migrasi pengguna tersebut. Pilih sekelompok pengguna untuk dimigrasi berdasarkan hash ID pengguna. Gunakan tugas batch untuk memigrasi dokumen untuk kumpulan pengguna tersebut dan gunakan operasi baca paralel untuk pengguna di tengah migrasi.

Perhatikan bahwa Anda tidak dapat melakukan rollback dengan mudah, kecuali Anda melakukan penulisan ganda pada entitas lama dan baru selama fase migrasi. Tindakan ini akan meningkatkan biaya Cloud Firestore yang timbul.

Mencegah akses tanpa izin

Cegah operasi tanpa izin di database Anda dengan Aturan Keamanan Cloud Firestore. Misalnya, penggunaan aturan dapat menghindari skenario di mana pengguna yang berbahaya mampu mendownload seluruh database Anda berulang kali.

Pelajari menggunakan Aturan Keamanan Cloud Firestore lebih lanjut.