Bigtable untuk pengguna DynamoDB

Dokumen ini ditujukan untuk developer DynamoDB dan administrator database 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 yang diskalakan hingga petabyte data, dan toleran terhadap kegagalan node.

Meskipun kumpulan fitur layanan database ini serupa, arsitektur dan detail interaksi yang mendasarinya berbeda dengan 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 memungkinkan Anda mengonfigurasi kapasitas serta menyiapkan dan mengelola resource. DynamoDB adalah produk tanpa server, dan tingkat interaksi tertinggi dengan DynamoDB adalah tingkat tabel. Dalam mode kapasitas yang disediakan, di sinilah Anda menyediakan unit permintaan baca dan tulis, memilih region dan replika, serta mengelola pencadangan. Bigtable bukan 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 pencadangan, replikasi, dan kapasitas. Instance: Sekelompok cluster Bigtable di zona atau region Google Cloud yang berbeda, tempat replikasi dan pemilihan rute koneksi terjadi. Kebijakan replikasi ditetapkan di level instance.

Cluster: Sekelompok node di zona geografis Google Cloud yang sama, idealnya ditempatkan bersama dengan server aplikasi Anda untuk alasan latensi dan replikasi. Kapasitas dikelola dengan menyesuaikan jumlah node di setiap cluster.

Tabel: Pengelompokan nilai yang logis dan diindeks menurut kunci baris.

Cadangan dikontrol di tingkat tabel.
Unit kapasitas baca (RCU) dan unit kapasitas tulis (WCU): Unit yang memungkinkan pembacaan atau penulisan per detik dengan ukuran payload tetap. Anda akan dikenai biaya untuk unit baca atau tulis untuk setiap operasi dengan ukuran payload yang lebih besar.Operasi

UpdateItem menggunakan kapasitas tulis yang digunakan untuk ukuran terbesar item yang diperbarui – sebelum atau sesudah pembaruan – meskipun pembaruan melibatkan sebagian atribut item.		 Node: Resource komputasi virtual yang bertanggung jawab untuk membaca dan menulis data. Jumlah node yang dimiliki cluster akan diterjemahkan menjadi batas throughput untuk operasi baca, tulis, dan pemindaian. Anda dapat menyesuaikan jumlah node, bergantung pada kombinasi sasaran latensi, jumlah permintaan, dan ukuran payload.

Node SSD memberikan throughput yang sama untuk operasi baca dan tulis, tidak seperti perbedaan yang signifikan antara RCU dan WCU. Untuk informasi selengkapnya, lihat Performa untuk beban kerja standar.
Partisi: Blok baris yang berdekatan, didukung oleh solid state drive (SSD) yang ditempatkan bersama dengan node.

Setiap partisi tunduk pada batas keras 1.000 WCU, 3.000 RCU, dan 10 GB data.		 Tablet: Blok baris yang berurutan dan didukung oleh media penyimpanan pilihan (SSD atau HDD).

Tabel di-sharding menjadi tablet untuk menyeimbangkan beban kerja. Tablet tidak disimpan di node di Bigtable, tetapi di sistem file terdistribusi Google, yang memungkinkan redistribusi data dengan cepat saat penskalaan, dan yang 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: Cara untuk meningkatkan ketersediaan dan ketahanan data dengan menyebarkan perubahan data secara otomatis di beberapa region atau beberapa zona dalam region yang sama.
Tidak berlaku (T/A) Profil aplikasi: Setelan yang memberi tahu Bigtable cara merutekan panggilan API klien ke cluster yang sesuai dalam instance. Anda juga dapat menggunakan profil aplikasi sebagai tag untuk mengelompokkan metrik guna atribusi.

Replikasi geografis

Replikasi digunakan untuk mendukung persyaratan pelanggan untuk hal berikut:

  • Ketersediaan tinggi untuk kelangsungan bisnis jika terjadi kegagalan zona atau regional.
  • Menempatkan data layanan Anda di dekat pengguna akhir untuk penayangan dengan latensi rendah di mana pun mereka berada di seluruh dunia.
  • Isolasi beban kerja saat Anda perlu menerapkan beban kerja batch di satu cluster dan mengandalkan replikasi untuk menayangkan cluster.

