Praktik terbaik desain skema

Halaman ini berisi informasi tentang desain skema Bigtable. Sebelum Anda membaca halaman ini, Anda harus memahami ringkasan Bigtable. Topik berikut dibahas di halaman ini:

• Konsep umum: Konsep dasar yang perlu diingat saat Anda mendesain skema.
• Praktik terbaik: Pedoman desain yang berlaku untuk sebagian besar kasus penggunaan, yang dikelompokkan berdasarkan komponen tabel.
• Kasus penggunaan khusus: Rekomendasi untuk beberapa kasus penggunaan dan pola data tertentu.

Konsep umum

Mendesain skema Bigtable berbeda dengan mendesain skema untuk database relasional. Skema Bigtable ditentukan oleh logika aplikasi, bukan oleh objek atau file definisi skema. Anda dapat menambahkan grup kolom ke tabel saat membuat atau mengupdate tabel, tetapi kolom dan pola kunci baris ditentukan oleh data yang Anda tulis ke tabel.

Di Bigtable, skema adalah blueprint atau model tabel, termasuk struktur komponen tabel berikut:

• Kunci baris
• Grup kolom, termasuk kebijakan pengumpulan sampah
• Kolom

Di Bigtable, desain skema terutama didorong oleh kueri, atau permintaan baca, yang akan Anda kirim ke tabel. Karena membaca rentang baris adalah cara tercepat untuk membaca data Bigtable, rekomendasi di halaman ini dirancang untuk membantu Anda mengoptimalkan pembacaan rentang baris. Dalam sebagian besar kasus, hal itu berarti mengirimkan kueri berdasarkan awalan kunci baris.

Pertimbangan sekunder adalah menghindari hotspot – untuk mencegah hotspot, Anda perlu mempertimbangkan pola penulisan dan cara menghindari akses ke ruang kunci kecil dalam waktu singkat.

Konsep umum berikut berlaku untuk desain skema Bigtable:

• Bigtable adalah penyimpanan nilai/kunci, bukan penyimpanan relasional. Tidak mendukung gabungan, dan transaksi hanya didukung dalam satu baris.
• Setiap tabel memiliki indeks: kunci baris. Setiap kunci baris harus unik. Untuk membuat indeks sekunder, gunakan tampilan terwujud berkelanjutan. Untuk mengetahui informasi selengkapnya, lihat Membuat indeks sekunder global.
• Kunci baris mengurutkan baris secara leksikografis dari string byte terendah hingga tertinggi. Urutan ini adalah big-endian (terkadang disebut urutan byte jaringan), yang merupakan urutan biner yang setara dengan urutan abjad.
• Grup kolom tidak disimpan dalam urutan tertentu.
• Kolom dikelompokkan menurut grup kolom dan diurutkan dalam urutan leksikografis dalam grup kolom. Misalnya, dalam family kolom yang disebut SysMonitor dengan kualifikasi kolom ProcessName, User, %CPU, ID, Memory, DiskRead, dan Priority, Bigtable menyimpan kolom dalam urutan ini:

• Persimpangan baris dan kolom dapat berisi beberapa sel yang diberi stempel waktu. Setiap sel berisi versi data yang unik dan diberi stempel waktu untuk baris dan kolom tersebut.
• Grup kolom gabungan berisi sel gabungan. Anda dapat membuat kolom keluarga yang hanya berisi sel gabungan. Agregat memungkinkan Anda menggabungkan data baru dengan data yang sudah ada di sel.
• Semua operasi bersifat atomik di tingkat baris. Operasi memengaruhi seluruh baris atau tidak ada baris.
• Idealnya, operasi baca dan tulis harus didistribusikan secara merata di seluruh ruang baris tabel.
• Tabel Bigtable bersifat renggang. Kolom tidak menggunakan ruang apa pun dalam baris yang tidak menggunakan kolom tersebut.

Praktik terbaik

Skema yang baik menghasilkan performa dan skalabilitas yang sangat baik, dan skema yang dirancang dengan buruk dapat menyebabkan sistem berperforma buruk. Setiap kasus penggunaan berbeda dan memerlukan desainnya sendiri, tetapi praktik terbaik berikut berlaku untuk sebagian besar kasus penggunaan. Pengecualian dicatat.

Mulai dari tingkat tabel dan berlanjut ke tingkat kunci baris, bagian berikut menjelaskan praktik terbaik untuk desain skema:

• Tables
• Grup kolom
• Kolom
• Baris
• Sel
• Kunci baris

Semua elemen tabel, terutama kunci baris, harus didesain dengan mempertimbangkan permintaan baca yang direncanakan. Periksa kuota dan batas untuk batas ukuran yang direkomendasikan dan batas ukuran tetap untuk semua elemen tabel.

Karena semua tabel dalam instance disimpan di tablet yang sama, desain skema yang menghasilkan hotspot dalam satu tabel dapat memengaruhi latensi tabel lain dalam instance yang sama. Hotspot disebabkan oleh seringnya mengakses satu bagian tabel dalam jangka waktu singkat.

Tabel

Simpan set data dengan skema serupa dalam tabel yang sama, bukan dalam tabel terpisah.

Dalam sistem database lain, Anda dapat memilih untuk menyimpan data dalam beberapa tabel berdasarkan subjek dan jumlah kolom. Namun, di Bigtable, biasanya lebih baik menyimpan semua data Anda dalam satu tabel. Anda dapat menetapkan awalan kunci baris unik untuk digunakan bagi setiap set data, sehingga Bigtable menyimpan data terkait dalam rentang baris yang berdekatan yang kemudian dapat Anda kueri berdasarkan awalan kunci baris.

Bigtable memiliki batas 1.000 tabel per instance, tetapi sebaiknya hindari membuat tabel dalam jumlah besar karena alasan berikut:

• Mengirim permintaan ke banyak tabel yang berbeda dapat meningkatkan overhead koneksi backend, sehingga meningkatkan latensi ekor.
• Membuat lebih banyak tabel tidak meningkatkan load balancing dan dapat meningkatkan overhead pengelolaan.

Anda mungkin ingin membuat tabel terpisah untuk kasus penggunaan berbeda yang memerlukan skema berbeda, tetapi Anda tidak boleh menggunakan tabel terpisah untuk data serupa. Misalnya, Anda tidak boleh membuat tabel baru hanya karena tahun baru atau Anda memiliki pelanggan baru.

Grup kolom

Tempatkan kolom terkait dalam grup kolom yang sama. Jika baris berisi beberapa nilai yang terkait satu sama lain, sebaiknya kelompokkan kolom yang berisi nilai tersebut dalam grup kolom yang sama. Kelompokkan data sedekat mungkin untuk menghindari kebutuhan merancang filter yang kompleks dan agar Anda mendapatkan hanya informasi yang Anda butuhkan, tetapi tidak lebih, dalam permintaan baca yang paling sering.

Buat hingga sekitar 100 grup kolom per tabel. Membuat lebih dari 100 family kolom dapat menyebabkan penurunan performa.

Pilih nama pendek untuk family kolom Anda. Nama disertakan dalam data yang ditransfer untuk setiap permintaan.

Tempatkan kolom yang memiliki kebutuhan retensi data yang berbeda dalam family kolom yang berbeda. Praktik ini penting jika Anda ingin membatasi biaya penyimpanan. Kebijakan pengumpulan sampah ditetapkan di tingkat family kolom, bukan di tingkat kolom. Misalnya, jika Anda hanya perlu menyimpan versi terbaru dari sepotong data tertentu, jangan menyimpannya di kolom family yang ditetapkan untuk menyimpan 1.000 versi dari sesuatu yang lain. Jika tidak, Anda membayar untuk menyimpan 999 sel data yang tidak Anda perlukan.

Kolom

Buat kolom sebanyak yang Anda butuhkan dalam tabel. Tabel Bigtable jarang terisi, dan tidak ada penalti ruang untuk kolom yang tidak digunakan dalam baris. Anda dapat memiliki jutaan kolom dalam tabel, asalkan tidak ada baris yang melebihi batas maksimum 256 MB per baris.

Hindari penggunaan terlalu banyak kolom dalam satu baris. Meskipun tabel dapat memiliki jutaan kolom, baris tidak boleh. Beberapa faktor yang berkontribusi pada praktik terbaik ini:

• Bigtable memerlukan waktu untuk memproses setiap sel dalam baris.
• Setiap sel menambahkan beberapa overhead ke jumlah data yang disimpan dalam tabel dan dikirim melalui jaringan. Misalnya, jika Anda menyimpan data sebesar 1 KB (1.024 byte), akan jauh lebih efisien untuk menyimpan data tersebut dalam satu sel, daripada menyebarkan data ke 1.024 sel yang masing-masing berisi 1 byte.

