Memahami pembacaan dan penulisan dalam skala besar

Memahami pembacaan dan penulisan dalam skala besar

Baca dokumen ini untuk membuat keputusan yang tepat dalam merancang aplikasi Anda demi menghasilkan performa dan keandalan yang tinggi. Dokumen ini berisi topik Firestore lanjutan. Jika Anda baru mulai menggunakan Firestore, lihat panduan memulai.

Agar aplikasi Anda terus memiliki performa yang baik seiring bertambahnya ukuran database dan traffic, sebaiknya pahami mekanisme pembacaan dan penulisan di backend Firestore. Anda juga harus memahami interaksi operasi baca dan tulis dengan lapisan penyimpanan dan batasan pokok yang dapat memengaruhi performa.

Lihat bagian berikut untuk mengetahui praktik terbaik sebelum merancang aplikasi.

Memahami komponen tingkat tinggi

Diagram berikut menunjukkan komponen tingkat tinggi yang terlibat dalam permintaan Firestore API.

SDK, library klien, dan driver

Firestore mendukung SDK, library klien, dan driver untuk berbagai platform.

Google Front End (“GFE”)

Ini adalah layanan infrastruktur yang umum untuk semua Google Cloud layanan. GFE menerima permintaan masuk dan meneruskannya ke layanan Google yang relevan (layanan Firestore dalam konteks ini).

Layanan Firestore

Layanan Firestore melakukan pemeriksaan terhadap permintaan API yang mencakup autentikasi, otorisasi, pemeriksaan kuota, dan juga mengelola transaksi. Layanan Firestore ini mencakup klien penyimpanan yang berinteraksi dengan lapisan penyimpanan untuk pembacaan dan penulisan data.

Lapisan penyimpanan Firestore

Lapisan penyimpanan Firestore bertanggung jawab untuk menyimpan data dan metadata, serta fitur database terkait yang disediakan oleh Firestore. Bagian berikut menjelaskan cara penyusunan data di lapisan penyimpanan Firestore dan cara sistem dalam melakukan penskalaan. Mempelajari cara penyusunan data dapat membantu Anda mendesain model data yang skalabel dan lebih memahami praktik terbaik di Firestore.

Bagian dan Rentang Kunci

Firestore adalah database NoSQL berorientasi dokumen. Anda menyimpan data di dokumen yang disusun dalam koleksi. Nama koleksi dan ID dokumen membentuk kunci unik untuk dokumen. Dokumen dalam koleksi yang sama disimpan bersama dalam keyspace. Dalam keyspace tersebut, ID dokumen di-hash. Istilah rentang kunci mengacu pada rentang kunci yang berdekatan dalam penyimpanan.

Firestore secara otomatis mempartisi data dalam koleksi di beberapa server penyimpanan. Partisi ini disebut sebagai pemisahan.

Dokumen dapat menghasilkan entri indeks yang diurutkan secara leksikografis dan berpartisipasi dalam pemisahan dan penempatan yang sama seperti data dokumen.

Poin Penting: Memahami cara Firestore mengelola rentang kunci dan pemisahan sangat penting untuk pemodelan data yang skalabel.

Replikasi Sinkron

Setiap penulisan direplikasi secara sinkron ke sebagian besar replika menggunakan Paxos. Satu replika per pemisahan dianggap sebagai pemimpin dan mengoordinasikan proses replikasi. Jika terjadi kegagalan pemimpin, pemimpin baru akan dipilih. Replika berada di zona yang berbeda agar tahan terhadap potensi kegagalan zona. Proses replikasi ini bermuara pada sistem yang skalabel dan sangat tersedia, yang memberikan latensi rendah untuk operasi baca dan tulis, terlepas dari workload yang berat dan pada skala yang sangat besar.

Region Tunggal versus Multi-Region

Saat membuat database, Anda harus memilih lokasi regional tunggal atau lokasi multi-region.

Lokasi regional tunggal merupakan lokasi geografis tertentu, seperti us-west1. Bagian data dari database Firestore memiliki replika di berbagai zona dalam region yang dipilih, seperti yang dijelaskan sebelumnya.

Lokasi multi-region terdiri dari kumpulan region yang ditentukan, tempat Firestore menyimpan replika database. Dalam deployment Firestore multi-region, dua region memiliki replika lengkap dari seluruh data dalam database. Region ketiga memiliki replika saksi yang tidak mempertahankan kumpulan data lengkap, tetapi berpartisipasi dalam replikasi. Data tersedia untuk ditulis dan dibaca bahkan jika seluruh region hilang, karena Firestore mereplikasi data di antara beberapa region.

Untuk mengetahui informasi selengkapnya tentang lokasi region, lihat Lokasi Firestore.

Poin Penting: Terdapat konsekuensi dalam memilih antara konfigurasi satu region versus multi-region, termasuk dalam hal performa utama, ketersediaan, dan biaya.

