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

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

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

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

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

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

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

Недостатки

  • Может ли MySQL справиться с 5000 базами данных? Будет ли производительность сосать?
  • Изменения в схеме могут быть трудно реплицироваться во всех базах данных. На самом деле нам действительно нужен автоматический план для этого, например, версия схемы и сценарий, который понимает, как брать базу данных из одной версии в другую.
  • Выполнение всего, что является общим для всех наших клиентов, может быть неудобным или невозможным.
  • Как и выше, но любые аналитики, которые мы хотим выполнить для всех наших клиентов, могут быть невозможны. Как мы можем отслеживать использование для всех клиентов, например?
41 голос | спросил Rik Heywood 3 FebruaryEurope/MoscowbThu, 03 Feb 2011 13:54:10 +0300000000pmThu, 03 Feb 2011 13:54:10 +030011 2011, 13:54:10

6 ответов


34

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

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

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

ответил Thomas 4 FebruaryEurope/MoscowbFri, 04 Feb 2011 06:51:18 +0300000000amFri, 04 Feb 2011 06:51:18 +030011 2011, 06:51:18
12

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

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

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

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

ответил eiefai 3 FebruaryEurope/MoscowbThu, 03 Feb 2011 20:12:34 +0300000000pmThu, 03 Feb 2011 20:12:34 +030011 2011, 20:12:34
8

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

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

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

  изменить schema.table ...
выберите ... из schema.table
 

...

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

...

Кроме того, имейте в виду, что они не используют mySQL для обмена стеками, они используют SQL Server.

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

ответил Joe 3 FebruaryEurope/MoscowbThu, 03 Feb 2011 15:25:08 +0300000000pmThu, 03 Feb 2011 15:25:08 +030011 2011, 15:25:08
5

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

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

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

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

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

MORAL OF THEORY . Масштабирование или выход не всегда является решением, если у вас плохо составленные таблицы. Я имею в виду следующее: если страницы индекса имеют однонаправленную популяцию ключевых слов для многоколоночных индексов, запрос ключей из однотипных частей индексов приводит к сканированию таблицы после сканирования таблицы или, по меньшей мере, индексов, которые никогда не будут использоваться из-за исключения из запроса MySQL Optimizer. Там просто нет никакой замены для надлежащего дизайна.

ответил RolandoMySQLDBA 11 MaramFri, 11 Mar 2011 11:24:26 +03002011-03-11T11:24:26+03:0011 2011, 11:24:26
1

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

ответил David Hall 4 FebruaryEurope/MoscowbFri, 04 Feb 2011 18:53:03 +0300000000pmFri, 04 Feb 2011 18:53:03 +030011 2011, 18:53:03
0

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

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

ответил Sean Siegel 18 FebruaryEurope/MoscowbMon, 18 Feb 2013 01:18:03 +0400000000amMon, 18 Feb 2013 01:18:03 +040013 2013, 01:18:03

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132