Praktik terbaik desain skema

Skema Bigtable yang efektif memungkinkan Anda memaksimalkan throughput baca dan tulis, mencegah hotspot, dan menskalakan penyimpanan secara efisien. Sebelum memulai, tinjau ringkasan Bigtable untuk memahami arsitektur dan model penyimpanan yang mendasarinya.

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 kolom dan pola row key ditentukan oleh data yang Anda tulis ke tabel.

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

• Row key
• Grup kolom, termasuk kebijakan pembersihan sampah memorinya
• Kolom

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

Di Bigtable, desain skema terutama didorong oleh kueri, atau permintaan baca, yang ingin 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 ini berarti mengirim kueri berdasarkan awalan row key.

Pertimbangan kedua 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 kunci/nilai, bukan penyimpanan relasional. Layanan ini tidak mendukung join, dan transaksi hanya didukung dalam satu baris.
• Setiap tabel memiliki indeks: row key. Setiap kunci baris harus unik. Untuk membuat indeks sekunder, gunakan tampilan terwujud berkelanjutan. Untuk mengetahui informasi selengkapnya, lihat Membuat indeks sekunder asinkron.
• Row key mengurutkan baris secara leksikografis dari string byte terendah hingga tertinggi. Urutan ini adalah big-endian (terkadang disebut urutan byte jaringan), setara biner dari urutan alfabet.
• Grup kolom tidak disimpan dalam urutan tertentu.
• Kolom dikelompokkan menurut grup kolom dan diurutkan dalam urutan leksikografis dalam grup kolom. Misalnya, dalam grup kolom bernama 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 yang diberi stempel waktu. Setiap sel berisi versi data yang unik dan diberi stempel waktu untuk baris dan kolom tersebut.
• Grup kolom agregat berisi sel agregat. Anda dapat membuat grup kolom yang hanya berisi sel agregat. 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 sama sekali.
• Idealnya, operasi baca dan tulis harus didistribusikan secara merata di seluruh ruang baris tabel.
• Tabel Bigtable bersifat sparse. 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, sedangkan 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 level tabel dan berlanjut ke level row key, bagian berikut menjelaskan praktik terbaik untuk desain skema:

• Tables
• Grup kolom
• Kolom
• Baris
• Sel
• Row key

Semua elemen tabel, terutama row key, harus didesain dengan mempertimbangkan permintaan baca yang direncanakan. Periksa kuota dan batas untuk mengetahui 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 row key unik untuk digunakan pada setiap set data, sehingga Bigtable menyimpan data terkait dalam rentang baris yang berurutan, yang kemudian dapat Anda kueri berdasarkan awalan row key.

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 tail.
• Membuat lebih banyak tabel tidak akan meningkatkan load balancing dan dapat meningkatkan overhead pengelolaan.

Anda mungkin ingin tabel terpisah untuk kasus penggunaan berbeda yang memerlukan skema berbeda, tetapi sebaiknya jangan gunakan tabel terpisah untuk data yang serupa. Misalnya, Anda tidak boleh membuat tabel baru karena ini 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 mendesain filter yang kompleks dan agar Anda hanya mendapatkan informasi yang diperlukan, tetapi tidak lebih, dalam permintaan baca yang paling sering Anda lakukan.

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

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

Tempatkan kolom yang memiliki kebutuhan retensi data yang berbeda dalam grup kolom yang berbeda. Praktik ini penting jika Anda ingin membatasi biaya penyimpanan. Kebijakan pembersihan sampah memori ditetapkan di tingkat grup kolom, bukan di tingkat kolom. Misalnya, jika Anda hanya perlu menyimpan versi terbaru dari bagian data tertentu, jangan simpan di grup kolom yang ditetapkan 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 perlukan 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 demikian. Beberapa faktor yang berkontribusi pada praktik terbaik ini:

• Bigtable memerlukan waktu untuk memproses setiap sel dalam satu baris.
• Setiap sel menambahkan beberapa overhead ke jumlah data yang disimpan dalam tabel Anda dan dikirim melalui jaringan. Misalnya, jika Anda menyimpan data sebesar 1 KB (1.024 byte), akan jauh lebih hemat ruang jika data tersebut disimpan 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.