Memahami masa berlaku penulisan

Driver dapat menulis data dengan membuat, memperbarui, atau menghapus satu dokumen. Penulisan ke satu dokumen memerlukan pembaruan dokumen dan entri indeks terkait secara atomik di lapisan penyimpanan. Firestore juga mendukung operasi atomik yang terdiri dari beberapa pembacaan dan penulisan pada satu atau beberapa dokumen.

Untuk semua jenis penulisan, Firestore menyediakan properti ACID (atomicity, konsistensi, isolasi, dan ketahanan) database relasional. Firestore juga menyediakan serialisasi, yang berarti semua transaksi muncul seolah-olah dijalankan dalam urutan serial.

Langkah-langkah tingkat tinggi dalam transaksi tulis

Saat driver menerbitkan operasi tulis atau meng-commit transaksi menggunakan salah satu metode yang disebutkan sebelumnya, hal ini dijalankan secara internal sebagai transaksi baca-tulis database di lapisan penyimpanan. Karena transaksi tersebut, Firestore dapat menyediakan properti ACID yang disebutkan sebelumnya.

Sebagai langkah pertama dalam transaksi, Firestore membaca dokumen yang sudah ada dan menentukan mutasi yang akan dilakukan pada data dalam dokumen.

Hal ini juga mencakup pembaruan pada indeks yang relevan:

• Kolom terindeks yang ditambahkan ke dokumen memerlukan penyisipan yang sesuai ke dalam indeks.
• Kolom terindeks yang dihapus dari dokumen memerlukan penghapusan yang sesuai di indeks.
• Kolom terindeks yang diubah dalam dokumen memerlukan penghapusan (untuk nilai lama) dan penyisipan (untuk nilai baru) dalam indeks.

Untuk menghitung mutasi yang disebutkan sebelumnya, Firestore membaca konfigurasi pengindeksan untuk project tersebut. Konfigurasi pengindeksan menyimpan informasi tentang indeks untuk sebuah project.

Setelah mutasi dihitung, Firestore mengumpulkannya di dalam transaksi, lalu melakukan commit terhadap mutasi tersebut.

Poin Penting: Secara internal, Firestore selalu menggunakan transaksi untuk menyediakan properti ACID untuk operasi tulis.

Memahami transaksi tulis di lapisan penyimpanan

Seperti yang telah dibahas sebelumnya, operasi tulis di Firestore melibatkan transaksi baca-tulis di lapisan penyimpanan. Bergantung pada tata letak data, operasi tulis mungkin melibatkan satu atau beberapa pemisahan.

Dalam diagram berikut, database Firestore memiliki delapan bagian (ditandai 1-8) yang dihosting di tiga server penyimpanan berbeda dalam satu zona, dan setiap bagian direplikasi di 3 zona(atau lebih) yang berbeda. Setiap bagian memiliki pimpinan Paxos, yang mungkin berada di zona berbeda untuk bagian yang berbeda pula.

Pertimbangkan database Firestore yang memiliki koleksi Restaurants sebagai berikut:

Driver meminta perubahan berikut pada dokumen dalam koleksi Restaurant dengan memperbarui nilai kolom priceCategory.

Sebagai bagian dari penulisan, langkah-langkah tingkat tinggi berikut menjelaskan hal yang terjadi:

1. Membuat transaksi baca-tulis.
2. Baca dokumen restaurant1 di koleksi Restaurants.
3. Baca indeks untuk dokumen.
4. Hitung mutasi yang akan dibuat pada data. Dalam hal ini, ada lima mutasi:
   • M1: Perbarui baris untuk restaurant1 agar sesuai dengan perubahan nilai kolom priceCategory.
   • M2 dan M3: Hapus entri indeks lama untuk priceCategory.
   • M4 dan M5: Tambahkan entri indeks baru untuk priceCategory.
5. Lakukan mutasi ini.

Klien penyimpanan di layanan Firestore mencari bagian yang memiliki kunci baris yang akan diubah. Pertimbangkan kasus saat Bagian 3 menyalurkan M1, dan Bagian 6 menyalurkan M2-M5. Ada transaksi terdistribusi yang melibatkan semua bagian ini sebagai peserta. Bagian peserta juga dapat menyertakan bagian lain dari data yang dibaca sebelumnya sebagai bagian dari transaksi baca-tulis.

Sebagai bagian dari commit, langkah-langkah berikut menjelaskan hal yang terjadi:

1. Klien penyimpanan menerbitkan commit. Commit berisi mutasi M1-M5.
2. Bagian 3 dan 6 adalah peserta dalam transaksi ini. Salah satu peserta dipilih sebagai koordinator, seperti Bagian 3. Tugas koordinator adalah memastikan transaksi di-commit atau dibatalkan secara atomik pada semua peserta.
   • Replika pemimpin dari bagian ini bertanggung jawab atas pekerjaan yang dilakukan oleh peserta dan koordinator.
