Производителността не е по-лоша, непременно. Както се обяснява в статията, има специфични условия, които правят подхода на схемата по-добър или по-лош в зависимост от дизайна на вашето приложение и натоварването. Позволете ми да обясня компромисите на подходите „схема на наемател“ срещу подходи „споделена таблица“:
схема-наемател е най-добре, когато имате сравнително малък брой сравнително големи наематели. Пример за това би било счетоводно приложение само с потребители с платен абонамент. Нещата, които го правят по-ефективната опция за вас, включват:
- малък брой наематели с много данни всеки
- сравнително проста схема без много таблици на клиент
- необходимост от персонализиране на схемите на някои наематели
- възможност за използване на роли на база данни за всеки клиент
- изискване за мигриране на данни на наемател от един сървър на друг
- възможност да завъртите специален сървър за приложения във вашия облак за всеки наемател
Нещата, които го правят вариант с лоша производителност, включват:
- много наематели с много малко данни всеки
- подход без състояние към връзки, където всяка заявка може да бъде всеки наемател
- клиентска библиотека или система, която кешира метаданни за всички таблици (като ActiveRecord)
- изискване за ефективно, високопроизводително групиране на връзки и/или кеширане
- проблеми с VACUUM и други административни операции на PostgreSQL, които се мащабират лошо в 1000 таблици.
Дали tenant-schema е лоша за миграции/промени в схема наистина зависи от това как ги правите. Лошо е бързото внедряване на универсална промяна на схемата, но е добро за внедряване на промени в схемата като постепенно внедряване сред клиентите.
споделена маса работи по-добре в ситуации, когато имате много наематели и много от вашите наематели имат много малко данни. Пример за това би било мобилно приложение за социални медии, което позволява безплатни акаунти и следователно има хиляди изоставени акаунти. Други неща, които правят модела на споделена таблица полезен са:
- по-добре за пулиране на връзки, тъй като всички връзки могат да използват един и същ пул
- по-добро за администриране на PostgreSQL, поради общо по-малкото таблици
- по-добре за миграции и промени в схеми, тъй като има само един „набор“ от таблици
Основният недостатък на споделената таблица е необходимостта от добавяне на условието за филтър на клиента към всяка отделна заявка в приложния слой. Също така е проблематично, защото:
- заявките, които се присъединяват към много таблици, може да се представят лошо, защото филтърът на клиента пречи на планирането на заявките
- таблици, които нарастват до 100 милиона редове, могат да причинят специфични проблеми с производителността и поддръжката
- няма начин за извършване на специфични за клиента промени в приложението или надграждане на схема
- по-скъпо мигриране на наематели между сървъри
Така че кой модел „се представя по-добре“ наистина зависи от това кои компромиси ви вредят най-много.
Съществува и хибриден модел, „tenant-view“, където действителните данни се съхраняват в споделени таблици, но всяка връзка на приложение използва изгледи на защитна бариера за преглед на данните. Това има някои от компромисите на всеки модел. На първо място, той има предимствата на сигурността на модела на схемата на клиента с някои от недостатъците на производителността и на двата модела.
