Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Konsep multitenancy dalam Real-Time Intelligence mengacu pada penyajian penyewa yang berbeda dan menyimpan data mereka dalam satu eventhouse.
Penyewa dapat mewakili pelanggan, sekelompok pengguna, atau klasifikasi pengguna apa pun di mana data perlu dipisahkan di sepanjang batas penyewa. Anda juga dapat memiliki skenario multitenansi multilevel, seperti beberapa aplikasi yang masing-masing memiliki beberapa tenant. Artikel ini tidak mencakup skenario ini, tetapi prinsip serupa berlaku.
Faktor penting adalah cara pengguna akhir mengakses data penyewa mereka. Saat pengguna akhir mengakses Azure Data Explorer secara langsung, kontrol akses harus dikonfigurasi di Azure Data Explorer untuk mengisolasi tampilan pengguna ke data mereka sendiri. Saat aplikasi proksi mengakses data mereka di Azure Data Explorer, aplikasi dapat melakukan isolasi.
Artikel ini menjelaskan beberapa arsitektur penyebaran dan menyediakan karakteristik untuk masing-masing arsitektur. Anda dapat menggunakan karakteristik untuk membantu Anda memutuskan arsitektur mana yang paling sesuai untuk solusi Anda.
Tetangga berisik
Secara umum, berbagi kluster di antara banyak penyewa, terlepas dari arsitektur yang digunakan, berarti penyewa yang berbeda berbagi sumber daya kluster. Ini dapat menyebabkan antipattern tetangga yang berisik.
Misalnya, jika penyewa melakukan banyak kueri atau pemrosesan intensif komputasi, penyewa lain kemungkinan akan terpengaruh oleh kekurangan sumber daya. Ini dapat dimitigasi dengan menggunakan grup beban kerja. Anda juga dapat menggunakan kebijakan untuk mengontrol cache dan penyimpanan secara keseluruhan.
Gambaran umum arsitektur
Bagian berikutnya menjelajahi arsitektur penyebaran secara rinci. Bagian ini membedakan arsitektur untuk memfasilitasi pengambilan keputusan.
| Architecture | Strengths |
|---|---|
| Satu penyewa per database | - Isolasi penyewa: tidak perlu proksi - Dapat memiliki kebijakan yang berbeda, seperti kebijakan retensi, per penyewa - Fleksibilitas dalam evolusi skema per penyewa - Penghapusan data penyewa yang mudah dan cepat |
| Satu tabel untuk banyak penyewa | - Konsolidasi data yang efisien dan manajemen ekstensi - Evolusi skema yang disederhanakan - Paling cocok untuk tampilan materialisasi - Ideal untuk pemartisian |
| Satu penyewa per tabel dalam satu database | Tidak disarankan |
Arsitektur: Satu penyewa per database
Ini adalah arsitektur populer dan mudah dipahami. Setiap penyewa mendapatkan databasenya sendiri. Setiap database memiliki skema yang sama.
Karakteristik arsitektur ini adalah:
Menyediakan penyewa baru: Memerlukan pembuatan database baru dan menyebarkan entitas skema di dalamnya.
Menghapus penyewa: Memerlukan penghapusan database. Menghapus database dapat dilakukan dalam beberapa detik. Mengonsumsi sumber daya kecil dan konstan yang tidak linier dengan volume data penyewa.
Pembaruan skema database: Setiap tenant dapat diperbarui secara independen pada waktu yang berbeda. Aplikasi yang mengakses database harus mengetahui versi setiap database yang berinteraksi dengannya.
Kebijakan retensi dan caching: Setiap penyewa dapat memiliki kebijakan yang unik, yang memungkinkan Anda untuk memberikan kebijakan retensi dan caching kustom kepada pelanggan Anda.
Batas keamanan per penyewa:
- Untuk aplikasi multipenyewa (proksi): Konfigurasikan aplikasi Anda untuk menargetkan database yang relevan. Gunakan pembatasan akses pada kueri untuk melarang kueri lintas database.
- Untuk pengguna dengan akses langsung: Pengguna dapat diberikan akses di tingkat database. Memberi pengguna akses langsung ke database mereka menciptakan dependensi untuk detail implementasi, sehingga sulit untuk mengubah implementasi. Oleh karena itu, kami sangat menyarankan untuk menggunakan pendekatan proksi untuk mengakses database.
Menggabungkan data dari beberapa penyewa dalam skala besar: Gunakan operator gabungan untuk menggabungkan data antar database. Namun, metode ini dapat menjadi rumit saat jumlah penyewa meningkat. Meskipun menggabungkan data dari beberapa penyewa mungkin merupakan tujuan desain dari perspektif penyewa, mungkin penting bagi pemilik solusi untuk menggabungkan data dari semua penyewa untuk mengumpulkan statistik.
Fragmentasi ekstensi: Setiap penyewa memasukkan beberapa rekaman per tabel database mengarah pada pembuatan ekstensi kecil yang nantinya perlu digabungkan. Ini menghasilkan biaya lebih tinggi dalam manajemen ekstensi. Oleh karena itu, kami sangat menyarankan penggunaan pengambilan data streaming, seperti pengambilan data Event Hubs atau pengambilan data Event Grid. Untuk menggunakan ingesting streaming, Anda harus memastikan bahwa fungsi tersebut diaktifkan pada kluster dan tabel.
Tampilan materialisasi dan kebijakan partisi. Ketika jumlah penyewa meningkat, penting untuk diingat bahwa ada batasan jumlah tampilan materialisasi dan kebijakan partisi yang dapat dijalankan kluster secara efisien.
Koneksi data Event Grid dan Event Hubs: Koneksi data ini dibuat per database. Oleh karena itu, arsitektur ini memerlukan koneksi data dan instans Event Grid atau Event Hubs per penyewa, yang menambahkan kompleksitas manajemen. Pertimbangkan untuk menggunakan perutean peristiwa untuk Event Hubs dan Event Grid.
Arsitektur: Satu tabel untuk banyak penyewa
Arsitektur ini lebih agresif dalam konsolidasinya, menggunakan database tunggal untuk semua penyewa. Setiap tabel dalam database memiliki kolom ID Penyewa, atau yang setara, yang memungkinkan pemfilteran untuk data penyewa tunggal. Anda dapat mempartisi tabel menurut penyewa untuk meningkatkan performa kueri, karena sebagian besar kueri kemungkinan akan difilter menurut penyewa. Jika memungkinkan, Anda harus mempertimbangkan partisi dengan kolom lain menggunakan kunci partisi gabungan . Misalnya, Anda dapat membuat kunci partisi campuran yang menggabungkan ID penyewa dan nilai kolom lain.
Karakteristik arsitektur ini adalah:
Menyediakan penyewa baru: Menyediakan penyewa baru tidak memerlukan pembuatan database atau penyesuaian skema apa pun. ID tenant baru digunakan dalam rekaman baru.
Menghapus penyewa: Memerlukan penghapusan sementara atau penghapusan menyeluruh data penyewa. Anda dapat mengumpulkan beberapa pembersihan bersama-sama, misalnya, pada akhir minggu untuk membatasi dampak pada konsumsi sumber daya.
Pembaruan skema database: Semua skema penyewa ditingkatkan secara bersamaan. Karena semua penyewa berbagi tabel, mengubah skema tabel mengubah semua penyewa sekaligus.
Kebijakan retensi dan penembolokan: Kebijakan tersebut sama untuk semua pengguna karena semua berbagi tabel yang sama.
Batas keamanan per penyewa:
- Untuk aplikasi multipenyewa (proksi): Gunakan pernyataan Batasi
- Untuk pengguna dengan akses langsung: Gunakan Kebijakan Keamanan Tingkat Baris dan biasakan diri Anda dengan batasannya. Memberi pengguna akses langsung ke database mereka menciptakan dependensi untuk detail implementasi, sehingga sulit untuk mengubah implementasi. Oleh karena itu, kami sangat menyarankan untuk menggunakan pendekatan proksi untuk mengakses database.
Menggabungkan data dari beberapa penyewa dalam skala besar: Pengguna dengan izin akses yang memadai dapat menjalankan kueri agregasi standar pada data beberapa penyewa.
Fragmentasi ekstensi: Karena semua klien mengolah data ke dalam tabel yang sama, data biasanya dapat dikonsolidasikan dan dimasukkan dengan efisien dalam satu, atau beberapa, ekstensi.
Tampilan materialisasi dan kebijakan partisi: Ini dapat digunakan pada tabel multipenyewa. Anda dapat meningkatkan performa dengan mempartisi pada Tenant ID, atau kolom yang setara. Untuk informasi selengkapnya, lihat Skenario untuk kebijakan partisi.
Koneksi data Event Grid dan Event Hubs: Anda menggabungkan koneksi data karena data dari semua penyewa dijadikan satu tabel.
Arsitektur: Satu penghuni per tabel dalam satu database
Arsitektur ini adalah kombinasi dari arsitektur sebelumnya di mana data semua penyewa berakhir dalam satu database tetapi tabel terpisah. Arsitektur ini gagal menangkap semua keuntungan dari arsitektur lain.
Meskipun data setiap penyewa dipisahkan, semuanya berada dalam konteks keamanan yang sama dari database yang sama. Seperti arsitektur multi-database, arsitektur ini dapat menyebabkan fragmentasi yang luas. Nama tabel berbeda untuk setiap penyewa dan oleh karena itu kueri harus disesuaikan untuk setiap penyewa.