3. Setiap peserta dan koordinator menjalankan algoritma Paxos dengan replika masing-masing.
   • Pemimpin tersebut menjalankan algoritma Paxos dengan replika. Kuorum dicapai jika sebagian besar replika membalas pemimpin dengan respons ok to commit.
   • Setiap peserta kemudian akan memberi tahu koordinator saat mereka siap (fase pertama dari commit dengan dua fase). Jika setiap peserta tidak dapat meng-commit transaksi, maka seluruh transaksi aborts.
4. Setelah koordinator mengetahui semua peserta sudah siap, termasuk dirinya sendiri, mereka akan mengomunikasikan hasil transaksi accept kepada semua peserta (fase kedua dari commit dengan dua fase). Pada fase ini, setiap peserta mencatat keputusan commit ke penyimpanan yang stabil dan transaksi di-commit.
5. Koordinator merespons klien penyimpanan di Firestore bahwa transaksi telah di-commit. Secara paralel, koordinator dan semua peserta menerapkan mutasi ke data.

Jika database Firestore berukuran kecil, satu bagian dapat memiliki semua kunci dalam mutasi M1-M5. Dalam kasus seperti itu, hanya ada satu peserta dalam transaksi. Selain itu, commit dengan dua fase yang disebutkan sebelumnya tidak diperlukan, sehingga penulisan menjadi lebih cepat.

Penulisan di multi-region

Dalam deployment multi-region, penyebaran replika di seluruh region meningkatkan ketersediaan, tetapi berdampak pada performa. Komunikasi antara replika di berbagai region memerlukan waktu round-trip yang lebih lama. Oleh karena itu, latensi dasar untuk operasi Firestore sedikit lebih banyak dibandingkan dengan deployment region tunggal.

Kami mengonfigurasi replika sedemikian rupa agar pemimpin bagian selalu berada di region utama. Region utama adalah region tempat traffic masuk ke server Firestore. Keputusan kepemimpinan ini mengurangi penundaan dua arah dalam komunikasi antara klien penyimpanan di Firestore dan pemimpin replika (atau koordinator untuk transaksi multi-bagian).

Poin Penting: Firestore menggunakan transaksi untuk melakukan penulisan, yang memerlukan perolehan kunci bersama untuk pembacaan dan kunci eksklusif untuk penulisan. Jika transaksi membaca banyak baris, tidak ada transaksi lain yang dapat menulis ke kumpulan baris tersebut hingga transaksi ini di-commit atau dibatalkan, yang menyebabkan latensi lebih tinggi dan error pertentangan kunci. Oleh karena itu, coba hindari membaca dalam jumlah besar di dalam transaksi.

Poin Penting: Latensi tulis/transaksi meningkat seiring dengan peningkatan jumlah bagian/peserta. Tidak ada mekanisme eksplisit untuk mengontrol jumlah peserta. Namun, Anda dapat melakukan hal berikut untuk mengurangi jumlah peserta:

• Fanout indeks yang tinggi terjadi saat banyak entri indeks harus ditulis. Fanout indeks yang tinggi untuk penulisan dokumen meningkatkan jumlah atau baris database yang akan dimutasi, sehingga menambah jumlah peserta. Jangan mengindeks kolom yang tidak digunakan untuk membuat kueri.
• Jumlah peserta akan meningkat seiring dengan bertambahnya jumlah dokumen yang diperbarui dalam transaksi tulis. Untuk latensi yang lebih rendah, pastikan jumlah dokumen yang diperbarui dalam satu transaksi tulis tetap rendah.

Memahami masa berlaku pembacaan

Bagian ini membahas pembacaan di Firestore. Khususnya, kueri terdiri dari campuran pembacaan dokumen dan pembacaan entri indeks.

Pembacaan data dari lapisan penyimpanan dilakukan secara internal dengan menggunakan transaksi database untuk memastikan pembacaan yang konsisten. Namun, tidak seperti transaksi yang digunakan untuk penulisan, transaksi ini tidak memerlukan kunci. Sebagai gantinya, opsi tersebut bekerja dengan memilih stempel waktu, lalu menjalankan semua operasi baca pada stempel waktu tersebut. Karena tidak memperoleh kunci, transaksi tersebut tidak memblokir transaksi baca-tulis serentak. Untuk menjalankan transaksi ini, klien penyimpanan di Firestore menentukan batas stempel waktu, yang memberi tahu lapisan penyimpanan cara memilih stempel waktu pembacaan. Jenis batas stempel waktu yang dipilih oleh klien penyimpanan di Firestore ditentukan oleh opsi baca untuk permintaan Baca.

Memahami transaksi baca di lapisan penyimpanan

