Praktik terbaik desain skema

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

• Konsep umum: Konsep dasar yang perlu diingat saat Anda mendesain skema.
• Praktik terbaik: Panduan desain yang berlaku untuk sebagian besar kasus penggunaan, yang dikelompokkan menurut 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 memperbarui tabel, tetapi pola kunci kolom dan 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 pembersihan sampahnya
• Kolom

Poin Penting: Desain skema untuk kueri yang ingin Anda gunakan.

Di Bigtable, desain skema terutama didorong oleh kueri, atau permintaan baca, yang Anda rencanakan untuk dikirim 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. Pada umumnya, hal ini berarti mengirim kueri berdasarkan awalan kunci baris.

Pertimbangan sekunder adalah menghindari hotspot – untuk mencegah hotspot, Anda perlu mempertimbangkan pola tulis 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. API ini tidak mendukung join, dan transaksi hanya didukung dalam satu baris.
• Setiap tabel hanya memiliki satu indeks, yaitu kunci baris. Tidak ada indeks sekunder. Setiap kunci baris harus unik.
• Baris diurutkan secara leksikografis menurut kunci baris, dari string byte terendah hingga tertinggi. Kunci baris diurutkan dalam urutan byte big-endian (terkadang disebut urutan byte jaringan), yang setara dengan urutan abjad biner.
• Keluarga kolom tidak disimpan dalam urutan tertentu.
• Kolom dikelompokkan menurut grup kolom dan diurutkan dalam urutan leksikografis dalam grup kolom. Misalnya, dalam keluarga kolom yang disebut SysMonitor dengan penentu kolom ProcessName, User, %CPU, ID, Memory, DiskRead, dan Priority, Bigtable menyimpan kolom dalam urutan ini:

			SysMonitor
%CPU	DiskRead	ID	Memori	Prioritas	ProcessName	Pengguna

• Persimpangan baris dan kolom dapat berisi beberapa sel dengan stempel waktu. Setiap sel berisi versi data unik dengan stempel waktu untuk baris dan kolom tersebut.
• Grup kolom gabungan berisi sel gabungan. Anda dapat membuat keluarga kolom 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 ruang baris tabel.
• Tabel Bigtable jarang digunakan. Kolom tidak akan menggunakan ruang apa pun dalam baris yang tidak menggunakan kolom.

Praktik terbaik

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

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

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

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

Karena semua tabel dalam instance disimpan di tablet yang sama, desain skema yang menghasilkan titik panas di 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.

Di 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 dalam satu tabel. Anda dapat menetapkan awalan kunci baris unik untuk digunakan untuk 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 Anda menghindari pembuatan 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 akan meningkatkan load balancing dan dapat meningkatkan overhead pengelolaan.

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

Grup kolom

Tempatkan kolom terkait dalam grup kolom yang sama. Jika baris berisi beberapa nilai yang saling terkait, sebaiknya kelompokkan kolom yang berisi nilai tersebut dalam grup kolom yang sama. Mengelompokkan data sesecara mungkin untuk menghindari kebutuhan mendesain filter yang kompleks sehingga Anda mendapatkan hanya informasi yang diperlukan, tetapi tidak lebih, dalam permintaan baca yang paling sering.

Buat hingga sekitar 100 grup kolom per tabel. Membuat lebih dari 100 keluarga kolom dapat menyebabkan menurunnya performa.

Pilih nama singkat untuk keluarga kolom Anda. Nama disertakan dalam data yang ditransfer untuk setiap permintaan.

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

Kolom

Buat kolom sebanyak yang Anda butuhkan dalam tabel. Tabel Bigtable renggang, 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 berkontribusi pada praktik terbaik ini:

• Bigtable memerlukan waktu untuk memproses setiap sel dalam baris.
• Setiap sel menambahkan beberapa overhead ke jumlah data yang disimpan di tabel dan dikirim melalui jaringan. Misalnya, jika Anda menyimpan data sebesar 1 KB (1.024 byte), akan lebih hemat ruang jika 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 pertemanan dalam grup kolom Friends. Setiap baris mewakili seseorang dan semua persahabatannya. Setiap penentu kolom dapat berupa ID teman. Kemudian, nilai untuk setiap kolom di baris tersebut dapat berupa lingkaran sosial tempat teman berada. Dalam contoh ini, baris mungkin terlihat seperti ini:

Row key	Fred	Gabriel	Hiroshi	Seo Yoon	Jakob
Jose	book-club	kantor	tenis
Sofia			kantor	school	chess-club

Bandingkan skema ini dengan skema untuk data yang sama yang tidak memperlakukan penentu kolom sebagai data, tetapi memiliki kolom yang sama di setiap baris:

Row key	Teman	Circle
Jose#1	Fred	book-club
Jose#2	Gabriel	kantor
Jose#3	Hiroshi	tenis
Sofia#1	Hiroshi	kantor
Sofia#2	Seo Yoon	school
Sofia#3	Jakob	chess-club

Desain skema kedua menyebabkan tabel berkembang jauh lebih cepat.

Jika Anda menggunakan penentu kolom untuk menyimpan data, berikan 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 menurunnya 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, satu baris mungkin berhasil diperbarui dan update 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 bagian dari 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 di baris yang berdekatan, untuk membuat pembacaan lebih efisien.

Sel

Jangan menyimpan data lebih dari 10 MB dalam satu sel. Ingat 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 pembersihan sampah yang Anda tetapkan untuk keluarga kolom yang berisi kolom tersebut.

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

Kunci baris

Buat desain kunci baris berdasarkan kueri yang akan Anda gunakan untuk mengambil data. Kunci baris yang dirancang dengan baik akan mendapatkan performa terbaik dari Bigtable. Kueri Bigtable yang paling efisien mengambil data menggunakan salah satu dari hal 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 rumit nanti.

Buat kunci baris Anda tetap singkat. 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.

Menyimpan beberapa nilai yang dipisahkan di setiap kunci baris. Karena cara terbaik untuk membuat kueri Bigtable secara efisien adalah dengan kunci baris, sebaiknya sertakan beberapa ID dalam kunci baris Anda. Jika kunci baris Anda menyertakan beberapa nilai, penting untuk memiliki pemahaman yang jelas tentang 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, tambahkan bilangan bulat dengan nol di awal. Bigtable menyimpan data secara leksikografis. Misalnya, secara leksikografis, 3 > 20, tetapi 20 > 03. Padding 3 dengan angka nol di awal memastikan bahwa angka tersebut diurutkan secara numerik. Taktik ini penting untuk stempel waktu tempat kueri berbasis rentang digunakan.

Anda harus 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 data dicatat. 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 akan optimal jika Anda ingin mengambil semua data untuk hari tertentu. Karena hari disimpan di segmen ketiga, atau akhiran kunci baris, Anda tidak dapat meminta rentang baris berdasarkan akhiran atau segmen tengah kunci baris. Sebagai gantinya, Anda harus mengirimkan permintaan baca dengan filter yang memindai seluruh tabel untuk mencari nilai hari.

Gunakan nilai string yang dapat dibaca manusia di kunci baris jika memungkinkan. Praktik ini akan memudahkan penggunaan alat Key Visualizer untuk memecahkan masalah terkait Bigtable.

Sering kali, Anda harus 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 sehingga secara 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

Catatan: Dalam produksi, gunakan ID yang menggunakan lebih sedikit penyimpanan, seperti AS untuk Asia atau 591 untuk Bolivia.

Kunci baris yang harus dihindari

Beberapa jenis kunci baris dapat mempersulit kueri data Anda, dan beberapa kunci menghasilkan performa yang buruk. Bagian ini menjelaskan beberapa jenis kunci baris yang sebaiknya Anda hindari penggunaannya di Bigtable.

Kunci baris yang diawali dengan stempel waktu. Pola ini menyebabkan operasi tulis berurutan didorong ke satu node, sehingga membuat hotspot. Jika Anda memasukkan stempel waktu dalam kunci baris, awali dengan nilai berkardinalitas tinggi seperti User-ID 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 cenderung menjadi pengguna aktif, pendekatan ini cenderung akan mendorong sebagian besar traffic Anda ke sejumlah kecil node.

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

ID yang sering diperbarui. Hindari penggunaan kunci baris tunggal 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 melebihi kapasitas tablet yang menyimpan baris yang sering digunakan. Hal ini juga dapat menyebabkan baris melebihi batas ukurannya, karena nilai kolom sebelumnya menghabiskan ruang hingga sel dihapus selama pembersihan sampah.