Bigtable mendukung cluster yang direplikasi di sebanyak mungkin zona yang tersedia di hingga 8 region Google Cloud tempat Bigtable tersedia. Sebagian besar region memiliki tiga zona. Untuk informasi selengkapnya, lihat Region dan zona.

Bigtable otomatis mereplikasi data di seluruh cluster dalam topologi multi-utama, yang berarti Anda dapat membaca dan menulis ke cluster mana pun. Replikasi Bigtable memiliki konsistensi tertunda. Untuk mengetahui detailnya, lihat Ringkasan replikasi.

DynamoDB menyediakan tabel global untuk mendukung replikasi tabel di beberapa region. Tabel global bersifat multi-utama dan direplikasi secara otomatis di seluruh region. Replikasi memiliki konsistensi tertunda.

Tabel berikut mencantumkan konsep replikasi dan menjelaskan ketersediaannya di DynamoDB dan Bigtable.

Properti DynamoDB Bigtable
Replikasi multi-primer Ya.

Anda dapat membaca dan menulis ke tabel global mana pun.		 Ya.

Anda dapat membaca dan menulis ke cluster Bigtable mana pun.
Model konsistensi Konsisten tertunda.

Konsistensi read-your-write di tingkat regional untuk tabel global.		 Konsisten tertunda.

Konsistensi read-your-writes di tingkat cluster untuk semua tabel asalkan Anda mengirim operasi baca dan tulis ke cluster yang sama.
Latensi replikasi Tidak ada perjanjian tingkat layanan (SLA).

Detik		 Tanpa SLA.

Detik
Perincian konfigurasi Tingkat tabel. Tingkat instance.

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 ke tabel global.

Tabel harus mengaktifkan DynamoDB Streams, dengan streaming berisi image item yang baru dan lama.

Hapus region untuk menghapus tabel global di region tersebut.		 Buat instance dengan lebih dari satu cluster.
Replikasi dilakukan secara 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 terjadi kegagalan, Anda akan menerapkan logika bisnis kustom untuk menentukan kapan harus mengalihkan permintaan ke region lain.		 Gunakan profil aplikasi untuk mengonfigurasi kebijakan perutean traffic cluster.

Gunakan pemilihan rute multi-cluster untuk merutekan traffic secara otomatis ke cluster terdekat yang responsif.

Jika terjadi kegagalan, Bigtable mendukung failover otomatis antara cluster untuk HA.
Penskalaan Kapasitas tulis dalam unit permintaan tulis yang direplikasi (R-WRU) disinkronkan di seluruh replika.

Kapasitas baca dalam unit kapasitas baca yang direplikasi (R-RCU) adalah per replika.		 Anda dapat menskalakan cluster secara independen dengan menambahkan atau menghapus node dari setiap cluster yang direplikasi sesuai kebutuhan.
Biaya R-WRU harganya 50% lebih mahal daripada WRU reguler. Anda akan ditagih untuk node dan penyimpanan setiap cluster.
Tidak ada biaya replikasi jaringan untuk replikasi regional di seluruh zona.
Biaya akan dikenakan jika replikasi dilakukan di seluruh 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 dikenali 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 Grup 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. ID lengkap kolom dinyatakan sebagai grup-kolom:penentu-kolom. Penentu kolom diurutkan secara leksikografis dalam grup kolom.

Ukuran maksimum yang diizinkan untuk pengontrol kualitas 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 gabungan.

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 pengurutan: Kunci yang menentukan pengurutan baris dalam partisi. Ukuran maksimum yang diizinkan adalah 1 KB.

Kunci gabungan: Kunci utama yang terdiri dari dua properti, kunci partisi dan kunci pengurutan atau atribut rentang.		 Kunci baris: ID unik untuk item dalam tabel. Biasanya direpresentasikan oleh penyambungan nilai dan pemisah. Ukuran maksimum yang diizinkan adalah 4 KB.

Penentu kolom dapat digunakan untuk memberikan perilaku yang setara dengan kunci pengurutan DynamoDB.

Kunci gabungan dapat dibuat menggunakan kunci baris yang digabungkan dan penentu kolom.

