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: 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 objek atau file definisi skema. Anda dapat menambahkan grup kolom ke tabel saat membuat atau memperbarui tabel, tetapi kolom dan pola kunci baris ditentukan oleh data yang Anda tulis di tabel.

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

• Kunci baris
• Kelompok kolom, termasuk kebijakan pembersihan sampah memori
• Kolom

Poin Penting: Desain skema untuk kueri yang akan digunakan.

Di Bigtable, desain skema didorong terutama 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, artinya mengirim kueri berdasarkan awalan baris kunci.

Pertimbangan kedua adalah menghindari hotspot. Untuk mencegah hotspot, Anda harus mempertimbangkan pola penulisan dan cara menghindari akses ke ruang kunci yang kecil dalam waktu singkat.

Konsep umum berikut berlaku untuk desain skema Bigtable:

• Bigtable adalah penyimpanan kunci/nilai, bukan penyimpanan relasional. Metode ini tidak mendukung gabungan, dan transaksi hanya didukung dalam satu baris.
• Setiap tabel hanya memiliki satu indeks, yaitu row key. Tidak ada indeks sekunder. Setiap row key harus unik.
• Baris diurutkan secara leksikografis berdasarkan kunci baris, dari string byte terendah ke tertinggi. Kunci baris diurutkan dalam urutan byte big-endian (terkadang disebut urutan byte jaringan), setara biner dari urutan abjad.
• Kelompok 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

• Perpotongan baris dan kolom dapat berisi beberapa sel dengan stempel waktu. Setiap sel berisi versi data yang memiliki stempel waktu dan unik untuk baris dan kolom tersebut.
• Grup kolom gabungan berisi sel gabungan. Anda dapat membuat kelompok kolom yang hanya berisi sel agregat. Agregat memungkinkan Anda menggabungkan data baru dengan data yang sudah ada di dalam 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 jarang. Kolom tidak 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 tidak dirancang dengan baik dapat menyebabkan sistem berperforma buruk. Setiap kasus penggunaan berbeda dan memerlukan desainnya sendiri, tetapi praktik terbaik berikut berlaku untuk sebagian besar kasus penggunaan. Ada pengecualian.

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

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

Semua elemen tabel, terutama tombol baris, harus didesain dengan mempertimbangkan permintaan baca yang direncanakan. Periksa kuota dan batas untuk mengetahui batas ukuran yang direkomendasikan dan batas ukuran mutlak 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 waktu singkat.

Tabel

Simpan set data dengan skema serupa di tabel yang sama, bukan di 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 untuk 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 dibuat kuerinya dengan awalan kunci baris.

Bigtable memiliki batas 1.000 tabel per instance, tetapi biasanya Anda akan memiliki tabel yang jauh lebih sedikit. Hindari membuat tabel dalam jumlah besar karena alasan berikut:

• Mengirim permintaan ke berbagai tabel dapat meningkatkan overhead koneksi backend, sehingga mengakibatkan peningkatan latensi tail.
• Memiliki beberapa tabel dengan ukuran berbeda dapat mengganggu load balancing di balik layar yang membuat Bigtable berfungsi dengan baik.

Anda mungkin menginginkan tabel terpisah untuk kasus penggunaan berbeda yang memerlukan skema 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.

Kelompok kolom

Masukkan kolom terkait di grup kolom yang sama. Jika baris berisi beberapa nilai yang terkait satu sama lain, sebaiknya kelompokkan kolom yang berisi nilai-nilai tersebut dalam kelompok kolom yang sama. Kelompokkan data semirip mungkin agar tidak perlu mendesain filter yang kompleks sehingga Anda hanya akan mendapatkan informasi yang diperlukan dalam permintaan operasi baca yang paling sering.

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.

