Kinerja tidak lebih buruk, tentu saja. Seperti yang dijelaskan artikel tersebut, ada kondisi khusus yang membuat pendekatan skema menjadi lebih baik atau lebih buruk tergantung pada desain aplikasi dan beban kerja Anda. Izinkan saya menjelaskan pengorbanan dari pendekatan "skema penyewa" vs. "meja bersama":
skema penyewa paling baik bila Anda memiliki jumlah penyewa yang cukup besar dalam jumlah yang relatif kecil. Contohnya adalah aplikasi akuntansi, dengan hanya pengguna langganan berbayar. Hal-hal yang menjadikannya opsi berkinerja lebih baik untuk Anda meliputi:
- sejumlah kecil penyewa dengan banyak data masing-masing
- skema yang relatif sederhana tanpa banyak tabel per penyewa
- kebutuhan untuk menyesuaikan skema beberapa penyewa
- kemampuan untuk memanfaatkan peran database per penyewa
- persyaratan untuk memigrasikan data tenant dari satu server ke server lain
- kemampuan untuk menjalankan server aplikasi khusus di cloud Anda untuk setiap penyewa
Hal-hal yang menjadikannya opsi berkinerja buruk meliputi:
- banyak penyewa dengan data yang sangat sedikit
- pendekatan tanpa status untuk koneksi di mana setiap permintaan dapat berupa penyewa apa pun
- library klien atau orm yang menyimpan metadata untuk semua tabel (seperti ActiveRecord)
- persyaratan untuk penyatuan koneksi dan/atau caching yang efisien dan berkinerja tinggi
- masalah dengan VACUUM dan operasi administratif PostgreSQL lainnya yang berskala buruk pada 1000 tabel.
Apakah skema penyewa buruk untuk migrasi/perubahan skema sangat tergantung pada bagaimana Anda melakukannya. Ini buruk untuk meluncurkan perubahan skema universal dengan cepat, tetapi bagus untuk menerapkan perubahan skema sebagai peluncuran bertahap di seluruh penyewa.
meja bersama bekerja lebih baik untuk situasi ketika Anda memiliki banyak penyewa, dan banyak penyewa Anda memiliki sedikit data. Contohnya adalah aplikasi seluler medial sosial yang memungkinkan akun gratis dan dengan demikian memiliki ribuan akun yang ditinggalkan. Hal lain yang membuat model tabel bersama bermanfaat adalah:
- lebih baik untuk penggabungan koneksi, karena semua koneksi dapat menggunakan kumpulan yang sama
- lebih baik untuk administrasi PostgreSQL, karena jumlah tabel yang lebih sedikit
- lebih baik untuk migrasi dan perubahan skema, karena hanya ada satu "set" tabel
Kelemahan utama tabel bersama adalah kebutuhan untuk menambahkan kondisi filter penyewa ke setiap kueri di lapisan aplikasi. Ini juga bermasalah karena:
- kueri yang menggabungkan banyak tabel mungkin berkinerja buruk karena filter penyewa membuang perencanaan kueri
- tabel yang tumbuh hingga 100 juta baris dapat menyebabkan masalah kinerja dan pemeliharaan tertentu
- tidak ada cara untuk melakukan perubahan aplikasi khusus penyewa atau peningkatan skema
- lebih mahal untuk memigrasikan penyewa antar server
Jadi model mana yang "berperforma lebih baik" sangat bergantung pada pengorbanan mana yang paling merugikan Anda.
Ada juga model hybrid, "tenant-view", di mana data aktual disimpan dalam tabel bersama, tetapi setiap koneksi aplikasi menggunakan tampilan penghalang keamanan untuk melihat datanya. Ini memiliki beberapa pengorbanan dari setiap model. Terutama, ia memiliki manfaat keamanan dari model skema penyewa dengan beberapa kelemahan kinerja dari kedua model.
