Бих препоръчал да потърсите информация в пощенските списъци на PostgreSQL относно многонаемния дизайн. Имаше много дискусии там и отговорът се свежда до „зависи“. Има компромиси по всякакъв начин между гарантирана изолация, производителност и поддръжка.
Често срещан подход е да се използва една база данни, но една схема (пространство от имена) на клиент с една и съща структура на таблица във всяка схема, плюс споделена или обща схема за данни, която е еднаква във всички тях. Схемата на PostgreSQL е като "база данни" на MySQL, тъй като можете да правите заявки в различни схеми, но те са изолирани по подразбиране. С клиентски данни в отделна схема можете да използвате search_path
настройка, обикновено чрез ALTER USER
customername SET search_path = 'customerschema, sharedschema' за да се гарантира, че всеки клиент вижда своите данни и само своите данни.
За допълнителна защита трябва да REVOKE
ALL FROM SCHEMA customerschema FROM public след това GRANT
ALL ON SCHEMA customerschema TO thecustomer така че те са единствените с някакъв достъп до него, като правят същото с всяка от своите маси. Тогава вашият пул от връзки може да влезе с фиксиран потребителски акаунт, който няма не GRANT ed достъп до всяка клиентска схема, но има право на SET ROLE
да стане всеки клиент. (Направете това, като им дадете членство във всяка клиентска роля с набор NOINHERIT, така че правата трябва да бъдат заявени изрично чрез SET ROLE ). Връзката трябва незабавно да SET ROLE към клиента, с който работи в момента. Това ще ви позволи да избегнете допълнителните разходи за създаване на нови връзки за всеки клиент, като същевременно поддържате силна защита срещу програмни грешки, водещи до достъп до грешни данни на клиента. Докато пулът прави DISCARD ALL
и/или RESET ROLE
преди да раздадете връзки на следващия клиент, това ще ви даде много силна изолация без разочарованието от отделните връзки на потребител.
Ако средата на вашето уеб приложение няма вграден приличен набор от връзки (да речем, че използвате PHP с постоянни връзки), тогава вие наистина трябва да поставите пул за добри връзки
така или иначе на място между Pg и уеб сървъра, защото твърде много връзки към бекенда ще навредят на ефективността ви. PgBouncer
и PgPool-II
са най-добрите опции и могат лесно да се погрижат за извършването на DISCARD ALL и RESET ROLE за вас по време на предаване на връзката.
Основният недостатък на този подход е режийната работа с поддържането на толкова много таблици, тъй като основният ви набор от несподелени таблици се клонира за всеки клиент. Ще се увеличава с нарастването на броя на клиентите, до точката, в която самият брой маси, които трябва да се изследват по време на автоматично вакуумиране, започва да става скъп и където всяка операция, която се мащабира въз основа на общия брой таблици в DB, се забавя. Това е по-голям проблем, ако мислите да имате много хиляди или десетки хиляди клиенти в една и съща база данни, но аз силно препоръчваме ви да направите някои тестове за мащабиране с този дизайн, като използвате фиктивни данни, преди да се ангажирате с него.
Идеалният подход вероятно ще бъдат единични таблици с автоматична сигурност на ниво ред, контролираща видимостта на кортежа, но за съжаление това е нещо, което PostgreSQL все още няма. Изглежда, че е на път благодарение на работата на SEPostgreSQL по добавянето на подходяща инфраструктура и API, но не е в 9.1.