Jika ingin, 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 pertemanannya. Setiap penentu kolom dapat berupa ID teman. Kemudian, nilai untuk setiap kolom di baris tersebut dapat berupa lingkaran sosial tempat teman tersebut 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 nama yang singkat, tetapi bermakna pada penentu kolom. Pendekatan ini memungkinkan Anda 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 sebuah entity 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 mengupdate dua baris dalam tabel, mungkin satu baris akan berhasil diupdate 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 entity dalam satu baris menghasilkan baris yang berukuran ratusan MB, Anda harus membagi data ke 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 yang unik, dan beberapa sel dapat disimpan di persimpangan baris dan kolom tersebut. Jumlah sel yang dipertahankan dalam kolom diatur oleh kebijakan pembersihan sampah memori yang Anda tetapkan untuk grup kolom yang berisi kolom tersebut.

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

Row key

Merancang row key Anda berdasarkan kueri yang akan Anda gunakan untuk mengambil data. Row key yang dirancang dengan baik akan menghasilkan performa terbaik dari Bigtable. Kueri Bigtable yang paling efisien mengambil data menggunakan salah satu hal berikut:

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

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

Buat row key yang singkat. Row key harus berukuran 4 KB atau kurang. Row key yang panjang menggunakan memori dan penyimpanan tambahan serta meningkatkan waktu yang diperlukan untuk mendapatkan respons dari server Bigtable.

Menyimpan beberapa nilai yang dibatasi dalam setiap row key. Karena cara terbaik untuk membuat kueri Bigtable secara efisien adalah dengan row key, sebaiknya sertakan beberapa ID dalam row key Anda. Jika row key Anda menyertakan beberapa nilai, sangat penting untuk memiliki pemahaman yang jelas tentang cara Anda menggunakan data.

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

Awalan row key yang direncanakan dengan baik memungkinkan Anda memanfaatkan tata urutan 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, daripada menjalankan pemindaian tabel yang tidak efisien.

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

Penting untuk membuat row key 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 row key yang terdiri dari jenis perangkat, ID perangkat, dan hari data direkam. Row key untuk data ini mungkin terlihat seperti ini:

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

Desain row key ini memungkinkan Anda mengambil data dengan satu permintaan untuk:

• Jenis perangkat
• Kombinasi jenis perangkat dan ID perangkat

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

Gunakan nilai string yang dapat dibaca manusia di row key Anda jika memungkinkan. Praktik ini memudahkan penggunaan alat Key Visualizer untuk memecahkan masalah Bigtable.

Sering kali, Anda harus mendesain row key yang dimulai dengan nilai umum dan diakhiri dengan nilai terperinci. Misalnya, jika row key Anda menyertakan benua, negara, dan kota, Anda dapat membuat row key 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

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

Row key terstruktur

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

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

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

Skema row key diabaikan saat Anda mengkueri tabel menggunakan metode ReadRows Bigtable Data API dengan library klien Bigtable.

Untuk mengetahui informasi selengkapnya, lihat Mengelola skema row key dan Kueri row key terstruktur.

Row key yang harus dihindari

Beberapa jenis row key dapat mempersulit kueri data Anda, dan beberapa jenis lainnya dapat menyebabkan performa yang buruk. Bagian ini menjelaskan beberapa jenis row key yang harus Anda hindari penggunaannya di Bigtable.

Row key yang dimulai dengan stempel waktu. Pola ini menyebabkan penulisan berurutan didorong ke satu node, sehingga menciptakan hotspot. Jika Anda menempatkan stempel waktu di row key, awali dengan nilai kardinalitas tinggi seperti ID pengguna untuk menghindari hotspot.

Row key yang menyebabkan data terkait tidak dikelompokkan. Hindari row key yang menyebabkan data terkait disimpan dalam rentang baris yang tidak berurutan, yang tidak efisien untuk dibaca bersama.

ID numerik berurutan. Misalnya, sistem Anda menetapkan ID numerik ke setiap pengguna aplikasi Anda. Anda mungkin tergoda untuk menggunakan ID numerik pengguna sebagai row key 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 row key untuk mengidentifikasi nilai yang harus sering diupdate. Misalnya, jika Anda menyimpan data penggunaan memori untuk sejumlah perangkat sekali per detik, jangan gunakan satu row key untuk setiap perangkat yang terdiri dari ID perangkat dan metrik yang disimpan, seperti 4c410523#memusage, dan memperbarui 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 pembersihan sampah memori.

