Pola Tampilan Terwujud

Hasilkan tampilan yang telah diisi sebelumnya atas data di satu atau beberapa penyimpanan data saat data tidak diformat secara ideal untuk operasi kueri yang diperlukan. Pendekatan ini dapat mendukung kueri dan ekstraksi data yang efisien dan meningkatkan performa aplikasi.

Konteks dan masalah

Saat menyimpan data, pengembang dan administrator data sering memprioritaskan bagaimana data disimpan daripada cara data dibaca. Format penyimpanan yang dipilih biasanya mencerminkan format data, persyaratan untuk mengelola ukuran data dan integritas data, dan jenis penyimpanan yang digunakan. Misalnya, saat Anda menggunakan penyimpanan dokumen NoSQL, Anda sering mewakili data sebagai serangkaian agregat, masing-masing berisi semua informasi untuk entitas tersebut.

Namun, pendekatan ini dapat memiliki efek negatif pada kueri. Ketika kueri hanya memerlukan subset data dari beberapa entitas, seperti ringkasan pesanan untuk beberapa pelanggan tanpa semua detail pesanan, kueri harus mengekstrak semua data untuk entitas yang relevan untuk mendapatkan informasi yang diperlukan.

Menambahkan indeks atau membentuk ulang kueri pada waktu baca tidak selalu mengatasi ketidakefisienan ini. Banyak sistem penyimpanan data tidak dapat diindeks ulang untuk pola baca yang beragam tanpa memengaruhi kinerja penulisan. Agregasi lintas entitas masih mahal saat kueri dijalankan. Beberapa penyimpanan data memang dirancang dengan kemampuan kueri yang terbatas. Karena kendala ini, mengoptimalkan jalur baca dalam penyimpanan sumber saja sering tidak mencukupi.

Solution

Untuk mendukung kueri secara efisien, solusi yang umum adalah membuat, sebelumnya, tampilan yang mematerialisasi data dalam format yang sesuai untuk kumpulan hasil yang diperlukan. Pola Tampilan Terwujud menjelaskan pembuatan tampilan data yang telah terisi sebelumnya di lingkungan tempat data sumber tidak dalam format yang sesuai untuk kueri, saat menghasilkan kueri yang sesuai sulit dilakukan, atau saat performa kueri buruk karena sifat data atau penyimpanan data.

Dalam pola ini, tampilan terwujud adalah model pembacaan atau proyeksi yang menyimpan data yang berasal dari satu atau beberapa penyimpanan sumber. Komponen aplikasi khusus atau alur data dapat mempertahankan proyeksi, termasuk di seluruh batas penyimpanan. Konsumen kueri memperlakukan proyeksi sebagai hanya-baca. Konsep arsitektur ini lebih luas daripada objek materialized view bawaan database, yang didefinisikan, disimpan, dan disegarkan oleh mesin database sesuai batasan fiturnya sendiri.

Tampilan materialisasi ini, yang hanya berisi data yang diperlukan oleh kueri, memungkinkan aplikasi untuk dengan cepat mendapatkan informasi yang mereka butuhkan. Selain menggabungkan tabel atau menggabungkan entitas data, tampilan terwujud dapat menyertakan nilai saat ini dari kolom terhitung atau item data, hasil menggabungkan nilai atau menjalankan transformasi pada item data, dan nilai yang ditentukan sebagai bagian dari kueri. Tampilan materialisasi bahkan dapat dioptimalkan untuk satu kueri.

Poin utamanya adalah bahwa tampilan terwujud dan data di dalamnya sepenuhnya dapat dibuang karena semuanya dapat dibangun kembali dari penyimpanan data sumber. Konsumen kueri tidak memperbarui tampilan secara langsung. Sebaliknya, komponen khusus, alur data, atau mesin database mempertahankannya, jadi ini adalah cache khusus.

