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

Я помню из подкастов stackoverflow, что Fog Creek использует базу данных для каждого клиента для Fogbugz . Я предполагаю, что это означает, что серверы Fogbugz On Demand имеют 10 тысяч баз данных.

Мы только начинаем разрабатывать веб-приложение, и нам предстоит решить аналогичную проблему (множество клиентов со своими изолированными данными).

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

Мои первоначальные мысли

Преимущества базы данных для каждого клиента

• Упрощенная схема базы данных
• Упрощенное резервное копирование - вы можете создавать резервные копии каждого клиента по очереди, не оказывая реального влияния на других клиентов.
• Упрощает экспорт данных о клиентах.
• Лучшая производительность кэша - запись в одну из более активных таблиц влияет только на одного клиента, который выполнил запись.
• Проще масштабировать по аппаратному обеспечению. Например, когда нам нужно перейти с 1 на 2 сервера, мы просто перемещаем половину наших клиентов на новый сервер.

Недостатки

• Может ли MySQL справиться с 5000 базами данных? Будет ли производительность отстой?
• Изменения в схеме могут быть трудно воспроизвести во всех базах данных. Нам действительно нужно иметь автоматизированный план для этого, такой как создание версий схемы и сценария, который понимает, как переносить базу данных из одной версии в другую.
• Делать что-либо общее для всех наших клиентов может быть неудобно или невозможно
• Как и выше, но любая аналитика, которую мы хотим выполнить для всех наших клиентов, может оказаться невозможной. Как мы должны отслеживать использование для всех клиентов, например?

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

1. С одной базой данных все должны быть в одной версии, несмотря ни на что. Невозможно обновить некоторых клиентов, а не других. Это может быть проблематично, если клиенту требуется исправление приложения, которое не готово к широкому выпуску.
2. С одной базой данных, когда вы делаете обновление, каждый клиент не работает. Если что-то идет не так, каждый клиент облажался.
3. С одной базой данных намного сложнее ограничить ресурсы. То есть, если один клиент работает с базой данных, труднее выделить ему больше ресурсов отдельно от всех остальных.
4. Гораздо сложнее позволить пользователям размещать собственные версии вашего приложения. Если вы создаете решение, которое будет использоваться крупными предприятиями, это часто не является началом. Их ИТ-отдел хочет получить полный контроль над доступом к системе.
5. Вероятно, дешевле масштабировать базы данных, чем масштабировать их. То есть необходимость инвестировать в более быстрое аппаратное обеспечение для размещения одной базы данных, чтобы управлять ими всеми, вероятно, дороже, чем возможность масштабирования клиентов на более мелкие и менее дорогие серверы баз данных. Я не могу сказать это однозначно, потому что это сильно зависит от серверного программного обеспечения. Если вы придерживаетесь MySQL, это, вероятно, верно, потому что затраты на лицензирование незначительны. Однако, если вы перейдете, например, на SQL Server, масштабирование станет намного более дорогим, если вы не используете среду VPS и не получаете экономическую выгоду от масштабирования против масштабирования изменений. Однако я могу сказать, что, как только ваша база данных становится очень большой, управление требует все более высокого уровня знаний. Очень большие базы данных требуют игры с несколькими файловыми группами и перемещения определенных индексов на разные шпиндели для повышения производительности. Короче говоря, они могут усложниться очень быстро.

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

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

В прошлом году я работал с 70 базами данных (намного меньше 5000), каждая с одинаковой схемой и все. Теоретически, все пойдет по плану (как вы упомянули в разделе преимуществ), но на самом деле не так много. У нас было много проблем с обновлением схем, поддержкой пользователей, обновлением программного обеспечения, вы называете это. Это было ужасно.

Мы использовали Firebird, и я был нанят после того, как продукт был отправлен, но это дало мне возможность никогда не работать с отдельными базами данных.

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

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

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

Поскольку «базы данных» mysql - это просто схемы, как указал Гай, если все они запускаются с одного экземпляра сервера, вы можете просто указать имя таблиц, которые вы пытаетесь изменить, или получить информацию из:

alter schema.table ...
select ... from schema.table

...

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

...

Также имейте в виду, что они не используют MySQL для обмена стека, они используют SQL Server.

И я понятия не имею, какие потери производительности будут в MySQL в таком масштабе, я не думаю, что я когда-либо получал более 30 «баз данных» в MySQL.

У меня есть клиент Web / DB Hosting, который имеет более 750 клиентских баз данных с таким же количеством таблиц (162) и одинаковыми структурами таблиц. В совокупности все данные клиента моего клиента составляют 524 ГБ (95% InnoDB)

Представьте себе, что все эти базы данных конкурируют за 13 ГБ пула буферов innodb на девяти серверах БД с помощью циклической репликации. Масштабирование с этой аппаратной конфигурацией было недостаточно. Сразу же мы порекомендовали клиенту увеличить масштаб.

Недавно мы перенесли этот клиент на 3 сервера БД с гораздо большей мощностью (ВСЕГДА избегайте SSD в средах с высокой записью, ВСЕГДА !!!). Мы обновили их с MySQL 5.0.90 до MySQL 5.5.9. Драматические различия были замечены почти мгновенно.

Следует также учитывать масштабирование, поскольку, если сотни клиентов используют один и тот же объем памяти и дисковые ресурсы, масштабирование линейно сокращает их использование (O (n)), где n основано на количестве серверов БД в среде с несколькими хозяевами.

В случае с моим клиентом моя компания сокращает его с 9 серверов БД (Quad Code, 32 ГБ ОЗУ, 824G RAID10) до более быстрых серверов БД (Dual HexaCore [это правильно, 12 ЦП], 192 ГБ ОЗУ, 1,7 ТБ RAID10) MySQL 5.5 .9 (для таблицы использовать преимущества нескольких процессоров). Кроме того, представьте себе пул буферов innodb объемом 150 ГБ в 50 разделах по 3 ГБ каждый (несколько буферных пулов InnoDB - это новая функция в MySQL 5.5). Меньшее масштабирование, но огромное увеличение работало на уникальную инфраструктуру моего клиента.

МОРАЛЬ ИСТОРИИ : Увеличение или уменьшение масштаба не всегда является решением, если у вас плохо спроектированные таблицы. Я имею в виду следующее: если на страницах индекса имеется однонаправленное заполнение ключей для многоколоночных индексов, запрос ключей из односторонних частей индексов приводит к сканированию таблицы после сканирования таблицы или, по крайней мере, к индексам, которые никогда не используются из-за исключения MySQL Query Optimizer. Там просто не может заменить правильный дизайн.

MySQL создает базы данных в отдельных каталогах, поэтому многое зависит от операционной системы и количества обработчиков папок / файлов, которые он может обрабатывать. Не должно быть проблем с современными операционными системами, но вот откуда появятся многие узкие места.

Ничто не говорит о том, что вы должны размещать разные версии базы данных или приложения. Что плохого в том, что вы просто изолируете данные, делая по одной базе данных на клиента и имея одну версию базы данных и приложения? Конечно, каждый клиентский БД должен быть клонирован из шаблона текущей рабочей версии. С точки зрения безопасности и изоляции данных, я думаю, что это идеально.

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