Как работает Multitenancy в App Engine с Objectify? - PullRequest
4 голосов
/ 07 мая 2011

Как работает мультитенантность с пространствами имен в движке приложения? В моем приложении несколько пользователей, и каждый из них похож на арендатора с несколькими арендаторами. Их URL начинается с домена / customer / companyToken # pageName? Param1 & param2. Так что из документов Google, если я хочу применить мультитенантность с пространством имен для каждого клиента вам нужно назначить уникальные идентификаторы для NamespaceManager для каждого клиента Так что-то вроде ниже:

NamespaceManager.set(request.getServerName());

Теперь у меня есть несколько вопросов.

  1. Как на самом деле работает мультитенантность с Namespace для App Engine?

  2. Как это меняет способ доступа к данным в целом?

  3. Как это меняет способ доступа к данным с помощью Objectify?

  4. Во-первых, мое понимание применения вышеуказанного к приложению состоит в том, что при извлечении данных все данные, относящиеся к вышеуказанным клиентам (арендаторам), собираются вместе в одном пространстве имен, так как способ, которым мы получаем доступ к данным, изменяется с помощью объективировать? В настоящее время компания obj является родителем всех объектов, связанных с клиентами. (Так в случае моей заявки?)

Заранее большое спасибо.

Ответы [ 2 ]

6 голосов
/ 08 мая 2011
  1. Google AppEngine не является открытым исходным кодом, поэтому только Google действительно знает, как это работает внутри. Но есть некоторые общедоступные данные о том, как внутреннее хранилище данных построено: http://www.youtube.com/watch?v=tx5gdoNpcZM. В основном все данные AppEngine находятся в одной таблице (да, одна таблица для ВСЕХ приложений AppEngine), распределенной по нескольким компьютерам. У каждого объекта есть ключ, по которому он уникально идентифицируется (идентификатор, родитель, который вы можете видеть в своем приложении), но есть также данные, которые сообщают, какому приложению принадлежит объект. Эти данные внутри AppEngine, и пользователь их не видит. Я предполагаю, что эта часть также расширена для включения данных пространства имен.

  2. Это не так. API хранилища данных поддерживает пространство имен, поэтому весь код остается неизменным. Он внутренне знает, к какому пространству имен принадлежит сущность.

  3. Objectify построен на основе низкоуровневого API хранилища данных, поэтому ответ такой же, как и у 2.

  4. Пространства имен разделяют данные: как только вы установите пространство имен, API хранилища данных будет видеть только объекты, которые были добавлены в это пространство имен.

2 голосов
/ 09 мая 2011
  1. На уровнях хранения хранилища данных пространство имен похоже на идентификатор приложения. Каждое пространство имен по существу выглядит для хранилища данных как другое представление данных приложения. Вот почему такие операции, как запрос, не могут охватывать пространства имен (по крайней мере, на данный момент). Четные диапазоны идентификаторов различаются для каждого пространства имен.

  2. Вы должны знать, какое пространство имен вы действительно используете. например После создания объекта его пространство имен не изменяется, поэтому выполнение NamespaceManager.set (...) не повлияет на его ключ. Аналогично с объектом Query. Как только запрос создан, его пространство имен установлено. То же самое с MemcacheService. Следовательно, важно знать, какие объекты имеют какие пространства имен, если вы привыкли вызывать NamespaceManager.set больше, чем с начала запроса.

  3. Трудно понять, как Obectify использует API хранилища данных, поэтому изменение текущего пространства имен несколько раз в одном запросе должно быть сделано с учетом того, как Objectify использует API хранилища данных, чтобы избежать непреднамеренного создания объектов в непреднамеренных пространствах имен.

  4. В общем, вы должны знать, когда Objectify создает низкоуровневые объекты Key, Entity и Query, и убедиться, что текущее пространство имен установлено в том пространстве имен, которое вы намереваетесь. Это просто, если в запросе всегда есть только одно пространство имен.

...