Должен ли я использовать одну или несколько настроек базы данных для многоклиентского приложения?

Question

Я работаю над PHP-приложением, которое намерено облегчить рабочий процесс и управление проектами, скажем, что-то вроде Basecamp и GoPlan.

Я не уверен, что лучший подход, основанный на базе данных. Должен ли я использовать единую базу данных и добавлять столбцы для конкретных клиентов в каждую из таблиц или создавать базу данных для каждого нового клиента? Важным фактором является автоматизация: я хочу, чтобы было мертво просто создать нового клиента (и, возможно, открыть возможность зарегистрироваться для себя).

Возможные минусы я могу думать, используя одну базу данных:

• Отсутствие расширяемости
• проблем безопасности (хотя ошибки там не должно быть, в первую очередь)

Что Ваши мысли об этом? Есть ли у вас какие-либо идеи о том, какое решение выбрали вышеперечисленные компании?

Answer 1

Обычно я добавляю ClientID ко всем таблицам и перехожу с одной базой данных. Но поскольку базы данных обычно трудно масштабировать, я также позволю работать в разных экземплярах базы данных для некоторых или всех клиентов.

Таким образом, у вас может быть множество маленьких клиентов в одной базе данных и большие на отдельных серверах.

Ключевым фактором обеспечения ремонтопригодности является то, что вы храните схему одинаковой во всех базах данных. Будет достаточно головной боли для управления версиями без введения специфических для клиента схем.

Answer 2

Для Multitenancy, производительность, как правило, увеличивают больше ресурсов вам удастся разделить по арендаторам, см

http://en.wikipedia.org/wiki/Multitenancy

Так что, если вы можете, пойти с единой базой данных. Я согласен с тем, что проблемы с безопасностью будут возникать только из-за ошибок, так как вы можете реализовать весь контроль доступа в приложении. В некоторых базах данных вы все равно можете использовать управление доступом к базе данных, тщательно используя представления (чтобы каждый аутентифицированный пользователь получал другое представление).

Существуют также способы обеспечения расширяемости. Например, вы можете создать единую таблицу с атрибутами расширения (с ключом по идентификатору, базовой записи и идентификатору атрибута расширения). Или вы можете создавать таблицы расширения для арендаторов, чтобы каждый арендатор имел свою собственную схему расширения.

Answer 3

На мой взгляд, это будет зависеть от вашей вероятной клиентской базы. Если бы вы могли попасть в ситуацию, когда арки-соперники используют вашу систему, то вам будет лучше с отдельными базами данных. Это также зависит от того, как ваши базы данных реализуются несколькими базами данных. Если каждая база данных имеет отдельную копию инфраструктуры, то это предполагает наличие единой базы данных (или смены СУБД). Если несколько баз данных могут обслуживаться одной копией инфраструктуры, я бы пошел на отдельные базы данных.

Подумайте о резервном копировании базы данных. Клиент А говорит: «Пожалуйста, пришлите мне копию моих данных». Гораздо проще в отдельной настройке базы данных, чем при совместном использовании одной базы данных. Подумайте об удалении клиента; опять же, намного проще с отдельными базами данных.

(The «инфраструктура» часть Слащавая, потому что существует значительные различия между различным СУБД о том, что представляет собой «базу данных» по сравнению с «экземпляром сервера», например Добавить:. Вопрос с тегами «MySQL» , так что, может быть, эти мысли не совсем уместно)

Добавить:. еще одна проблема - с несколькими клиентами в одной базе данных, каждый SQL-запрос будет необходимо убедиться, что данные для правильного заказчика выбран. Это означает, что SQL будет сложнее писать и читать, и СУБД будет вынуждена больше работать над обработкой данных, а индексы будут больше, и ... Я действительно поеду с отдельной базой данных на каждый клиент для многих целей.

Очевидно, что StackOverflow (в качестве примера) не имеет отдельной базы данных для каждого пользователя; мы все используем одну и ту же базу данных. Но если вы ведете учетные системы для разных компаний, я не думаю, что было бы приемлемо (для компаний и, возможно, не для юридических лиц) делиться базами данных.

Answer 4

Слушайте подкаст Stackoverflow, где Джоэл и Джефф рассказывают об одном и том же вопросе. Джоэл говорит об их опыте, предлагающем размещенную версию своего программного обеспечения. Он указывает, что добавление идентификаторов клиентов по всей вашей БД усложняет дизайн и код (вы уверены, что не случайно не забыли добавить его в какое-либо предложение WHERE?) И усложняет функцию хостинга, такую ​​как резервные копии для конкретного клиента.

Это было в эпизоде ​​№ 20 или № 21 (подробнее см. Стенограммы).

Answer 5

Еще один момент, который следует учитывать, заключается в том, что у вас может быть юридическое обязательство хранить данные одной компании отдельно от других.

