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


49

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

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

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

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

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

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

Недостатки

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

2
Помните, что «база данных» означает разные вещи для разных людей. В мире Oracle, база данных на пользователя была бы огромным излишним. Но в MySQL «база данных» является синонимом «схемы».
Гай

Я имею в виду это в смысле MySQL. USE CompanyData;
Рик Хейвуд

1
У Microsoft есть подробная статья о мультитенантной архитектуре данных .
Ник Чаммас

я бы не сказал, что создание версий схемы является недостатком ... больше работы, но в целом лучше
Нил МакГиган,

Ответы:


41

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

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

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


2
Я запускаю веб-сервисы как с общей базой данных, так и с несколькими арендаторами отдельных баз данных. Есть времена, когда оба являются правильным выбором. В приложении, где у меня есть отдельная база данных для каждого клиента, я столкнулся с теми же 5 причинами, по которым он был правильным выбором для этого приложения.
Дэн Гроссман

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

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

14

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

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

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

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


Мы внедрили базу данных с несколькими списками, которая обслуживает нескольких клиентов. Мы оказались в ситуации, когда клиенты захотели получить индивидуальные результаты. Чтобы решить эту проблему, мы клонировали хранимые процессы и дали им уникальные префиксы имен клиентов, а затем вызвали их из приложения. С другой стороны, мы продали 150 интернет-магазинов в каждом с отдельной базой данных (97% одинаково). Так что и то и другое можно сделать, это зависит от ситуации.
Майкл Райли - AKA Gunny

Приятно. Я не говорю, что это невозможно, просто это не так просто, как кажется, хорошо для тебя, Ганни.
Eiefai

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

9

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

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

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

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

...

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

...

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

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


Почему бы не сохранить таблицу информации о версии в самой вашей БД?
Борис Калленс

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

7

У меня есть клиент 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. Там просто не может заменить правильный дизайн.


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

4
@EdCottrell Я предполагаю, что это было предупреждением об ограниченных записях твердотельных накопителей. В какой-то момент это приводит к тому, что диск больше не может использоваться, я считаю, что в последние несколько лет TRIM и другие технологии были встроены в микросхемы контроллера SSD, чтобы по большей части устранить эти проблемы, поэтому запись на SSD не такая большая проблема, хотя я уверен, что это все еще может быть проблемой.
Шонхусейн

2

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


1

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.