Matriks keputusan

Untuk memutuskan model partisi SaaS multi-penyewa mana yang harus Anda gunakan dengan PostgreSQL, lihat matriks keputusan berikut. Matriks menganalisis empat opsi partisi ini:

• Silo - Instance atau klaster PostgreSQL terpisah untuk setiap penyewa.

• Jembatani dengan database terpisah - Database terpisah untuk setiap penyewa dalam satu instance atau klaster PostgreSQL.

• Jembatan dengan skema terpisah - Skema terpisah untuk setiap penyewa dalam satu database PostgreSQL, dalam satu instance atau klaster PostgreSQL.

• Pool - Tabel bersama untuk penyewa dalam satu contoh dan skema.

	Silo	Jembatan dengan database terpisah	Jembatan dengan skema terpisah	Kolam
Kasus penggunaan	Isolasi data dengan kontrol penuh atas penggunaan sumber daya adalah persyaratan utama, atau Anda memiliki penyewa yang sangat besar dan sangat sensitif terhadap kinerja.	Isolasi data adalah persyaratan utama, dan terbatas atau tidak ada referensi silang data penyewa diperlukan.	Sedang jumlah penyewa dengan jumlah moderat data. Ini adalah model yang disukai jika Anda harus referensi silang data penyewa.	Sejumlah besar penyewa dengan lebih sedikit data per penyewa.
Kelincahan orientasi penyewa baru	Sangat lambat. (Instance atau cluster baru diperlukan untuk setiap penyewa.)	Cukup lambat. (Membutuhkan pembuatan database baru untuk setiap penyewa untuk menyimpan objek skema.)	Cukup lambat. (Membutuhkan pembuatan skema baru untuk setiap penyewa untuk menyimpan objek.)	Opsi tercepat. (Diperlukan pengaturan minimal.)
Koneksi database upaya konfigurasi kolam renang dan efisiensi	Diperlukan upaya yang signifikan. (Satu kolam koneksi per penyewa.) Kurang efisien. (Tidak ada koneksi database berbagi antara penyewa.)	Diperlukan upaya yang signifikan. (Satu konfigurasi kumpulan koneksi per penyewa kecuali Anda menggunakan Amazon RDS Proxy.) Kurang efisien. (Tidak ada koneksi database berbagi antara penyewa dan jumlah total koneksi. Penggunaan di semua penyewa dibatasan berdasarkan kelas instans DB.)	Kurang usaha yang dibutuhkan. (Satu konfigurasi kolam koneksi untuk semua penyewa.) Cukup efisien. (Koneksi digunakan kembali melaluiSET SCHEMA perintahSET ROLE atau dalam mode sesi kolam renang saja. SETperintah juga menyebabkan sesi menyematkan saat menggunakan Amazon RDS Proxy, tetapi kumpulan koneksi klien dapat dihilangkan dan koneksi langsung dapat dibuat untuk setiap permintaan efisiensi.)	Setidaknya usaha yang dibutuhkan. Paling efisien. (Satu kolam koneksi untuk semua penyewa dan penggunaan kembali koneksi yang efisien di semua penyewa. Batasan koneksi didasarkan pada kelas instans DB.)
Pemeliharaan database (manajemen vakum) dan penggunaan sumber daya	Manajemen yang lebih sederhana.	kompleksitas sedang. (Mungkin menyebabkan konsumsi sumber daya yang tinggi, karena pekerja vakum harus dimulai untuk setiap database setelahnyavacuum_naptime, yang mengarah ke penggunaan CPU peluncur autovacuum tinggi. Mungkin juga ada overhead tambahan yang terkait dengan penyedotan tabel katalog sistem PostgreSQL untuk setiap database.)	Tabel katalog sistem PostgreSQL besar. (pg_catalogUkuran total dalam puluhan GB, tergantung pada jumlah penyewa dan relasi. Mungkin memerlukan modifikasi parameter yang berhubungan dengan debu untuk mengontrol meja mengasapi.)	Tabel mungkin besar, tergantung pada jumlah penyewa dan data per penyewa. (Kemungkinan memerlukan modifikasi parameter terkait debu untuk mengontrol mengasapi meja.)
Upaya manajemen ekstensi	Upaya signifikan (untuk setiap database dalam kasus terpisah).	Upaya yang signifikan (di setiap tingkat database).	Upaya minimal (satu kali dalam database umum).	Upaya minimal (satu kali dalam database umum).
Ubah upaya penyebaran	Upaya signifikan. (Connect ke setiap instance terpisah dan luncurkan perubahan.)	Upaya signifikan. (Connect ke setiap database dan skema, dan meluncurkan perubahan.)	Upaya moderat. (Connect ke database umum dan meluncurkan perubahan untuk setiap skema.)	Upaya minimal. (Connect ke database umum dan meluncurkan perubahan.)
Ubah penyebaran — cakupan dampak	minimal minimal. (Penyewa tunggal terpengaruh.)	minimal minimal. (Penyewa tunggal terpengaruh.)	minimal minimal. (Penyewa tunggal terpengaruh.)	Sangat besar. (Semua penyewa terpengaruh.)
Manajemen dan upaya kinerja kueri	Kinerja query dikelola.	Kinerja query dikelola.	Kinerja query dikelola.	Upaya signifikan kemungkinan diperlukan untuk mempertahankan kinerja kueri. (Seiring waktu, kueri mungkin berjalan lebih lambat karena peningkatan ukuran tabel. Anda dapat menggunakan partisi tabel dan sharding database untuk mempertahankan kinerja.)
Dampak sumber daya lintas penyewa	Tidak ada Dampak. (Tidak ada berbagi sumber daya di antara penyewa.)	Dampak moderat. (Penyewa berbagi sumber daya umum seperti misalnya CPU dan memori.)	Dampak moderat. (Penyewa berbagi sumber daya umum seperti misalnya CPU dan memori.)	Dampak berat. (Penyewa saling mempengaruhi dalam hal sumber daya, mengunci konflik, dan sebagainya.)
Penyewa tingkat tuning (misalnya, penciptaan indeks tambahan per penyewa atau parameter DB tweaking untuk penyewa tertentu)	Kemungkinan.	Agak mungkin. (Perubahan tingkat skema dapat dilakukan untuk setiap penyewa, tetapi parameter database bersifat global di semua penyewa.)	Agak mungkin. (Perubahan tingkat skema dapat dilakukan untuk setiap penyewa, tetapi parameter database bersifat global di semua penyewa.)	Tidak memungkinkan. (Tabel dibagi oleh semua penyewa.)
Upaya menyeimbangkan kembali penyewa yang peka terhadap kinerja	minimal minimal. (Tidak perlu menyeimbangkan kembali. Skala server dan sumber daya I/O untuk menangani skenario ini.)	Sedang. (Gunakan replikasi logis ataupg_dump untuk mengekspor database, tetapi downtime mungkin panjang tergantung pada ukuran data. Anda dapat menggunakan fitur database yang dapat diangkut di Amazon RDS for PostgreSQL untuk menyalin database antar instans dengan lebih cepat.)	Sedang tetapi kemungkinan melibatkan waktu henti yang lama. (Gunakan replikasi logis ataupg_dump untuk mengekspor skema, tetapi downtime mungkin panjang tergantung pada ukuran data.)	Signifikan, karena semua penyewa berbagi tabel yang sama. (Sharding database membutuhkan menyalin semuanya ke instance lain dan langkah tambahan untuk membersihkan data penyewa.) Kemungkinan besar membutuhkan perubahan logika aplikasi.
Downtime database untuk peningkatan versi mayor	Downtime standar. (Tergantung pada ukuran katalog sistem PostgreSQL.)	Kemungkinan downtime yang lebih lama. (Tergantung pada ukuran katalog sistem, waktu akan bervariasi. Tabel katalog sistem PostgreSQL juga diduplikasi di seluruh database)	Kemungkinan downtime yang lebih lama. (Tergantung pada ukuran katalog sistem PostgreSQL, waktu akan bervariasi.)	Downtime standar. (Tergantung pada ukuran katalog sistem PostgreSQL.)
Overhead administrasi (misalnya, untuk analisis log database atau pemantauan pekerjaan cadangan)	Upaya signifikan	Upaya minimal.	Upaya minimal.	Upaya minimal.
Ketersediaan tingkat penyewa	Tertinggi. (Setiap penyewa gagal dan pulih secara independen.)	Lingkup dampak yang lebih tinggi. (Semua penyewa gagal dan pulih bersama jika terjadi masalah perangkat keras atau sumber daya.)	Lingkup dampak yang lebih tinggi. (Semua penyewa gagal dan pulih bersama jika terjadi masalah perangkat keras atau sumber daya.)	Lingkup dampak yang lebih tinggi. (Semua penyewa gagal dan pulih bersama jika terjadi masalah perangkat keras atau sumber daya.)
Upaya pencadangan dan pemulihan tingkat penyewa	Upaya paling tidak tertunda. (Setiap penyewa dapat didukung dan dipulihkan secara independen.)	Upaya moderat. (Gunakan ekspor logis dan impor untuk setiap penyewa. Beberapa pengkodean dan otomatisasi diperlukan.)	Upaya moderat. (Gunakan ekspor logis dan impor untuk setiap penyewa. Beberapa pengkodean dan otomatisasi diperlukan.)	Upaya signifikan. (Semua penyewa berbagi tabel yang sama.)
Upaya point-in-time pemulihan tingkat penyewa	Upaya minimal. (Gunakan pemulihan waktu point-in dengan menggunakan snapshot, atau gunakan pelacakan mundur di Amazon Aurora.)	Upaya moderat. (Gunakan snapshot restore, diikuti oleh ekspor/impor. Namun, ini akan menjadi operasi yang lambat.)	Upaya moderat. (Gunakan snapshot restore, diikuti oleh ekspor/impor. Namun, ini akan menjadi operasi yang lambat.)	Upaya dan kompleksitas yang signifikan.
Nama skema seragam	Nama skema yang sama untuk setiap penyewa.	Nama skema yang sama untuk setiap penyewa.	Skema yang berbeda untuk setiap penyewa.	Skema umum.
Kustomisasi per penyewa (misalnya, kolom tabel tambahan untuk penyewa tertentu)	Kemungkinan.	Kemungkinan.	Kemungkinan.	Rumit (karena semua penyewa berbagi tabel yang sama).
Efisiensi manajemen katalog pada layer object-relasional mapping (ORM) (misalnya, Ruby)	Efisien (karena koneksi klien khusus untuk penyewa).	Efisien (karena koneksi klien khusus untuk database).	Cukup efisien. (Bergantung pada ORM yang digunakan, model keamanan pengguna/peran, dansearch_path konfigurasi, klien terkadang menyimpan metadata untuk semua penyewa, yang mengarah ke penggunaan memori koneksi DB yang tinggi.)	Efisien (karena semua penyewa berbagi tabel yang sama).
Upaya pelaporan penyewa konsolidasi	Upaya signifikan. (Anda harus menggunakan pembungkus data asing [FDWs] untuk mengkonsolidasikan data di semua penyewa atau mengekstrak, mengubah, dan memuat [ETL] ke database pelaporan lain.)	Upaya signifikan. (Anda harus menggunakan FDW untuk mengkonsolidasikan data di semua penyewa atau ETL ke database pelaporan lain.)	Upaya moderat. (Anda dapat mengumpulkan data dalam semua skema dengan menggunakan serikat pekerja.)	Upaya minimal. (Semua data penyewa ada dalam tabel yang sama, jadi pelaporan itu sederhana.)
Instance hanya-baca khusus penyewa untuk pelaporan (misalnya, berdasarkan langganan)	Upaya paling tidak tertunda. (Ciptakan sebuah replika baca baca.)	Upaya moderat. (Anda dapat menggunakan replikasi logis atauAWS Database Migration Service [AWS DMS] untuk mengkonfigurasi.)	Upaya moderat. (Anda dapat menggunakan replikasi logis atauAWS DMS untuk mengkonfigurasi.)	Rumit (karena semua penyewa berbagi tabel yang sama).
Isolasi data	Terbaik.	Lebih baik. (Anda dapat mengelola izin tingkat database dengan menggunakan peran PostgreSQL.)	Lebih baik. (Anda dapat mengelola izin tingkat skema dengan menggunakan peran PostgreSQL.)	Lebih buruk. (Karena semua penyewa berbagi tabel yang sama, Anda harus menerapkan fitur seperti keamanan tingkat baris [RLS] untuk isolasi penyewa.)
Kunci enkripsi penyimpanan khusus penyewa	Kemungkinan. (Setiap klaster PostgreSQL dapat memiliki kunciAWS Key Management Service [AWS KMS] sendiri untuk enkripsi penyimpanan.)	Tidak memungkinkan. (Semua penyewa berbagi kunci KMS yang sama untuk enkripsi penyimpanan.)	Tidak memungkinkan. (Semua penyewa berbagi kunci KMS yang sama untuk enkripsi penyimpanan.)	Tidak memungkinkan. (Semua penyewa berbagi kunci KMS yang sama untuk enkripsi penyimpanan.)
MenggunakanAWS Identity and Access Management (IAM) untuk otentikasi database untuk setiap penyewa	Kemungkinan.	Kemungkinan.	Kemungkinan (dengan memiliki pengguna PostgreSQL terpisah untuk setiap skema).	Tidak mungkin (karena tabel dibagi oleh semua penyewa).
Biaya infrastruktur	Tertinggi (karena tidak ada yang dibagikan).	Sedang.	Sedang.	Terendah.
Duplikasi data dan penggunaan penyimpanan	Agregat tertinggi di semua penyewa. (Tabel katalog sistem PostgreSQL dan data statis dan umum aplikasi diduplikasi di semua penyewa.)	Agregat tertinggi di semua penyewa. (Tabel katalog sistem PostgreSQL dan data statis dan umum aplikasi diduplikasi di semua penyewa.)	Sedang. (Data statis dan umum aplikasi dapat dalam skema umum dan diakses oleh penyewa lain.)	minimal minimal. (Tidak ada duplikasi data. Data statis dan umum aplikasi dapat dalam skema yang sama.)
Pemantauan yang berpusat pada penyewa (cari tahu penyewa mana yang menyebabkan masalah)	Upaya paling tidak tertunda. (Karena setiap penyewa dipantau secara terpisah, mudah untuk memeriksa aktivitas penyewa tertentu.)	Upaya moderat. (Karena semua penyewa berbagi sumber daya fisik yang sama, Anda harus menerapkan penyaringan tambahan untuk memeriksa aktivitas penyewa tertentu.)	Upaya moderat. (Karena semua penyewa berbagi sumber daya fisik yang sama, Anda harus menerapkan penyaringan tambahan untuk memeriksa aktivitas penyewa tertentu.)	Upaya signifikan. (Karena semua penyewa berbagi semua sumber daya, termasuk tabel, Anda harus menggunakan penangkapan variabel bind untuk memeriksa penyewa mana yang dimiliki oleh kueri SQL tertentu.)
Manajemen terpusat dan pemantauan kesehatan/aktivitas	Upaya signifikan (untuk mengatur pemantauan pusat dan pusat komando pusat).	Upaya moderat (karena semua penyewa berbagi contoh yang sama).	Upaya moderat (karena semua penyewa berbagi contoh yang sama).	Upaya minimal (karena semua penyewa berbagi sumber daya yang sama, termasuk skema).
Kemungkinan obyek identifier (OID) dan ID transaksi (XID) sampul	minimal minimal.	Tinggi. (Karena OID, XID adalah penghitung klaster PostgreSQL tunggal dan mungkin ada masalah penyedotan debu secara efektif di seluruh database fisik).	Sedang. (Karena OID, XID adalah penghitung klaster PostgreSQL tunggal).	Tinggi. (Misalnya, satu tabel dapat mencapai batas TOAST OID sebesar 4 miliar, tergantung pada jumlah out-of-line kolom.)