Простой пример горизонтального масштабирования VS. вертикальное масштабирование только с помощью базы данных

Рассмотрим пример такого приложения: У приложения много клиентов, у каждого клиента есть несколько пользователей.

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

Вертикальное масштабирование:

Данные клиента хранятся в нормализованной базе данных на основе SQL. {{1} } учетные данные всех пользователей хранятся в таблице client_users.

Преимущества

1. Кратчайший путь сопротивления для разработки
2. относительно легко поддерживать целостность с помощью
3. Легко создавать резервные копии

Проблема:

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

Горизонтальное масштабирование:

Каждый клиент существует в схеме таблицы с префиксом.client_users становится client01_users

Преимущества

Кто-то со средним уровнем навыков администрирования БД может написать простой сценарий для копирования таблиц client # _ * на новый сервер БД примерно за 5 минут (затем еще час на проверку / тестирование / проверку работоспособности). ). Таким образом, вы можете подтолкнуть своих клиентов с низким трафиком к серверу с избыточным количеством мест и получить прибыль от экономии на инфраструктуре, одновременно взимая с клиентов с более высоким трафиком плату за выделенное оборудование.

Проблемы

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

Резюме

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