Блог

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

Какие преимущества / компромиссы нам следует рассмотреть? Каковы наилучшие методы реализации многопользовательского приложения в Rails?

Я исследовал то же самое и только что обнаружил, что в этой презентации предлагается интересное решение: использование схем Postgre (немного похожих на пространства имен) для разделения данных на уровне БД, сохраняя при этом всех клиентов в одной БД и оставаясь (в основном) прозрачными для rails.

Написание многопользовательских приложений в Rails — Гай Наор

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

• Весь SQL должен быть проверен и переработан, чтобы включить значение ClientID.

• Необходимо проверить все индексы, чтобы определить, нужно ли включать ClientID

• Ошибка в инструкции SQL разработчиком / системным администратором в рабочей среде повлияет на всех ваших клиентов.

• Повреждение / проблема базы данных повлияет на всех ваших клиентов

• У вас есть некоторые проблемы с конфиденциальностью данных, из-за которых плохой код / реализация могут позволить CustomerA видеть данные, принадлежащие CustomerB

• Клиент, использующий вашу систему интенсивным / агрессивным образом, может повлиять на восприятие производительности другими клиентами

• Адаптация статических данных к индивидуальным предпочтениям клиентов становится все более сложной.

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

Это действительно зависит от того, что вы делаете.

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

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

В настоящее время мы находимся на стадии бета-тестирования нашей программы, и вот некоторые вещи, с которыми мы столкнулись:

• Миграции: Предполагается, что Rails будет иметь только 1 базу данных. Вы можете адаптировать его для нескольких баз данных, и миграция — одна из них. Вам нужна пользовательская задача rake, чтобы применить миграции ко всем существующим базам данных. Будьте готовы к множеству проблем, поскольку миграция может завершиться успешно в одной базе данных, но завершиться неудачей в другой.
• Порождающие базы данных: как создать новую базу данных? Из файла SQL, копирование существующей базы данных или выполнение всех миграций? Как вы поддерживаете согласованность схемы между вашей системой создания таблиц и вашими действующими базами данных?
• Подключение к соответствующей базе данных: мы используем cookie для хранения уникального значения, которое сопоставляется с правильной базой данных. Мы используем фильтр before в авторизованном контроллере, который наследуется от ActionController, который получает базу данных из этого уникального значения и использует метод establish_connection в подклассе ActiveRecord::Base. Это позволяет нам извлекать некоторые модели из общей базы данных, а другие — из конкретной базы данных клиента.

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

У меня лично нет никакого опыта в этом, но во время выступлений lightning на Ruby Hoedown 2009 Эндрю Коулман представил плагин, который он разработал и использует для многопользовательских баз данных в rails с поддоменами. Вы можете ознакомиться со слайдами lightning talk, а вот репозиторий acts_as_restricted_subdomain.

Зачем вам это? У вас сильная агрегация между пользователями или вы создаете слишком много баз данных? Рассматривали ли вы возможность использования файлов SQLite для каждого клиента вместо общих серверов БД (поскольку многопользовательские приложения часто низкопрофильны и не требуют такого большого параллелизма)?