Tampilan Materialisasi

  • Artikel

Tampilan materialisasi mengekspos kueri agregasi melalui tabel sumber, atau di atas tampilan material lainnya.

Tampilan material selalu mengembalikan hasil terbaru dari kueri agregasi (selalu segar). Mengkueri tampilan materialisasi lebih bersifat performant daripada menjalankan agregasi langsung di atas tabel sumber.

Catatan

Mengapa menggunakan tampilan materialisasi?

Dengan menginvestasikan sumber daya (penyimpanan data, siklus CPU latar belakang) untuk tampilan terwujud dari agregasi yang umum digunakan, Anda mendapatkan manfaat berikut:

  • Peningkatan performa: Mengkueri tampilan materialisasi biasanya berperforma lebih baik daripada mengkueri tabel sumber untuk fungsi agregasi yang sama.

  • Kesegaran: Kueri tampilan material selalu mengembalikan hasil terbaru, terlepas dari kapan materialisasi terakhir terjadi. Kueri menggabungkan bagian materialisasi tampilan dengan catatan dalam tabel sumber, yang belum terwujud ( delta bagian), selalu memberikan hasil terbaru.

  • Pengurangan biaya:Mengkueri tampilan materialisasi menghabiskan lebih sedikit sumber daya dari kluster daripada melakukan agregasi di atas tabel sumber. Kebijakan retensi tabel sumber dapat dikurangi jika hanya diperlukan agregasi. Pengaturan ini mengurangi biaya cache panas untuk tabel sumber.

Misalnya kasus penggunaan, lihat Kasus penggunaan tampilan materialisasi.

Bagaimana tampilan materialisasi bekerja

Tampilan materialisasi terbuat dari dua komponen:

  • Bagian materialisasi - tabel yang menyimpan rekaman agregat dari tabel sumber, yang telah diproses. Tabel ini selalu menyimpan satu catatan per kombinasi grup demi gabungan agregasi.
  • Delta - catatan yang baru dicerna dalam tabel sumber yang belum diproses.

Mengkueri tampilan materialisasi menggabungkan bagian materialisasi dengan bagian delta, memberikan hasil terbaru dari kueri agregasi. Proses materialisasi offline menyerap rekaman baru dari delta ke tabel terwujud, dan memperbarui rekaman yang ada. Jika persimpangan antara delta dan bagian yang terwujud besar, dan banyak catatan memerlukan pembaruan, ini mungkin berdampak negatif pada proses materialisasi. Lihat memantau tampilan materialisasi tentang cara memecahkan masalah situasi tersebut.

Kueri tampilan materialisasi

Ada 2 cara untuk menanyakan tampilan materialisasi:

  • Kueri seluruh tampilan: saat Anda menanyakan tampilan materialisasi dengan namanya, mirip dengan kueri tabel, kueri tampilan materialisasi menggabungkan bagian materialisasi tampilan dengan catatan di tabel sumber yang belum terwujud (delta).

    • Mengkueri tampilan materialisasi selalu mengembalikan hasil terbaru, berdasarkan semua rekaman yang diserap ke tabel sumber. Untuk informasi lebih lanjut tentang bagian material vs. non-materialisasi dalam tampilan material, lihat cara kerja tampilan yang terwujud.
    • Opsi ini mungkin tidak berkinerja terbaik karena perlu mewujudkan delta bagian selama waktu kueri. Performa dalam hal ini tergantung pada usia tampilan dan filter yang diterapkan dalam kueri. Bagian pengoptimal kueri tampilan material mencakup kemungkinan cara untuk meningkatkan performa kueri saat mengkueri seluruh tampilan.

  • Kueri hanya bagian yang terwujud: cara lain untuk mengkueri tampilan adalah dengan menggunakan materialized_view()fungsi. Opsi ini hanya mendukung kueri bagian tampilan yang terwujud, sambil menentukan latensi maksimum yang bersedia ditoleransi pengguna.

    • Opsi ini tidak dijamin untuk mengembalikan catatan terbaru, tetapi harus selalu lebih berperforma daripada menanyakan seluruh tampilan.
    • Fungsi ini berguna untuk skenario di mana Anda bersedia mengorbankan kesegaran untuk performa, misalnya untuk dasbor telemetri.

Tip

Kueri atas bagian materialisasi hanya selalu berkinerja lebih baik daripada mengkueri seluruh tampilan. Selalu gunakan fungsi materialized_view() ini jika berlaku untuk kasus penggunaan Anda.

  • Tampilan materialisasi berpartisipasi dalam kueri lintas kluster atau lintas database, tetapi tidak termasuk dalam serikat atau penelusuran kartubebas.

    • Contoh berikut semuanya mencakup tampilan materialisasi dengan nama ViewName:
    cluster('cluster1').database('db').ViewName
cluster('cluster1').database('*').ViewName
database('*').ViewName
database('DB*').ViewName
database('*').materialized_view('ViewName')
database('DB*').materialized_view('ViewName')
    • Contoh berikut tidak menyertakan rekaman dari tampilan materialisasi:
    cluster('cluster1').database('db').*
database('*').View*
search in (*)
search *

Pengoptimal kueri tampilan material