Untuk mengetahui detail selengkapnya, lihat contoh terjemahan skema di bagian desain Skema dalam dokumen ini.
Time to live: Stempel waktu per item menentukan kapan item tidak lagi diperlukan. Setelah tanggal dan waktu stempel waktu yang ditentukan, item akan dihapus dari tabel Anda tanpa menggunakan throughput operasi tulis apa pun. Pembersihan Sampah Memori: Stempel waktu per sel menentukan kapan item tidak lagi diperlukan. Pembersihan sampah memori menghapus item yang sudah tidak berlaku selama proses latar belakang yang disebut pemadatan. Kebijakan pembersihan sampah ditetapkan di tingkat keluarga kolom dan dapat menghapus item tidak hanya berdasarkan usianya, tetapi juga sesuai dengan jumlah versi yang ingin dipertahankan pengguna. Anda tidak perlu mengakomodasi kapasitas untuk pemadatan saat menentukan ukuran cluster.

Operasi

Operasi bidang data memungkinkan Anda melakukan tindakan pembuatan, pembacaan, pembaruan, dan penghapusan (CRUD) pada data dalam tabel. Tabel berikut membandingkan operasi platform data yang serupa untuk DynamoDB dan Bigtable.

DynamoDB Bigtable
CreateTable CreateTable
PutItem
BatchWriteItem		 MutateRow
MutateRows
Bigtable memperlakukan operasi tulis sebagai pembaruan dan penyisipan.
UpdateItem
  • Operasi tulis bersyarat
  • Penambahan dan pengurangan
Bigtable memperlakukan operasi tulis sebagai pembaruan dan penyisipan.
GetItem
BatchGetItem, Query, Scan		 `ReadRow`
`ReadRows` (rentang, awalan, pemindaian balik)
Bigtable mendukung pemindaian yang efisien berdasarkan awalan kunci baris, pola ekspresi reguler, atau rentang kunci baris ke depan atau ke belakang.

Jenis data

Bigtable dan DynamoDB tidak memiliki skema. Kolom dapat ditentukan pada waktu penulisan tanpa penerapan di 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. Pengecualian adalah operasi inkremental, yang menafsirkan nilai sebagai bilangan bulat bertanda big-endian 64-bit.

Tabel berikut membandingkan perbedaan jenis data antara DynamoDB dan Bigtable.

DynamoDB Bigtable
Jenis skalar: Ditampilkan sebagai token deskripsi jenis data dalam respons server. Byte: Byte ditransmisikan ke jenis yang diinginkan dalam aplikasi klien.

Increment menafsirkan nilai sebagai bilangan bulat big-endian 64-bit yang telah ditandai
Set: Kumpulan elemen unik yang tidak diurutkan. Grup kolom: Anda dapat menggunakan penentu kolom sebagai nama anggota set dan untuk setiap penentu kolom, berikan satu byte 0 sebagai nilai sel. Anggota set diurutkan secara leksikografis dalam keluarga kolomnya.
Peta: Kumpulan key-value pair yang tidak diurutkan dengan kunci unik. Grup 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 list_append yang setara, kebalikan dari stempel waktu penyisipan untuk menambahkan di awal.

Desain skema

Pertimbangan penting dalam desain skema adalah cara data disimpan. Di antara 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 satu nilai

Operasi UpdateItem di DynamoDB menggunakan kapasitas tulis untuk ukuran item "sebelum" dan "setelah" yang lebih besar meskipun pembaruan melibatkan sebagian atribut item. Artinya, di DynamoDB, Anda dapat menempatkan kolom yang sering diperbarui di baris terpisah, meskipun secara logika kolom tersebut berada di baris yang sama dengan kolom lain.

Bigtable dapat memperbarui sel secara efisien, baik itu satu-satunya kolom dalam baris tertentu atau salah satu dari ribuan kolom. Untuk mengetahui detailnya, lihat Penulisan sederhana.

Penyortiran data

DynamoDB melakukan hashing dan mendistribusikan kunci partisi secara acak, sedangkan Bigtable menyimpan baris dalam urutan leksikografis menurut kunci baris dan membiarkan hashing kepada pengguna.

Distribusi kunci acak tidak optimal untuk semua pola akses. Hal ini mengurangi risiko rentang baris panas, tetapi membuat pola akses yang melibatkan pemindaian yang melintasi batas partisi menjadi mahal dan tidak efisien. Pemindaian tanpa batas ini umum, 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 menanganinya tanpa memerlukan indeks sekunder. Demikian pula, di DynamoDB, operasi kueri dan pemindaian dibatasi hingga 1 MB data yang dipindai, sehingga memerlukan penomoran halaman di luar batas ini. Bigtable tidak memiliki batas tersebut.