Sebagai gantinya, simpan setiap pembacaan baru di baris baru. Dengan menggunakan contoh penggunaan memori, setiap row key dapat berisi ID perangkat, jenis metrik, dan stempel waktu, sehingga row key 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 hash. Melakukan hashing pada row key akan menghilangkan kemampuan Anda untuk memanfaatkan urutan pengurutan alami Bigtable, sehingga tidak mungkin untuk menyimpan baris dengan cara yang optimal untuk pembuatan kueri. Untuk alasan yang sama, melakukan hashing pada nilai akan menyulitkan penggunaan alat Key Visualizer untuk memecahkan masalah Bigtable. 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 cocok untuk nilai kolom, tetapi untuk keterbacaan dan pemecahan masalah, gunakan nilai string di row key.

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 pencatatannya, Anda dapat menyertakan stempel waktu sebagai bagian dari row key.

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

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

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

Anda bisa mendapatkan stempel waktu terbalik dengan mengurangi stempel waktu dari nilai maksimum bahasa pemrograman Anda 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 row key 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 membuat 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 row key pelanggan tersebut.

Misalnya, jika Anda menyimpan data perangkat seluler untuk pelanggan altostrat dan examplepetstore, Anda dapat membuat row key seperti berikut. Kemudian, jika altostrat bukan lagi pelanggan Anda, hapus semua baris dengan awalan row key 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 mencapai batas Bigtable secara tidak sengaja,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 mengharuskannya, hindari penggunaan informasi identitas pribadi (PII) atau data pengguna dalam row key atau ID grup kolom. Nilai dalam row key dan grup 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 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 entity yang dapat direpresentasikan sebagai nama domain, pertimbangkan untuk menggunakan nama domain terbalik (misalnya, com.company.product) sebagai row key. 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 dengan 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 mengakibatkan kompresi dan pembacaan yang kurang efisien.

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

Untuk mengilustrasikan poin 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 mengkueri 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 pengambilan baris tersebut sebagai rentang baris.

Beberapa nama domain

Jika Anda ingin menyimpan banyak data hanya untuk satu atau sejumlah kecil nama domain, pertimbangkan nilai lain untuk row key Anda. Jika tidak, Anda mungkin akan mengirim penulisan ke satu node di cluster, sehingga menyebabkan hotspot, atau baris Anda mungkin menjadi terlalu besar.

Menyimpan data dalam format protobuf

Untuk mengurangi biaya penyimpanan dan meningkatkan efisiensi baca dan tulis, Anda dapat mengelompokkan data terkait ke dalam pesan buffering protokol (protobuf) dan menyimpannya dalam satu kolom, bukan menyimpan setiap kolom di kolomnya sendiri. Jika Anda biasanya membaca sekumpulan kolom bersama-sama, menyimpannya dalam satu kolom sebagai satu nilai akan lebih efisien, karena membaca satu kolom lebih cepat daripada membaca banyak kolom satu per satu. Jika Anda menyimpan data sebagai pesan protobuf, Anda dapat memanfaatkan fitur Bigtable berikut:

• Menggunakan buffering protokol untuk menyimpan struktur data yang fleksibel akan mengurangi biaya penyimpanan dengan menyimpan data Anda di tempatnya dan menghindari duplikasi.
• Mengupload skema protobuf ke Bigtable dalam paket skema memungkinkan pembuatan kueri sisi server. Paket skema memungkinkan Bigtable memahami dan mengurai struktur data yang diserialisasi selama eksekusi kueri.
• Menggunakan GoogleSQL untuk mengkueri dan memfilter setiap kolom dalam pesan protobuf Anda secara langsung di Bigtable dapat dilakukan dengan cepat dan efisien. Dengan melakukan deserialisasi data di sisi server, Anda dapat melakukan kueri dan proyeksi terperinci tanpa perlu mentransfer seluruh objek protobuf ke klien Anda.
• Menggunakan tabel eksternal BigQuery untuk menganalisis data protobuf yang disimpan di Bigtable memungkinkan Anda menyederhanakan analisis.

Untuk mengetahui informasi selengkapnya, lihat Membuat dan mengelola skema protobuf dan Membuat dan mengelola skema Avro (Pratinjau).

Langkah berikutnya

• Mendesain skema untuk data deret waktu
• Tinjau langkah-langkah yang diperlukan dalam merencanakan skema
• Pelajari jenis permintaan tulis yang dapat Anda kirim ke Bigtable
• Mengimplementasikan penghitung menggunakan sel agregat
• Meninjau kuota dan batas yang berlaku
• Membuat kueri data protobuf
• Membuat kueri data Avro