Saat mengkueri seluruh tampilan, bagian yang terwujud digabungkan dengan delta selama waktu kueri. Ini termasuk menggabungkan delta dan menggabungkannya dengan bagian yang terwujud.

  • Mengkueri seluruh tampilan berkinerja lebih baik jika kueri menyertakan filter pada grup menurut kunci kueri tampilan materialisasi. Lihat tips selengkapnya tentang cara membuat tampilan materialisasi Anda, berdasarkan pola kueri Anda, di .create materialized-view tips performa bagian .
  • Pengoptimal kueri memilih strategi ringkasan/gabungan yang diharapkan dapat meningkatkan performa kueri. Misalnya, keputusan apakah akan mengocok kueri sebagian didasarkan pada jumlah catatan delta. Properti permintaan klien berikut memberikan kontrol atas pengoptimalan yang diterapkan. Anda dapat menguji properti ini dengan kueri tampilan materialisasi dan mengevaluasi dampaknya terhadap performa kueri.
Nama properti permintaan klien Jenis Deskripsi
materialized_view_query_optimization_costbased_enabled bool Jika diatur ke false, nonaktifkan ringkasan/gabung pengoptimalan dalam kueri tampilan material. Menggunakan strategi default. Defaultnya adalah true.
materialized_view_shuffle dynamic Paksa pengocokan kueri tampilan materialisasi, dan (opsional) menyediakan kunci tertentu untuk dikocok. Lihat contoh di bawah.

Contoh

  1. Kueri seluruh tampilan. Catatan terbaru dalam tabel sumber disertakan:

    ViewName

  2. Kueri bagian material dari tampilan saja, terlepas dari kapan terakhir kali terwujud.

    materialized_view("ViewName")

  3. Query seluruh tampilan, dan memberikan "petunjuk" untuk menggunakan strategi shuffle. Catatan terbaru dalam tabel sumber disertakan:

    • Contoh # 1: mengocok berdasarkan kolom Id (mirip dengan menggunakan hint.shufflekey=Id):
    set materialized_view_shuffle = dynamic([{"Name" : "ViewName", "Keys" : [ "Id" ] }]);
ViewName
    • Contoh # 2: mengocok berdasarkan semua tombol (mirip dengan menggunakan hint.strategy=shuffle):
    set materialized_view_shuffle = dynamic([{"Name" : "ViewName" }]);
ViewName

Pertimbangan performa

Kontributor utama yang dapat mempengaruhi kesehatan pandangan material adalah:

  • Sumber daya kluster: Seperti proses lain yang berjalan pada kluster, tampilan material mengonsumsi sumber daya (CPU, memori) dari kluster. Jika kluster kelebihan beban, menambahkan tampilan material untuk itu dapat menyebabkan degradasi dalam performa kluster. Pantau kesehatan kluster Anda menggunakan metrik kesehatan kluster. Skala otomatis yang dioptimalkan saat ini tidak mempertimbangkan kesehatan tampilan material sebagai bagian dari aturan skala otomatis.

  • Tumpang tindih dengan data materialisasi: Selama materialisasi, semua rekaman baru diserap ke tabel sumber sejak materialisasi terakhir (delta) diproses dan diwujudkan dalam tampilan. Semakin tinggi persimpangan antara rekaman baru dan rekaman yang sudah terwujud, semakin buruk performa tampilan materialnya. Tampilan materialisasi akan bekerja paling baik jika jumlah rekaman yang diperbarui (misalnya, dalam tampilan arg_max) merupakan subset kecil dari tabel sumber. Jika semua atau sebagian besar rekaman tampilan material perlu diperbarui dalam setiap siklus materialisasi, maka tampilan materialisasi tidak akan bekerja dengan baik.

  • Tingkat konsumsi: Tidak ada batasan kode keras pada volume data atau tingkat penyerapan di tabel sumber tampilan materialisasi. Namun, tingkat penyerapan yang disarankan untuk tampilan materialisasi tidak lebih dari 1-2GB /detik. Tingkat konsumsi yang lebih tinggi mungkin masih berperforma baik. Performa tergantung pada ukuran kluster, sumber daya yang tersedia, dan jumlah persimpangan dengan data yang ada.

  • Jumlah tampilan materialisasi dalam kluster: Pertimbangan di atas berlaku untuk setiap pandangan materialisasi individu yang didefinisikan dalam kluster. Setiap tampilan menggunakan sumber dayanya sendiri, dan banyak tampilan bersaing satu sama lain pada sumber daya yang tersedia. Meskipun tidak ada batasan kode keras untuk jumlah tampilan materialisasi dalam kluster, kluster mungkin tidak dapat menangani semua tampilan material, ketika ada banyak yang ditentukan. Kebijakan kapasitas dapat disesuaikan jika ada lebih dari satu tampilan materialisasi dalam kluster. Meningkatkan nilai ClusterMinimumConcurrentOperations dalam kebijakan untuk menjalankan pandangan yang lebih material secara bersamaan.

  • Definisi tampilan materialisasi: Definisi tampilan materialisasi harus didefinisikan sesuai dengan praktik terbaik kueri untuk performa kueri terbaik. Untuk informasi selengkapnya, lihat membuat tips performa perintah.

Tampilan materialisasi atas tampilan materialisasi

Tampilan materialisasi dapat dibuat di atas tampilan materialisasi lain jika tampilan material sumber adalah tampilan deduplikasi. Secara khusus, agregasi tampilan material sumber harus take_any(*) untuk mengurai sumber catatan. Tampilan material kedua dapat menggunakan fungsi agregasi yang didukung. Untuk informasi spesifik tentang cara membuat tampilan materialisasi atas tampilan materialisasi, lihat .create materialized-view perintah.

Tip

Saat mengkueri tampilan materialisasi yang ditentukan di atas tampilan materialisasi lain, sebaiknya kueri bagian materialisasi hanya menggunakan fungsi.materialized_view() Mengkueri seluruh tampilan tidak berkinerja saat kedua tampilan tidak sepenuhnya terwujud. Untuk informasi selengkapnya, lihat pemantauan tampilan materialisasi.

Konten terkait