Rails multitenant architecture, обзор доступа к нескольким арендаторам

Question

У нас есть архитектура базы данных с одним арендатором на данный момент, когда MySQL работает с 100 базами данных. Мы переключаем соединение с базой данных на субдомен, используя драгоценный камень Apartment, и все это денди!

Однако у нас есть требование создать так называемые клиенты «Umbrella», которые могут получить доступ ко всем данным от группы наших существующих клиентов. Я не вижу в этом возможности сразу с нашей архитектурой базы данных с одним арендатором (я просмотрел ее, и запросы к нескольким базам данных MySQL просто казались адскими), поэтому я начинаю рассматривать различные реализации с помощью схем Postgres.

Я ищу несколько советов:

• можно ли запросить несколько схем в Postgres и сверить результаты каким-то образом (ищет реализации Rails)? Я могу предвидеть проблемы с конфликтующими первичными ключами?

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

• Если да, может ли быть что-то подобное достигнуто в моей текущей базе данных DB с MySQL? (Для уменьшения боли)

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

Answer 1

просто продумывая это на подходе высокого уровня к этой проблеме.

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

Тогда вы, надеюсь, достаточно уникальных полей в таблицы для создания составного или составного ключа. (Тогда вам не нужно было бы создавать новый ключевой столбец, просто индекс). Поскольку Rails 3 является агностиком ORM, вы можете использовать DataMapper (или, возможно, новый ROM-жемчуг), чтобы установить соединение для этой модели.

Если вы делаете сложные клавиши, понимаете, что вам может потребоваться явно определить метод * to_param * в вашей модели, чтобы построить ключ в виде строки. Это для разворачивания: id, когда вы отправляете его в URL-адресе.

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

Другой вариант заключается в том, что, возможно, вы могли бы использовать Mongo в качестве «временной базы данных запросов». BSON автоматически предоставит вам уникальные ключи. И вы можете создавать объекты, которые по существу являются объектами SQL Scalar. Не уверен, что вы захотите сделать запись в исходную базу данных в этом случае, хотя ... но вы, возможно, сможете это сделать.

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

Сказав все это ... это также похоже на процессный запах. Если я правильно прочитал проблему, я думаю, что то, что вы действительно пытаетесь сделать в этом случае, - это то, что Hadoop предназначено для ... по существу карты/сокращения релевантных данных (aka Big Data Analysis)

Удачи !

Answer 2

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

В частности, я имею в виду MongoDB, который использует «схему», базу данных базы данных. Это позволит вам извлекать данные из вашей базы данных на основе ключа и сортировать его в программном обеспечении. MongoDB также поддерживает очертание, которое позволяет вам использовать одну базу данных на столько серверов баз данных, сколько захотите, что звучит так, как будто это может хорошо работать в вашем приложении. Возможно, стоит проверить документы на http://www.mongodb.org/. Я не уверен, что это будет идеально подходит, но похоже, что это может сработать для вашего приложения.

Answer 3

OBS: Я не парень из Ruby, поэтому я могу дать вам только сторону PG идеи.

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

SET search_path TO client1; 

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

SELECT ... FROM customer ...; 

И, когда вам нужно запросить для другого арендатора (не в search_path) вы можете запросить таблицу со схемой:

SELECT ... FROM client2.customer ...; 

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

SET search_path TO client1, public; 

Answer 4

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

Я начал с 'Multitenancy с прицелы' railscast

http://railscasts.com/episodes/388-multitenancy-with-scopes

затем посмотрел на то, чтобы Multitenancy работу с DEViSE субдоменов, используя это руководство:

https://github.com/plataformatec/devise/wiki/How-To:--Isolate-users-to-log-into-a-single-subdomain

Но я Бесполезный не принимайте это по номиналу; Я встал, чтобы понять, как это работает.

После того, как у меня было все, что на месте, я был готов к драгоценным камнем Многоквартирный:

https://github.com/wireframe/multitenant

Но я не останавливаться на достигнутом. драгоценный камень требует Многоквартирного что вы говорите Multitenant.with_tenant всякий раз, когда вы хотите вещей, область действия appropriatey, поэтому я создал TenantController, который выглядит примерно так:

around_filter :scope_current_tenant 

    def scope_current_tenant 
    begin 
     Firm.current = Firm.find_by_subdomain!(request.subdomain) 
    rescue 
     raise ActionController::RoutingError.new('Not Found') 
    end 

    Multitenant.with_tenant Firm.current do 
     yield 
    end 

    ensure 
     Firm.current = nil 
    end 
    end 

, а затем любой контроллер я хочу быть ограничен арендатор наследует TenantController, а не ApplicationController. Таким образом, мне не нужно было ничего запоминать в деталях контроллера, он просто работал ». единственное, о чем разработчики должны были подумать: «Это контроллер, который обрабатывает данные арендатора?»

Хотя это все еще зависит от разработчиков делать несколько вещей правильно (наследуемых от правого регулятора, говоря «acts_as_multitenant» в модели, она работает очень хорошо на практике.