Bagian ini menjelaskan jenis pembacaan dan cara pemrosesannya di lapisan penyimpanan di Firestore.

Pembacaan andal

Secara default, pembacaan Firestore sangat konsisten. Konsistensi kuat ini berarti bahwa pembacaan Firestore menampilkan versi terbaru data yang mencerminkan semua penulisan yang telah di-commit hingga awal pembacaan.

Pembacaan Bagian Tunggal

Klien penyimpanan di Firestore mencari bagian yang memiliki kunci baris yang akan dibaca. Anggaplah Anda perlu membaca dari Bagian 3 dari bagian sebelumnya. Klien mengirimkan permintaan baca ke replika terdekat untuk mengurangi latensi dua arah.

Pada tahap ini, kasus berikut mungkin terjadi bergantung pada replika yang dipilih:

• Permintaan baca ditujukan ke replika pemimpin (Zona A).
  • Karena pemimpin selalu diperbarui, pembacaan dapat langsung dilanjutkan.
• Permintaan baca ditujukan ke replika non-pemimpin (seperti Zona B)
  • Bagian 3 mungkin tahu dari status internalnya bahwa variabel tersebut memiliki informasi yang cukup untuk menyajikan operasi baca, dan bagian tersebut pun melakukannya.
  • Bagian 3 tidak yakin apakah sudah melihat data terbaru atau belum. Fungsi ini mengirim pesan ke pemimpin untuk meminta stempel waktu transaksi terakhir yang perlu diterapkan untuk melayani pembacaan. Setelah transaksi tersebut diterapkan, pembacaan dapat dilanjutkan.

Firestore kemudian menampilkan respons ke kliennya.

Pembacaan multi-bagian

Jika operasi baca harus dilakukan dari beberapa bagian, mekanisme yang sama akan diterapkan pada semua bagian. Setelah data ditampilkan dari semua bagian, klien penyimpanan di Firestore akan menggabungkan hasilnya. Firestore kemudian merespons kliennya dengan data ini.

Poin Penting: Overhead latensi meningkat seiring peningkatan jumlah bagian yang terlibat dalam pembacaan. Memastikan hasil kueri tetap kecil, jika memungkinkan, akan sangat membantu.

Menghindari hotspot

Bagian di Firestore secara otomatis dipecah menjadi bagian-bagian yang lebih kecil untuk mendistribusikan tugas penayangan traffic ke lebih banyak server penyimpanan saat diperlukan atau ketika ruang kunci diperluas. Bagian yang dibuat untuk menangani kelebihan traffic akan dipertahankan selama sekitar ~24 jam meskipun traffic hilang. Jadi, jika ada lonjakan traffic berulang, bagian tersebut akan dipertahankan, sementara bagian lainnya akan dilakukan setiap kali diperlukan. Mekanisme ini membantu database Firestore melakukan penskalaan otomatis pada peningkatan beban traffic atau ukuran database. Namun, ada beberapa batasan yang perlu diketahui.

Membagi penyimpanan dan beban membutuhkan waktu, dan meningkatkan traffic terlalu cepat dapat menyebabkan error yang melebihi batas atau latensi tinggi, biasanya disebut sebagai hotspot, sembari layanan disesuaikan. Praktik terbaiknya adalah mendistribusikan operasi di seluruh rentang kunci, sambil meningkatkan traffic secara bertahap pada koleksi dalam database.

Meskipun bagian dibuat secara otomatis dengan bertambahnya beban, Firestore dapat membagi rentang kunci hanya sampai menyajikan satu dokumen menggunakan kumpulan server penyimpanan replika khusus. Akibatnya, volume operasi serentak yang tinggi dan berkelanjutan pada satu dokumen dapat menyebabkan hotspot pada dokumen tersebut. Jika Anda mendapati latensi tinggi yang berkelanjutan pada satu dokumen, sebaiknya ubah model data untuk membagi atau mereplikasi data di beberapa dokumen.

Error pertentangan terjadi saat beberapa operasi mencoba membaca dan menulis dokumen yang sama secara bersamaan.

Poin Penting: Hindari kecepatan baca atau tulis yang tinggi ke satu dokumen, atau dokumen dalam rentang kunci yang berisi beberapa dokumen. Jika tidak, aplikasi Anda dapat mengalami latensi dan error pertentangan yang tinggi.

Poin Penting: Mengindeks kolom dengan nilai yang meningkat/menurun secara monoton, seperti stempel waktu, dapat menyebabkan hotspot yang memengaruhi latensi untuk aplikasi dengan kecepatan baca dan tulis yang tinggi.

Perhatikan bahwa dengan mengikuti praktik yang diuraikan di halaman ini, Firestore dapat diskalakan untuk melayani beban kerja besar yang berubah-ubah tanpa harus menyesuaikan konfigurasi.