Meskipun kunci partisi didistribusikan secara acak, DynamoDB masih dapat memiliki partisi panas jika kunci partisi yang dipilih tidak mendistribusikan traffic secara merata yang memengaruhi throughput secara negatif. Untuk mengatasi masalah ini, DynamoDB menyarankan sharding operasi tulis, yang membagi operasi tulis secara acak di beberapa nilai kunci partisi logis.

Untuk menerapkan pola desain ini, Anda perlu membuat angka acak dari kumpulan tetap (misalnya, 1 hingga 10), lalu menggunakan angka ini sebagai kunci partisi logis. Karena Anda melakukan pengacakan kunci partisi, penulisan ke tabel didistribusikan secara merata di semua nilai kunci partisi.

Bigtable menyebut prosedur ini sebagai key salting, dan ini dapat menjadi cara yang efektif untuk menghindari hot tablet.

Pembuatan versi data

Setiap sel Bigtable memiliki stempel waktu, dan stempel waktu terbaru selalu merupakan nilai default untuk kolom tertentu. Kasus penggunaan 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 waktunya.

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 diperbarui, Anda menggunakan awalan versi berikutnya yang lebih tinggi di kunci pengurutan versi yang diperbarui, dan menyalin konten yang diperbarui ke dalam item dengan awalan versi nol. Hal ini memastikan bahwa versi terbaru item apa pun 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 Anda dapat menyimpan baris yang jauh lebih besar daripada item di DynamoDB, Anda sering kali mendapatkan transaksi yang diinginkan dengan mendesain skema untuk mengelompokkan item yang relevan berdasarkan kunci baris bersama. Untuk contoh yang mengilustrasikan pendekatan ini, lihat Pola desain tabel tunggal.

Menyimpan nilai besar

Karena item DynamoDB, yang analog dengan baris Bigtable, dibatasi hingga 400 KB, penyimpanan nilai besar memerlukan pemisahan nilai di seluruh item atau penyimpanan di media lain seperti S3. Kedua pendekatan ini akan 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 adalah tampilan skema tersebut di DynamoDB.

Kunci Utama Atribut
Kunci partisi Kunci pengurutan Deskripsi Harga Thumbnail
topi fedoras#brandA Dibuat dari wol premium… 30 https://storage…
topi fedoras#brandB Kanvas tahan air yang tahan lama dan dibuat untuk.. 28 https://storage…
topi newsboy#brandB Tambahkan sentuhan pesona vintage ke tampilan sehari-hari Anda. 25 https://storage…
sepatu sneakers#brandA Tampil gaya dan nyaman dengan… 40 https://storage…
sepatu sneakers#brandB Fitur klasik dengan bahan kontemporer… 50 https://storage…

Untuk tabel ini, pemetaan dari DynamoDB ke Bigtable sederhana: Anda mengonversi kunci utama gabungan DynamoDB menjadi kunci baris Bigtable gabungan. Anda membuat satu grup kolom (SKU) yang berisi kumpulan kolom yang sama.

SKU
Kunci baris Deskripsi Harga Thumbnail
hats#fedoras#brandA Dibuat dari wol premium… 30 https://storage…
hats#fedoras#brandB Kanvas tahan air yang tahan lama dan dibuat untuk.. 28 https://storage…
hats#newsboy#brandB Tambahkan sentuhan pesona vintage ke tampilan sehari-hari Anda. 25 https://storage…
shoes#sneakers#brandA Tampil gaya dan nyaman dengan… 40 https://storage…
shoes#sneakers#brandB Fitur klasik dengan bahan kontemporer… 50 https://storage…

Pola desain tabel tunggal

Pola desain tabel tunggal menggabungkan beberapa tabel dalam database relasional menjadi satu tabel di DynamoDB. Anda dapat menggunakan pendekatan dalam contoh sebelumnya dan menduplikasi skema ini apa adanya di Bigtable. Namun, sebaiknya atasi masalah skema dalam prosesnya.

