Topik ini menjelaskan praktik terbaik untuk operasi tabel.
Desain Kunci Utama
Tablestore mendistribusikan data tabel secara dinamis ke partisi berdasarkan kunci partisi. Setiap partisi di-hosting pada satu node server. Kunci partisi digunakan sebagai unit partisi minimum. Data dengan nilai kunci partisi yang sama tidak dapat dibagi lebih lanjut.
Aplikasi harus menyeimbangkan distribusi data dan akses di seluruh partisi. Jika tidak, data dengan nilai kunci partisi yang sama mungkin menjadi hotspot, meningkatkan beban kerja pada server yang meng-hosting partisi tersebut.
Tablestore mengurutkan baris dalam tabel berdasarkan kunci utama. Desain kunci utama yang baik dapat menyeimbangkan distribusi data di seluruh partisi dan memungkinkan Anda memanfaatkan skalabilitas tinggi Tablestore sepenuhnya.
Saat memilih kunci partisi, perhatikan hal-hal berikut:
Kami merekomendasikan agar data dengan nilai kunci partisi yang sama dalam sebuah tabel tidak melebihi ukuran 10 GB.
nullRekomendasi ini diberikan untuk mencegah hotspot akses dan bukan karena batasan penggunaan penyimpanan.
Data dengan nilai kunci partisi yang berbeda dalam tabel yang sama secara logis independen.
Jangan konsentrasikan beban akses pada rentang kecil dari nilai kunci partisi berturutan.
Desain Kunci Partisi
Kunci Partisi Terpisah
Di Tablestore, kami merekomendasikan agar data dengan nilai kunci partisi yang sama dalam sebuah tabel tidak melebihi ukuran 10 GB. Jika data dengan nilai kunci partisi yang sama dalam sebuah tabel melebihi ukuran 10 GB, Anda dapat menyambung beberapa kolom kunci utama asli menjadi kunci partisi saat merancang tabel.
Ini mencegah ukuran data dengan nilai kunci partisi yang sama mencapai batas atas. Saat menyambung kunci partisi, perhatikan hal-hal berikut:
Saat memilih kolom kunci utama yang ingin disambung, pastikan bahwa baris asli memiliki nilai kunci partisi yang berbeda setelah penyambungan.
Saat menyambung kolom kunci utama tipe Integer, ubah integer menjadi string dengan panjang tetap. Jika integer memiliki digit lebih sedikit daripada panjang tetap, Anda dapat melengkapinya dengan nol di depan untuk memastikan urutan data tabel tetap tidak berubah.
Saat memilih konektor, pertimbangkan efeknya pada urutan leksikografis kunci partisi baru. Kami merekomendasikan agar Anda memilih konektor dengan kode ASCII lebih rendah daripada semua karakter lain yang tersedia.
Tambahkan awalan hash ke kunci partisi
Jangan gunakan kolom kunci utama dengan nilai yang meningkat secara berurutan sebagai kunci partisi. Jika Anda perlu menggunakan kolom kunci utama dengan nilai yang meningkat secara berurutan sebagai kunci partisi, kami merekomendasikan agar Anda menambahkan awalan hash ke kunci partisi untuk memastikan distribusi data acak di seluruh partisi, menyeimbangkan beban akses.
Namun, Anda tidak dapat lagi memanggil operasi GetRange untuk membaca data yang berdekatan secara logis dengan nilai kunci utama dalam rentang tertentu.
Operasi Data
Tulis data secara paralel
Tabel Tablestore dibagi menjadi beberapa partisi yang didistribusikan di beberapa server Tablestore.
Saat Anda menulis data secara berurutan yang diurutkan berdasarkan kunci utama ke Tablestore dalam batch, beban tulis terkonsentrasi pada partisi tertentu, sementara partisi lainnya dalam keadaan idle. Dalam kasus ini, Anda tidak dapat sepenuhnya memanfaatkan throughput baca dan tulis yang dicadangkan, yang memperlambat impor data. Anda dapat menggunakan salah satu metode berikut untuk mempercepat impor data:
Ubah urutan data asli, lalu impor data. Pastikan bahwa data yang ditulis didistribusikan secara merata di setiap partisi.
Gunakan beberapa thread pekerja untuk mengimpor data secara paralel. Pisahkan kumpulan data besar menjadi beberapa kumpulan data yang lebih kecil dan kemudian impor secara acak melalui thread pekerja.
Bedakan antara data panas dan dingin
Dalam kebanyakan kasus, data bersifat sensitif terhadap waktu. Data yang baru dihasilkan mungkin lebih sering diakses daripada data yang sebelumnya dihasilkan. Data yang sebelumnya dihasilkan secara bertahap menjadi data dingin tetapi masih menempati ruang penyimpanan.
Sejumlah besar data dingin yang disimpan dalam tabel mengakibatkan distribusi beban akses yang tidak seimbang di seluruh partisi. Dalam kasus ini, throughput baca dan tulis yang dicadangkan tidak dimanfaatkan sepenuhnya.
Untuk menyelesaikan masalah ini, gunakan tabel yang berbeda untuk memisahkan data panas dan dingin, serta konfigurasikan throughput baca dan tulis yang dicadangkan berbeda untuk setiap tabel.
Studi kasus berbasis skenario
Bab ini menjelaskan cara merancang tabel berdasarkan skenario tertentu.
Skema
Sebuah tabel menyimpan catatan konsumsi mahasiswa universitas. Setiap catatan konsumsi dikaitkan dengan seorang mahasiswa menggunakan kartu ID mahasiswa mereka. Kolom-kolom kunci utama termasuk kolom CardID, SellerID, DeviceID, dan OrderNumber. Kolom CardID berisi ID kartu mahasiswa, kolom SellerID berisi ID penjual, kolom DeviceID berisi ID perangkat point-of-sale, dan kolom OrderNumber berisi nomor pesanan. Aturan berikut berlaku untuk tabel:
Setiap kartu mahasiswa sesuai dengan satu CardID, dan setiap penjual sesuai dengan satu SellerID.
Setiap perangkat point-of-sale sesuai dengan DeviceID unik secara global.
Setiap catatan konsumsi yang dihasilkan oleh perangkat point-of-sale memiliki OrderNumber. OrderNumber yang dihasilkan oleh perangkat hanya unik untuk perangkat tersebut. Misalnya, perangkat point-of-sale yang berbeda dapat menghasilkan dua catatan konsumsi terpisah menggunakan OrderNumber yang sama.
OrderNumber yang dihasilkan oleh perangkat point-of-sale yang sama diurutkan berdasarkan timestamp. Catatan konsumsi baru memiliki OrderNumber berurutan yang lebih besar daripada sebelumnya.
Setiap catatan konsumsi ditulis ke dalam tabel secara real-time.
Proses desain
Tentukan kolom kunci utama yang cocok sebagai kunci partisi.
Untuk menggunakan Tablestore secara efisien, Anda harus mempertimbangkan pengaturan kunci partisi saat merancang kunci utama tabel. Tabel berikut menganalisis berbagai pengaturan kunci partisi. Berdasarkan tabel berikut, kami merekomendasikan agar Anda menggunakan kolom CardID atau DeviceID alih-alih kolom SellerID atau OrderNumber sebagai kunci partisi tabel. Anda dapat merancang kolom kunci utama lainnya berdasarkan kebutuhan bisnis Anda.
Metode Partisi
Analisis
Kesimpulan
Gunakan kolom CardID sebagai kunci partisi tabel
Dalam kebanyakan kasus, setiap kartu memiliki jumlah catatan konsumsi yang serupa setiap hari. Akibatnya, beban akses pada setiap partisi seimbang.
Jika Anda menggunakan kolom CardID sebagai kunci partisi tabel, Anda dapat lebih memanfaatkan throughput baca dan tulis yang dicadangkan.
Kami merekomendasikan agar Anda menggunakan kolom CardID sebagai kunci partisi tabel.
Gunakan kolom SellerID sebagai kunci partisi tabel
Jumlah penjual di sebuah universitas relatif kecil, dan banyak catatan konsumsi mungkin terkonsentrasi pada penjual tertentu. Dalam kasus ini, sejumlah kecil penjual menjadi hotspot. Ini menyebabkan distribusi beban akses yang tidak merata di seluruh partisi.
Kami merekomendasikan agar Anda tidak menggunakan kolom SellerID sebagai kunci partisi tabel.
Gunakan kolom DeviceID sebagai kunci partisi tabel
Jumlah catatan konsumsi yang dihasilkan oleh setiap perangkat point-of-sale per hari dapat diperkirakan meskipun jumlah catatan konsumsi untuk setiap penjual per hari bervariasi. Perkiraan ini dihitung berdasarkan kecepatan pemrosesan pesanan oleh kasir, yang menentukan jumlah catatan konsumsi yang dapat dihasilkan oleh perangkat point-of-sale per hari. Oleh karena itu, kolom DeviceID dapat digunakan sebagai kunci partisi tabel untuk menjamin distribusi beban akses yang seimbang di seluruh partisi.
Kami merekomendasikan agar Anda menggunakan kolom DeviceID sebagai kunci partisi tabel.
Gunakan kolom OrderNumber sebagai kunci partisi tabel
Kolom OrderNumber menyimpan nomor pesanan yang meningkat secara berurutan. Nomor pesanan yang dihasilkan dalam periode waktu yang sama berada dalam rentang kecil dan terkumpul di partisi tertentu. Dalam kasus ini, throughput baca dan tulis yang dicadangkan tidak dimanfaatkan sepenuhnya.
Jika Anda perlu menggunakan kolom OrderNumber sebagai kunci partisi, kami merekomendasikan agar Anda menghitung nilai hash dari nomor pesanan dan menambahkannya ke nomor pesanan sebagai awalan untuk memastikan distribusi beban akses yang sama di seluruh partisi.
Kami merekomendasikan agar Anda tidak menggunakan kolom OrderNumber sebagai kunci partisi tabel.
Jika data dengan nilai kunci partisi yang sama dalam sebuah tabel mungkin melebihi ukuran 10 GB, Anda dapat menyambung beberapa kolom kunci utama menjadi kunci partisi saat merancang tabel.
Sebagai contoh, kolom-kolom kunci utama tabel yang berisi catatan konsumsi siswa adalah kolom DeviceID, SellerID, CardID, dan OrderNumber, di antaranya kolom DeviceID ditentukan sebagai kunci partisi tabel. Baris-baris di mana nilai kolom DeviceID mungkin melebihi ukuran 10 GB. Dalam kasus ini, gabungkan kolom DeviceID, SellerID, dan CardID menjadi kunci partisi.
Tabel berikut menjelaskan skema tabel asli.
DeviceID
SellerID
CardID
OrderNumber
attrs
16
'a100'
66661
200001
...
54
'a100'
6777
200003
...
54
'a1001'
6777
200004
...
167
'a101'
283408
200002
...
Tabel berikut menjelaskan skema tabel baru di mana kolom DeviceID, SellerID, dan CardID disambung menjadi kunci partisi.
CombineDeviceIDSellerIDCardID
OrderNumber
attrs
'16:a100:66661'
200001
...
'167:a101:283408'
200002
...
'54:a1001:6777'
200004
...
'54:a100:6777'
200003
...
Pada tabel asli, dua baris di mana nilai kolom DeviceID adalah 54 berisi dua catatan konsumsi dengan nilai kunci partisi yang sama. Pada tabel baru, dua catatan konsumsi tersebut memiliki nilai kunci partisi yang berbeda. Ini mengurangi jumlah total data dengan nilai kunci partisi yang sama dengan menyambung beberapa kolom kunci utama untuk membentuk kunci partisi.
Pada tabel yang berisi catatan konsumsi siswa, dua baris di mana nilai kolom DeviceID sama memiliki nilai yang sama pada kolom SellerID. Jika Anda hanya menyambung kolom DeviceID dan SellerID menjadi kunci partisi, data dengan nilai kunci partisi yang sama masih besar ukurannya. Dalam kasus ini, Anda dapat menyambung kolom DeviceID, SellerID, dan CardID menjadi kunci partisi.
Akibatnya, muncul masalah baru. Sebagai contoh, kolom DeviceID adalah kolom kunci utama tipe Integer. Pada tabel asli, baris di mana nilai kolom DeviceID adalah 54 muncul sebelum baris di mana nilai kolom DeviceID adalah 167. Jika Anda menyambung kolom DeviceID, SellerID, dan CardID menjadi kunci partisi, baris di mana nilai kolom DeviceID adalah 54 muncul setelah baris di mana nilai kolom DeviceID adalah 167. Dalam kasus ini, tabel baru tidak memenuhi persyaratan ketika aplikasi mencoba membaca baris di mana nilai kolom DeviceID lebih besar dari atau sama dengan 15 dan kurang dari 100.
Untuk menyelesaikan masalah ini, ubah bilangan bulat dalam kolom DeviceID menjadi string dengan panjang tetap. Jika bilangan bulat memiliki digit lebih sedikit daripada panjang tetap, Anda dapat melengkapinya dengan nol di depan berdasarkan panjang tetap. Panjang tetap bervariasi berdasarkan jumlah maksimum digit bilangan bulat dalam kolom DeviceID. Sebagai contoh, jika nilai-nilai dalam kolom DeviceID berkisar dari 0 hingga 999999, lengkapi bilangan bulat dalam kolom dengan nol di depan hingga jumlah digit bilangan bulat mencapai 6. Lalu, sambung kolom DeviceID, SellerID, dan CardID menjadi kunci partisi. Tabel berikut menjelaskan skema tabel baru setelah penyambungan.
CombineDeviceIDSellerIDCardID
OrderNumber
attrs
'000016:a100:66661'
200001
...
'000054:a1001:6777'
200004
...
'000054:a100:6777'
200003
...
'000167:a101:283408'
200002
...
Masalah lain muncul. Sebagai contoh, baris di mana nilai kolom DeviceID adalah 54 dan nilai kolom SellerID adalah 'a1001' muncul setelah baris di mana nilai kolom DeviceID adalah 54 dan nilai kolom SellerID adalah 'a100'. Ketidaksesuaian ini disebabkan oleh konektor
:, yang memengaruhi urutan leksikografis. Akibatnya, '000054:a1001' secara leksikografis kurang dari '000054:a100:', tetapi 'a1001' secara leksikografis lebih besar dari 'a100'.Kami merekomendasikan agar Anda memilih konektor dengan kode ASCII lebih rendah daripada semua karakter lain yang tersedia. Pada tabel, setiap nilai dalam kolom SellerID terdiri dari huruf dan angka. Berdasarkan analisis,
,memiliki kode ASCII lebih rendah daripada semua karakter yang tersedia dalam nilai-nilai kolom SellerID. Oleh karena itu, Anda dapat menggunakan,sebagai konektor.Tabel berikut menjelaskan skema tabel baru setelah Anda menggunakan
,sebagai konektor.CombineDeviceiDSellerIDCardID
OrderNumber
attrs
'000016,a100,66661'
200001
...
'000054,a100,6777'
200003
...
'000054,a1001,6777'
200004
...
'000167,a101,283408'
200002
...
Baris-baris pada tabel di atas diurutkan dalam urutan yang sama seperti pada tabel asli.
Jika Anda menggunakan kolom kunci utama dengan nilai yang meningkat secara berurutan sebagai kunci partisi, tambahkan awalan hash ke kunci partisi.
Kolom OrderNumber menyimpan nilai yang meningkat secara berurutan. Saat catatan konsumsi baru ditulis, mereka selalu berada dalam rentang nomor pesanan terbaru, sedangkan catatan konsumsi dengan nomor pesanan lama tetap tidak berubah. Ini menciptakan beban tulis yang tidak seimbang karena tulisan terkonsentrasi hanya pada partisi terbaru. Akibatnya, throughput baca dan tulis yang dicadangkan tidak dimanfaatkan sepenuhnya. Oleh karena itu, jangan gunakan kolom OrderNumber sebagai kunci partisi saat merancang tabel.
Jika Anda perlu menggunakan kolom OrderNumber sebagai kunci partisi tabel, tambahkan awalan hash ke kunci partisi untuk memastikan bahwa baris-baris dengan nilai kolom OrderNumber yang sama didistribusikan secara acak di dalam tabel. Ini menyeimbangkan beban akses di seluruh partisi.
Tabel berikut menjelaskan skema tabel saat Anda menggunakan kolom OrderNumber sebagai kunci partisi.
OrderNumber
DeviceID
SellerID
CardID
attrs
200001
16
'a100'
66661
...
200002
167
'a101'
283408
...
200003
54
'a100'
6777
...
200004
54
'a1001'
6777
...
200005
66
'b304'
178994
...
Gunakan algoritma hashing, seperti algoritma MD5, untuk menghitung dan menambahkan awalan hash ke nilai-nilai dalam kolom OrderNumber untuk membentuk kunci partisi. Awalan hash yang dihitung menggunakan algoritma MD5 mungkin terlalu panjang. Anda dapat mengambil beberapa karakter pertama untuk memastikan bahwa baris-baris dengan nilai kolom OrderNumber yang sama didistribusikan secara acak di dalam tabel.
Dalam contoh ini, empat karakter pertama dari awalan hash digunakan. Tabel berikut menjelaskan skema tabel saat awalan hash ditambahkan ke nilai-nilai dalam kolom OrderNumber untuk membentuk kunci partisi.
HashOrderNumber
DeviceID
SellerID
CardID
attrs
'2e38200004'
54
'a1001'
6777
...
'a5a9200003'
54
'a100'
6777
...
'c335200005'
66
'b304'
178994
...
'db6e200002
167
'a101'
283408
...
'ddba200001'
16
'a100'
66661
...
Saat Anda kemudian mengakses catatan konsumsi, gunakan algoritma yang sama untuk menghitung awalan hash untuk nilai-nilai dalam kolom OrderNumber untuk mendapatkan kunci partisi setiap catatan konsumsi. Namun, Anda tidak dapat lagi memanggil operasi GetRange untuk membaca data yang berdekatan secara logis dengan nilai kunci utama dalam rentang tertentu.
Simpan data panas dan dingin secara terpisah berdasarkan waktu data.
Aplikasi perlu memproses dan mengumpulkan statistik pada catatan konsumsi atau menanyakan catatan konsumsi terbaru tepat waktu. Catatan konsumsi terbaru dalam tabel lebih mungkin diakses. Catatan konsumsi sebelumnya jarang ditanyakan dan akhirnya menjadi data dingin. Kartu ID mahasiswa dari mahasiswa yang lulus tidak lagi menghasilkan catatan konsumsi.
Nilai-nilai dalam kolom CardID meningkat berdasarkan tanggal aplikasi ID kartu. Jika Anda menggunakan kolom CardID sebagai kunci partisi, throughput baca dan tulis yang dicadangkan dialokasikan ke baris-baris di mana nilai kolom CardID tidak lagi diakses karena mahasiswa telah lulus. Ini menyebabkan pemborosan sumber daya. Dalam kasus ini, Anda dapat membagi catatan konsumsi ke dalam tabel berdasarkan bulan dan menggunakan tabel baru untuk setiap bulan kalender baru. Anda dapat melakukan operasi berikut berdasarkan waktu data:
Tabel catatan konsumsi bulan saat ini: Catatan konsumsi baru terus ditulis ke dalam tabel, dan catatan konsumsi ditanyakan. Anda dapat mengalokasikan throughput baca dan tulis yang dicadangkan besar untuk tabel.
Tabel catatan konsumsi bulan-bulan sebelumnya: Sedikit atau tidak ada data baru yang ditulis ke dalam tabel, sedangkan banyak permintaan query dilakukan untuk menanyakan catatan konsumsi. Anda dapat mengalokasikan throughput tulis yang dicadangkan lebih kecil dan throughput baca yang dicadangkan lebih besar untuk tabel-tabel tersebut.
Tabel catatan konsumsi yang dihasilkan lebih dari satu tahun: Tabel-tabel tersebut jarang diakses. Anda dapat menentukan throughput baca dan tulis yang dicadangkan lebih kecil untuk tabel-tabel tersebut.
Tabel catatan konsumsi yang tidak lagi dipelihara: Tabel-tabel tersebut tidak lagi diakses. Anda dapat mengekspor data ke Object Storage Service (OSS) untuk arsip atau menghapus data.