Sebagai gantinya, simpan setiap pembacaan baru di 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 yang lebih lama daripada membuat sel baru. Selain itu, strategi ini memungkinkan Anda membaca data dari rentang tanggal tertentu dengan cepat 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. Meng-hash kunci baris akan menghilangkan kemampuan Anda untuk memanfaatkan urutan pengurutan alami Bigtable, sehingga tidak dapat menyimpan baris dengan cara yang optimal untuk kueri. Karena alasan yang sama, nilai hashing membuat penggunaan alat Key Visualizer untuk memecahkan masalah dengan Bigtable menjadi sulit. Gunakan nilai yang dapat dibaca manusia, bukan nilai yang di-hash.

Nilai yang dinyatakan sebagai byte mentah, bukan string yang dapat dibaca manusia. Byte mentah baik-baik saja untuk nilai kolom, tetapi untuk keterbacaan dan pemecahan masalah, gunakan nilai string dalam 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 sering mengambil data berdasarkan waktu saat data dicatat, Anda dapat menyertakan stempel waktu sebagai bagian dari kunci baris.

Misalnya, aplikasi Anda mungkin merekam data terkait performa, seperti penggunaan CPU dan memori, sekali per detik untuk banyak mesin. Kunci baris 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 kunci baris, jangan gunakan stempel waktu itu sendiri atau di awal kunci baris. Pola ini menyebabkan operasi tulis berurutan didorong ke satu node, sehingga membuat hotspot.

Jika Anda biasanya mengambil kumpulan data terbaru terlebih dahulu dalam kueri, pola yang perlu dipertimbangkan adalah menggunakan stempel waktu terbalik di kunci baris. Pola ini menyebabkan baris diurutkan dari yang terbaru ke yang paling lama, sehingga data yang lebih baru tercantum lebih awal dalam tabel. Seperti stempel waktu lainnya, hindari memulai kunci baris dengan stempel waktu yang terbalik agar Anda tidak menyebabkan hotspot.

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

Catatan: Stempel waktu biasanya dinyatakan sebagai jumlah mikrodetik sejak 1970-01-01 00:00:00 UTC.

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 tempat 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 mengkueri atau memfilter menggunakan awalan kunci baris. Kemudian, jika perusahaan tidak lagi menjadi pelanggan Anda dan Anda perlu menghapus data histori pembelian yang disimpan 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 cenderung tidak sengaja mencapai batas Bigtable sebesar 1.000 tabel per instance. Setelah instance mencapai batas ini, Bigtable akan mencegah Anda membuat lebih banyak tabel dalam instance.

Privasi

Kecuali jika kasus penggunaan Anda mengharuskannya, hindari penggunaan informasi identitas pribadi (PII) atau data pengguna dalam kunci baris atau ID keluarga 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 tidak boleh memiliki akses ke data pribadi.

Untuk mengetahui informasi selengkapnya tentang cara penanganan data layanan, lihat Pemberitahuan Privasi Google Cloud.

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 bagus 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 di satu tempat, yang dapat menghasilkan kompresi yang kurang efisien dan pembacaan yang kurang efisien.

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

Untuk mengilustrasikan hal ini, pertimbangkan nama domain berikut, yang secara otomatis diurutkan 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 dengan cara yang memudahkan pengambilannya sebagai rentang baris.

Beberapa nama domain

Jika Anda ingin menyimpan banyak data hanya untuk satu atau sejumlah kecil nama domain, pertimbangkan nilai lain untuk kunci baris Anda. Jika tidak, Anda mungkin mendorong operasi tulis ke satu node di cluster, sehingga menghasilkan hotspot, atau baris Anda mungkin menjadi terlalu besar.

Kueri yang berubah atau tidak pasti

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

Kunci baris masih dirancang 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 beberapa kolom, memiliki kelebihan dan kekurangan. Keunggulannya meliputi hal berikut:

• Data ini memerlukan lebih sedikit ruang, sehingga biaya penyimpanannya lebih rendah.
• Anda mempertahankan sejumlah fleksibilitas dengan tidak berkomitmen pada grup kolom dan penentu kolom.
• Aplikasi pembacaan Anda tidak perlu "mengetahui" skema tabel Anda.

Beberapa kelemahannya adalah sebagai berikut:

• Anda harus mendeserialisasi 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 selanjutnya

• Buat desain 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.