Jika set data Anda secara logis memerlukan lebih banyak kolom per baris daripada yang dapat diproses Bigtable secara efisien, pertimbangkan untuk menyimpan data sebagai protobuf dalam satu kolom.

Secara opsional, Anda dapat memperlakukan penentu kolom sebagai data. Karena Anda harus menyimpan penentu kolom untuk setiap kolom, Anda dapat menghemat ruang dengan memberi nama kolom dengan nilai. Sebagai contoh, pertimbangkan tabel yang menyimpan data tentang persahabatan dalam grup kolom Friends. Setiap baris mewakili seseorang dan semua persahabatannya. Setiap penentu kolom dapat berupa ID teman. Kemudian, nilai untuk setiap kolom dalam baris tersebut dapat berupa lingkaran sosial tempat teman berada. Dalam contoh ini, baris mungkin terlihat seperti ini:

Bandingkan skema ini dengan skema untuk data yang sama yang tidak memperlakukan kualifikasi kolom sebagai data dan memiliki kolom yang sama di setiap baris:

Desain skema kedua menyebabkan tabel berkembang jauh lebih cepat.

Jika Anda menggunakan penentu kolom untuk menyimpan data, beri penentu kolom nama yang pendek tetapi bermakna. Dengan pendekatan ini, Anda dapat mengurangi jumlah data yang ditransfer untuk setiap permintaan. Ukuran maksimumnya adalah 16 KB.

Baris

Pertahankan ukuran semua nilai dalam satu baris di bawah 100 MB. Pastikan data dalam satu baris tidak melebihi 256 MB. Baris yang melebihi batas ini dapat menyebabkan penurunan performa baca.

Simpan semua informasi untuk entitas dalam satu baris. Untuk sebagian besar kasus penggunaan, hindari menyimpan data yang harus Anda baca secara atomik, atau sekaligus, di lebih dari satu baris untuk menghindari inkonsistensi. Misalnya, jika Anda memperbarui dua baris dalam tabel, ada kemungkinan satu baris akan berhasil diperbarui dan pembaruan lainnya akan gagal. Pastikan skema Anda tidak memerlukan lebih dari satu baris untuk diperbarui secara bersamaan agar data terkait akurat. Praktik ini memastikan bahwa jika sebagian permintaan tulis gagal atau harus dikirim lagi, bagian data tersebut tidak akan tidak lengkap untuk sementara.

Pengecualian: Jika menyimpan entitas dalam satu baris menghasilkan baris yang berukuran ratusan MB, Anda harus membagi data di beberapa baris.

Simpan entity terkait dalam baris yang berdekatan, agar pembacaan lebih efisien.

Sel

Jangan menyimpan lebih dari 10 MB data dalam satu sel. Ingatlah bahwa sel adalah data yang disimpan untuk baris dan kolom tertentu dengan stempel waktu unik, dan beberapa sel dapat disimpan di persimpangan baris dan kolom tersebut. Jumlah sel yang dipertahankan dalam kolom diatur oleh kebijakan pengumpulan sampah yang Anda tetapkan untuk family kolom yang berisi kolom tersebut.

Gunakan sel gabungan untuk menyimpan dan memperbarui data gabungan. Jika Anda hanya ingin mengetahui nilai gabungan peristiwa untuk suatu entitas, seperti jumlah bulanan penjualan per karyawan di toko retail, Anda dapat menggunakan agregat. Untuk mengetahui informasi selengkapnya, lihat Menghitung nilai agregat saat penulisan.

Kunci baris

Rancang kunci baris berdasarkan kueri yang akan Anda gunakan untuk mengambil data. Kunci baris yang didesain dengan baik akan mendapatkan performa terbaik dari Bigtable. Kueri Bigtable yang paling efisien mengambil data menggunakan salah satu dari berikut:

• Row key
• Awalan kunci baris
• Rentang baris yang ditentukan oleh kunci baris awal dan akhir

Jenis kueri lainnya memicu pemindaian tabel penuh, yang jauh kurang efisien. Dengan memilih kunci baris yang benar sekarang, Anda dapat menghindari proses migrasi data yang menyakitkan di kemudian hari.