Saat data sumber untuk tampilan berubah, tampilan harus diperbarui untuk menyertakan informasi baru. Anda dapat menjadwalkan pembaruan ini terjadi secara otomatis atau ketika sistem mendeteksi perubahan pada data asli. Dalam beberapa kasus, Anda mungkin perlu meregenerasi tampilan secara manual. Gambar berikut menunjukkan contoh bagaimana pola Tampilan Terwujud mungkin digunakan.

Diagram yang menunjukkan pola materialized view. Penyimpanan data sumber menjadi masukan bagi proses pembuatan tampilan termaterialisasi, yang mengisi tampilan termaterialisasi yang langsung dikueri oleh aplikasi alih-alih langsung mengkueri penyimpanan sumber.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat Anda memutuskan cara menerapkan pola ini:

• Lihat strategi refresh. Idealnya, tampilan meregenerasi sebagai respons terhadap peristiwa yang menunjukkan perubahan pada data sumber, meskipun pendekatan ini dapat menyebabkan overhead yang berlebihan jika data sumber berubah dengan cepat. Atau, pertimbangkan untuk menggunakan tugas terjadwal, pemicu eksternal, atau tindakan manual untuk meregenerasi tampilan.

• Segarkan perilaku. Tentukan apakah implementasi melakukan pembangunan ulang penuh atau menerapkan perubahan secara bertahap. Anda juga perlu memutuskan apakah operasi penyegaran memblokir operasi baca.

  Keputusan ini menentukan apakah kueri mengembalikan data materialisasi yang berpotensi kedaluarsa, menggabungkan data materialisasi dengan perubahan sumber yang tidak diproses untuk mengembalikan hasil saat ini, atau terus melayani versi lengkap terakhir hingga refresh selesai.

• Menyegarkan keandalan sinyal. Jika sinyal aktivasi yang memicu regenerasi tampilan hilang atau tertunda - misalnya, peristiwa umpan perubahan yang terlewat atau tugas terjadwal yang gagal - tampilan secara diam-diam menyajikan hasil kedaluarsa. Pantau keterkinian penyegaran dan beri peringatan saat usia tampilan melebihi batas keusangan yang masih dapat diterima.

• Segarkan biaya komputasi. Meregenerasi tampilan menggunakan sumber daya komputasi sebanding dengan volume data sumber dan kompleksitas transformasi. Untuk refresh berbasis peristiwa pada data sumber yang berubah dengan cepat, atau untuk pembangunan ulang penuh tampilan analitik besar, biaya komputasi refresh dapat menjadi pendorong biaya yang signifikan. Sesuaikan ukuran frekuensi refresh dan cakupan untuk menyeimbangkan kesegaran data terhadap pengeluaran komputasi.

• Dependensi Sumber Peristiwa. Dalam beberapa sistem, seperti ketika Anda menggunakan pola Sumber Peristiwa untuk mempertahankan penyimpanan hanya peristiwa yang memodifikasi data, tampilan materialisasi biasanya diperlukan. Mengisi tampilan di awal dengan memeriksa semua peristiwa untuk menentukan status saat ini mungkin merupakan satu-satunya cara untuk mendapatkan informasi dari penyimpanan peristiwa. Jika Anda tidak menggunakan Event Sourcing, pertimbangkan apakah tampilan terwujud akan berguna. View termaterialisasi cenderung dirancang khusus untuk satu atau beberapa kueri saja. Jika banyak kueri digunakan, tampilan materialisasi dapat mengakibatkan persyaratan kapasitas penyimpanan dan biaya penyimpanan yang tidak dapat diterima.

• Konsistensi data. Pertimbangkan dampak pada konsistensi data saat menghasilkan tampilan, dan saat memperbarui tampilan jika proses ini terjadi sesuai jadwal. Jika data sumber berubah pada saat yang sama saat tampilan dihasilkan, salinan data dalam tampilan tidak sepenuhnya konsisten dengan data asli. Jendela keusangan maksimum adalah konsekuensi langsung dari interval refresh atau lag pemrosesan peristiwa, jadi tentukan keusangan yang dapat diterima sebelum memilih antara refresh berbasis peristiwa, terjadwal, atau manual.

