Bigtable untuk pengguna DynamoDB
Dokumen ini ditujukan bagi developer dan administrator database DynamoDB yang ingin memigrasikan atau mendesain aplikasi untuk digunakan dengan Bigtable sebagai datastore. Sebelum membaca dokumen ini, baca Ringkasan Bigtable.
Bigtable dan DynamoDB adalah penyimpanan nilai kunci terdistribusi yang dapat mendukung jutaan kueri per detik (QPS), menyediakan penyimpanan dengan skala hingga petabyte data, dan menoleransi kegagalan node.
Meskipun set fitur dari layanan database ini serupa, arsitektur yang mendasarinya dan detail interaksinya berbeda dalam cara yang penting untuk dipahami sebelum Anda memulai migrasi. Dokumen ini menyoroti persamaan dan perbedaan antara kedua sistem database.
Bidang kontrol
Di DynamoDB dan Bigtable, bidang kontrol dapat digunakan untuk mengonfigurasi kapasitas serta menyiapkan dan mengelola resource. DynamoDB adalah produk serverless, dan tingkat interaksi tertinggi dengan DynamoDB adalah level tabel. Dalam mode kapasitas yang disediakan, di sini Anda dapat menyediakan unit permintaan baca dan tulis, memilih region dan replikasi, serta mengelola cadangan. Bigtable bukanlah produk serverless. Anda harus membuat instance dengan satu atau beberapa cluster, yang kapasitasnya ditentukan oleh jumlah node yang dimilikinya. Untuk mengetahui detail tentang resource ini, lihat Instance, cluster, dan node.
Tabel berikut membandingkan resource bidang kontrol untuk DynamoDB dan Bigtable.
| DynamoDB | Bigtable |
|---|---|
| Tabel: Kumpulan item dengan kunci utama yang ditentukan. Tabel memiliki setelan untuk cadangan, replikasi, dan kapasitas. | Instance: Sekelompok cluster Bigtable di zona atau region Google Cloud berbeda, yang menjadi tempat terjadinya replikasi dan perutean koneksi. Kebijakan replikasi ditetapkan pada level instance. Cluster: Sekelompok node di zona Google Cloud geografis yang sama, idealnya ditempatkan bersama server aplikasi untuk alasan latensi dan replikasi. Kapasitas dikelola dengan menyesuaikan jumlah node di setiap cluster. Tabel: Organisasi nilai logis yang diindeks oleh kunci baris. Cadangan dikontrol di tingkat tabel. |
| Membaca unit kapasitas (RCU) dan unit kapasitas tulis (WCU):
Unit yang memungkinkan pembacaan atau penulisan per detik dengan ukuran payload tetap. Anda dikenai biaya unit baca atau tulis untuk setiap operasi dengan ukuran payload yang lebih besar. Operasi UpdateItem menggunakan kapasitas tulis yang digunakan untuk
ukuran terbesar dari item yang diupdate – sebelum atau setelah update –
meskipun update melibatkan subset atribut item. |
Node: Resource komputasi virtual yang bertanggung jawab untuk membaca dan menulis data. Jumlah node yang diterjemahkan
oleh cluster ke batas throughput untuk pembacaan, penulisan, dan pemindaian. Anda dapat menyesuaikan jumlah node, bergantung pada kombinasi sasaran latensi, jumlah permintaan, dan ukuran payload. Node SSD memberikan throughput yang sama untuk pembacaan dan penulisan, tidak seperti perbedaan signifikan antara RCU dan WCU. Untuk mengetahui informasi selengkapnya, lihat Performa untuk workload umum. |
| Partisi: Blok baris yang berdekatan, yang didukung oleh
solid state drive (SSD) yang dikolokasi dengan node. Setiap partisi dikenai batas ketat 1.000 WCU, 3.000 RCU, dan 10 GB data. |
Tablet: Blok baris berdekatan yang didukung oleh
media penyimpanan pilihan (SSD atau HDD). Tabel di-sharding menjadi tablet untuk menyeimbangkan beban kerja. Tablet tidak disimpan pada node di Bigtable, tetapi dalam sistem file terdistribusi milik Google, yang memungkinkan distribusi ulang data dengan cepat saat melakukan penskalaan, dan memberikan ketahanan tambahan dengan mempertahankan beberapa salinan. |
| Tabel global: Cara untuk meningkatkan ketersediaan dan ketahanan data Anda dengan menyebarkan perubahan data secara otomatis di beberapa region. | Replikasi: Suatu cara untuk meningkatkan ketersediaan dan ketahanan data Anda dengan menyebarkan perubahan data secara otomatis di beberapa region atau beberapa zona dalam region yang sama. |
| Tidak berlaku (T/A) | Profil aplikasi: Setelan yang menginstruksikan Bigtable cara merutekan panggilan API klien ke cluster yang sesuai dalam instance. Anda juga dapat menggunakan profil aplikasi sebagai tag untuk menyegmentasikan metrik untuk atribusi. |
Replikasi geografis
Replikasi digunakan untuk mendukung persyaratan pelanggan untuk hal berikut:
- Ketersediaan tinggi untuk kelangsungan bisnis jika terjadi kegagalan zona atau regional.
- Tempatkan data layanan Anda di dekat pengguna akhir untuk layanan berlatensi rendah di mana pun mereka berada di dunia.
- Pemisahan beban kerja saat Anda perlu menerapkan beban kerja batch pada satu cluster dan mengandalkan replikasi untuk melayani cluster.
Bigtable mendukung cluster yang direplikasi di banyak zona yang tersedia hingga 8 region Google Cloud tempat Bigtable tersedia. Sebagian besar region memiliki tiga zona. Bigtable secara otomatis mereplikasi data ke berbagai cluster dalam topologi multiutama, sehingga Anda dapat membaca dan menulis ke cluster mana pun. Replikasi Bigtable pada akhirnya konsisten. Untuk mengetahui detailnya, lihat Ringkasan replikasi.
DynamoDB menyediakan tabel global untuk mendukung replikasi tabel di beberapa region. Tabel global bersifat multi-utama dan otomatis direplikasi di berbagai region. Replikasi akan menjadi konsisten.
Tabel berikut mencantumkan konsep replikasi dan menjelaskan ketersediaannya di DynamoDB dan Bigtable.
| Properti | DynamoDB | Bigtable |
|---|---|---|
| Replikasi multi-primary | Ya. Anda dapat membaca dan menulis ke tabel global apa pun. |
Ya. Anda dapat membaca dan menulis ke cluster Bigtable mana pun. |
| Model konsistensi | Akhirnya konsisten. Konsistensi read-your-write di tingkat regional untuk tabel global. |
Akhirnya konsisten. Konsistensi read-your-write di tingkat regional untuk semua tabel. |
| Latensi replikasi | Tidak ada perjanjian tingkat layanan (SLA). Detik |
Tidak ada SLA. Detik |
| Perincian konfigurasi | Tingkat tabel. | Tingkat instance. Sebuah instance dapat berisi beberapa tabel. |
| Penerapan | Buat tabel global dengan replika tabel di setiap region yang dipilih. Tingkat regional. Replikasi otomatis di seluruh replika dengan mengonversi tabel menjadi tabel global. Tabel harus mengaktifkan Aliran DynamoDB, dengan aliran berisi gambar baru dan lama item. Hapus wilayah untuk menghapus tabel global di wilayah tersebut. |
Buat instance dengan lebih dari satu cluster. Replikasi bersifat otomatis di seluruh cluster dalam instance tersebut. Tingkat zona. Menambahkan dan menghapus cluster dari instance Bigtable. |
| Opsi replikasi | Per tabel. | Per instance. |
| Pemilihan rute dan ketersediaan traffic | Traffic dirutekan ke replika geografis terdekat. Jika gagal, Anda akan menerapkan logika bisnis kustom untuk menentukan kapan harus mengalihkan permintaan ke wilayah lain. |
Gunakan profil aplikasi untuk mengonfigurasi
kebijakan perutean traffic cluster. Gunakan perutean multi-cluster untuk merutekan traffic secara otomatis ke cluster responsif terdekat. Jika terjadi kegagalan, Bigtable mendukung failover otomatis antar-cluster untuk HA. |
| Penskalaan | Kapasitas tulis di unit permintaan tulis yang direplikasi (R-WRU) disinkronkan di seluruh replika. Kapasitas baca dalam unit kapasitas baca replika (R-RCU) adalah per replika. |
Anda dapat menskalakan cluster secara independen dengan menambahkan atau menghapus node dari setiap cluster yang direplikasi sesuai kebutuhan. |
| Biaya | Biaya R-WRU 50% lebih mahal daripada WRU biasa. | Anda akan ditagih untuk setiap node dan penyimpanan cluster. Tidak ada biaya replikasi jaringan untuk replikasi regional di seluruh zona. Biaya dikeluarkan saat replikasi terjadi di berbagai region atau benua. |
| SLA | 99,999% | 99,999% |
Bidang data
Tabel berikut membandingkan konsep model data untuk DynamoDB dan Bigtable. Setiap baris dalam tabel menjelaskan fitur analog. Misalnya, item di DynamoDB mirip dengan baris di Bigtable.
| DynamoDB | Bigtable |
|---|---|
| Item: Sekelompok atribut yang dapat diidentifikasi secara unik di antara semua item lainnya berdasarkan kunci utamanya. Ukuran maksimum yang diizinkan adalah 400 KB. | Baris: Satu entitas yang diidentifikasi oleh kunci baris. Ukuran maksimum yang diizinkan adalah 256 MB. |
| T/A | Kelompok kolom: Namespace yang ditentukan pengguna yang mengelompokkan kolom. |
| Atribut: Pengelompokan nama dan nilai. Nilai atribut dapat berupa jenis skalar, set, atau dokumen. Tidak ada batas eksplisit pada ukuran atribut itu sendiri. Namun, karena setiap item dibatasi hingga 400 KB, untuk item yang hanya memiliki satu atribut, atribut dapat berukuran hingga 400 KB dikurangi ukuran yang digunakan oleh nama atribut. | Penentu kolom: ID unik dalam
grup kolom untuk kolom. Pengenal lengkap sebuah kolom
dinyatakan sebagai column-family:column-qualifier. Penentu kolom diurutkan secara leksikografis dalam grup kolom. Ukuran maksimum yang diizinkan untuk penentu kolom adalah 16 KB. Sel: Sel menyimpan data untuk baris, kolom, dan stempel waktu tertentu. Sel berisi satu nilai yang dapat mencapai 100 MB. |
| Kunci utama: ID unik untuk item dalam
tabel. Kunci ini dapat berupa kunci partisi atau kunci komposit. Kunci partisi: Kunci utama sederhana, yang terdiri dari satu atribut. Ini menentukan partisi fisik tempat item berada. Ukuran maksimum yang diizinkan adalah 2 KB. Kunci urutan: Kunci yang menentukan urutan baris dalam partisi. Ukuran maksimum yang diizinkan adalah 1 KB. Kunci komposit: Kunci utama yang terdiri dari dua properti, kunci partisi dan atribut kunci urutan atau rentang. |
Kunci baris: ID unik untuk item pada tabel.
Biasanya diwakili oleh penyambungan nilai dan pembatas.
Ukuran maksimum yang diizinkan adalah 4 KB. Penentu kolom dapat digunakan untuk mengirim perilaku yang setara dengan kunci pengurutan DynamoDB. Kunci gabungan dapat dibuat menggunakan kunci baris gabungan dan penentu kolom. Untuk mengetahui detail selengkapnya, lihat contoh terjemahan skema di bagian Desain skema dalam dokumen ini. |
| Waktu aktif: Stempel waktu per item menentukan kapan item tidak lagi diperlukan. Setelah tanggal dan waktu dari stempel waktu yang ditentukan, item akan dihapus dari tabel tanpa memakai throughput penulisan. | Pengumpulan Sampah: Stempel waktu per sel menentukan kapan item tidak lagi diperlukan. Pembersihan sampah memori menghapus item yang habis masa berlakunya selama proses latar belakang yang disebut pemadatan. Kebijakan pembersihan sampah memori ditetapkan pada tingkat kelompok kolom dan dapat menghapus item tidak hanya berdasarkan usianya, tetapi juga berdasarkan jumlah versi yang ingin dipertahankan oleh pengguna. Anda tidak perlu mengakomodasi kapasitas untuk pemadatan saat mengukur ukuran cluster. |
Operasi
Operasi bidang data memungkinkan Anda melakukan tindakan membuat, membaca, memperbarui, dan menghapus (CRUD) pada data dalam tabel. Tabel berikut membandingkan operasi bidang data serupa untuk DynamoDB dan Bigtable.
| DynamoDB | Bigtable |
|---|---|
CreateTable |
CreateTable |
PutItemBatchWriteItem |
MutateRow MutateRowsBigtable memperlakukan operasi tulis sebagai pembaruan dan penyisipan. |
UpdateItem
|
Bigtable memperlakukan operasi tulis sebagai pembaruan dan penyisipan. |
GetItemBatchGetItem, Query, Scan |
`ReadRow`` ReadRows` (rentang, prefiks, pemindaian terbalik)Bigtable mendukung pemindaian yang efisien berdasarkan awalan tombol baris, pola ekspresi reguler, atau rentang kunci baris maju atau mundur. |
Jenis data
Bigtable dan DynamoDB tidak memiliki skema. Kolom dapat ditentukan pada waktu penulisan tanpa penerapan seluruh tabel untuk keberadaan kolom atau jenis data. Demikian pula, jenis data kolom atau atribut tertentu dapat berbeda dari satu baris atau item ke baris atau item lainnya. Namun, DynamoDB dan Bigtable API menangani jenis data dengan cara yang berbeda.
Setiap permintaan tulis DynamoDB menyertakan definisi jenis untuk setiap atribut, yang ditampilkan dengan respons untuk permintaan baca.
Bigtable memperlakukan semuanya sebagai byte dan mengharapkan kode klien mengetahui jenis dan encoding sehingga klien dapat mengurai respons dengan benar. Pengecualiannya adalah operasi penambahan, yang menafsirkan nilainya sebagai bilangan bulat big-endian 64-bit yang ditandai.
Tabel berikut membandingkan perbedaan jenis data antara DynamoDB dan Bigtable.
| DynamoDB | Bigtable |
|---|---|
| Jenis skalar: Ditampilkan sebagai token deskriptor jenis data dalam respons server. | Byte: Byte ditransmisikan ke jenis yang diinginkan dalam aplikasi
klien. Increment menafsirkan nilai sebagai bilangan bulat yang ditandatangani big-endian 64-bit |
| Set: Kumpulan elemen unik yang tidak diurutkan. | Kelompok kolom: Anda dapat menggunakan penentu kolom sebagai nama anggota yang ditetapkan, dan untuk setiap nama, menyediakan byte 0 tunggal sebagai nilai sel. Anggota kumpulan diurutkan secara leksikografis dalam grup kolomnya. |
| Peta: Kumpulan key-value pair yang tidak diurutkan dengan kunci unik. | Kelompok kolom Gunakan penentu kolom sebagai kunci peta dan nilai sel untuk nilai. Kunci peta diurutkan secara leksikografis. |
| Daftar: Kumpulan item yang diurutkan. | Penentu kolom Gunakan stempel waktu penyisipan untuk mencapai perilaku yang setara dengan perilaku list_append, kebalikan dari stempel waktu penyisipan untuk awalan. |
Desain skema
Pertimbangan penting dalam desain skema adalah bagaimana data disimpan. Perbedaan utama antara Bigtable dan DynamoDB adalah cara keduanya menangani hal berikut:
- Pembaruan pada nilai tunggal
- Penyortiran data
- Pembuatan versi data
- Penyimpanan nilai besar
Pembaruan pada nilai tunggal
Operasi UpdateItem di DynamoDB akan menggunakan kapasitas tulis untuk ukuran item
"sebelum" dan "setelah" yang lebih besar meskipun pembaruan melibatkan subset
atribut item. Ini berarti bahwa di DynamoDB, Anda mungkin menempatkan kolom yang sering diperbarui dalam baris terpisah, meskipun secara logis kolom tersebut berada di baris yang sama dengan kolom lainnya.
Bigtable dapat memperbarui sel secara efisien, baik itu kolom satu-satunya di baris tertentu maupun satu di antara ribuan. Untuk mengetahui detailnya, lihat Penulisan sederhana.
Penyortiran data
Hash DynamoDB dan mendistribusikan kunci partisi secara acak, sedangkan Bigtable menyimpan baris dalam urutan leksikografis menurut kunci baris dan menyerahkan setiap hashing kepada pengguna.
Distribusi kunci acak tidak optimal untuk semua pola akses. Metode ini mengurangi risiko rentang baris panas, tetapi membuat pola akses yang melibatkan pemindaian yang melintasi batas partisi menjadi mahal dan tidak efisien. Pemindaian tidak terbatas ini umum dilakukan, terutama untuk kasus penggunaan yang memiliki dimensi waktu.
Menangani jenis pola akses ini — pemindaian yang melintasi batas partisi — memerlukan indeks sekunder di DynamoDB, tetapi Bigtable dapat menanganinya tanpa memerlukan indeks sekunder. Demikian pula, di DynamoDB, operasi kueri dan pemindaian dibatasi hingga 1 MB data yang dipindai, memerlukan penomoran halaman di luar batas ini. Bigtable tidak memiliki batas tersebut.
Meskipun memiliki kunci partisi yang didistribusikan secara acak, DynamoDB masih dapat memiliki partisi hot jika kunci partisi yang dipilih tidak mendistribusikan traffic secara seragam yang berdampak buruk pada throughput. Untuk mengatasi masalah ini, DynamoDB menyarankan write-sharding, yang secara acak membagi penulisan di beberapa nilai kunci partisi logis.
Untuk menerapkan pola desain ini, Anda harus membuat angka acak dari kumpulan tetap (misalnya, 1 sampai 10), lalu menggunakan angka ini sebagai kunci partisi logis. Karena Anda mengacak kunci partisi, penulisan ke tabel disebarkan secara merata di semua nilai kunci partisi.
Bigtable mengacu pada prosedur ini sebagai salting kunci, dan dapat menjadi cara efektif untuk menghindari tablet panas.
Pembuatan versi data
Setiap sel Bigtable memiliki stempel waktu, dan stempel waktu terbaru selalu menjadi nilai default untuk kolom tertentu. Kasus penggunaan yang umum untuk stempel waktu adalah pembuatan versi — menulis sel baru ke kolom yang dibedakan dari versi data sebelumnya untuk baris dan kolom tersebut berdasarkan stempel waktu.
DynamoDB tidak memiliki konsep seperti itu dan memerlukan
desain skema yang kompleks
untuk mendukung pembuatan versi. Pendekatan ini melibatkan pembuatan dua salinan dari setiap item:
satu salinan dengan awalan nomor versi nol, seperti v0_, di awal
kunci pengurutan, dan salinan lain dengan awalan nomor versi satu, seperti
v1_. Setiap kali item diupdate, Anda menggunakan awalan versi yang lebih tinggi berikutnya di
kunci sortir dari versi yang diupdate, lalu menyalin konten yang diupdate ke item
dengan awalan versi nol. Hal ini memastikan bahwa versi terbaru dari setiap item dapat
ditemukan menggunakan awalan nol. Strategi ini tidak hanya memerlukan logika sisi aplikasi untuk dipertahankan, tetapi juga membuat penulisan data menjadi sangat mahal dan lambat, karena setiap penulisan memerlukan pembacaan nilai sebelumnya ditambah dua penulisan.
Transaksi multi-baris versus kapasitas baris besar
Bigtable tidak mendukung transaksi multi-baris. Namun, karena memungkinkan Anda menyimpan baris yang jauh lebih besar daripada item yang ada di DynamoDB, Anda sering kali bisa mendapatkan transaksialitas yang diinginkan dengan mendesain skema untuk mengelompokkan item yang relevan dalam kunci baris bersama. Untuk contoh yang menggambarkan pendekatan ini, lihat Pola desain tabel tunggal.
Menyimpan nilai besar
Karena item DynamoDB, yang setara dengan baris Bigtable, dibatasi hingga 400 KB, penyimpanan nilai besar memerlukan pembagian nilai di seluruh item atau disimpan di media lain seperti S3. Kedua pendekatan ini menambah kompleksitas pada aplikasi Anda. Sebaliknya, sel Bigtable dapat menyimpan hingga 100 MB, dan baris Bigtable dapat mendukung hingga 256 MB.
Contoh terjemahan skema
Contoh di bagian ini menerjemahkan skema dari DynamoDB ke Bigtable dengan mempertimbangkan perbedaan desain skema utama.
Memigrasikan skema dasar
Katalog produk adalah contoh yang baik untuk menunjukkan pola nilai kunci dasar. Berikut ini adalah tampilan skema di DynamoDB.
| Kunci Utama | Atribut | |||
|---|---|---|---|---|
| Kunci partisi | Urutkan kunci | Deskripsi | Price | Thumbnail |
| topi | fedora#brandA | Dibuat dari wol premium... | 30 | https://storage… |
| topi | fedoras#brandB | Kanvas tahan air yang tahan lama.. | 28 | https://storage… |
| topi | anak berita#brandB | Tambahkan sentuhan pesona vintage ke tampilan sehari-hari Anda.. | 25 | https://storage… |
| sepatu | sepatu kets#brandA | Melangkahlah dengan bergaya dan nyaman dengan... | 40 | https://storage… |
| sepatu | sepatu kets#merekB | Fitur klasik dengan bahan kontemporer... | 50 | https://storage… |
Untuk tabel ini, pemetaan dari DynamoDB ke Bigtable sangatlah mudah: Anda harus mengonversi kunci utama komposit DynamoDB menjadi kunci baris Bigtable gabungan. Anda membuat satu kelompok kolom (SKU) yang berisi kumpulan kolom yang sama.
| SKU | |||
|---|---|---|---|
| Kunci baris | Deskripsi | Price | Thumbnail |
| topi#fedoras#brandA | Dibuat dari wol premium... | 30 | https://storage… |
| topi#fedoras#brandB | Kanvas tahan air yang tahan lama.. | 28 | https://storage… |
| topi#pembawa berita#merekB | Tambahkan sentuhan pesona vintage ke tampilan sehari-hari Anda.. | 25 | https://storage… |
| sepatu#sepatu#kets#merekA | Melangkahlah dengan bergaya dan nyaman dengan... | 40 | https://storage… |
| sepatu#sepatu#kets#merekB | Fitur klasik dengan bahan kontemporer... | 50 | https://storage… |
Pola desain tabel tunggal
Pola desain tabel tunggal menyatukan beberapa tabel dalam database relasional menjadi satu tabel di DynamoDB. Anda dapat mengambil pendekatan dalam contoh sebelumnya dan menduplikasi skema ini apa adanya di Bigtable. Namun, akan lebih baik untuk mengatasi masalah skema dalam prosesnya.
Dalam skema ini, kunci partisi berisi ID unik untuk video, yang
membantu mengalokasikan semua atribut yang terkait dengan video tersebut untuk akses yang lebih cepat. Mengingat
batasan ukuran item DynamoDB, Anda tidak dapat menempatkan komentar teks bebas
dalam jumlah tak terbatas dalam satu baris. Oleh karena itu, kunci sortir dengan pola
VideoComment#reverse-timestamp digunakan untuk membuat setiap komentar menjadi baris terpisah
dalam partisi, yang diurutkan dalam urutan kronologis terbalik.
Asumsikan video ini memiliki 500 komentar dan pemiliknya ingin menghapus video tersebut. Artinya, semua atribut komentar dan video juga harus dihapus. Untuk melakukannya di DynamoDB, Anda harus memindai semua kunci dalam partisi ini, lalu mengeluarkan beberapa permintaan penghapusan, yang melakukan iterasi pada setiap kunci. DynamoDB mendukung transaksi multi-baris, tetapi permintaan penghapusan ini terlalu besar untuk dilakukan dalam satu transaksi.
| Kunci Utama | Atribut | |||
|---|---|---|---|---|
| Kunci partisi | Urutkan kunci | UploadDate | Format | |
| 0123 | Video | 2023-09-10T15:21:48 | {"480": "https://storage...", "720": "https://storage...", "1080p": "https://storage..."} | |
| KomentarVideo#98765481 | Konten | |||
| Saya sangat suka ini. Efek khusus luar biasa. | ||||
| KomentarVideo#86751345 | Konten | |||
| Tampaknya ada gangguan audio pada menit 1:05. | ||||
| VideoStatsLikes | Jumlah | |||
| 3 | ||||
| VideoStatsViews | Jumlah | |||
| 156 | ||||
| 0124 | Video | 2023-09-10T17:03:21 | {"480": "https://storage…", "720": "https://storage…"} | |
| KomentarVideo#97531849 | Konten | |||
| Saya membagikannya kepada semua teman saya. | ||||
| KomentarVideo#87616471 | Konten | |||
| Gaya ini mengingatkan saya pada sutradara film, tapi saya tidak bisa menyentuhnya. | ||||
| VideoStats | ViewCount | |||
| 45 | ||||
Ubah skema ini saat Anda bermigrasi agar dapat menyederhanakan kode dan mempercepat serta mempercepat permintaan data. Baris Bigtable memiliki kapasitas yang jauh lebih besar daripada item DynamoDB dan dapat menangani komentar dalam jumlah besar. Untuk menangani kasus ketika video mendapatkan jutaan komentar, Anda dapat menetapkan kebijakan pembersihan sampah memori agar hanya mempertahankan komentar terbaru dalam jumlah tertentu.
Karena penghitung dapat diperbarui tanpa overhead memperbarui seluruh baris, Anda juga tidak perlu membaginya. Anda tidak perlu menggunakan kolom UploadDate atau menghitung stempel waktu terbalik dan menjadikannya sebagai kunci sortir, karena stempel waktu Bigtable memberikan komentar yang diurutkan secara kronologis terbalik secara otomatis. Cara ini menyederhanakan skema secara signifikan, dan jika video dihapus, Anda dapat menghapus baris video secara transaksional, termasuk semua komentar, dalam satu permintaan.
Terakhir, karena kolom di Bigtable diurutkan secara leksikografis, sebagai pengoptimalan, Anda dapat mengganti nama kolom dengan cara yang memungkinkan pemindaian rentang cepat - dari properti video ke N komentar terbaru teratas - dalam satu permintaan baca, yang Anda ingin lakukan saat video dimuat. Nantinya, Anda dapat menelusuri komentar lainnya saat penonton men-scroll.
| Atribut | ||||
|---|---|---|---|---|
| Kunci baris | Format | Suka | Tabel Virtual | UserComments |
| 0123 | {"480": "https://storage...", "720": "https://storage...", "1080p": "https://storage..."} @2023-09-10T15:21:48 | 3 | 156 | Saya sangat suka ini. Efek khusus luar biasa. @
2023-09-10T19:01:15 Tampaknya ada gangguan audio pada menit 1:05. @ 10-09-2023T16.30.42 |
| 0124 | {"480": "https://storage...", "720":"https://storage..."} @2023-09-10T17:03:21 | 45 | Gaya ini mengingatkan saya pada sutradara film, tapi saya tidak bisa menyentuhnya. @2023-10-12T07:08:51 | |
Pola desain daftar yang berdekatan
Pertimbangkan versi yang sedikit berbeda dari desain ini, yang sering disebut DynamoDB sebagai pola desain daftar adjacency.
| Kunci Utama | Atribut | |||
|---|---|---|---|---|
| Kunci partisi | Urutkan kunci | DateCreated | Detail | |
| Invoice-0123 | Invoice-0123 | 2023-09-10T15:21:48 | {"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."} |
|
| Payment-0680 | 2023-09-10T15:21:40 | {"amount_usd": 120, "bill_to":"John...", "address":"123 Abc St..."} |
||
| Payment-0789 | 2023-09-10T15:21:31 | {"amount_usd": 120, "bill_to":"Jane...", "address":"13 Xyz St..."} |
||
| Invoice-0124 | Invoice-0124 | 2023-09-09T10:11:28 | {"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."} |
|
| Payment-0327 | 2023-09-09T10:11:10 | {"amount_usd": 180, "bill_to":"Bob...", "address":"321 Cba St..."} |
||
| Payment-0275 | 2023-09-09T10:11:03 | {"amount_usd": 70, "bill_to":"Kate...", "address":"21 Zyx St..."} |
||
Dalam tabel ini, kunci pengurutan tidak didasarkan pada waktu, melainkan pada ID pembayaran. Dengan begitu, Anda dapat menggunakan pola kolom lebar yang berbeda dan membuat ID tersebut menjadi kolom terpisah di Bigtable, dengan manfaat yang mirip dengan contoh sebelumnya.
| Invoice | Pembayaran | |||
|---|---|---|---|---|
| tombol baris | Detail | 0680 | 0789 | |
| 0123 | {"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."} @ 10-09-2023T15.21.48 |
{"amount_usd": 120, "bill_to":"John...", "address":"123 Abc St..."} @ 2023-09-10T15:21:40 |
{"amount_usd": 120, "bill_to":"Jane...", "address":"13 Xyz St..."} @ 2023-09-10T15:21:31 |
|
| tombol baris | Detail | 0275 | 0327 | |
| 0124 | {"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."} @ 09-09-2023T10:11.28 |
{"amount_usd": 70, "bill_to":"Kate...", "address":"21 Zyx St..."} @ 2023-09-09T10:11:03 |
{"amount_usd": 180, "bill_to":"Bob...", "address":"321 Cba St..."} @ 2023-09-09T10:11:10 |
|
Seperti yang dapat Anda lihat di contoh sebelumnya, dengan desain skema yang tepat, model kolom lebar Bigtable cukup andal dan menghasilkan banyak kasus penggunaan yang memerlukan transaksi multi-baris yang mahal, pengindeksan sekunder, atau perilaku jenjang on-delete di database lain.
Langkah selanjutnya
- Baca Desain skema Bigtable.
- Pelajari emulator Bigtable.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.