Buat kunci baris Anda tetap pendek. Kunci baris harus berukuran 4 KB atau kurang. Kunci baris yang panjang memerlukan memori dan penyimpanan tambahan serta meningkatkan waktu yang diperlukan untuk mendapatkan respons dari server Bigtable.

Simpan beberapa nilai yang dibatasi dalam setiap kunci baris. Karena cara terbaik untuk mengkueri Bigtable secara efisien adalah dengan kunci baris, sering kali berguna untuk menyertakan beberapa ID dalam kunci baris Anda. Jika kunci baris Anda menyertakan beberapa nilai, Anda harus memahami dengan jelas cara Anda menggunakan data.

Segmen kunci baris biasanya dipisahkan oleh pembatas, seperti titik dua, garis miring, atau simbol hash. Segmen pertama atau kumpulan segmen yang berdekatan adalah awalan kunci baris, dan segmen terakhir atau kumpulan segmen yang berdekatan adalah akhiran kunci baris.

Awalan kunci baris yang direncanakan dengan baik memungkinkan Anda memanfaatkan urutan pengurutan bawaan Bigtable untuk menyimpan data terkait dalam baris yang berdekatan. Menyimpan data terkait dalam baris yang berdekatan memungkinkan Anda mengakses data terkait sebagai rentang baris, bukan menjalankan pemindaian tabel yang tidak efisien.

Jika data Anda menyertakan bilangan bulat yang ingin Anda simpan atau urutkan secara numerik, isi bilangan bulat dengan nol di depannya. Bigtable menyimpan data secara leksikografis. Misalnya, secara leksikografis, 3 > 20 tetapi 20 > 03. Menambahkan angka nol di depan angka 3 memastikan angka diurutkan secara numerik. Taktik ini penting untuk stempel waktu saat kueri berbasis rentang digunakan.

Penting untuk membuat kunci baris yang memungkinkan pengambilan rentang baris yang ditentukan dengan baik. Jika tidak, kueri Anda memerlukan pemindaian tabel, yang jauh lebih lambat daripada mengambil baris tertentu.

Misalnya, jika aplikasi Anda melacak data perangkat seluler, Anda dapat memiliki kunci baris yang terdiri dari jenis perangkat, ID perangkat, dan hari saat data direkam. Kunci baris untuk data ini mungkin terlihat seperti ini:

        phone#4c410523#20200501
        phone#4c410523#20200502
        tablet#a0b81f74#20200501
        tablet#a0b81f74#20200502

Desain kunci baris ini memungkinkan Anda mengambil data dengan satu permintaan untuk:

• Jenis perangkat
• Kombinasi jenis perangkat dan ID perangkat

Desain kunci baris ini tidak optimal jika Anda ingin mengambil semua data untuk hari tertentu. Karena hari disimpan di segmen ketiga, atau sufiks kunci baris, Anda tidak dapat hanya meminta rentang baris berdasarkan sufiks atau segmen tengah kunci baris. Sebagai gantinya, Anda harus mengirim permintaan baca dengan filter yang memindai seluruh tabel untuk mencari nilai hari.

Gunakan nilai string yang mudah dibaca dalam kunci baris Anda jika memungkinkan. Praktik ini mempermudah penggunaan alat Key Visualizer untuk memecahkan masalah Bigtable.

Sebaiknya, Anda mendesain kunci baris yang dimulai dengan nilai umum dan diakhiri dengan nilai terperinci. Misalnya, jika kunci baris Anda menyertakan benua, negara, dan kota, Anda dapat membuat kunci baris yang terlihat seperti berikut agar otomatis diurutkan terlebih dahulu berdasarkan nilai dengan kardinalitas yang lebih rendah:

        asia#india#bangalore
        asia#india#mumbai
        asia#japan#osaka
        asia#japan#sapporo
        southamerica#bolivia#cochabamba
        southamerica#bolivia#lapaz
        southamerica#chile#santiago
        southamerica#chile#temuco

Kunci baris terstruktur

Jika berencana membuat kueri tabel menggunakan SQL, Anda dapat menentukan kunci baris terstruktur, yang memungkinkan Anda mengakses data Bigtable menggunakan kunci multi-bagian, mirip dengan kunci komposit dalam database relasional. Menentukan kunci baris terstruktur untuk tabel memungkinkan Anda mengakses segmen tertentu dari kunci baris menggunakan kueri GoogleSQL untuk Bigtable.

