Praktik terbaik untuk Cloud Firestore

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

Lokasi database

Saat Anda membuat instance database, pilih lokasi database yang terdekat dengan pengguna dan resource komputasi. Hop jaringan dengan jangkauan jauh lebih rentan terhadap error dan meningkatkan latensi kueri.

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

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

ID dokumen

  • Hindari ID dokumen . dan ...
  • Hindari penggunaan 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 tersebut dapat menyebabkan hotspot yang memengaruhi latensi.

Nama Kolom

  • Hindari penggunaan karakter berikut dalam nama kolom karena memerlukan escaping 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 mengindeks kolom 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 memiliki kolom string yang biasanya memuat nilai string yang panjang, yang tidak digunakan untuk membuat 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 meningkat atau menurun secara berurutan antardokumen dalam koleksi, seperti stempel waktu, maka tingkat operasi tulis maksimum ke koleksi itu adalah 500 penulisan per detik. Jika tidak membuat 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, koleksi yang berisi dokumen dengan kolom stempel waktu mungkin akan mendekati batas 500 operasi tulis per detik.

Kolom peta atau array berukuran lebar

Kolom peta atau array berukuran lebar dapat mendekati batas entri indeks sebesar 40.000 per dokumen. Jika Anda tidak membuat 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 selengkapnya, lihat Pembaruan pada satu dokumen.

  • Gunakan panggilan asinkron jika bisa, 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, maka 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 dilewati di aplikasi Anda, tetapi dokumen tersebut masih diambil secara internal. Dokumen yang dilewati memengaruhi latensi kueri dan aplikasi Anda akan dikenai biaya untuk operasi baca yang diperlukan untuk mengambil dokumen tersebut.

Upaya coba lagi transaksi

SDK dan library klien Cloud Firestore secara otomatis mencoba lagi transaksi yang gagal untuk menangani error sementara. Jika aplikasi Anda mengakses Cloud Firestore melalui REST atau RPC API secara langsung, bukan melalui SDK, aplikasi Anda harus menerapkan 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 pemroses yang sering kali churning, terutama jika database Anda mengalami 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 dengan cepat.

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

Pemroses snapshot Anda dapat mengalami peningkatan latensi jika Anda sering menambahkan atau menghapus pemroses snapshot ke referensi. Secara umum, pemroses yang terus terpasang akan melakukan performa yang lebih baik dibandingkan memasang dan melepas pemroses pada lokasi tersebut untuk jumlah data yang sama. Untuk performa terbaik, pemroses snapshot harus memiliki masa aktif 30 detik atau lebih. Jika Anda menemukan masalah performa pemroses di aplikasi, coba lacak pemrosesan dan penghentian pemrosesan aplikasi untuk menentukan apakah hal tersebut 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 kecepatan push setiap 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.

Ini adalah batas yang bisa dilewati. Cloud Firestore tidak akan menghentikan Anda melampaui batas ini, tetapi akan sangat memengaruhi performa.

Batasi payload setiap 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 oleh 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

Perhatikan batas standar untuk Cloud Firestore.

Anda harus memperhatikan batas 1 penulisan per detik untuk dokumen dan batas 1.000.000 koneksi serentak per database. Ini merupakan batas yang bisa dilewati. Cloud Firestore tidak akan menghentikan Anda melampaui batas tersebut. Namun, performa mungkin akan terpengaruh jika batas tersebut terlampaui, bergantung pada total kecepatan baca dan tulis Anda.

Cloud Functions

Mengaktifkan Cloud Function dengan lebih dari 2.000 peristiwa Cloud Firestore per detik dapat meningkatkan tingkat error untuk sementara waktu dan meningkatkan latensi untuk sementara selama beberapa menit. Sebelum mengaktifkan fungsi dengan traffic tinggi, Anda dapat menghubungi dukungan guna menyiapkan database untuk fungsi dengan traffic tinggi dan menghindari peningkatan latensi.

Mendesain untuk penskalaan

Praktik terbaik berikut menjelaskan cara menghindari situasi yang menciptakan 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 habis, dan error lainnya.

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

Hindari kecepatan baca atau tulis yang tinggi ke dokumen yang mirip secara leksikografis, atau aplikasi Anda akan mengalami error pertentangan. Masalah ini dikenal sebagai hotspotting dan aplikasi Anda dapat mengalami hotspotting jika melakukan salah satu dari hal berikut:

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

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

  • Membuat dokumen baru dengan kecepatan tinggi dalam koleksi dengan sedikit 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 meningkatkan traffic secara bertahap.

Menghindari melewati data yang dihapus

Menghindari kueri yang melewati data yang baru saja dihapus. Kueri mungkin harus melewati sejumlah besar entri indeks jika hasil kueri awal baru dihapus.

Contoh beban kerja yang mungkin harus melewati banyak data yang telah dihapus adalah beban kerja yang mencoba menemukan item pekerjaan terlama yang ada dalam antrean. Kueri mungkin terlihat seperti ini:

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

Setiap kali dijalankan, kueri ini akan memindai entri indeks untuk kolom created pada dokumen yang baru-baru ini dihapus. Langkah ini akan memperlambat kueri.

Untuk meningkatkan performa, gunakan metode start_at guna menemukan tempat terbaik untuk memulai. Contoh:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

CATATAN: Contoh di atas menggunakan kolom yang meningkat secara monoton, yang merupakan anti-pola untuk kecepatan tulis yang tinggi.

Meningkatkan traffic

Anda harus secara bertahap meningkatkan traffic ke koleksi baru atau dokumen yang mirip secara leksikografis agar memberikan cukup waktu bagi Cloud Firestore untuk menyiapkan dokumen bagi traffic yang meningkat. Sebaiknya mulai dengan maksimum 500 operasi per detik ke koleksi baru, lalu tingkatkan traffic sebesar 50% setiap 5 menit. Anda juga dapat meningkatkan traffic penulisan 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, namun jika dokumen tidak ada, membaca dari koleksi baru. Namun, hal ini dapat menyebabkan peningkatan traffic secara tiba-tiba ke dokumen yang mirip secara leksikografis dalam koleksi baru. Cloud Firestore mungkin tidak dapat menyiapkan koleksi baru secara efisien untuk traffic yang meningkat, terutama jika koleksi tersebut berisi sedikit dokumen.

Masalah serupa dapat terjadi jika Anda mengubah ID dokumen milik 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 untuk dokumen yang tidak ada dapat menyebabkan hotspotting. Jadi, pastikan untuk secara bertahap meningkatkan beban 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 penentu ID pengguna untuk memilih persentase acak dari pengguna yang mencoba menulis dokumen baru. Pastikan bahwa hasil hash ID pengguna tidak condong ke pengguna tertentu karena 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.

Perbaikan strategi ini dapat berupa migrasi pengguna dalam batch kecil pada satu waktu. Tambahkan kolom ke dokumen pengguna yang melacak status migrasi pengguna tersebut. Pilih sekelompok pengguna yang akan dimigrasi berdasarkan hash ID pengguna. Gunakan tugas batch untuk memigrasi dokumen untuk sekelompok pengguna tersebut, dan gunakan operasi baca paralel untuk pengguna di tengah migrasi.

Perlu diperhatikan bahwa Anda tidak dapat melakukan roll back dengan mudah, kecuali Anda melakukan operasi tulis ganda pada entity 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 penggunaan Aturan Keamanan Cloud Firestore lebih lanjut.