Masukkan kolom yang memiliki kebutuhan retensi data yang berbeda ke dalam grup kolom yang berbeda. Praktik ini penting jika Anda ingin membatasi biaya penyimpanan. Kebijakan pembersihan sampah memori ditetapkan pada tingkat kelompok kolom, bukan pada tingkat kolom. Misalnya, jika Anda hanya perlu menyimpan versi terbaru dari bagian data tertentu, jangan menyimpannya dalam grup kolom yang ditetapkan untuk menyimpan 1.000 versi data lain. Jika tidak, Anda membayar untuk menyimpan 999 sel data yang tidak Anda butuhkan.

Kolom

(Opsional) Perlakukan penentu kolom sebagai data. Karena harus menyimpan penentu kolom untuk setiap kolom, Anda dapat menghemat ruang dengan memberi nama kolom dengan nilai. Sebagai contoh, perhatikan tabel yang menyimpan data tentang pertemanan di grup kolom Friends. Setiap baris mewakili seseorang dan semua pertemanan mereka. Setiap penentu kolom bisa menjadi ID teman. Kemudian nilai untuk setiap kolom di baris itu bisa berupa lingkaran sosial tempat teman berada. Dalam contoh ini, baris mungkin terlihat seperti ini:

Row key	Penentu kolom:value	Penentu kolom:value	Penentu kolom:value
Joshua	Fahmi:klub buku	Gabriel:kerja	Hiroshi:tenis
Sofia	Hiroshi:kantor	Seo Yoon:sekolah	Jakob:klub catur

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

Row key	Penentu kolom:value	Penentu kolom:value
Jose#1	Teman:Fahmi	Lingkaran:klub-buku
Jose#2	Teman:Gabriel	Lingkaran:kantor
Jose#3	Teman:Hiroshi	Lingkaran:tenis
Sofia#1	Teman:Hiroshi	Lingkaran:kantor
Sofia#2	Teman:Seo Yoon	Lingkaran:sekolah
Sofia#3	Teman:Jakob	Lingkaran:klub catur

Desain skema kedua menyebabkan tabel bertambah lebih cepat.

Jika Anda menggunakan penentu kolom untuk menyimpan data, berikan nama pendek tetapi bermakna pada penentu kolom. Pendekatan ini memungkinkan Anda mengurangi jumlah data yang ditransfer untuk setiap permintaan. Ukuran maksimumnya adalah 16 KB.

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, selama tidak ada baris yang melebihi batas maksimum 256 MB per baris.

Hindari menggunakan terlalu banyak kolom dalam satu baris. Meskipun tabel dapat memiliki jutaan kolom, baris seharusnya tidak. Ada beberapa faktor yang berkontribusi pada praktik terbaik ini:

• Bigtable membutuhkan waktu untuk memproses setiap sel secara berurutan.
• Setiap sel menambahkan beberapa overhead pada jumlah data yang disimpan di tabel dan dikirim melalui jaringan. Misalnya, jika Anda menyimpan 1 KB (1.024 byte), akan jauh lebih menghemat ruang untuk menyimpan data tersebut dalam satu sel, daripada menyebarkan data di 1.024 sel yang masing-masing berisi 1 byte.

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

Baris

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

Simpan semua informasi untuk 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 memperbarui dua baris dalam tabel, satu baris mungkin berhasil diperbarui dan baris lainnya akan gagal. Pastikan skema Anda tidak memerlukan pembaruan lebih dari satu baris secara bersamaan agar data terkait akurat. Praktik ini memastikan bahwa jika ada bagian dari permintaan tulis yang gagal atau harus dikirim lagi, bagian data tersebut tidak lengkap untuk sementara.

Pengecualian: Jika menyimpan entity dalam satu baris menghasilkan baris dengan ratusan MB, Anda harus membagi data ke beberapa baris.

Simpan entity terkait dalam baris yang berdekatan, agar operasi baca menjadi lebih efisien.

Sel

Jangan simpan lebih dari 10 MB data 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 memori yang Anda tetapkan untuk grup kolom yang berisi kolom tersebut.

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

Kunci baris

Desain row key Anda berdasarkan kueri yang akan digunakan untuk mengambil data. Tombol 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 dengan tombol baris awal dan akhir

