Mendesain tabel yang dapat diskalakan dan berperforma
Tip
Konten di dalam artikel ini berlaku ke Microsoft Azure Storage Table asli. Namun, konsep yang sama berlaku untuk Azure Cosmos DB for Table yang lebih baru, yang menawarkan performa dan ketersediaan yang lebih tinggi, distribusi global, dan indeks sekunder otomatis. Hal tersebut juga tersedia dalam berbasis konsumsi mode tidak berlayanan. Ada beberapa perbedaan fitur antara Table API di Azure Cosmos DB dan penyimpanan Azure Table. Untuk informasi selengkapnya, lihat Azure Cosmos DB untuk Tabel. Untuk kemudahan pengembangan, kami sekarang menyediakan Azure Tables SDK terpadu yang dapat digunakan untuk menargetkan penyimpanan Azure Table dan Azure Cosmos DB for Table.
Untuk mendesain tabel yang dapat diskalakan dan berperforma, Anda harus mempertimbangkan faktor-faktor seperti performa, skalabilitas, dan biaya. Jika Sebelumnya Anda telah mendesain skema untuk database hubungan, pertimbangan ini sudah tidak asing lagi, tetapi meskipun ada beberapa kesamaan antara model penyimpanan layanan Azure Table dan model hubungan, terdapat juga perbedaan penting. Perbedaan ini biasanya mengarah pada desain yang berbeda yang mungkin terlihat kontra-intuitif atau salah bagi seseorang yang akrab dengan database hubungan, tetapi masuk akal jika Anda merancang untuk penyimpanan kunci/nilai NoSQL, seperti layanan Azure Table. Banyak perbedaan desain Anda mencerminkan fakta bahwa layanan Table dirancang untuk mendukung aplikasi skala cloud yang dapat berisi miliaran entitas (atau baris dalam terminologi database hubungan) data atau untuk set data yang harus mendukung volume transaksi tinggi. Oleh karena itu, Anda harus berpikir secara berbeda tentang cara Anda menyimpan data dan memahami cara kerja layanan Table. Penyimpanan data NoSQL yang didesain dengan baik, dapat memungkinkan solusi Anda untuk menskalakan lebih jauh, dan dengan biaya lebih rendah daripada solusi yang menggunakan database hubungan. Panduan ini membantu Anda dengan topik-topik ini.
Tentang layanan Azure Table
Bagian ini menyoroti beberapa fitur utama layanan Table yang sangat relevan dengan desain untuk performa dan skalabilitas. Jika Anda baru menggunakan Azure Storage dan layanan Tabel, pertama-tama baca Mulai menggunakan Azure Table Storage menggunakan .NET sebelum membaca sisa artikel ini. Meskipun fokus panduan ini ada pada layanan Tabel, panduan ini menyertakan diskusi tentang layanan Azure Queue dan Blob, dan bagaimana Anda dapat menggunakannya dengan layanan Table.
Apa itu layanan Table? Seperti yang mungkin Anda harapkan dari namanya, layanan Table menggunakan format tabular untuk menyimpan data. Dalam terminologi standar, setiap baris tabel mewakili entitas, dan kolom menyimpan berbagai properti entitas tersebut. Setiap entitas memiliki sepasang kunci untuk mengidentifikasinya secara unik, dan kolom tanda waktu yang digunakan layanan Table untuk melacak kapan entitas terakhir diperbarui. Tand waktu diterapkan secara otomatis, dan Anda tidak dapat menimpa tanda waktu secara manual dengan nilai arbiter. Layanan Tabel menggunakan tanda waktu terakhir yang dimodifikasi (LMT) ini untuk mengelola konkurensi optimis.
Catatan
Operasi API REST layanan Table juga mengembalikan nilai ETag yang berasal dari LMT. Dokumen ini menggunakan istilah ETag dan LMT secara bergantian karena merujuk ke data dasar yang sama.
Contoh berikut menunjukkan desain tabel sederhana untuk menyimpan entitas karyawan dan departemen. Banyak contoh yang ditampilkan nanti dalam panduan ini didasarkan pada desain sederhana ini.
| PartitionKey | RowKey | Tanda Waktu | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Marketing | 00001 | 2014-08-22T00:50:32Z |
| ||||||||
| Marketing | 00002 | 2014-08-22T00:50:34Z |
| ||||||||
| Marketing | Departemen | 2014-08-22T00:50:30Z |
|
||||||||
| Sales | 00010 | 2014-08-22T00:50:44Z |
|
Sejauh ini, data ini terlihat mirip dengan tabel dalam database hubungan dengan perbedaan utama adalah kolom wajib, dan kemampuan untuk menyimpan beberapa jenis entitas dalam tabel yang sama. Selain itu, masing-masing properti yang ditentukan pengguna seperti FirstName atau Age memiliki jenis data, seperti bilangan bulat atau string, sama seperti kolom dalam database hubungan. Meskipun tidak seperti dalam database hubungan, sifat tanpa skema dari layanan Table berarti bahwa properti tidak memerlukan jenis data yang sama pada setiap entitas. Untuk menyimpan jenis data kompleks dalam satu properti, Anda harus menggunakan format berseri seperti JSON atau XML. Untuk informasi selengkapnya tentang layanan tabel seperti jenis data yang didukung, rentang tanggal yang didukung, aturan penamaan, dan batasan ukuran, lihat Memahami Model Data Layanan Table.
Pilihan PartitionKey dan RowKey Anda sangat penting untuk desain tabel yang baik. Setiap entitas yang disimpan dalam tabel harus memiliki kombinasi unik PartitionKey dan RowKey. Seperti halnya kunci dalam tabel database hubungan, nilai PartitionKey dan RowKey diindeks untuk membuat indeks terkluster untuk mengaktifkan pencarian cepat. Namun, layanan Table tidak membuat indeks sekunder, sehingga PartitionKey dan RowKey adalah properti terindeks saja. Beberapa pola yang dijelaskan dalam Pola desain tabel menggambarkan bagaimana Anda dapat mengatasi batasan yang jelas ini.
Tabel terdiri dari satu atau lebih partisi, dan banyak keputusan desain yang Anda buat akan berada di seputer pemilihan PartitionKey dan RowKey yang cocok untuk mengoptimalkan solusi Anda. Solusi dapat terdiri dari satu tabel yang berisi semua entitas Anda yang diatur ke dalam partisi, tetapi biasanya solusi memiliki beberapa tabel. Tabel membantu Anda menata entitas Anda secara logis, membantu Anda mengelola akses ke data menggunakan daftar kontrol akses, dan Anda bisa meletakkan seluruh tabel menggunakan satu operasi penyimpanan.
Partisi tabel
Nama akun, nama tabel, dan PartitionKey bersama-sama mengidentifikasi partisi dalam layanan penyimpanan tempat layanan tabel menyimpan entitas. Selain menjadi bagian dari skema mengatasi entitas, partisi menentukan ruang lingkup untuk transaksi (lihat Transaksi Grup Entitas di bawah), dan bentuk dasar bagaimana layanan tabel diskalakan. Untuk informasi selengkapnya tentang partisi, lihat Daftar periksa performa dan skalabilitas untuk penyimpanan Table.
Dalam layanan Table, layanan simpul individual satu atau beberapa partisi lengkap, dan layanan diskalakan dengan partisi penyeimbang beban dinamis di seluruh simpul. Jika simpul sedang dimuat, layanan tabel dapat membagi rentang partisi yang dilayani oleh simpul tersebut ke simpul berbeda; ketika lalu lintas mereda, layanan dapat menggabungkan rentang partisi dari simpul diam kembali ke simpul tunggal.
Untuk informasi selengkapnya tentang detail internal layanan Table, dan khususnya bagaimana layanan mengelola partisi, lihat makalah Microsoft Azure Storage: Layanan Penyimpanan Cloud yang Sangat Tersedia dengan Konsistensi Yang Kuat.
Transaksi Grup Entitas
Dalam layanan Table, Transaksi Grup Entitas (EGT) adalah satu-satunya mekanisme bawaan untuk melakukan pembaruan atom di beberapa entitas. EGT terkadang juga disebut sebagai transaksi batch. EGT hanya dapat beroperasi pada entitas yang disimpan dalam partisi yang sama (artinya, berbagi kunci partisi yang sama dalam tabel tertentu). Jadi kapan saja Anda memerlukan perilaku transaksional atom di beberapa entitas, Anda harus memastikan bahwa entitas tersebut berada dalam partisi yang sama. Ini sering menjadi alasan untuk menyimpan beberapa jenis entitas dalam tabel yang sama (dan partisi) dan tidak menggunakan beberapa tabel untuk jenis entitas yang berbeda. EGT tunggal dapat beroperasi pada paling banyak 100 entitas. Jika Anda mengirimkan beberapa EGT bersamaan untuk diproses, penting untuk memastikan EGT tersebut tidak beroperasi pada entitas yang umum di seluruh EGT; jika tidak, pemrosesan dapat ditunda.
EGT juga memperkenalkan potensi trade-off bagi Anda untuk mengevaluasi dalam desain Anda. Artinya, menggunakan lebih banyak partisi meningkatkan skalabilitas aplikasi Anda, karena Azure memiliki lebih banyak peluang untuk permintaan penyeimbangan beban di seluruh simpul. Tetapi menggunakan lebih banyak partisi mungkin membatasi kemampuan aplikasi Anda untuk melakukan transaksi atom dan mempertahankan konsistensi yang kuat untuk data Anda. Selain itu, ada target skalabilitas khusus pada tingkat partisi yang mungkin membatasi throughput transaksi yang dapat Anda harapkan untuk satu node. Untuk informasi selengkapnya tentang target skalabilitas untuk akun penyimpanan standar Azure, lihat Target skalabilitas untuk akun penyimpanan standar. Untuk informasi selengkapnya tentang target skalabilitas untuk layanan Table, lihat Skalabilitas dan target performa untuk penyimpana Table.
Pertimbangan kapasitas
Tabel berikut ini menjelaskan kapasitas, skalabilitas, dan target kinerja untuk Penyimpanan tabel.
| Sumber daya | Target |
|---|---|
| Jumlah tabel dalam akun penyimpanan Azure | Hanya dibatasi oleh kapasitas akun penyimpanan |
| Jumlah partisi dalam tabel | Hanya dibatasi oleh kapasitas akun penyimpanan |
| Jumlah entitas dalam partisi | Hanya dibatasi oleh kapasitas akun penyimpanan |
| Ukuran minimum tabel tunggal | 500 TiB |
| Ukuran maksimum entitas tunggal, termasuk semua nilai properti | 1 MiB |
| Jumlah properti maksimum dalam tabel entitas | 255 (termasuk tiga properti sistem, PartitionKey, RowKey, dan Timestamp) |
| Ukuran total maksimum properti individual dalam entitas | Bervariasi menurut jenis properti. Untuk informasi selengkapnya, lihat Jenis Properti di Memahami Model Data Layanan Tabel. |
| Ukuran PartitionKey | String berukuran hingga 1024 karakter |
| Ukuran RowKey | String berukuran hingga 1024 karakter |
| Ukuran transaksi grup entitas | Transaksi dapat mencakup paling banyak 100 entitas, dan ukuran payload harus berukuran kurang dari 4 MB. Transaksi grup entitas dapat mencakup pembaruan ke entitas hanya sekali. |
| Jumlah maksimum kebijakan akses tersimpan per tabel | 5 |
| Tingkat permintaan maksimum per akun penyimpanan | 20.000 transaksi per detik, yang mengasumsikan ukuran entitas 1-KiB |
| Throughput target untuk partisi tabel tunggal (1 entitas KiB) | Hingga 2.000 entitas per detik |
Pertimbangan biaya
Penyimpanan tabel relatif murah, tetapi Anda harus menyertakan perkiraan biaya untuk penggunaan kapasitas dan kuantitas transaksi sebagai bagian dari evaluasi Anda terhadap solusi layanan Table apa pun. Namun, dalam banyak skenario, menyimpan data yang didenormalisasi atau duplikat untuk meningkatkan kinerja atau skalabilitas solusi Anda adalah pendekatan yang valid. Untuk informasi selengkapnya tentang harga, lihat Harga Azure Storage.