多租户如何在App Engine中使用Objectify工作?

时间:2011-05-07 16:18:24

标签: java google-app-engine multi-tenant objectify

app引擎中的命名空间多租户如何运作? 我的应用程序有多个用户,每个用户有点像多租户中的租户。 他们的URL以domain / customer / companyToken#pageName?param1& param2开头。 因此,如果我想为每个客户应用名称空间的多租户,请从Google文档中获取 您需要为每个客户分配NamespaceManager的唯一ID 如下所示:

NamespaceManager.set(request.getServerName());

现在我有几个问题。

  1. App Engine的命名空间多租户如何真正起作用?

  2. 它如何改变我们访问数据的方式?

  3. 它如何改变我们使用Objectify访问数据的方式?

  4. 首先,我对应用程序的上述应用的理解是,在检索数据时,所有与上述客户(租户)相关的数据都聚集在同一名称空间中,那么我们如何使用物化?目前公司obj作为与客户相关的所有obj的父母。 (那么在申请的情况下?)

  5. 提前非常感谢你。

2 个答案:

答案 0 :(得分:6)

  1. Google AppEngine不是开源的,所以只有Google真的知道这是如何在内部运作的。但是有一些关于如何在内部构建数据存储的公开数据:http://www.youtube.com/watch?v=tx5gdoNpcZM。基本上所有AppEngine数据都在一个表中(是所有AppEngine应用程序的一个表)分布在多台计算机上。每个实体都有唯一标识的Key(id,parent,您可以在应用中看到),但也有一个数据告诉实体属于哪个应用。此数据是AppEngine内部,用户没有看到它。我的猜测是这部分也扩展到包括命名空间数据。

  2. 没有。数据存储区API可识别名称空间,因此您所有代码都保持不变。它在内部知道实体属于哪个命名空间。

  3. Objectify建立在低级数据存储API之上,因此答案与2相同。

  4. 命名空间划分数据:一旦设置了命名空间,Datastore API将只会看到在此命名空间下添加的实体。

答案 1 :(得分:2)

  1. 在数据存储区的存储级别,命名空间就像app-id一样。每个命名空间实际上都将数据存储区视为应用程序数据的另一个视图。这就是为什么像查询这样的操作不能跨越命名空间(至少目前为止)。甚至每个命名空间的id范围也不同。

  2. 您需要了解您真正使用的命名空间。例如创建实体后,它的命名空间不会更改,因此执行NamespaceManager.set(...)将不会对其键产生任何影响。与Query对象类似。创建查询后,将设置其命名空间。与MemcacheService相同。因此,如果您处于调用NamespaceManager.set的习惯,而不是从请求的开头,那么知道哪些对象具有哪些名称空间是很重要的。

  3. 很难知道Obectify如何使用数据存储区API,因此需要在一次请求中多次更改当前命名空间,并了解Objectify如何使用数据存储区API来确保您不会无意中创建实体在非预期的命名空间中。

  4. 通常,您应该知道Objectify何时创建低级Key,Entity和Query对象,并确保将当前命名空间设置为您想要的命名空间。如果每个请求只有一个命名空间,那就很容易了。