Jenis kueri lain memicu pemindaian tabel penuh, yang jauh kurang efisien. Dengan memilih kunci baris yang benar sekarang, Anda dapat menghindari proses migrasi data yang sulit di lain waktu.

Buat tombol baris yang singkat. Baris kunci harus berukuran 4 KB atau kurang. Kunci baris panjang menggunakan memori dan penyimpanan tambahan serta meningkatkan waktu yang diperlukan untuk mendapatkan respons dari server Bigtable.

Simpan beberapa nilai yang dipisahkan di setiap kunci baris. Karena cara terbaik untuk mengkueri Bigtable secara efisien adalah dengan kunci baris, menyertakan beberapa ID di kunci baris sering kali berguna. Jika row key Anda menyertakan beberapa nilai, Anda harus memiliki pemahaman yang jelas tentang cara Anda menggunakan data.

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

Dengan awalan kunci baris yang terencana dengan baik, Anda dapat memanfaatkan urutan penyortiran bawaan dari Bigtable untuk menyimpan data terkait dalam baris yang berdekatan. Dengan menyimpan data terkait dalam baris yang berdekatan, Anda dapat mengakses data terkait sebagai rentang baris, bukan menjalankan pemindaian tabel yang tidak efisien.

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

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 dicatat. Kunci baris 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 kunci baris, Anda tidak dapat hanya meminta rentang baris berdasarkan akhiran atau segmen tengah dari tombol baris. 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 kunci baris Anda jika memungkinkan. Praktik ini 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 row key mencakup benua, negara, dan kota, Anda dapat membuat kunci baris yang terlihat seperti berikut sehingga kunci baris diurutkan terlebih dahulu berdasarkan nilai dengan kardinalitas 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 memerlukan lebih sedikit penyimpanan, seperti AS untuk Asia atau 591 untuk Bolivia.

Tombol baris yang harus dihindari

Beberapa jenis kunci baris dapat menyulitkan kueri data Anda, dan beberapa lainnya menghasilkan 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 row key, 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 sehingga 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 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 kunci baris tunggal untuk mengidentifikasi nilai yang harus sering diperbarui. Misalnya, jika Anda menyimpan data penggunaan memori untuk sejumlah perangkat satu kali per detik, jangan gunakan kunci baris tunggal untuk setiap perangkat yang terdiri dari ID perangkat dan metrik yang disimpan, seperti 4c410523#memusage, lalu perbarui baris tersebut berulang kali. Jenis operasi ini melebihi tablet yang menyimpan baris yang sering digunakan. Hal ini juga dapat menyebabkan baris melebihi batas ukurannya, karena nilai pada kolom sebelumnya menghabiskan ruang sampai sel-sel dihapus selama pembersihan sampah memori.

Sebagai gantinya, simpan setiap bacaan baru di baris yang baru. Dengan menggunakan contoh penggunaan memori, setiap tombol baris dapat berisi ID perangkat, jenis metrik, dan stempel waktu sehingga kunci baris serupa dengan 4c410523#memusage#1423523569918. Strategi ini efisien karena di Bigtable, membuat baris baru tidak memerlukan lebih banyak waktu 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, pada lapisan aplikasi, dan tulis baris baru ke Bigtable secara berkala.

Nilai yang di-hash. Dengan melakukan hashing pada row key, Anda tidak dapat memanfaatkan urutan penyortiran alami BigQuery, sehingga tidak mungkin untuk menyimpan baris dengan cara yang optimal untuk membuat kueri. Karena alasan yang sama, nilai hashing membuat penggunaan alat Key Visualizer sulit dilakukan untuk memecahkan masalah Bigtable. Gunakan nilai yang dapat dibaca manusia, bukan nilai hash.

Nilai yang 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 merancang skema untuk menyimpannya di Bigtable. Bagian ini menjelaskan beberapa, tetapi tidak semua, berbagai jenis data Bigtable dan beberapa taktik yang disarankan untuk menyimpannya dengan cara yang paling optimal.

Data berbasis waktu