• Lihat lokasi penyimpanan. Tampilan tidak harus berada di penyimpanan atau partisi yang sama dengan data asli. Anda dapat menggabungkan subset dari beberapa partisi yang berbeda.

• Bangun ulang jika terjadi kehilangan data. Tampilan dapat dibangun kembali jika hilang. Oleh karena itu, jika tampilan bersifat sementara dan hanya digunakan untuk meningkatkan performa kueri dengan mencerminkan status data saat ini, atau untuk meningkatkan skalabilitas, Anda dapat menyimpannya di cache atau di lokasi yang kurang dapat diandalkan.

  Namun, jika proses refresh itu sendiri gagal di tengah jalan - misalnya, jika tugas regenerasi terjadwal mengalami crash - tentukan apakah beban kerja harus melayani tampilan lengkap sebelumnya, tampilan yang diperbarui sebagian, atau tidak ada tampilan sama sekali sampai regenerasi berhasil.

  Pendekatan yang paling aman biasanya adalah publikasi atomik atau penggantian berversi, di mana beban kerja Anda tetap menyajikan dan menggunakan tampilan lengkap terakhir sementara Anda membangun dan memvalidasi tampilan baru. Tukar ke tampilan baru setelah validasi selesai.

• Kolom terhitung. Saat menentukan tampilan materialisasi, maksimalkan nilainya dengan menambahkan item data atau kolom berdasarkan komputasi atau transformasi item data yang ada, pada nilai yang diteruskan dalam kueri, atau pada kombinasi nilai ini jika sesuai.

• Lihat pengindeksan. Jika mekanisme penyimpanan mendukungnya, pertimbangkan untuk mengindeks tampilan terwujud untuk lebih meningkatkan performa. Banyak database relasional mendukung pengindeksan untuk tampilan. Namun, pemeliharaan indeks pada tampilan menambahkan overhead jalur tulis selama setiap siklus refresh, jadi seimbangkan perolehan performa baca terhadap waktu refresh dan biaya komputasi tambahan.

• Kontrol akses pada tampilan. Ketika tampilan materialisasi digunakan untuk membatasi subset data mana yang terlihat oleh konsumen tertentu, seperti untuk alasan keamanan atau privasi, penyimpanan tampilan harus memberlakukan kontrol akses yang sama atau lebih ketat sebagai data sumber. Alur refresh Anda harus mengecualikan kolom atau baris yang tidak diinginkan, karena tampilan yang secara tidak sengaja menyertakan data di luar cakupan yang dimaksudkan dapat mengekspos data yang dilindungi.

• Siklus hidup data pada tampilan. Terapkan persyaratan retensi dan penghapusan data sumber pada setiap tampilan termaterialisasi. Terapkan penghapusan dan penyamaran dari sumber dalam jangka waktu yang diwajibkan, dan sertakan setiap tampilan dalam pemantauan kepatuhan. Untuk informasi selengkapnya, lihat Tata kelola data dan garis besar keamanan dengan Microsoft Purview.

