Daftar periksa performa dan skalabilitas untuk Table Storage
Microsoft telah mengembangkan banyak praktik yang terbukti untuk mengembangkan aplikasi berkinerja tinggi dengan penyimpanan Table. Daftar periksa ini mengidentifikasi kunci praktik yang dapat diikuti pengembang untuk mengoptimalkan performa. Ingatlah praktik ini saat Anda merancang aplikasi dan sepanjang proses.
Azure Storage memiliki skalabilitas dan target performa untuk kapasitas, kecepatan transaksi, dan bandwidth. Untuk informasi selengkapnya tentang target skalabilitas Azure Storage, lihat Skalabilitas dan target performa untuk akun penyimpanan standar dan Skalabilitas dan target performa untuk Table Storage.
Daftar periksa
Artikel ini mengatur praktik yang terbukti untuk performa ke dalam daftar periksa yang dapat Anda ikuti saat mengembangkan aplikasi Table Storage Anda.
Target skalabilitas
Jika aplikasi Anda mendekati atau melebihi salah satu target skalabilitas, aplikasi mungkin mengalami peningkatan latensi atau pembatasan transaksi. Ketika Azure Storage membatasi aplikasi Anda, layanan tersebut mulai mengembalikan kode galat 503 (Server sibuk) atau 500 (Waktu habis operasi). Menghindari kesalahan ini dengan tetap berada dalam batas target skalabilitas adalah bagian penting untuk meningkatkan performa aplikasi Anda.
Untuk informasi selengkapnya tentang target skalabilitas untuk layanan Table, lihat Skalabilitas dan target performa untuk penyimpana Table.
Jumlah akun penyimpanan maksimum
Jika Anda mendekati jumlah maksimum akun penyimpanan yang diizinkan untuk kombinasi langganan/wilayah tertentu, apakah Anda menggunakan beberapa akun penyimpanan untuk memecahkan supaya meningkatkan masuk, keluar, operasi I/O per detik (IOPS), atau kapasitas? Dalam skenario ini, Microsoft menyarankan agar Anda memanfaatkan peningkatan batas untuk akun penyimpanan untuk mengurangi jumlah akun penyimpanan yang diperlukan untuk beban kerja Anda jika memungkinkan. Hubungi Dukungan Azure untuk meminta peningkatan batas untuk akun penyimpanan Anda.
Kapasitas dan target transaksi
Jika aplikasi Anda mendekati target skalabilitas untuk satu akun penyimpanan, pertimbangkan untuk mengadopsi salah satu pendekatan berikut:
- Pertimbangkan kembali beban kerja yang menyebabkan aplikasi Anda mendekati atau melebihi target skalabilitas. Dapatkah Anda mendesainnya secara berbeda untuk menggunakan lebih sedikit bandwidth atau kapasitas, atau lebih sedikit transaksi?
- Jika aplikasi Anda harus melebihi salah satu target skalabilitas, maka buat beberapa akun penyimpanan dan partisi data aplikasi Anda di beberapa akun penyimpanan tersebut. Jika Anda menggunakan pola ini, pastikan untuk mendesain aplikasi Anda sehingga Anda dapat menambahkan lebih banyak akun penyimpanan di masa depan untuk penyeimbangan muatan. Akun penyimpanan tidak memiliki biaya selain penggunaan Anda dalam hal data yang disimpan, transaksi yang dilakukan, atau data yang ditransfer.
- Jika aplikasi Anda mendekati target bandwidth, pertimbangkan untuk memadatkan data di pihak klien untuk mengurangi bandwidth yang diperlukan untuk mengirim data ke Azure Storage. Meskipun mengompresi data dapat menghemat bandwidth dan meningkatkan performa jaringan, data juga dapat berdampak negatif pada performa. Evaluasi dampak performa dari persyaratan pemrosesan tambahan untuk pemadatan dan dekompresi data di pihak klien. Perlu diingat bahwa menyimpan data yang dipadatkan dapat mempersulit pemecahan masalah karena mungkin lebih sulit untuk melihat data dengan menggunakan alat standar.
- Jika aplikasi Anda mendekati target skalabilitas, pastikan Anda menggunakan backoff eksponensial untuk percobaan kembali. Sebaiknya hindari mencapai target skalabilitas dengan menerapkan rekomendasi yang dijelaskan dalam artikel ini. Namun, menggunakan backoff eksponensial untuk percobaan kembali akan mencegah aplikasi Anda mencoba kembali dengan cepat, yang dapat memperburuk pembatasan. Untuk informasi selengkapnya, lihat bagian Kesalahan Waktu Habis dan Server Sibuk.
Target untuk operasi data
Keseimbangan beban Azure Storage saat lalu lintas ke akun penyimpanan Anda meningkat, tetapi jika lalu lintas menunjukkan ledakan tiba-tiba, Anda mungkin tidak dapat segera mendapatkan volume throughput ini. Perkirakan bahwa Anda akan melihat pembatasan dan/atau waktu habis selama ledakan lalu lintas karena Azure Storage secara otomatis menyeimbangkan beban tabel Anda. Peningkatan perlahan-lahan umumnya memberikan hasil yang lebih baik, karena sistem memiliki waktu untuk menyeimbangkan beban dengan tepat.
Entitas per detik (akun penyimpanan)
Batas skalabilitas untuk mengakses tabel adalah hingga 20.000 entitas (masing-masing 1 KB) per detik untuk satu akun. Secara umum, setiap entitas yang dimasukkan, diperbarui, dihapus, atau dipindai dihitung terhadap target ini. Jadi masukan satu batch yang berisi 100 entitas akan dihitung sebagai 100 entitas. Satu kueri yang memindai 1000 entitas dan mengembalikan 5 akan dihitung sebagai 1000 entitas.
Entitas per detik (partisi)
Dalam satu partisi, target skalabilitas untuk mengakses tabel adalah 2.000 entitas (masing-masing 1 KB) per detik, menggunakan penghitungan yang sama seperti yang dijelaskan di bagian sebelumnya.
Jaringan
Batasan jaringan fisik aplikasi mungkin berdampak signifikan pada performa. Bagian berikut ini menjelaskan beberapa batasan yang mungkin ditemui pengguna.
Kemampuan jaringan klien
Bandwidth dan kualitas tautan jaringan berperan penting dalam performa aplikasi, seperti yang dijelaskan di bagian berikut.
Throughput
Untuk bandwidth, masalahnya sering kali pada kemampuan klien. Instans Azure yang lebih besar memiliki NIC dengan kapasitas yang lebih besar, jadi Anda harus mempertimbangkan menggunakan instans yang lebih besar atau lebih banyak VM jika Anda memerlukan batas jaringan yang lebih tinggi dari satu komputer. Jika Anda mengakses Azure Storage dari aplikasi lokal, aturan yang sama berlaku: pahami kemampuan jaringan perangkat klien dan konektivitas jaringan ke lokasi Azure Storage dan tingkatkan sesuai kebutuhan atau desain aplikasi Anda agar berfungsi dalam kemampuannya.
Kualitas tautan
Seperti halnya penggunaan jaringan apa pun, perlu diingat bahwa kondisi jaringan yang mengakibatkan kesalahan dan kehilangan paket memperlambat throughput yang efektif. Menggunakan WireShark atau NetMon dapat membantu dalam mendiagnosis masalah ini.
Lokasi
Dalam lingkungan terdistribusi apa pun, menempatkan klien di dekat server memberikan performa terbaik. Untuk mengakses Azure Storage dengan latensi terendah, lokasi terbaik untuk klien Anda berada dalam wilayah Azure yang sama. Misalnya, jika Anda memiliki aplikasi web Azure yang menggunakan Azure Storage, temukan keduanya dalam satu wilayah, seperti US Barat atau Asia Tenggara. Sumber daya yang berada di lokasi yang sama mengurangi latensi dan biaya, karena penggunaan bandwidth dalam satu wilayah gratis.
Jika aplikasi klien akan mengakses Azure Storage tetapi tidak dihosting dalam Azure, seperti aplikasi perangkat seluler atau layanan perusahaan lokal, maka menemukan akun penyimpanan di wilayah yang dekat dengan klien tersebut dapat mengurangi latensi. Jika klien Anda tersebar luas (misalnya, beberapa di Amerika Utara, dan beberapa di Eropa), pertimbangkan untuk menggunakan satu akun penyimpanan per wilayah. Pendekatan ini lebih mudah diterapkan jika data yang disimpan aplikasi khusus untuk pengguna individual, dan tidak memerlukan replikasi data antar akun penyimpanan.
SAS dan CORS
Misalkan Anda perlu memberikan otorisasi kode seperti JavaScript yang berjalan di browser web pengguna atau di aplikasi ponsel untuk mengakses data di Azure Storage. Salah satu pendekatannya adalah dengan membangun aplikasi layanan yang bertindak sebagai proksi. Perangkat pengguna mengautentikasi dengan layanan, yang pada gilirannya memberikan otorisasi akses ke sumber daya Azure Storage. Dengan cara ini, Anda dapat menghindari mengekspos kunci akun penyimpanan Anda di perangkat yang tidak aman. Namun, pendekatan ini menempatkan overhead yang signifikan pada aplikasi layanan, karena semua data yang ditransfer antara perangkat pengguna dan Azure Storage harus melewati aplikasi layanan.
Anda dapat menghindari penggunaan aplikasi layanan sebagai proksi untuk Azure Storage dengan menggunakan tanda tangan akses bersama (SAS). Dengan menggunakan SAS, Anda dapat mengaktifkan perangkat pengguna untuk membuat permintaan langsung ke Azure Storage dengan menggunakan token akses terbatas. Misalnya, jika pengguna ingin mengunggah foto ke aplikasi Anda, maka aplikasi layanan Anda dapat menghasilkan SAS dan mengirimkannya ke perangkat pengguna. Token SAS dapat memberikan izin untuk menulis ke sumber daya Azure Storage untuk interval waktu tertentu, setelah itu token SAS kedaluwarsa. Untuk informasi selengkapnya tentang SAS, lihat Memberikan akses terbatas ke sumber daya Azure Storage dengan menggunakan tanda tangan akses bersama (SAS).
Biasanya, browser web tidak akan mengizinkan JavaScript di halaman yang dihosting oleh situs web di satu domain untuk melakukan operasi tertentu, seperti operasi tulis, ke domain lain. Dikenal sebagai kebijakan asal yang sama, kebijakan ini mencegah skrip berbahaya di satu halaman untuk mendapatkan akses ke data di halaman web lain. Namun, kebijakan asal yang sama dapat menjadi batasan saat membangun solusi di cloud. Berbagi sumber daya lintas asal (CORS) adalah fitur browser yang memungkinkan domain target untuk berkomunikasi dengan browser yang mempercayai permintaan berasal dari domain sumber.
Misalnya, aplikasi web yang berjalan di Azure membuat permintaan sumber daya ke akun Azure Storage. Aplikasi web adalah domain sumber, dan akun penyimpanan adalah domain target. Anda dapat mengonfigurasi CORS untuk salah satu layanan Azure Storage untuk berkomunikasi dengan browser web yang permintaan dari domain sumber dipercaya oleh Azure Storage. Untuk informasi lebih lanjut tentang CORS, lihat Dukungan berbagi sumber daya lintas asal (CORS) untuk Azure Storage.
SAS dan CORS dapat membantu Anda menghindari beban yang tidak perlu pada aplikasi web Anda.
Transaksi batch
Layanan Tabel mendukung transaksi batch pada entitas yang berada dalam tabel yang sama dan termasuk dalam grup partisi yang sama. Untuk informasi selengkapnya, lihat Melakukan transaksi grup entitas.
Konfigurasi .NET
Untuk proyek yang menggunakan .NET Framework, bagian ini mencantumkan beberapa pengaturan konfigurasi cepat yang dapat Anda gunakan untuk melakukan peningkatan performa yang signifikan. Jika Anda menggunakan bahasa selain .NET, periksa untuk melihat apakah konsep serupa berlaku dalam bahasa yang Anda pilih.
Meningkatkan batas koneksi default
Catatan
Bagian ini berlaku untuk proyek yang menggunakan .NET Framework, karena pengumpulan koneksi dikontrol oleh kelas ServicePointManager. .NET Core memperkenalkan perubahan signifikan sekeliling manajemen kumpulan koneksi, di mana pengumpulan koneksi terjadi pada tingkat HttpClient dan ukuran kumpulan tidak dibatasi secara default. Ini berarti bahwa koneksi HTTP secara otomatis diskalakan untuk memenuhi beban kerja Anda. Menggunakan versi terbaru .NET disarankan, jika memungkinkan, untuk memanfaatkan peningkatan performa.
Untuk proyek yang menggunakan .NET Framework, Anda dapat menggunakan kode berikut untuk meningkatkan batas koneksi default (yang biasanya 2 di lingkungan klien atau 10 di lingkungan server) menjadi 100. Biasanya, Anda harus mengatur nilainya kira-kira sejumlah alur yang digunakan oleh aplikasi Anda. Atur batas koneksi sebelum membuka koneksi apa pun.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Untuk mempelajari selengkapnya tentang batas kumpulan koneksi di .NET Framework, lihat .NET Framework Koneksi ion Pool Limits dan Azure SDK baru untuk .NET.
Untuk bahasa pemrogram lainnya, lihat dokumentasi untuk menentukan cara mengatur batas koneksi.
Meningkatkan jumlah alur minimum
Jika Anda menggunakan panggilan sinkron bersama dengan tugas asinkron, Anda mungkin ingin meningkatkan jumlah utas di kumpulan utas:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Untuk informasi selengkapnya, lihat metode ThreadPool.SetMinThreads.
Paralelisme tidak terbatas
Meskipun paralelisme bisa sangat bagus untuk performa, berhati-hatilah menggunakan paralelisme yang tidak terbatas, yang berarti bahwa tidak ada batasan yang diberlakukan pada jumlah utas atau permintaan paralel. Pastikan untuk membatasi permintaan paralel untuk mengunggah atau mengunduh data, untuk mengakses beberapa partisi di akun penyimpanan yang sama, atau untuk mengakses beberapa item di partisi yang sama. Jika paralelisme tidak dibatasi, aplikasi Anda dapat melebihi kemampuan perangkat klien atau target skalabilitas akun penyimpanan, yang mengakibatkan keterlambatan dan pembatasan yang lebih lama.
Pustaka dan alat klien
Untuk performa terbaik, selalu gunakan pustaka dan alat klien terbaru yang disediakan oleh Microsoft. Pustaka klien Azure Storage tersedia untuk berbagai bahasa. Azure Storage juga mendukung PowerShell dan Azure CLI. Microsoft secara aktif mengembangkan pustaka dan alat klien ini dengan mempertimbangkan performa, menjaganya tetap mutakhir dengan versi layanan terbaru, dan memastikan bahwa mereka menangani banyak praktik performa yang terbukti secara internal.
Handel kesalahan layanan
Azure Storage mengembalikan kesalahan saat layanan tidak dapat memproses permintaan. Memahami kesalahan yang dikembalikan oleh Azure Storage dalam skenario tertentu sangat membantu untuk mengoptimalkan performa.
Kesalahan Waktu Habis dan Server Sibuk
Azure Storage mungkin membatasi aplikasi Anda jika mendekati batas skalabilitas. Dalam beberapa kasus, Azure Storage mungkin tidak dapat menangani permintaan karena beberapa kondisi sementara. Dalam kedua kasus, layanan mungkin mengembalikan kesalahan 503 (Server Sibuk) atau 500 (Waktu Habis). Kesalahan ini juga dapat terjadi jika layanan menyeimbangkan ulang partisi data untuk memungkinkan throughput yang lebih tinggi. Aplikasi klien biasanya harus mencoba kembali operasi yang menyebabkan salah satu kesalahan ini. Namun, jika Azure Storage membatasi aplikasi Anda karena melebihi target skalabilitas, atau bahkan jika layanan tidak dapat melayani permintaan karena beberapa alasan lain, percobaan ulang yang agresif mungkin memperburuk masalah. Disarankan menggunakan kebijakan percobaan kembali back off eksponensial, dan pustaka klien default untuk perilaku ini. Misalnya, aplikasi Anda mungkin mencoba kembali setelah 2 detik, lalu 4 detik, lalu 10 detik, lalu 30 detik, lalu menyerah sepenuhnya. Dengan cara ini, aplikasi Anda secara signifikan mengurangi bebannya pada layanan, daripada memperburuk perilaku yang dapat menyebabkan pembatasan.
Koneksi kesalahan dapat segera dicoba kembali, karena bukan hasil pembatasan dan diharapkan bersifat sementara.
Kesalahan yang tidak dapat dicoba kembali
Pustaka klien menangani percobaan ulang dengan kesadaran tentang kesalahan mana yang dapat dicoba kembali dan yang tidak dapat. Namun, jika Anda memanggil Azure Storage REST API secara langsung, ada beberapa kesalahan yang tidak boleh Anda coba lagi. Misalnya, kesalahan 400 (Permintaan Buruk) menunjukkan bahwa aplikasi klien mengirim permintaan yang tidak dapat diproses karena tidak dalam bentuk yang diharapkan. Mengirim ulang permintaan ini menghasilkan respons yang sama setiap kali, sehingga tidak ada gunanya mencobanya kembali. Jika Anda memanggil Azure Storage REST API secara langsung, ketahui potensi kesalahan dan apakah kesalahan tersebut harus dicoba kembali.
Untuk informasi selengkapnya tentang kode galat Azure Storage, lihat Status dan kode galat.
Konfigurasi
Bagian ini mendaftar beberapa pengaturan konfigurasi cepat yang dapat Anda gunakan untuk membuat peningkatan performa yang signifikan dalam layanan Tabel:
Menggunakan JSON
Dimulai dengan layanan penyimpanan versi 2013-08-15, layanan Tabel mendukung penggunaan JSON alih-alih format AtomPub berbasis XML untuk mentransfer data tabel. Menggunakan JSON dapat mengurangi ukuran payload sebanyak 75% dan dapat meningkatkan performa aplikasi Anda secara signifikan.
Untuk informasi selengkapnya, lihat postingan Tabel Microsoft Azure: Memperkenalkan JSON dan Format Payload untuk Operasi Layanan Tabel.
Menonaktifkan Nagle
Algoritma Nagle secara luas diterapkan di seluruh jaringan TCP/IP sebagai sarana untuk meningkatkan performa jaringan. Namun, ini tidak optimal dalam semua keadaan (seperti lingkungan yang sangat interaktif). Algoritma Nagle berdampak negatif pada performa permintaan ke layanan Tabel Azure, dan Anda harus menonaktifkannya jika memungkinkan.
Skema
Bagaimana Anda mewakili dan meminta data Anda adalah faktor tunggal terbesar yang memengaruhi performa layanan Tabel. Meskipun setiap aplikasi berbeda, bagian ini menguraikan beberapa praktik terbukti umum yang terkait dengan:
- Desain tabel
- Kueri yang efisien
- Pembaruan data yang efisien
Tabel dan partisi
Tabel dibagi menjadi partisi. Setiap entitas yang disimpan dalam partisi berbagi kunci partisi yang sama dan memiliki kunci baris yang unik untuk mengidentifikasinya dalam partisi tersebut. Partisi memberikan keuntungan tetapi juga memperkenalkan batas skalabilitas.
- Keuntungan: Anda dapat memperbarui entitas dalam partisi yang sama dalam transaksi batch atomik tunggal yang berisi hingga 100 operasi penyimpanan terpisah (batas ukuran total 4 MB). Dengan mengasumsikan jumlah entitas yang sama yang akan diambil, Anda juga dapat meminta data dalam satu partisi lebih efisien daripada data yang mencakup partisi (meskipun begitu, baca terus untuk rekomendasi selengkapnya tentang meminta data tabel).
- Batas skalabilitas: Akses ke entitas yang disimpan dalam satu partisi tidak dapat diseimbangkan bebannya karena partisi mendukung transaksi batch atomik. Untuk alasan ini, target skalabilitas untuk partisi tabel individu lebih rendah daripada untuk layanan Tabel secara keseluruhan.
Karena karakteristik tabel dan partisi ini, Anda harus mengadopsi prinsip desain berikut:
- Temukan data yang sering diperbarui atau diminta aplikasi klien Anda di unit kerja logis yang sama dalam partisi yang sama. Misalnya, temukan data dalam partisi yang sama jika aplikasi Anda menggabungkan penulisan atau Anda melakukan operasi batch atomik. Selain itu, data dalam satu partisi dapat lebih efisien diminta dalam satu kueri daripada data di seluruh partisi.
- Temukan data yang tidak dimasukkan, diperbarui, atau dikueri aplikasi klien Anda di unit kerja logis yang sama (yaitu, dalam satu kueri atau pembaruan batch) di partisi terpisah. Perlu diingat bahwa tidak ada batasan jumlah kunci partisi dalam satu tabel, sehingga memiliki jutaan kunci partisi tidak menjadi masalah dan tidak akan memengaruhi performa. Misalnya, jika aplikasi Anda adalah situs web populer dengan pengguna masuk, menggunakan ID Pengguna sebagai kunci partisi bisa menjadi pilihan yang baik.
Partisi panas
Partisi panas adalah partisi yang menerima persentase lalu lintas yang tidak proporsional ke akun, dan tidak dapat diseimbangkan bebannya karena merupakan partisi tunggal. Secara umum, partisi panas dibuat dengan salah satu dari dua cara berikut:
Pola Append Only dan Prepend Only
Pola "Append Only" adalah pola di mana semua (atau hampir semua) lalu lintas ke kunci partisi tertentu meningkat dan menurun sesuai dengan waktu saat ini. Misalnya, aplikasi Anda menggunakan tanggal saat ini sebagai kunci partisi untuk data log. Desain ini menghasilkan semua sisipan yang masuk ke partisi terakhir dalam tabel Anda, dan sistem tidak dapat memuat keseimbangan dengan benar. Jika volume lalu lintas ke partisi tersebut melebihi target skalabilitas tingkat partisi, maka itu menghasilkan pembatasan. Lebih baik memastikan bahwa lalu lintas dikirim ke beberapa partisi, untuk memungkinkan penyeimbangan beban permintaan di seluruh tabel Anda.
Data lalu lintas tinggi
Jika skema partisi Anda menghasilkan satu partisi yang hanya memiliki data yang jauh lebih banyak digunakan daripada partisi lain, Anda mungkin juga melihat pembatasan saat partisi tersebut mendekati target skalabilitas untuk satu partisi. Lebih baik memastikan bahwa skema partisi Anda tidak menghasilkan partisi tunggal mendekati target skalabilitas.
Melakukan Permintaan
Bagian ini menjelaskan praktik yang terbukti untuk meminta layanan Tabel.
Cakupan kueri
Ada beberapa cara untuk menentukan rentang entitas yang akan diminta. Daftar berikut ini menjelaskan setiap opsi untuk cakupan kueri.
- Kueri titik:- Kueri titik mengambil tepat satu entitas dengan menentukan kunci partisi dan kunci baris entitas yang akan diambil. Kueri ini efisien, dan Anda harus menggunakannya jika memungkinkan.
- Kueri partisi: Kueri partisi adalah kueri yang mengambil set data yang berbagi kunci partisi umum. Biasanya, kueri menentukan rentang nilai kunci baris atau rentang nilai untuk beberapa properti entitas selain kunci partisi. Kueri ini kurang efisien daripada kueri titik, dan harus digunakan dengan hemat.
- Kueri tabel: Kueri tabel adalah kueri yang mengambil sekumpulan entitas yang tidak berbagi kunci partisi umum. Kueri ini tidak efisien dan Anda harus menghindarinya jika memungkinkan.
Secara umum, hindari pemindaian (kueri yang lebih besar dari satu entitas), tetapi jika Anda harus memindai, cobalah untuk mengatur data Anda sehingga pemindaian Anda mengambil data yang Anda butuhkan tanpa memindai atau mengembalikan entitas dalam jumlah signifikan yang tidak Anda perlukan.
Kepadatan kueri
Faktor kunci lain dalam efisiensi kueri adalah jumlah entitas yang dikembalikan dibandingkan dengan jumlah entitas yang dipindai untuk menemukan set yang dikembalikan. Jika aplikasi Anda melakukan kueri tabel dengan filter untuk nilai properti yang hanya 1% dari berbagi data, kueri memindai 100 entitas untuk setiap entitas yang dikembalikannya. Target skalabilitas tabel yang dibahas sebelumnya semuanya berkaitan dengan jumlah entitas yang dipindai, dan bukan jumlah entitas yang dikembalikan: kepadatan kueri rendah dapat dengan mudah menyebabkan layanan Tabel membatasi aplikasi Anda karena harus memindai begitu banyak entitas untuk mengambil entitas yang Anda cari. Untuk informasi selengkapnya tentang cara menghindari pembatasan, lihat bagian berjudul Denormalisasi.
Membatasi jumlah data yang dikembalikan
Saat Anda tahu bahwa kueri mengembalikan entitas yang tidak Anda butuhkan di aplikasi klien, pertimbangkan untuk menggunakan filter untuk mengurangi ukuran set yang dikembalikan. Meskipun entitas yang tidak dikembalikan ke klien masih dihitung terhadap batas skalabilitas, performa aplikasi Anda meningkat karena ukuran payload jaringan yang berkurang dan berkurangnya jumlah entitas yang harus diproses aplikasi klien Anda. Perlu diingat bahwa target skalabilitas berkaitan dengan jumlah entitas yang dipindai, sehingga kueri yang memfilter banyak entitas mungkin masih mengakibatkan pembatasan, bahkan jika beberapa entitas dikembalikan. Untuk informasi selengkapnya tentang membuat kueri efisien, lihat bagian berjudul Kepadatan kueri.
Jika aplikasi klien Anda hanya memerlukan set properti terbatas dari entitas dalam tabel Anda, Anda dapat menggunakan proyeksi untuk membatasi ukuran set data yang dikembalikan. Seperti halnya pemfilteran, proyeksi membantu mengurangi beban jaringan dan pemrosesan klien.
Denormalisasi
Tidak seperti bekerja dengan database relasional, praktik yang terbukti untuk meminta data tabel secara efisien menyebabkan denormalisasi data Anda. Artinya, menduplikasi data yang sama dalam beberapa entitas (satu untuk setiap kunci yang mungkin Anda gunakan untuk menemukan data) untuk meminimalkan jumlah entitas yang harus dipindai kueri untuk menemukan data yang dibutuhkan klien, daripada harus memindai sejumlah besar entitas untuk menemukan data yang dibutuhkan aplikasi Anda. Misalnya, di situs web e-niaga, Anda mungkin ingin menemukan pesanan baik dengan ID pelanggan (beri saya pesanan pelanggan ini) dan pada tanggal (beri saya pesanan pada tanggal). Di Table Storage, yang terbaik adalah menyimpan entitas (atau referensi ke entitas tersebut) dua kali – sekali dengan Nama Tabel, PK, dan RK untuk memfasilitasi temuan berdasarkan ID pelanggan, sekali untuk memfasilitasi menemukannya pada tanggal.
Masukkan, perbarui, hapus
Bagian ini menjelaskan praktik yang terbukti untuk memodifikasi entitas yang disimpan dalam layanan Tabel.
Pembuatan batch
Transaksi batch dikenal sebagai transaksi grup entitas di Azure Storage. Semua operasi dalam transaksi grup entitas harus berada pada satu partisi dalam satu tabel. Jika memungkinkan, gunakan transaksi grup entitas untuk melakukan masukkan, perbarui, dan hapus dalam batch. Menggunakan transaksi grup entitas mengurangi jumlah perjalanan pulang pergi dari aplikasi klien Anda ke server, mengurangi jumlah transaksi yang dapat ditagih (transaksi grup entitas dihitung sebagai satu transaksi untuk tujuan penagihan dan dapat berisi hingga 100 operasi penyimpanan), dan memungkinkan pembaruan atomik (semua operasi berhasil atau gagal dalam transaksi grup entitas). Lingkungan dengan latensi tinggi seperti perangkat seluler mendapat manfaat besar dari penggunaan transaksi grup entitas.
Upsert
Gunakan operasi Upsert tabel jika memungkinkan. Ada dua jenis Upsert, yang keduanya bisa lebih efisien daripada operasi Masukkan dan Perbarui tradisional:
- MasukkanAtauGabungkan: Gunakan operasi ini saat Anda ingin mengunggah subset properti entitas, tetapi tidak yakin apakah entitas tersebut sudah ada. Jika entitas ada, panggilan ini memperbarui properti yang disertakan dalam operasi Upsert , dan meninggalkan semua properti yang ada apa adanya, jika entitas tidak ada, ia menyisipkan entitas baru. Ini mirip dengan menggunakan proyeksi dalam kueri, di mana Anda hanya perlu mengunggah properti yang berubah.
- MasukkanAtauGanti: Gunakan operasi ini saat Anda ingin mengunggah entitas yang sama sekali baru, tetapi Anda tidak yakin apakah entitas itu sudah ada. Gunakan operasi ini ketika Anda tahu bahwa entitas yang baru diunggah sepenuhnya benar karena operasi ini menimpa entitas lama sepenuhnya. Misalnya, Anda ingin memperbarui entitas yang menyimpan lokasi pengguna saat ini terlepas dari apakah aplikasi sebelumnya telah menyimpan data lokasi untuk pengguna atau tidak; entitas lokasi baru selesai, dan Anda tidak memerlukan informasi apa pun dari entitas sebelumnya.
Menyimpan seri data dalam satu entitas
Terkadang, aplikasi menyimpan serangkaian data yang sering perlu diambil sekaligus: misalnya, aplikasi mungkin melacak penggunaan CPU dari waktu ke waktu untuk membuat plot bagan data yang bergulir dari 24 jam terakhir. Salah satu pendekatan adalah memiliki satu entitas tabel per jam, dengan setiap entitas mewakili jam tertentu dan menyimpan penggunaan CPU selama jam tersebut. Untuk membuat plot data ini, aplikasi perlu mengambil entitas yang menampung data dari 24 jam terbaru.
Atau, aplikasi Anda dapat menyimpan penggunaan CPU untuk setiap jam sebagai properti terpisah dari satu entitas: untuk memperbarui setiap jam, aplikasi Anda dapat menggunakan satu panggilan MasukkanAtauGabungkan Upsert untuk memperbarui nilai selama satu jam terakhir. Untuk membuat plot data, aplikasi hanya perlu mengambil satu entitas, bukan 24, membuat kueri yang efisien. Untuk informasi selengkapnya tentang efisiensi kueri, lihat bagian berjudul Cakupan kueri.
Menyimpan data terstruktur dalam blob
Jika Anda melakukan sisipan batch lalu mengambil rentang entitas bersama-sama, pertimbangkan untuk menggunakan blob alih-alih tabel. Contoh yang baik adalah file log. Anda dapat membuat batch beberapa menit log dan memasukkannya, lalu mengambil beberapa menit log sekaligus. Dalam hal ini, performa lebih baik jika Anda menggunakan blob alih-alih tabel, karena Anda dapat mengurangi jumlah objek tempat ditulis atau dibaca secara signifikan, dan juga mungkin jumlah permintaan yang perlu dibuat.