Merancang strategi partisi yang dapat diskalakan untuk penyimpanan Azure Table
Artikel ini membahas pemartisian tabel dalam penyimpanan dan strategi Azure Table yang dapat Anda gunakan untuk memastikan skalabilitas yang efisien.
Azure menyediakan penyimpanan cloud yang sangat tersedia dan sangat dapat diskalakan. Sistem penyimpanan yang mendasar untuk Azure disediakan melalui serangkaian layanan, termasuk penyimpanan Azure Blob, penyimpanan Azure Table, penyimpanan Azure Queue, dan Azure Files.
Penyimpanan Azure Table dirancang untuk menyimpan data terstruktur. Layanan Azure Storage mendukung jumlah tabel yang tidak terbatas. Setiap tabel dapat menskalakan ke tingkat besar dan menyediakan terabyte penyimpanan fisik. Untuk memanfaatkan tabel dengan baik, Anda harus mempartisi data Anda secara optimal. Artikel ini mengeksplorasi strategi yang dapat Anda gunakan untuk mempartisi data secara efisien untuk penyimpanan Azure Table.
Entitas tabel
Entitas tabel mewakili unit data yang disimpan dalam tabel. Entitas tabel mirip dengan baris dalam tabel database relasional biasa. Setiap entitas mendefinisikan kumpulan properti. Setiap properti didefinisikan sebagai pasangan kunci/nilai berdasarkan nama, nilai, dan jenis data nilainya. Entitas harus menentukan tiga properti sistem berikut sebagai bagian dari kumpulan properti:
PartitionKey: Properti PartitionKey menyimpan nilai string yang mengidentifikasi partisi tempat entitas berada. Partisi, seperti yang kita bahas nanti, merupakan integral dari skalabilitas tabel. Entitas yang memiliki nilai PartitionKey yang sama disimpan dalam partisi yang sama.
RowKey: Properti RowKey menyimpan nilai string yang secara unik mengidentifikasi entitas dalam setiap partisi. PartitionKey dan RowKey bersama-sama membentuk kunci utama untuk entitas.
Tanda waktu: Properti Tanda waktu memberikan keterlacakan untuk entitas. Tanda waktu adalah nilai tanggal/waktu yang memberi tahu Anda terakhir kali entitas dimodifikasi. Tanda waktu terkadang disebut sebagai versi entitas. Modifikasi pada tanda waktu diabaikan karena layanan tabel mempertahankan nilai untuk properti ini selama semua operasi sisipkan dan perbarui.
Kunci primer tabel
Kunci utama untuk entitas Azure terdiri dari properti PartitionKey dan RowKey gabungan. Dua properti membentuk satu indeks berkluster dalam tabel. Nilai PartitionKey dan RowKey dapat berukuran hingga 1024 karakter. String kosong juga diizinkan; namun, nilai null tidak diizinkan.
Indeks berkluster mengurutkan menurut PartitionKey dalam urutan naik lalu menurut RowKey dalam urutan naik. Urutan pengurutan diamati di semua respons kueri. Perbandingan leksikal digunakan selama operasi pengurutan. Nilai string "111" muncul sebelum nilai string "2". Dalam beberapa kasus, Anda mungkin ingin urutan pengurutan menjadi numerik. Untuk mengurutkan dalam urutan numerik dan naik, Anda harus menggunakan untai (karakter) dengan panjang tetap nol. Dalam contoh sebelumnya, "002" muncul sebelum "111".
Partisi tabel
Partisi mewakili kumpulan entitas dengan nilai PartitionKey yang sama. Partisi selalu disajikan dari satu server partisi. Setiap server partisi dapat melayani satu atau beberapa partisi. Server partisi memiliki batas laju jumlah entitas yang dapat dilayaninya dari satu partisi dari waktu ke waktu. Secara khusus, partisi memiliki target skalabilitas 2000 entitas per detik. Throughput ini mungkin lebih tinggi selama beban minimal pada simpul penyimpanan, tetapi dibatasi ketika simpul menjadi panas atau aktif.
Untuk mengilustrasikan konsep partisi dengan lebih baik, gambar berikut menunjukkan tabel yang berisi subkumpulan kecil data untuk pendaftaran acara balap kaki. Gambar menyajikan tampilan konseptual partisi di mana PartitionKey berisi tiga nilai yang berbeda: nama acara dikombinasikan dengan tiga jarak (maraton penuh, setengah maraton, dan 10 km). Contoh ini menggunakan dua server partisi. Server A berisi pendaftaran untuk jarak setengah maraton dan 10 km. Server B hanya berisi jarak maraton penuh. Nilai RowKey diperlihatkan untuk memberikan konteks, tetapi nilainya tidak bermakna untuk contoh ini.
Tabel dengan tiga partisi
Skalabilitas
Karena partisi selalu disajikan dari server partisi tunggal dan setiap server partisi dapat melayani satu atau beberapa partisi, efisiensi melayani entitas berkorelasi dengan kesehatan server. Server yang menemukan lalu lintas tinggi untuk partisi mereka mungkin tidak dapat mempertahankan throughput tinggi. Misalnya, pada gambar sebelumnya, jika banyak permintaan untuk "2011 New York City Marathon__Half" diterima, server A mungkin menjadi terlalu panas. Untuk meningkatkan throughput server, sistem penyimpanan menyeimbangkan beban partisi ke server lain. Hasilnya adalah bahwa lalu lintas didistribusikan di banyak server lain. Untuk penyeimbangan beban lalu lintas yang optimal, Anda harus menggunakan lebih banyak partisi sehingga penyimpanan Azure Table dapat mendistribusikan partisi ke lebih banyak server partisi.
Transaksi Grup Entitas
Transaksi grup entitas adalah sekumpulan operasi penyimpanan yang diterapkan secara atomik pada entitas yang memiliki nilai PartitionKey yang sama. Jika ada operasi penyimpanan dalam grup entitas yang gagal, semua operasi penyimpanan di entitas akan digulung balik. Transaksi grup entitas terdiri dari tidak lebih dari 100 operasi penyimpanan dan mungkin berukuran tidak lebih dari 4 MiB. Transaksi grup entitas menyediakan penyimpanan Azure Table dengan bentuk terbatas dari semantik atomitas, konsistensi, isolasi, dan durabilitas (ACID) yang disediakan oleh database relasional.
Transaksi grup entitas meningkatkan throughput karena mengurangi jumlah operasi penyimpanan individual yang harus dikirimkan ke penyimpanan Azure Table. Transaksi grup entitas juga memberikan manfaat ekonomi. Transaksi grup entitas ditagih sebagai operasi penyimpanan tunggal terlepas dari berapa banyak operasi penyimpanan yang dikandungnya. Karena semua operasi penyimpanan dalam transaksi grup entitas memengaruhi entitas yang memiliki nilai PartitionKey yang sama, kebutuhan untuk menggunakan transaksi grup entitas dapat mendorong pemilihan nilai PartitionKey .
Partisi rentang
Jika Anda menggunakan nilai PartitionKey unik untuk entitas Anda, setiap entitas berada dalam partisinya sendiri. Jika nilai unik yang Anda gunakan menambah atau mengurangi nilai, ada kemungkinan Azure akan membuat partisi rentang. Entitas grup partisi rentang yang memiliki nilai PartitionKey yang berurutan dan unik untuk meningkatkan performa kueri rentang. Tanpa partisi rentang, kueri rentang harus melewati batas partisi atau batas server, yang dapat mengurangi performa kueri. Pertimbangkan aplikasi yang menggunakan tabel berikut, yang memiliki nilai urutan yang meningkat untuk PartitionKey:
| PartitionKey | TombolBaris |
|---|---|
| "0001" | - |
| "0002" | - |
| "0003" | - |
| "0004" | - |
| "0005" | - |
| "0006" | - |
Azure mungkin mengelompokkan tiga entitas pertama ke dalam partisi rentang. Jika Anda menerapkan kueri rentang ke tabel yang menggunakan PartitionKey sebagai kriteria dan meminta entitas dari "0001" ke "0003", kueri mungkin berkinerja efisien karena entitas dilayani dari satu server partisi. Tidak ada jaminan kapan dan bagaimana partisi rentang akan dibuat.
Keberadaan partisi rentang untuk tabel Anda dapat memengaruhi performa operasi penyisipan jika Anda menyisipkan entitas yang mengalami peningkatan atau penurunan nilai PartitionKey . Menyisipkan entitas yang memiliki nilai PartitionKey yang meningkat disebut pola khusus tambahan. Menyisipkan entitas yang memiliki nilai yang menurun disebut pola prepend-only. Pertimbangkan untuk tidak menggunakan pola semacam ini karena throughput keseluruhan permintaan sisipan Anda dibatasi oleh satu server partisi. Ini karena, jika partisi rentang ada, partisi pertama dan terakhir (rentang) masing-masing berisi nilai PartitionKey terkecil dan terbesar. Oleh karena itu, sisipan entitas baru, yang memiliki nilai PartitionKey yang lebih rendah atau lebih tinggi secara berurutan, menargetkan salah satu partisi akhir. Gambar berikut menunjukkan kumpulan partisi rentang yang mungkin didasarkan pada contoh sebelumnya. Jika satu set entitas "0007", "0008", dan "0009" dimasukkan, entitas tersebut akan ditetapkan ke partisi terakhir (oranye).
Sekumpulan partisi rentang
Penting untuk dicatat bahwa tidak ada efek negatif pada performa jika operasi penyisipan menggunakan nilai PartitionKey yang lebih tersebar.
Menganalisis data
Tidak seperti tabel dalam database relasional yang bisa Anda gunakan untuk mengelola indeks, tabel di penyimpanan Azure Table hanya dapat memiliki satu indeks. Indeks dalam penyimpanan Azure Table selalu terdiri dari properti PartitionKey dan RowKey .
Dalam tabel Azure, Anda tidak memiliki kemewahan penyetelan performa tabel Anda dengan menambahkan lebih banyak indeks atau dengan mengubah tabel yang ada setelah Anda meluncurkannya. Anda harus menganalisis data saat mendesain tabel Anda. Aspek terpenting yang perlu dipertimbangkan untuk skalabilitas optimal dan untuk efisiensi kueri dan sisipan adalah nilai PartitionKey dan RowKey . Artikel ini menekankan cara memilih PartitionKey karena secara langsung berkaitan dengan bagaimana tabel dipartisi.
Ukuran partisi
Ukuran partisi mengacu pada jumlah entitas yang dikandung partisi. Seperti yang kita bahas dalam Skalabilitas, memiliki lebih banyak partisi berarti Anda mendapatkan penyeimbangan beban yang lebih baik. Granularitas nilai PartitionKey memengaruhi ukuran partisi. Pada tingkat koarsest, jika satu nilai digunakan sebagai PartitionKey, semua entitas berada dalam satu partisi yang sangat besar. Pada tingkat granularitas terbaik, PartitionKey dapat berisi nilai unik untuk setiap entitas. Hasilnya adalah bahwa ada partisi untuk setiap entitas. Tabel berikut menunjukkan kelebihan dan kekurangan untuk rentang granularitas:
| Granularitas PartitionKey | Ukuran partisi | Kelebihan | Kekurangan |
|---|---|---|---|
| Nilai tunggal | Sejumlah kecil entitas | Transaksi batch dimungkinkan dengan entitas apa pun. Semua entitas bersifat lokal dan disajikan dari simpul penyimpanan yang sama. |
|
| Nilai tunggal | Sejumlah besar entitas | Transaksi grup entitas mungkin dimungkinkan dengan entitas apa pun. Untuk informasi selengkapnya tentang batas transaksi grup entitas, lihat Melakukan transaksi grup entitas. | Penskalakan terbatas. Throughput terbatas pada performa satu server. |
| Beberapa nilai | Beberapa partisi Ukuran partisi bergantung pada distribusi entitas. |
Transaksi batch dimungkinkan pada beberapa entitas. Pemartisian dinamis dimungkinkan. Kueri permintaan tunggal dimungkinkan (tidak ada token kelanjutan). Penyeimbangan beban di lebih banyak server partisi dimungkinkan. |
Distribusi entitas yang sangat tidak merata di seluruh partisi mungkin membatasi performa partisi yang lebih besar dan lebih aktif. |
| Nilai unik | Banyak partisi kecil | Tabel ini sangat dapat diskalakan. Partisi rentang dapat meningkatkan performa kueri rentang lintas partisi. |
Kueri yang melibatkan rentang mungkin memerlukan kunjungan ke lebih dari satu server. Transaksi batch tidak dimungkinkan. Pola khusus tambahan atau khusus prepend dapat memengaruhi throughput sisipan. |
Tabel memperlihatkan bagaimana penskalaan dipengaruhi oleh nilai PartitionKey . Ini adalah praktik terbaik untuk mendukung partisi yang lebih kecil karena menawarkan penyeimbangan beban yang lebih baik. Partisi yang lebih besar mungkin sesuai dalam beberapa skenario, dan tidak selalu kurang menguntungkan. Misalnya, jika aplikasi Anda tidak memerlukan skalabilitas, satu partisi besar mungkin sesuai.
Menentukan kueri
Kueri mengambil data dari tabel. Saat Anda menganalisis data untuk tabel di penyimpanan Azure Table, penting untuk mempertimbangkan kueri mana yang akan digunakan aplikasi. Jika aplikasi memiliki beberapa kueri, Anda mungkin perlu memprioritaskannya, meskipun keputusan Anda mungkin subjektif. Dalam banyak kasus, kueri dominan dapat dilihat dari kueri lain. Dalam hal performa, kueri termasuk dalam kategori yang berbeda. Karena tabel hanya memiliki satu indeks, performa kueri biasanya terkait dengan properti PartitionKey dan RowKey . Tabel berikut ini memperlihatkan berbagai jenis kueri dan peringkat performanya:
| Jenis Kueri | Kecocokan PartitionKey | Kecocokan RowKey | Peringkat performa |
|---|---|---|---|
| Pemindaian rentang baris | Exact | Sebagian | Lebih baik dengan partisi berukuran lebih kecil. Buruk dengan partisi yang sangat besar. |
| Pemindaian rentang partisi | Sebagian | Sebagian | Bagus dengan sejumlah kecil server partisi yang disentuh. Lebih buruk lagi dengan lebih banyak server yang disentuh. |
| Pemindaian tabel penuh | Parsial, tidak ada | Parsial, tidak ada | Lebih buruk lagi dengan subset partisi yang dipindai. Terburuk dengan semua partisi yang dipindai. |
Catatan
Tabel menentukan peringkat performa relatif satu sama lain. Jumlah dan ukuran partisi pada akhirnya dapat menentukan performa kueri. Misalnya, pemindaian rentang partisi untuk tabel yang memiliki banyak partisi besar mungkin berkinerja buruk dibandingkan dengan pemindaian tabel penuh untuk tabel yang memiliki beberapa partisi kecil.
Tipe kueri yang tercantum dalam tabel sebelumnya memperlihatkan perkembangan dari jenis kueri terbaik untuk digunakan ke jenis terburuk, berdasarkan peringkat performanya. Kueri titik adalah jenis kueri terbaik untuk digunakan karena kueri tersebut sepenuhnya menggunakan indeks berkluster tabel. Kueri titik berikut menggunakan data dari tabel pendaftaran pacuan kaki:
http://<account>.windows.core.net/registrations(PartitionKey=”2011 New York City Marathon__Full”,RowKey=”1234__John__M__55”)
Jika aplikasi menggunakan beberapa kueri, tidak semuanya dapat menjadi kueri titik. Dalam hal performa, kueri rentang mengikuti kueri titik. Ada dua jenis kueri rentang: pemindaian rentang baris dan pemindaian rentang partisi. Pemindaian rentang baris menentukan satu partisi. Karena operasi terjadi pada server partisi tunggal, pemindaian rentang baris umumnya lebih efisien daripada pemindaian rentang partisi. Namun, faktor kunci dalam performa pemindaian rentang baris adalah seberapa selektif kueri. Pemilihan kueri menentukan berapa banyak baris yang harus diulang untuk menemukan baris yang cocok. Kueri yang lebih selektif lebih efisien selama pemindaian rentang baris.
Untuk menilai prioritas kueri Anda, pertimbangkan persyaratan frekuensi dan waktu respons untuk setiap kueri. Kueri yang sering dijalankan mungkin diprioritaskan lebih tinggi. Namun, kueri penting tetapi jarang digunakan mungkin memiliki persyaratan latensi rendah yang dapat memberi peringkat lebih tinggi pada daftar prioritas.
Pilih nilai PartitionKey
Inti dari desain tabel apa pun adalah skalabilitasnya, kueri yang digunakan untuk mengaksesnya, dan persyaratan operasi penyimpanan. Nilai PartitionKey yang Anda pilih menentukan bagaimana tabel dipartisi dan jenis kueri yang bisa Anda gunakan. Operasi penyimpanan, dan terutama sisipan, juga dapat memengaruhi pilihan nilai PartitionKey Anda. Nilai PartitionKey dapat berkisar dari nilai tunggal hingga nilai unik. Mereka juga dapat dibuat dengan menggunakan beberapa nilai. Anda dapat menggunakan properti entitas untuk membentuk nilai PartitionKey . Atau, aplikasi dapat menghitung nilai. Bagian berikut membahas pertimbangan penting.
Transaksi Grup Entitas
Pengembang harus terlebih dahulu mempertimbangkan apakah aplikasi akan menggunakan transaksi grup entitas (pembaruan batch). Transaksi grup entitas mengharuskan entitas memiliki nilai PartitionKey yang sama. Selain itu, karena pembaruan batch adalah untuk seluruh grup, pilihan nilai PartitionKey mungkin terbatas. Misalnya, aplikasi perbankan yang mempertahankan transaksi tunai harus memasukkan transaksi tunai ke dalam tabel secara atomik. Transaksi tunai mewakili sisi debit dan kredit dan harus bersih hingga nol. Persyaratan ini berarti bahwa nomor akun tidak dapat digunakan sebagai bagian mana pun dari nilai PartitionKey karena setiap sisi transaksi menggunakan nomor akun yang berbeda. Sebaliknya, ID transaksi mungkin merupakan pilihan yang lebih baik.
Partisi
Jumlah dan ukuran partisi memengaruhi skalabilitas tabel yang sedang dimuat. Mereka juga dikendalikan oleh seberapa terperinci nilai PartitionKey . Mungkin sulit untuk menentukan PartitionKey berdasarkan ukuran partisi, terutama jika distribusi nilai sulit diprediksi. Aturan praktis yang baik adalah menggunakan beberapa partisi yang lebih kecil. Banyak partisi tabel memudahkan penyimpanan Azure Table untuk mengelola simpul penyimpanan tempat partisi dilayani.
Memilih nilai unik atau lebih halus untuk PartitionKey menghasilkan partisi yang lebih kecil tetapi lebih banyak. Ini umumnya menguntungkan karena sistem dapat menyeimbangkan beban banyak partisi untuk mendistribusikan beban di banyak partisi. Namun, Anda harus mempertimbangkan efek memiliki banyak partisi pada kueri rentang lintas partisi. Jenis kueri ini harus mengunjungi beberapa partisi untuk memenuhi kueri. Ada kemungkinan bahwa partisi didistribusikan di banyak server partisi. Jika kueri melewati batas server, token kelanjutan harus dikembalikan. Token kelanjutan menentukan nilai PartitionKey atau RowKey berikutnya untuk mengambil kumpulan data berikutnya untuk kueri. Dengan kata lain, token kelanjutan mewakili setidaknya satu permintaan lagi ke layanan, yang dapat menurunkan performa kueri secara keseluruhan.
Pemilihan kueri adalah faktor lain yang dapat memengaruhi performa kueri. Pemilihan kueri adalah ukuran berapa banyak baris yang harus diulang untuk setiap partisi. Semakin selektif kueri, semakin efisien kueri mengembalikan baris yang Anda inginkan. Performa keseluruhan kueri rentang mungkin bergantung pada jumlah server partisi yang harus disentuh atau seberapa selektif kuerinya. Anda juga harus menghindari penggunaan pola khusus tambahan atau prepend-only saat Anda menyisipkan data ke dalam tabel Anda. Jika Anda menggunakan pola ini, meskipun membuat partisi kecil dan banyak, Anda mungkin membatasi throughput operasi penyisipan Anda. Pola khusus tambahan dan prapending dibahas dalam Partisi rentang.
Kueri
Mengetahui kueri yang akan Anda gunakan dapat membantu Anda menentukan properti mana yang penting untuk dipertimbangkan untuk nilai PartitionKey . Properti yang Anda gunakan dalam kueri adalah kandidat untuk nilai PartitionKey . Tabel berikut ini menyediakan panduan umum tentang cara menentukan nilai PartitionKey :
| Jika entitas... | Tindakan |
|---|---|
| Memiliki satu properti kunci | Gunakan sebagai PartitionKey. |
| Memiliki dua properti utama | Gunakan satu sebagai PartitionKey dan yang lainnya sebagai RowKey. |
| Memiliki lebih dari dua properti utama | Gunakan kunci komposit dari nilai yang digabungkan. |
Jika ada lebih dari satu kueri yang sama dominannya, Anda bisa menyisipkan informasi beberapa kali dengan menggunakan nilai RowKey berbeda yang Anda butuhkan. Aplikasi Anda akan mengelola baris sekunder (atau tersier, dan sebagainya). Anda dapat menggunakan jenis pola ini untuk memenuhi persyaratan performa kueri Anda. Contoh berikut menggunakan data dari contoh pendaftaran perlombaan kaki. Ini memiliki dua kueri dominan:
- Kueri menurut nomor bib
- Kueri menurut usia
Untuk melayani kedua kueri dominan, sisipkan dua baris sebagai transaksi grup entitas. Tabel berikut ini memperlihatkan properti PartitionKey dan RowKey untuk skenario ini. Nilai RowKey memberikan awalan untuk bib dan usia sehingga aplikasi dapat membedakan antara kedua nilai.
| PartitionKey | TombolBaris |
|---|---|
| Marathon__Full Kota New York 2011 | BIB:01234__John__M__55 |
| Marathon__Full Kota New York 2011 | USIA:055__1234__John__M |
Dalam contoh ini, transaksi grup entitas dimungkinkan karena nilai PartitionKey sama. Transaksi grup memberikan atomitas operasi penyisipan. Meskipun dimungkinkan untuk menggunakan pola ini dengan nilai PartitionKey yang berbeda, kami sarankan Anda menggunakan nilai yang sama untuk mendapatkan manfaat ini. Jika tidak, Anda mungkin harus menulis logika tambahan untuk memastikan transaksi atomik yang menggunakan nilai PartitionKey yang berbeda.
Operasi penyimpanan
Tabel di penyimpanan Azure Table mungkin mengalami beban tidak hanya dari kueri. Mereka juga mungkin mengalami beban dari operasi penyimpanan seperti sisipan, pembaruan, dan penghapusan. Pertimbangkan jenis operasi penyimpanan apa yang akan Anda lakukan pada tabel dan pada tingkat berapa. Jika Anda jarang melakukan operasi ini, Anda mungkin tidak perlu khawatir tentang operasi tersebut. Namun, untuk operasi yang sering seperti melakukan banyak sisipan dalam waktu singkat, Anda harus mempertimbangkan bagaimana operasi tersebut dilayani sebagai hasil dari nilai PartitionKey yang Anda pilih. Contoh penting adalah pola khusus tambahan dan khusus prepend. Pola khusus tambahan dan prapending dibahas dalam Partisi rentang.
Saat Anda menggunakan pola khusus tambahan atau prepend-only, Anda menggunakan nilai naik atau turun unik untuk PartitionKey pada penyisipan berikutnya. Jika Anda menggabungkan pola ini dengan operasi penyisipan yang sering, tabel Anda tidak akan dapat melayani operasi penyisipan dengan skalabilitas besar. Skalabilitas tabel Anda terpengaruh karena Azure tidak dapat menyeimbangkan beban permintaan operasi ke server partisi lain. Dalam hal ini, Anda mungkin ingin mempertimbangkan untuk menggunakan nilai yang acak, seperti nilai GUID. Kemudian, ukuran partisi Anda dapat tetap kecil dan masih mempertahankan penyeimbangan beban selama operasi penyimpanan.
Pengujian stres partisi tabel
Ketika nilai PartitionKey kompleks atau memerlukan perbandingan dengan pemetaan PartitionKey lainnya, Anda mungkin perlu menguji performa tabel. Pengujian harus memeriksa seberapa baik performa partisi di bawah beban puncak.
Untuk melakukan tes stres
- Create tabel pengujian.
- Muat tabel pengujian dengan data sehingga berisi entitas yang memiliki nilai PartitionKey yang akan Anda targetkan.
- Gunakan aplikasi untuk menyimulasikan beban puncak ke tabel. Targetkan partisi tunggal dengan menggunakan nilai PartitionKey dari langkah 2. Langkah ini berbeda untuk setiap aplikasi, tetapi simulasi harus mencakup semua kueri dan operasi penyimpanan yang diperlukan. Anda mungkin perlu menyesuaikan aplikasi sehingga menargetkan satu partisi.
- Periksa throughput operasi GET atau PUT pada tabel.
Untuk memeriksa throughput, bandingkan nilai aktual dengan batas partisi tunggal yang ditentukan pada satu server. Partisi dibatasi hingga 2000 entitas per detik. Jika throughput melebihi 2000 entitas per detik untuk partisi, server mungkin berjalan terlalu panas dalam pengaturan produksi. Dalam hal ini, nilai PartitionKey mungkin terlalu kasar, sehingga tidak ada cukup partisi atau partisi terlalu besar. Anda mungkin perlu memodifikasi nilai PartitionKey sehingga partisi akan didistribusikan di antara lebih banyak server.
Penyeimbangan Beban
Penyeimbangan beban pada lapisan partisi terjadi ketika partisi terlalu panas. Ketika partisi terlalu panas, partisi, khususnya server partisi, beroperasi di luar skalabilitas targetnya. Untuk penyimpanan Azure, setiap partisi memiliki target skalabilitas 2000 entitas per detik. Penyeimbangan beban juga terjadi pada lapisan Sistem File Terdistribusi (DFS).
Penyeimbangan beban di lapisan DFS berkaitan dengan beban I/O dan berada di luar cakupan artikel ini. Penyeimbangan beban pada lapisan partisi tidak segera terjadi setelah target skalabilitas terlampaui. Sebaliknya, sistem menunggu beberapa menit sebelum memulai proses penyeimbangan beban. Ini memastikan bahwa partisi telah benar-benar menjadi panas. Tidak perlu partisi utama dengan beban yang dihasilkan yang memicu penyeimbangan beban karena sistem secara otomatis melakukan tugas.
Jika tabel prima dengan beban tertentu, sistem mungkin dapat menyeimbangkan partisi berdasarkan beban aktual, yang menghasilkan distribusi partisi yang berbeda secara signifikan. Alih-alih membuat priming partisi, pertimbangkan untuk menulis kode yang menangani waktu habis dan kesalahan Server Sibuk. Kesalahan dikembalikan ketika sistem sedang menyeimbangkan beban. Dengan menangani kesalahan tersebut dengan menggunakan strategi coba lagi, aplikasi Anda dapat menangani beban puncak dengan lebih baik. Strategi coba lagi dibahas secara lebih rinci di bagian berikut.
Saat penyeimbangan beban terjadi, partisi menjadi offline selama beberapa detik. Selama periode offline, sistem menetapkan ulang partisi ke server partisi yang berbeda. Penting untuk dicatat bahwa data Anda tidak disimpan oleh server partisi. Sebaliknya, server partisi melayani entitas dari lapisan DFS. Karena data Anda tidak disimpan di lapisan partisi, memindahkan partisi ke server yang berbeda adalah proses yang cepat. Fleksibilitas ini sangat membatasi waktu henti, jika ada, yang mungkin dihadapi aplikasi Anda.
Coba lagi strategi
Penting bagi aplikasi Anda untuk menangani kegagalan operasi penyimpanan untuk membantu memastikan bahwa Anda tidak kehilangan pembaruan data apa pun. Beberapa kegagalan tidak memerlukan strategi coba lagi. Misalnya, pembaruan yang mengembalikan kesalahan 401 Tidak sah tidak mendapat manfaat dari mencoba kembali operasi karena kemungkinan status aplikasi tidak akan berubah antara percobaan ulang yang mengatasi kesalahan 401. Namun, kesalahan seperti Server Sibuk atau Waktu Habis terkait dengan fitur penyeimbangan beban Azure yang menyediakan skalabilitas tabel. Saat simpul penyimpanan yang melayani entitas Anda menjadi panas, Azure menyeimbangkan beban dengan memindahkan partisi ke simpul lain. Selama waktu ini, partisi mungkin tidak dapat diakses, yang mengalihkan kesalahan Server Sibuk atau Waktu Habis. Akhirnya, partisi diaktifkan kembali dan pembaruan dilanjutkan.
Strategi coba lagi sesuai untuk kesalahan Server Sibuk atau Waktu Habis. Dalam kebanyakan kasus, Anda dapat mengecualikan kesalahan tingkat 400 dan beberapa kesalahan tingkat 500 dari logika coba lagi. Kesalahan yang dapat dikecualikan termasuk 501 Tidak Diimplementasikan dan Versi HTTP 505 Tidak Didukung. Kemudian, Anda dapat menerapkan strategi coba lagi hingga kesalahan tingkat 500, seperti Server Sibuk (503) dan Waktu Habis (504).
Anda dapat memilih dari tiga strategi coba lagi umum untuk aplikasi Anda:
- Tidak ada Coba Lagi: Tidak ada upaya coba lagi yang dilakukan.
- Memperbaiki Backoff: Operasi dicoba ulang N kali dengan nilai backoff konstan.
- Backoff Eksponensial: Operasi dicoba ulang N kali dengan nilai backoff eksponensial.
Strategi No Retry adalah cara sederhana (dan evasif) untuk menangani kegagalan operasi. Namun strategi No Retry tidak terlalu berguna. Tidak memberlakukan upaya coba lagi menimbulkan risiko yang jelas dengan data yang tidak disimpan dengan benar setelah operasi gagal. Strategi yang lebih baik adalah menggunakan strategi Backoff Tetap. yang menyediakan kemampuan untuk mencoba kembali operasi dengan durasi backoff yang sama.
Namun, strategi ini tidak dioptimalkan untuk menangani tabel yang sangat dapat diskalakan. Jika banyak utas atau proses menunggu durasi yang sama, tabrakan dapat terjadi. Strategi coba lagi yang direkomendasikan adalah strategi yang menggunakan backoff eksponensial di mana setiap upaya coba lagi lebih lama dari upaya terakhir. Ini mirip dengan algoritma penghindarian tabrakan yang digunakan dalam jaringan komputer, seperti Ethernet. Backoff eksponensial menggunakan faktor acak untuk memberikan varians tambahan pada interval yang dihasilkan. Nilai backoff kemudian dibatasi hingga batas minimum dan maksimum. Rumus berikut ini dapat digunakan untuk menghitung nilai backoff berikutnya menggunakan algoritma eksponensial:
y = Rand(0.8z, 1.2z)(2x-1
y = Min(zmin + y, zmax
Di mana:
z = backoff default dalam milidetik
zmin = backoff minimum default dalam milidetik
zmax = backoff maksimum default dalam milidetik
x = jumlah percobaan ulang
y = nilai backoff dalam milidetik
Pengali 0.8 dan 1.2 yang digunakan dalam fungsi Rand (acak) menghasilkan varians acak dari backoff default dalam ±20% dari nilai asli. Rentang ±20% dapat diterima untuk sebagian besar strategi coba lagi, dan mencegah tabrakan lebih lanjut. Rumus dapat diimplementasikan dengan menggunakan kode berikut:
int retries = 1;
// Initialize variables with default values
var defaultBackoff = TimeSpan.FromSeconds(30);
var backoffMin = TimeSpan.FromSeconds(3);
var backoffMax = TimeSpan.FromSeconds(90);
var random = new Random();
double backoff = random.Next(
(int)(0.8D * defaultBackoff.TotalMilliseconds),
(int)(1.2D * defaultBackoff.TotalMilliseconds));
backoff *= (Math.Pow(2, retries) - 1);
backoff = Math.Min(
backoffMin.TotalMilliseconds + backoff,
backoffMax.TotalMilliseconds);
Ringkasan
Aplikasi di penyimpanan Azure Table dapat menyimpan sejumlah besar data karena penyimpanan Tabel mengelola dan menetapkan ulang partisi di banyak simpul penyimpanan. Anda dapat menggunakan partisi data untuk mengontrol skalabilitas tabel. Rencanakan ke depan saat Anda menentukan skema tabel untuk memastikan bahwa Anda menerapkan strategi partisi yang efisien. Secara khusus, analisis persyaratan, data, dan kueri aplikasi sebelum Anda memilih nilai PartitionKey . Setiap partisi mungkin ditetapkan ulang ke simpul penyimpanan yang berbeda saat sistem merespons lalu lintas. Gunakan uji stres partisi untuk memastikan bahwa tabel memiliki nilai PartitionKey yang benar. Pengujian ini membantu Anda menentukan kapan partisi terlalu panas dan membantu Anda membuat penyesuaian partisi yang diperlukan.
Untuk memastikan bahwa aplikasi Anda menangani kesalahan terputus-terputus dan data Anda tetap ada, gunakan strategi coba lagi dengan backoff. Kebijakan coba lagi default yang digunakan Pustaka Klien Azure Storage memiliki backoff eksponensial yang menghindari tabrakan dan memaksimalkan throughput aplikasi Anda.