Dalam skema ini, kunci partisi berisi ID unik untuk video, yang membantu menempatkan 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 pengurutan dengan pola VideoComment#reverse-timestamp digunakan untuk membuat setiap komentar menjadi baris terpisah dalam partisi, yang diurutkan dalam urutan kronologis terbalik.

Anggap video ini memiliki 500 komentar dan pemiliknya ingin menghapus video tersebut. Artinya, semua komentar dan atribut video juga harus dihapus. Untuk melakukannya di DynamoDB, Anda perlu memindai semua kunci dalam partisi ini, lalu mengeluarkan beberapa permintaan penghapusan, dengan melakukan iterasi pada setiap kunci. DynamoDB mendukung transaksi multibaris, tetapi permintaan penghapusan ini terlalu besar untuk dilakukan dalam satu transaksi.

Kunci Utama Atribut
Kunci partisi Kunci pengurutan UploadDate Format
0123 Video 2023-09-10T15:21:48 {"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"}
VideoComment#98765481 Konten
Saya sangat menyukainya. Efek khusus memang luar biasa.
VideoComment#86751345 Konten
Sepertinya 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…"}
VideoComment#97531849 Konten
Saya membagikannya kepada semua teman saya.
VideoComment#87616471 Konten
Gayanya mengingatkan saya pada sutradara film, tetapi saya tidak dapat mengingatnya.
VideoStats ViewCount
45

Ubah skema ini saat Anda melakukan migrasi sehingga Anda dapat menyederhanakan kode dan membuat permintaan data lebih cepat dan lebih murah. Baris Bigtable memiliki kapasitas yang jauh lebih besar daripada item DynamoDB dan dapat menangani komentar dalam jumlah besar. Untuk menangani kasus saat video mendapatkan jutaan komentar, Anda dapat menetapkan kebijakan pengumpulan sampah agar hanya menyimpan jumlah tetap komentar terbaru.

Karena penghitung dapat diperbarui tanpa overhead pembaruan seluruh baris, Anda juga tidak perlu membaginya. Anda tidak perlu menggunakan kolom UploadDate atau menghitung stempel waktu terbalik dan menjadikannya kunci pengurutan, karena stempel waktu Bigtable memberi Anda komentar yang diurutkan secara kronologis terbalik secara otomatis. Hal ini secara signifikan menyederhanakan skema, dan jika video dihapus, Anda dapat menghapus baris video secara transaksional, termasuk semua komentar, dalam satu permintaan.

Terakhir, karena kolom di Bigtable diurutkan leksikografik, sebagai pengoptimalan, Anda dapat mengganti nama kolom dengan cara yang memungkinkan pemindaian rentang yang cepat – dari properti video hingga N komentar terbaru teratas – dalam satu permintaan baca, yang merupakan hal yang ingin Anda lakukan saat video dimuat. Kemudian, Anda dapat melihat halaman 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 menyukainya. Efek khusus memang luar biasa. @ 2023-09-10T19:01:15
Sepertinya ada gangguan audio pada menit ke-1.05. @ 2023-09-10T16:30:42
0124 {"480": "https://storage…", "720":"https://storage…"} @2023-09-10T17:03:21 45 Gayanya mengingatkan saya pada sutradara film, tetapi saya tidak dapat mengingatnya. @2023-10-12T07:08:51

Pola desain daftar adjacency

Pertimbangkan versi desain ini yang sedikit berbeda, yang sering kali disebut DynamoDB sebagai pola desain daftar adjacency.

Kunci Utama Atribut
Kunci partisi Kunci pengurutan 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, tetapi pada ID pembayaran, sehingga 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
kunci baris Detail 0680 0789
0123 {"discount": 0.10,
"sales_tax_usd":"8",
"due_date":"2023-10-03.."}
@ 2023-09-10T15: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
kunci baris Detail 0275 0327
0124 {"discount": 0.20,
"sales_tax_usd":"11",
"due_date":"2023-10-03.."}
@ 2023-09-09T10: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 pada contoh sebelumnya, dengan desain skema yang tepat, model kolom lebar Bigtable dapat menjadi sangat efektif dan memberikan banyak kasus penggunaan yang akan memerlukan transaksi multibaris yang mahal, pengindeksan sekunder, atau perilaku cascade saat penghapusan di database lain.

Langkah selanjutnya