На нижнем уровне, это в основном сводится к "вы можете абсолютно сказать, что у вас нет общих данных?" В отличие от mysql, база данных является абсолютной границей в postgresql. Вы не можете, SELECT zip_code FROM common.city_zip WHERE city=...если вы идете с отдельными базами данных (по крайней мере, не без dblink).
Если у вас есть какие-либо общие данные, «схема» postgresql похожа на то, что mysql называет «базой данных» . Вы можете CREATE SCHEMA clienta; CREATE TABLE clienta.customer (...);. Вы бы создать схему для каждого клиента, что пользователь клиента будет иметь свою схему первый в своем пути поиска и разрешения будут предоставляться таким образом , чтобы пользователь - клиент А был бы иметь доступ к clientaи publicсхемам (и их таблица).
Ваша проблема заключается в том, что на верхнем уровне # клиентов каждая таблица хранится в виде файла, поэтому независимо от того, используете ли вы одну базу данных для каждого клиента, одну схему для каждого клиента или используете что-то вроде ${client}_customerимен таблиц, вы будете Скорее всего, вы столкнетесь с ограничениями файловых дескрипторов для 10 000 клиентов, даже если у вас была только одна таблица на клиента (плюс один файловый дескриптор на соединение). Конечно, вы можете настроить максимальное количество файловых дескрипторов ядра на лету, используя sysctl, но ограничение для каждого процесса (ulimit) потребует перезапуска postgresql, если вы установите его слишком низким в первый раз.
Альтернатива состоит в том, чтобы иметь «одну большую таблицу» со столбцом клиента, который идентифицирует, к какому клиенту принадлежит эта строка (в идеале, по имени пользователя, если у вас есть один пользователь на клиента, это облегчает работу под много) Не предоставляя клиентам никакого доступа к этой таблице, вы можете создавать клиентские представления (или использовать session_userдля идентификации текущего клиента). Обновления не могут быть сделаны непосредственно через представление, все же. Вам необходимо иметь определенные функции для вставки / обновления / удаления в таблице (один набор функций на клиента или другое использование session_user) с функциями, используемыми SECURITY DEFINERдля выполнения в качестве специального пользователя с разрешением вставлять / обновлять / удалять таблицы (примечание : session_userиспользуется потому что userиcurrent_user основаны на текущем контексте, и внутри функции SECURITY DEFINER это всегда будет пользователь, который определил функцию).
С точки зрения производительности, помимо проблемы fd, я, честно говоря, не знаю, что произойдет с 10000 базами данных в postgresql, в отличие от одной большой таблицы с данными на 10000 клиентов. Правильный дизайн индекса не должен допускать медленной обработки большой таблицы.
Я скажу, что здесь я использовал отдельные базы данных для каждого клиента (мы добавляем серверы, чтобы поддерживать работоспособность системы, перемещая клиентские базы данных на новые серверы по мере необходимости, поэтому мы никогда не доберемся до 10 тысяч баз данных на одном сервере). Мне приходилось восстанавливать данные отдельных клиентов из резервных копий для отладки или из-за ошибок пользователя на регулярной основе, что было бы абсолютным кошмаром при проектировании «одной большой таблицы». Кроме того, если вы намереваетесь продавать индивидуальную настройку вашего продукта своим клиентам, дизайн «одной большой таблицы» может в конечном итоге затруднить вам возможность настройки модели данных.