• Lihat manajemen siklus hidup. Perlakukan definisi tampilan sebagai artefak yang dapat disebarkan yang dikelola melalui kontrol sumber dan alur CI/CD, terutama ketika tampilan didefinisikan secara deklaratif. Tanpa manajemen siklus hidup, definisi tampilan dapat melayang di antara lingkungan, menyebabkan perilaku kueri yang tidak konsisten di seluruh pengembangan, penahapan, dan produksi.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Anda perlu membuat tampilan atas data yang sulit untuk dikueri secara langsung, atau di mana kueri harus sangat kompleks untuk mengekstrak data yang disimpan dengan cara yang dinormalisasi, semi terstruktur, atau tidak terstruktur.
• Anda ingin membuat proyeksi cache yang dapat dibangun kembali atau sementara yang meningkatkan performa kueri, atau data bentuk yang digunakan untuk membuat objek transfer data untuk UI, laporan, atau tampilan.
• Anda perlu mendukung skenario yang terkadang tersambung atau terputus di mana koneksi ke penyimpanan data tidak selalu tersedia. Anda dapat menyimpan tampilan secara lokal dalam kasus ini.
• Anda ingin menyederhanakan kueri dan mengekspos data untuk eksperimen dengan cara yang tidak memerlukan pengetahuan tentang format data sumber. Misalnya, dengan menggabungkan tabel yang berbeda dalam satu atau beberapa database, atau satu atau beberapa domain di penyimpanan NoSQL, lalu memformat data agar sesuai dengan penggunaan akhirnya.
• Anda ingin memberikan akses ke subset tertentu dari data sumber yang, karena alasan keamanan atau privasi, seharusnya tidak dapat diakses secara umum, terbuka untuk modifikasi, atau sepenuhnya diekspos ke pengguna.
• Anda ingin menghubungkan berbagai penyimpanan data untuk memanfaatkan kemampuan masing-masing. Misalnya, Anda dapat menggunakan penyimpanan cloud yang efisien untuk operasi penulisan sebagai penyimpanan data referensi, dan basis data relasional yang menawarkan performa kueri dan pembacaan yang baik untuk menampung tampilan termaterialisasi.
• Saat Anda menggunakan mikrolayanan, pastikan layanan-layanan tersebut tetap berketerkaitan longgar, termasuk dalam penyimpanan datanya. Tampilan materialisasi dapat membantu Anda mengonsolidasikan data dari layanan Anda. Jika materialized view tidak tepat untuk arsitektur layanan mikro atau skenario tertentu Anda, pertimbangkan untuk memiliki batas yang terdefinisi dengan jelas dan selaras dengan desain berbasis domain (DDD), lalu mengagregasikan datanya sesuai kebutuhan.

Pola ini mungkin tidak cocok ketika:

• Sumber datanya sederhana dan mudah untuk dikuerikan.
• Data sumber berubah sangat cepat, atau dapat diakses tanpa menggunakan tampilan. Dalam kasus ini, hindari beban tambahan pemrosesan saat membuat tampilan.
• Konsistensi adalah prioritas tinggi. Tampilan mungkin tidak selalu sepenuhnya konsisten dengan data asli.

Desain beban kerja

Arsitek harus mengevaluasi bagaimana pola Tampilan Materialisasi dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:

Prinsip Dasar	Bagaimana pola ini mendukung tujuan pilar
Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien melalui pengoptimalan dalam penskalaan, data, dan kode.	Tampilan materialisasi menyimpan hasil komputasi atau kueri yang kompleks tanpa mengharuskan mesin database atau klien untuk mengolah ulang untuk setiap permintaan. Desain ini mengurangi konsumsi sumber daya secara keseluruhan. - PE:08 Kinerja data

Jika pola ini memperkenalkan kompromi di dalam pilar, bandingkan dengan tujuan pilar lain.

Example

Pertimbangkan aplikasi penjualan yang menyimpan entitas Order, OrderItem, dan Customer di Penyimpanan Tabel Azure. Pesanan dipartisi oleh ID pelanggan, item pesanan berdasarkan ID pesanan, dan pelanggan berdasarkan wilayah. Kunci ini mendukung pola akses operasional aplikasi, tetapi laporan penjualan yang dikelompokkan menurut produk harus membaca data di seluruh partisi dan menggabungkannya dalam kode aplikasi.

Gambar berikut menunjukkan tampilan materialisasi yang menyimpan total nilai penjualan dan jumlah pelanggan pembelian yang berbeda untuk setiap produk dalam kategori Elektronik. Baris sumber dan nilai ringkasan bersifat ilustratif, bukan himpunan data input lengkap untuk total yang ditampilkan.