Kunci baris terstruktur dibuat secara otomatis saat Anda membuat tampilan terwujud berkelanjutan. Untuk menerapkan kunci baris terstruktur untuk tabel Bigtable, Anda dapat membuat skema kunci baris yang menentukan jenis data dan encoding setiap segmen kunci baris. Bigtable menyimpan kunci baris sebagai byte yang diurutkan secara leksikografis, dan skema kunci baris memberi tahu GoogleSQL untuk Bigtable cara mendekode dan menafsirkan byte tersebut.

Skema kunci baris diabaikan saat Anda membuat kueri tabel menggunakan metode Bigtable Data API ReadRows dengan library klien Bigtable.

Untuk mengetahui informasi selengkapnya, lihat Mengelola skema kunci baris dan Kueri kunci baris terstruktur.

Kunci baris yang harus dihindari

Beberapa jenis kunci baris dapat mempersulit kueri data Anda, dan beberapa jenis kunci baris dapat menyebabkan performa yang buruk. Bagian ini menjelaskan beberapa jenis kunci baris yang sebaiknya tidak Anda gunakan di Bigtable.

Kunci baris yang dimulai dengan stempel waktu. Pola ini menyebabkan penulisan berurutan didorong ke satu node, sehingga membuat hotspot. Jika Anda menempatkan stempel waktu di kunci baris, awali dengan nilai berkardinalitas tinggi seperti ID pengguna untuk menghindari hotspot.

Kunci baris yang menyebabkan data terkait tidak dikelompokkan. Hindari kunci baris yang menyebabkan data terkait disimpan dalam rentang baris yang tidak berdekatan, yang tidak efisien untuk dibaca bersama.

ID numerik berurutan. Misalkan sistem Anda menetapkan ID numerik ke setiap pengguna aplikasi Anda. Anda mungkin tergoda untuk menggunakan ID numerik pengguna sebagai kunci baris untuk tabel Anda. Namun, karena pengguna baru lebih cenderung menjadi pengguna aktif, pendekatan ini kemungkinan akan mendorong sebagian besar traffic Anda ke sejumlah kecil node.

Pendekatan yang lebih aman adalah menggunakan versi terbalik dari ID numerik pengguna, yang menyebarkan traffic secara lebih merata di semua node untuk tabel Bigtable Anda.

ID yang sering diperbarui. Hindari penggunaan satu kunci baris untuk mengidentifikasi nilai yang harus sering diperbarui. Misalnya, jika Anda menyimpan data penggunaan memori untuk sejumlah perangkat sekali per detik, jangan gunakan satu kunci baris untuk setiap perangkat yang terdiri dari ID perangkat dan metrik yang disimpan, seperti 4c410523#memusage, dan perbarui baris berulang kali. Jenis operasi ini membebani tablet yang menyimpan baris yang sering digunakan. Hal ini juga dapat menyebabkan baris melebihi batas ukurannya, karena nilai kolom sebelumnya menggunakan ruang hingga sel dihapus selama pengumpulan sampah.

Sebagai gantinya, simpan setiap data bacaan baru dalam baris baru. Dengan menggunakan contoh penggunaan memori, setiap kunci baris dapat berisi ID perangkat, jenis metrik, dan stempel waktu, sehingga kunci baris mirip dengan 4c410523#memusage#1423523569918. Strategi ini efisien karena di Bigtable, membuat baris baru tidak memerlukan waktu lebih lama daripada membuat sel baru. Selain itu, strategi ini memungkinkan Anda membaca data dengan cepat dari rentang tanggal tertentu dengan menghitung kunci awal dan akhir yang sesuai.

Untuk nilai yang sering berubah, seperti penghitung yang diperbarui ratusan kali setiap menit, sebaiknya simpan data dalam memori, di lapisan aplikasi, dan tulis baris baru ke Bigtable secara berkala.

Nilai yang di-hash. Melakukan hashing pada kunci baris akan menghilangkan kemampuan Anda untuk memanfaatkan urutan pengurutan alami Bigtable, sehingga tidak mungkin menyimpan baris dengan cara yang optimal untuk kueri. Karena alasan yang sama, nilai hashing menyulitkan penggunaan alat Key Visualizer untuk memecahkan masalah Bigtable. Gunakan nilai yang mudah dibaca, bukan nilai hash.

Nilai dinyatakan sebagai byte mentah, bukan string yang dapat dibaca manusia. Byte mentah tidak masalah untuk nilai kolom, tetapi untuk keterbacaan dan pemecahan masalah, gunakan nilai string di kunci baris.