Sertakan stempel waktu sebagai bagian dari row key jika Anda sering mengambil data berdasarkan waktu saat data direkam.

Misalnya, aplikasi Anda mungkin merekam data terkait performa, seperti penggunaan CPU dan memori, sekali per detik untuk banyak mesin. Baris kunci 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.

Jangan gunakan stempel waktu saja atau di awal row key, karena hal ini akan menyebabkan penulisan berurutan didorong ke satu node, sehingga menghasilkan hotspot. Dalam hal ini, Anda perlu mempertimbangkan pola penulisan serta pola baca.

Jika biasanya Anda mengambil data terbaru terlebih dahulu, Anda dapat menggunakan stempel waktu terbalik dalam row key dengan mengurangi stempel waktu dari nilai maksimum bahasa pemrograman untuk bilangan bulat panjang (di Java, java.lang.Long.MAX_VALUE). Dengan stempel waktu terbalik, data akan diurutkan dari yang paling baru ke yang paling lama.

Catatan: Stempel waktu biasanya merupakan jumlah mikrodetik sejak 01-01-1970 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 menyediakan solusi skalabel untuk kasus penggunaan "multi-tenancy", skenario yang Anda gunakan untuk 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 baris kunci. Semua data untuk tenant disimpan dalam baris yang berdekatan dalam tabel yang sama, dan Anda dapat membuat kueri atau memfilter menggunakan awalan row key. Kemudian, jika perusahaan tidak lagi menjadi pelanggan dan Anda perlu menghapus data histori pembelian yang disimpan untuk perusahaan, 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 tidak lagi menjadi pelanggan Anda, hapus 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. Kemungkinan besar Anda juga secara 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 tersebut.

Privasi

Kecuali jika kasus penggunaan Anda mengharuskannya, hindari penggunaan informasi identitas pribadi (PII) atau data pengguna di kunci baris atau ID kelompok kolom. Nilai dalam kunci baris dan kelompok kolom adalah data pelanggan serta 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-nama domain

Beragam 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 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 bersama di satu tempat, sehingga dapat mengakibatkan kompresi yang kurang efisien dan pembacaan yang kurang efisien.

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

Untuk menggambarkan poin ini, pertimbangkan nama domain berikut, yang diurutkan secara otomatis dalam urutan leksikografis berdasarkan 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

Pada contoh kedua, baris terkait diurutkan secara otomatis dengan cara yang memudahkan pengambilannya sebagai rentang baris.

Nama domain sedikit

Jika Anda ingin menyimpan banyak data hanya untuk satu atau beberapa nama domain, pertimbangkan nilai lain untuk kunci baris Anda. Jika tidak, Anda dapat mengirim operasi tulis ke satu node di cluster, yang akan menyebabkan 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 kueri apa yang akan dihasilkan, salah satu opsinya adalah menyimpan semua data untuk satu baris dalam satu kolom, bukan beberapa kolom. Dengan pendekatan ini, Anda menggunakan format yang memudahkan untuk mengekstrak nilai individual nantinya, seperti format biner protokol buffer atau file JSON.

Baris kunci 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 dalam beberapa kolom, memiliki kelebihan dan kekurangan. Manfaatnya mencakup hal berikut:

• Data ini menggunakan lebih sedikit ruang, sehingga Anda dapat menghemat biaya untuk menyimpannya.
• Anda dapat mempertahankan fleksibilitas tertentu dengan tidak berkomitmen pada grup kolom dan penentu kolom.
• Aplikasi pembacaan Anda tidak perlu "mengetahui" skema tabel Anda.

Beberapa kekurangannya adalah sebagai berikut:

• Anda harus melakukan deserialisasi pesan protobuf setelah pesan tersebut 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

• Pelajari cara mendesain skema untuk data deret waktu.

• Tinjau langkah-langkah yang terlibat dalam merencanakan skema.

• Tinjau jenis permintaan tulis yang dapat Anda kirim ke Bigtable.

• Tinjau kuota dan batas yang berlaku.