Tiga tabel muncul di sebelah kiri: Pesan di bagian atas, OrderItem di tengah, dan Pelanggan di bagian bawah. Kunci partisi mereka masing-masing adalah ID pelanggan, ID pesanan, dan wilayah. Panah besar mengarah dari tabel sumber ke tabel Tampilan Materialisasi di sebelah kanan. Tampilan menggunakan kategori produk sebagai kunci partisi dan ID produknya sebagai kunci barisnya. Setiap baris berisi nama produk, total nilai penjualan, dan jumlah pelanggan. Tampilan yang diilustrasikan memiliki dua baris produk dalam partisi Elektronik.

Proses di latar belakang membaca entitas sumber yang diperlukan, mengaitkan item-item pesanan dengan pesanan serta pelanggannya, dan mengagregasikan penjualan menurut produk. Ini menghitung setiap pelanggan sekali per produk, bahkan ketika pelanggan tersebut memiliki beberapa pesanan atau baris pesanan. Proses menulis hasilnya ke tabel ringkasan terpisah dengan kategori produk sebagai PartitionKey dan ID produk sebagai RowKey. Tabel ringkasan ini adalah proyeksi yang dikelola aplikasi, bukan tampilan materialisasi asli database.

Dasbor kemudian dapat meminta partisi Elektronik alih-alih mengulangi pembacaan dan agregasi lintas partisi untuk setiap permintaan. Pencarian untuk satu produk menghasilkan kedua kunci. Untuk implikasi performa kueri kunci ini, lihat Desain untuk kueri.

Segarkan ringkasan sesuai jadwal yang memenuhi batas toleransi keterlambatan laporan yang dapat diterima. Buat dan validasi versi baru sebelum menerbitkannya, sehingga pembaca terus menggunakan versi lengkap sebelumnya selama pembangunan ulang. Penyegaran masih menimbulkan biaya pembacaan dan agregasi lintas partisi, tetapi kueri laporan yang berulang menggunakan kembali hasil tersebut. Perubahan sumber tidak terlihat sampai refresh berikutnya menyertakannya.

Langkah berikutnya

• Membuat tampilan terindeks menjelaskan bagaimana database SQL dapat mempertahankan hasil tampilan komputasi dengan membuat indeks pada tampilan.
• Pola desain umpan perubahan di Azure Cosmos DB untuk NoSQL menjelaskan bagaimana konsumen umpan perubahan dapat mempertahankan tampilan terwujud.
• Gambaran umum tampilan materialisasi menjelaskan tampilan materialisasi dalam Azure Data Explorer.
• Azure Managed Redis dapat menyimpan hasil kueri yang telah dikomputasi sebelumnya sebagai lapisan yang dioptimalkan untuk dibaca di depan penyimpanan data persisten.
• Penyimpanan Tabel Azure dapat menyimpan data tampilan yang telah dikomputasi yang dihasilkan oleh logika aplikasi atau proses latar belakang.

Sumber daya terkait

Pola berikut mungkin juga relevan ketika Anda menerapkan pola ini:

• Pola Pemisahan Tanggung Jawab Command and Query (CQRS). Gunakan untuk memperbarui informasi dalam tampilan terwujud dengan merespons peristiwa yang terjadi saat nilai data yang mendasarinya berubah.
• Polanya Event Sourcing. Gunakan bersama dengan pola CQRS untuk mempertahankan informasi dalam tampilan materialisasi. Ketika nilai data tampilan materialisasi didasarkan pada perubahan, sistem dapat menaikkan peristiwa yang menjelaskan perubahan ini dan menyimpannya di penyimpanan peristiwa.
• Pola Tabel Indeks. Data dalam tampilan terwujud biasanya diatur oleh kunci utama, tetapi kueri mungkin perlu mengambil informasi dari tampilan ini dengan memeriksa data di bidang lain. Gunakan pola ini untuk membuat indeks sekunder melalui himpunan data untuk penyimpanan data yang tidak mendukung indeks sekunder asli.