Pro dan kontra menggunakan banyak skema di PostgreSQL bukan hanya satu?

Untuk aplikasi SAAS besar (didukung oleh PostgreSql 9.4), dengan lebih dari 300.000 akun (dan terus bertambah), apa pro dan kontra menggunakan skema per akun untuk mempartisi data vs menempatkan semua data dalam satu skema dan menggunakan kunci asing untuk mempartisi dalam kueri?

Saya tahu di masa lalu pg_dump sangat lambat ketika bekerja dengan banyak skema tetapi tidak yakin apakah itu yang terjadi hari ini. Saya juga menyadari bahwa setiap perubahan dalam struktur database harus dilakukan pada semua skema. Dan saya tahu bahwa di sisi positifnya, memindahkan skema dari satu server fisik ke server fisik lainnya itu mudah, serta memulihkan skema dari cadangan, belum lagi masuk akal untuk mem-partisi data seperti itu.

Jadi apa pro dan kontra yang saya lewatkan?

— Harel
sumber

Tidak terlihat bagus. Tabel tunggal besar ("pertumbuhan vertikal") sulit untuk dikelola dan sejumlah besar skema ("pertumbuhan horisontal") juga sulit untuk dikelola.

— Daniel Vérité

Saya membangun kembali sistem lama yang memiliki jumlah akun di atasnya (dan bahkan lebih banyak pengguna). Itu menggunakan pendekatan bersama (menggunakan mySql) dan berfungsi dengan baik sejauh kinerja berjalan. Kekhawatiran saya adalah untuk mempertahankan tingkat kinerja itu tetapi menambahkan rawatan untuk itu.

— Harel

@ Harel Saya ingin tahu, apakah Anda mencobanya dengan skema 400k atau beralih ke arsitektur / teknologi lain?

— sthzg

Saya menyerah pada ide itu setelah melihat lebih dalam. Jumlah skema yang akan saya buat akan mengalahkan penggunaan praktis ini. Saya pergi dengan bidang id akun lama yang baik di setiap catatan. Apa yang saya lakukan juga, adalah untuk menghapus angka pertambahan otomatis dalam mendukung UUID yang berarti saya dapat mengambil seluruh akun dari satu db ke yang lain dengan mudah tanpa harus khawatir tentang melanggar integritas.

— Harel

Jelas, Anda berhadapan dengan tabel yang sama di setiap skema pengguna. Sudahkah Anda mempertimbangkan warisan untuk ini? Ini dapat memberi Anda yang terbaik dari kedua dunia untuk beberapa kasus penggunaan. Ada juga beberapa batasan . Anda dapat memiliki skema terpisah untuk setiap pengguna dan masih mencari semua tabel pengguna sekaligus dengan sangat mudah.

Terkait:

Selain itu, setidaknya pemberian / pencabutan hak istimewa harus disebutkan, yang jauh lebih sederhana dengan skema terpisah.

— Erwin Brandstetter
sumber

Saya akan melihat warisan. Namun, perhatian saya adalah pada skala di sini. Di mana-mana saya membaca orang berbicara tentang strategi skema multi-tenant tetapi mengacu pada puluhan, ratusan atau ribuan skema. Satu tempat menyebutkan skema 20 ribu. Pertanyaannya adalah - apakah skema 400K terlalu banyak? Apakah ini akan menyebabkan kegilaan deskriptor file dan membunuh server? Apakah saya mendorongnya?

— Harel

Juga, saya bermaksud untuk menyimpan data penyewa (akun dan pengguna) dalam skema publik, sambil mempertahankan skema itu sendiri sebagai data pengguna yang sebenarnya. Data itu tidak, dan tidak akan pernah, dibagikan di seluruh skema.

— Harel

Warisan tidak akan membantu saya di sini saya tidak berpikir. Pendekatan bersama menggunakan skema tunggal dengan kunci asing wajib untuk pengguna atau penyewa sehingga tidak ada yang diperoleh dari mewarisi saya khawatir.

— Harel

Dari artikel ini influitive.io/... Saya pikir mode multi-skema bukan cara yang baik untuk penyewa dalam jumlah besar. Kolom tenant_id (cara kuno) menjadi lebih baik.

— Xiaohui Zhang