Answer 6

Наличие базы данных на одного клиента обычно не очень хорошо масштабируется. MySQL (и, возможно, другие базы данных) содержит ресурсы, открытые для каждой таблицы, это не позволяет хорошо подходить к 10k + таблицам на одном экземпляре, что может произойти в ситуации крупномасштабной многопользовательской ситуации.

Конечно, если у вас есть еще одна проблема, которая вызывает другие проблемы до того, как вы доберетесь до этого уровня, это может быть нецелесообразно.

Кроме того, «ошпаривание» приложения с несколькими арендаторами, скорее всего, будет правильным, поскольку в конечном итоге ваше приложение станет больше и больше.

Sharding, однако, не означает одну базу данных (или экземпляр) для каждого арендатора, но по одному на осколок или множество осколков, которые могут иметь несколько арендаторов каждый. Вам нужно будет найти правильные параметры настройки для себя, возможно, в производстве (отсюда, вероятно, это должно быть довольно перестраиваемо с самого начала)

€ Я не могу этого гарантировать.

Answer 7

Вы можете начать с единой базы данных и разбить ее по мере того, как приложение растет. Если вы это сделаете, я бы рекомендовал несколько вещей:

1) Создайте базу данных так, чтобы ее можно было легко разделить. Например, если клиенты собираются обмениваться данными, убедитесь, что данные легко реплицируются в каждой базе данных.

2) Если у вас есть только одна база данных, убедитесь, что она копируется на другой физический сервер. В случае отказоустойчивости вы можете вернуть трафик на этот другой сервер и по-прежнему иметь ваши данные в целости.

Answer 8

• РАЗВИТИЯ Для быстрого развития, использовать базу данных для каждого клиента. Подумайте, как легко будет выполнять резервное копирование, восстановление или удаление данных клиента. Или для измерения/мониторинга/использования счета. Вам не нужно будет писать код, чтобы сделать это самостоятельно, просто используйте примитивы базы данных.

• PERFORMANCE Для обеспечения эффективности используйте базу данных для всех. Подумайте о том, пулы соединений, разделяемой памяти, кэширование и т.д.

• БИЗНЕС Если ваш бизнес-план должен иметь много мелких клиентов (думаю, Hotmail), вы должны, вероятно, работать на одной БД. И все административные задачи, такие как регистрация, удаление, миграция данных и т. Д., Полностью автоматизированы и доступны в дружественном интерфейсе. Если вы планируете иметь десятки или до нескольких сотен крупных клиентов, вы можете работать в одной БД на каждого клиента и иметь сценарии администрирования системы, которые могут обслуживаться вашим персоналом службы поддержки.

Answer 9

screencast объясняет, как это делается на salesforce.com. Они используют одну базу данных со специальным столбцом OrgId, который идентифицирует данные каждого арендатора. Там гораздо больше, поэтому вы должны изучить это. Я бы пошел с ними.

Есть еще один отличный article об этом на MSDN. Он подробно объясняет, когда вы должны использовать общий или изолированный подход. Помните, что наличие общей БД для всех ваших арендаторов имеет некоторые важные последствия для безопасности, и если все они используют одни и те же объекты БД, вы можете использовать [безопасность на уровне строк] - в зависимости от используемой СУБД (я уверен, что это возможно в MS SQL Server и Oracle, возможно, также в IBM DB2). Вы можете использовать трюки, такие как row level security in mySQL, для достижения аналогичных результатов (просмотров + триггеров).

Answer 10

Когда вы разрабатываете базы данных в многопользовательских, вы, как правило, три варианта:

1. У одной базы данных для каждого арендатора
2. имеют одну схему для каждого арендатора
3. У всех жильцов одни и те же таблицы (ы)

Вариант, который вы выбираете, имеет последствия для масштабируемости, расширяемости и изоляции. Эти последствия широко обсуждались в разных статьях StackOverflow questions и в базе данных.

На практике каждый из трех вариантов дизайна - с достаточным усилием - может решать вопросы вокруг масштаба, данные, которые различаются между арендаторами и изоляция. Решение зависит от основного измерения, для которого вы строите. Резюме:

• Если вы строите для масштаба: У всех жильцов одни и те же таблицы (ы)
• Если вы строите для изоляции: Создание одной базы данных для каждого арендатора

Для Например, Google и Salesforce следуют первому шаблону, и их арендаторы используют одни и те же таблицы. С другой стороны, Stackoverflow следует второму шаблону и сохраняет одну базу данных для каждого арендатора.Второй подход также более распространен в регулируемых отраслях, таких как здравоохранение.

Решение сводится к основному измерению, которое вы оптимизируете для своей базы данных. This article on designing your SaaS database for scale рассказывает о компромиссах и дает резюме в контексте PostgreSQL.