Есть ли выигрыш в производительности при использовании одной базы данных или нескольких? - PullRequest
3 голосов
/ 27 октября 2011

Мы создаем программное обеспечение, которое получает предварительно рассчитанные средние значения часов около 100 элементов данных на систему, которые отправляются примерно один раз в день.Там может быть около 20 клиентов с 5-50 системами.Таким образом, теоретический максимум будет примерно 100 * 24 * 20 * 50 = 2400000 строк, вставленных в день.

Маловероятно, что в день будет столько вставок, но об этом нужно помнить.

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

enter image description here

Или

multiple databases

Обновление

Данные будут храниться в течение примерно 2-3 года, после чего система автоматически удалит старые данные.Пользователи не удаляют «что-нибудь», в этом контексте что-либо означает данные, которые отправляются из систем клиентов.

Обновление 2

На изображениях вокруг облакасервер и база данных.Точнее, это облако - реализация облачных вычислений в Microsoft Azure.

Ответы [ 4 ]

1 голос
/ 27 октября 2011

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

При этом разделение базы данных сделает администрирование (создание резервных копий, изменение структуры базы данных, обновление адресов базы данных и т. Д.) Более хлопотным и подверженным ошибкам.

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

Помните, преждевременная оптимизация - корень всего зла!

0 голосов
/ 27 октября 2011

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

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

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

Наличие отдельной инфраструктуры (аппаратного или программного обеспечения) для отдельных клиентов сразу же делает все намного более сложным - и вы должны инвестировать в тяжелую автоматизацию, чтобы справиться с этой сложностью (я рекомендую подход "непрерывной доставки" - http://continuousdelivery.com/). стоимость выходит далеко за рамки лицензий на оборудование или программное обеспечение, поэтому вы должны понести эти затраты только в том случае, если для этого есть веская причина.

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

0 голосов
/ 27 октября 2011

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

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

0 голосов
/ 27 октября 2011

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

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

  • Убедитесь, что записи только для добавления.В MySQL / InnoDB данные хранятся в порядке первичного ключа, поэтому используйте автоинкремент, чтобы избежать случайных записей.В других RDBM вы можете выбрать свой ключ кластера, поэтому выбирайте мудро
  • Если вы можете сохранить данные на одном дистрибутиве и журналы bin на другом диске - вы эффективно разделите нагрузку на 2 диска таким образом
  • Если вы можете разделить чтение и запись (репликация master / slave), то мастер будет занят только записью
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...