Kasus penggunaan khusus

Anda mungkin memiliki set data unik yang memerlukan pertimbangan khusus saat mendesain skema untuk menyimpannya di Bigtable. Bagian ini menjelaskan beberapa, tetapi tidak semua, jenis data Bigtable yang berbeda dan beberapa taktik yang disarankan untuk menyimpannya dengan cara yang paling optimal.

Data berbasis waktu

Jika Anda sering mengambil data berdasarkan waktu saat data tersebut dicatat, Anda dapat menyertakan stempel waktu sebagai bagian dari kunci baris.

Misalnya, aplikasi Anda dapat merekam data terkait performa, seperti penggunaan CPU dan memori, sekali per detik untuk banyak mesin. Kunci baris Anda untuk data ini dapat menggabungkan ID untuk mesin dengan stempel waktu untuk data (misalnya, machine_4223421#1425330757685). Perlu diingat bahwa kunci baris diurutkan secara leksikografis.

Jika Anda menyertakan stempel waktu dalam row key, jangan gunakan stempel waktu itu sendiri atau di awal row key. Pola ini menyebabkan penulisan berurutan didorong ke satu node, sehingga membuat hotspot.

Jika Anda biasanya mengambil data terbaru terlebih dahulu dalam kueri, pola yang dapat dipertimbangkan adalah menggunakan stempel waktu terbalik di kunci baris. Pola ini menyebabkan baris diurutkan dari yang terbaru hingga yang terlama, sehingga data yang lebih baru berada di bagian awal tabel. Seperti stempel waktu lainnya, hindari memulai kunci baris dengan stempel waktu terbalik agar tidak menyebabkan hotspot.

Anda bisa mendapatkan stempel waktu terbalik dengan mengurangi stempel waktu dari nilai maksimum bilangan bulat panjang bahasa pemrograman Anda (di Java, java.lang.Long.MAX_VALUE).

Untuk informasi khusus tentang cara menggunakan data deret waktu, lihat Desain skema untuk data deret waktu.

Multi-tenancy

Awalan kunci baris memberikan solusi yang skalabel untuk kasus penggunaan "multi-tenancy", yaitu skenario saat Anda menyimpan data serupa, menggunakan model data yang sama, atas nama beberapa klien. Menggunakan satu tabel untuk semua tenant adalah cara paling efisien untuk menyimpan dan mengakses data multi-tenant.

Misalnya, Anda menyimpan dan melacak histori pembelian atas nama banyak perusahaan. Anda dapat menggunakan ID unik untuk setiap perusahaan sebagai awalan kunci baris. Semua data untuk tenant disimpan dalam baris yang berdekatan di tabel yang sama, dan Anda dapat melakukan kueri atau memfilter menggunakan awalan row key. Kemudian, jika perusahaan tidak lagi menjadi pelanggan Anda dan Anda perlu menghapus data histori pembelian yang Anda simpan untuk perusahaan tersebut, Anda dapat menghapus rentang baris yang menggunakan awalan kunci baris pelanggan tersebut.

Misalnya, jika Anda menyimpan data perangkat seluler untuk pelanggan altostrat dan examplepetstore, Anda dapat membuat kunci baris seperti berikut. Kemudian, jika altostrat bukan lagi pelanggan Anda, Anda akan menghapus semua baris dengan awalan kunci baris altostrat.

        altostrat#phone#4c410523#20190501
        altostrat#phone#4c410523#20190502
        altostrat#tablet#a0b41f74#20190501
        examplepetstore#phone#4c410523#20190502
        examplepetstore#tablet#a6b81f79#20190501
        examplepetstore#tablet#a0b81f79#20190502

Sebaliknya, jika Anda menyimpan data atas nama setiap perusahaan dalam tabelnya sendiri, Anda dapat mengalami masalah performa dan skalabilitas. Anda juga lebih mungkin secara tidak sengaja mencapai batas Bigtable,yaitu 1.000 tabel per instance. Setelah instance mencapai batas ini, Bigtable akan mencegah Anda membuat lebih banyak tabel di instance tersebut.

Privasi

Kecuali jika kasus penggunaan Anda memerlukannya, hindari penggunaan informasi identitas pribadi (PII) atau data pengguna dalam kunci baris atau ID family kolom. Nilai dalam kunci baris dan keluarga kolom adalah data pelanggan dan data layanan, dan aplikasi yang menggunakannya, seperti enkripsi atau logging, dapat secara tidak sengaja mengeksposnya kepada pengguna yang seharusnya tidak memiliki akses ke data pribadi.

Untuk mengetahui informasi selengkapnya tentang cara data layanan ditangani, lihat Google CloudPemberitahuan Privasi.

Nama domain

Anda dapat menyimpan nama domain sebagai data Bigtable.

Berbagai nama domain

Jika Anda menyimpan data tentang entitas yang dapat direpresentasikan sebagai nama domain, pertimbangkan untuk menggunakan nama domain terbalik (misalnya, com.company.product) sebagai kunci baris. Menggunakan nama domain terbalik adalah ide yang sangat baik jika data setiap baris cenderung tumpang-tindih dengan baris yang berdekatan. Dalam hal ini, Bigtable dapat mengompresi data Anda secara lebih efisien.

Sebaliknya, nama domain standar yang tidak dibalik dapat menyebabkan baris diurutkan sedemikian rupa sehingga data terkait tidak dikelompokkan bersama di satu tempat, yang dapat menghasilkan kompresi yang kurang efisien dan pembacaan yang kurang efisien.

Pendekatan ini paling efektif jika data Anda tersebar di banyak nama domain terbalik yang berbeda.

Untuk mengilustrasikan hal ini, pertimbangkan nama domain berikut, yang diurutkan secara otomatis dalam urutan leksikografis oleh Bigtable:

      drive.google.com
      en.wikipedia.org
      maps.google.com

Hal ini tidak diinginkan untuk kasus penggunaan saat Anda ingin membuat kueri semua baris untuk google.com. Sebaliknya, pertimbangkan baris yang sama dengan nama domain yang telah dibalik:

      com.google.drive
      com.google.maps
      org.wikipedia.en

Dalam contoh kedua, baris terkait diurutkan secara otomatis sehingga lebih mudah diambil sebagai rentang baris.

Beberapa nama domain

Jika Anda berencana menyimpan banyak data hanya untuk satu atau sejumlah kecil nama domain, pertimbangkan nilai lain untuk kunci baris Anda. Jika tidak, Anda dapat mendorong penulisan ke satu node dalam cluster, yang mengakibatkan hotspot, atau baris Anda mungkin bertambah terlalu besar.

Kueri yang berubah atau tidak pasti

Jika Anda tidak selalu menjalankan kueri yang sama pada data, atau Anda tidak yakin dengan kueri yang akan dijalankan, salah satu opsi adalah menyimpan semua data untuk baris dalam satu kolom, bukan beberapa kolom. Dengan pendekatan ini, Anda menggunakan format yang memudahkan ekstraksi nilai individual di kemudian hari, seperti format biner protocol buffer atau file JSON.

Kunci baris masih didesain dengan cermat untuk memastikan Anda dapat mengambil data yang diperlukan, tetapi setiap baris biasanya hanya memiliki satu kolom yang berisi semua data untuk baris dalam satu protobuf.

Menyimpan data sebagai pesan protobuf dalam satu kolom, bukan menyebarkan data ke dalam beberapa kolom, memiliki kelebihan dan kekurangan. Keunggulannya antara lain:

• Data menggunakan lebih sedikit ruang, sehingga biaya penyimpanannya lebih rendah.
• Anda mempertahankan sejumlah fleksibilitas dengan tidak melakukan commit pada grup kolom dan penentu kolom.
• Aplikasi pembaca Anda tidak perlu "mengetahui" skema tabel Anda.

Beberapa kerugiannya adalah sebagai berikut:

• Anda harus melakukan deserialisasi pesan protobuf setelah dibaca dari Bigtable.
• Anda kehilangan opsi untuk membuat kueri data dalam pesan protobuf menggunakan filter.
• Anda tidak dapat menggunakan BigQuery untuk menjalankan kueri gabungan pada kolom dalam pesan protobuf setelah membacanya dari Bigtable.

Langkah berikutnya

• Mendesain skema untuk data deret waktu.
• Tinjau langkah-langkah yang terlibat dalam merencanakan skema.
• Pelajari jenis permintaan tulis yang dapat Anda kirim ke Bigtable.
• Terapkan penghitung menggunakan sel gabungan.
• Tinjau kuota dan batas yang berlaku.