Jumlah maksimum database untuk instance tunggal PostgreSQL 9

9

Mengembangkan aplikasi multi-pelanggan kami berencana untuk menggunakan database yang berbeda untuk setiap pelanggan. Tetapi bisa jadi lebih dari 1000 pelanggan (aplikasi).

Akankah PostgreSQL menanganinya tanpa masalah?

Adakah yang mencoba sesuatu yang serupa?

Catatan: 35 tabel untuk masing-masing, dengan hingga 3000 catatan sebagai rata-rata, untuk setiap database.

postgresql postgresql-9.1

— Juanin
sumber

5

Saya belum mencobanya sendiri, tetapi ada orang lain di sekitar yang pernah mencobanya. Di sini Anda dapat melihat bahwa bahkan 10.000 database berjalan tanpa masalah pada satu contoh. Anda bahkan dapat menemukan beberapa aspek praktis pada ServerFault juga.

Karena basis data Anda sangat kecil, Anda tidak akan mengalami pembatasan nomor file apa pun dari OS host. Satu-satunya masalah yang dapat saya pikirkan adalah bahwa ketika semua database ini akan diakses secara bersamaan, menangani semua koneksi itu akan rumit.

Dan, sebagai catatan terakhir: Anda sangat disambut di situs ini. Kami harap Anda akan tetap bersama kami untuk waktu yang lama.

— dezso
sumber

Terima kasih atas komentar anda Ya, koneksi bersamaan bisa menjadi sakit kepala, tetapi opsi lainnya adalah tabel bersama untuk setiap aplikasi, luar biasa lebih kompleks (perlu pemrograman ulang untuk aplikasi).

— Juanin

2

Kedengarannya seperti berantakan dari sudut pandang manajemen. Hanya bagaimana Anda berencana untuk membuat cadangan banyak database? dengan script yang masing-masing loop?

Kecuali Anda memiliki alasan yang sangat bagus, mengapa tidak hanya memiliki satu basis data di mana strukturnya dirancang sehingga semua data akan ditautkan kembali ke ID pelanggan. Tambahkan Indeks / Kunci Asing / Kunci Utama berdasarkan bidang ini yang akan memastikan integritas data.

Maka Anda hanya perlu memiliki klausa di mana dalam semua pertanyaan Anda untuk mengakses hanya satu ID pelanggan. Ini akan jauh lebih mudah untuk dipelihara dan sama mudah untuk dikembangkan (karena dalam kasus apa pun Anda perlu untuk memungkinkan identifikasi pelanggan)

— adam f
sumber

1

Ini adalah poin yang sangat bagus dan valid. Mungkin OP harus berpikir tentang menggunakan skema, dan hanya memiliki beberapa tabel dalam skema publik, tersedia untuk BERGABUNG dengan tabel dalam skema pelanggan pribadi.

— François Beausoleil

Terima kasih, tetapi opsi ini dibuang dari awal. Ini adalah port dari aplikasi yang sudah dikembangkan, dan ubah SEMUA kode yang tidak sepele pada tahap ini. Tapi ya, manajemen harian untuk lebih dari 100 basis data akan ... menarik ... bukan?

— Juanin

1

Beralih dari database terpisah ke skema terpisah seharusnya tidak menyiratkan perubahan signifikan dalam kode. Khususnya Anda tidak perlu membuat awalan objek dengan skema mereka karena search_pathmelakukannya untuk Anda.

— Daniel Vérité

Pengarsipan Wal untuk cadangan akan masuk akal di sini.

— Jharwood

0

Ada orang yang melakukan ini, terutama untuk hosting server bersama.

Memikirkan masalah di sini tidak ada makan siang gratis. Anda mungkin dapat melakukannya dengan skema dengan cara yang transparan. Namun kemudian Anda mendapatkan ribuan skema dan puluhan ribu tabel, yang akan menimbulkan masalah tambahan.

Saya pikir secara keseluruhan, pendekatan multiple db paling bagus diberikan komentar Anda.

Manajemen (seperti cadangan) akan menjadi menarik. Juga saya akan berpikir bahwa pada titik tertentu koneksi ke db akan mulai memakan waktu lebih lama. Jika Anda menggunakan pg_hba.conf untuk membatasi akses (yang harus Anda lakukan) yang akan menjadi sakit kepala juga dan Anda mungkin ingin membangun solusi untuk menghasilkan file itu untuk Anda .....

— Chris Travers
sumber

Saya tidak bisa melihat masalah dengan pg_hba.conf. Aplikasi kami menggunakan Ruby on Rails dan itu mengubah koneksi untuk database yang berbeda, tetapi dalam kotak linux yang sama sepanjang waktu. berbicara tentang masalah konkurensi mengakses file?

— Juanin

1

Tidak, hanya jika Anda ingin mengelola dbs mana yang dapat diakses oleh host mana, itu akan menjadi file yang panjang dan manajemen mungkin menjadi sedikit mengganggu.

— Chris Travers

0

Saya harap tautan ini lebih baik dibaca: 10.000 basis data pada kluster PostgreSQL oleh Jon Jensen, 2008.

Satu kutipan:

Jawaban singkatnya: Postgres 8.1 menangani 10.000 basis data dengan baik. \l di psql menghasilkan daftar panjang database, tentu saja, tetapi kembali dengan cukup cepat. Pengujian konkurensi ad-hoc baik-baik saja. Menjalankan kueri, menyisipkan, dll. Pada kelompok yang dipilih sendiri dari berbagai database play berfungsi dengan baik, termasuk saat database baru sedang dibuat.

[...]

Batas aktual pada platform [ Linux ext3 ] ini mungkin adalah 31995 basis data, karena setiap basis data menempati subdirektori dalam data / basis / dan sistem file ext3 memiliki batas 31.998 sub-direktori per satu direktori, yang berasal dari batas 32.000 tautan per inode.

— pengguna117336
sumber

1

Jawaban yang hanya berisi tautan tidak terlalu berguna, karena tautan cenderung basi seiring waktu. Harap pertimbangkan untuk menambahkan ringkasan apa pun yang Anda tautkan dalam jawaban Anda.

— mustaccio