Question

是否有任何东西（云JSON数据存储产品，支持移动应用程序）在纯模式下具有与GCP Firestore一样的性能和丰富的功能，但提供了名称空间？

由于软件开发周期的性质，多种环境需求（开发，测试，产品），在纯模式下缺少Firestore的预期功能（或与此相关的任何数据库）在所有方面都是杀手kill ），持续的部署和交付管道，使用名称空间的JSON数据模型等等。

如果没有，那么在您的大型Firestore项目上，您正在做什么以创建人们可以工作的开发，测试，集成环境或区域，或支持生产中单独运行的相关应用程序，每个应用程序都需要自己的命名空间，或定义的集合集，而不必为每个项目创建和管理庞大的项目，Firestore本机实例和服务帐户（每个项目/ Firestore实例都需要创建服务帐户.json文件，分发给开发人员，安全地存储），每个其他实例都会增加和的管理开销，而不必在GCP数据存储区模式下运行Firestore，在这种模式下，您将失去所有优势，功能和主要卖点，导致您选择Firestore首先支持您的应用程序？

可选读物：背景/上下文：

我最近加入了一个新项目，被要求为构成整个服务的各种服务（独立运行的程序）创建JSON数据模型，还为多个运行时环境（例如'dev1'，'dev2'， “测试”，“产品”，其中数据模型可能会不断变化，或者在一段时间内在“开发”或“测试”中有所不同，直到下一次生产更新的数据模型。过去，我是通过GCP数据存储区以及其他所有类型的数据库（NoSQL和Not NoSQL）完成此操作的。

当时，尚未选择JSON文档存储库（数据库），尚未确定。在研究数据模型并计划用于支持开发工作的多个环境时，被告知要选择的数据存储为Firestore，随后在尝试实现基本CRUD操作以插入示例数据并创建单独的沙箱的过程中在同一Firestore实例中'dev1'和'dev2'可以工作的区域，并且在自己的区域内具有所需的破坏力，而不会彼此影响，发现本机模式不支持名称空间（并且客户端希望本机模式以及那里提供的功能，否则他们会考虑另一种产品来实现）。

因此，现在，我们以为我们只需要两个项目，一个Firestore实例，如果我们全面使用Firestore以纯模式运行，则将需要36个实例。因此，我正在寻求有关正在执行的操作的输入，以避免或减少这么多的项目/实例。我有一种可以提交给公司的解决方案，其中涉及不使用Firestore，但我想我会在放弃此方案之前先提出要求。我们需要能够针对通用软件开发生命周期需求以及我们自己的应用程序运行时需求，对数据进行隔离，隔离，分区和划分，并且在所有这些环境中，始终保持与生产基础架构的匹配。

我们对名称空间的需求与支持多个客户端或多租户无关，正如我在Google文档中经常提到的那样（这似乎是主要目的，也是唯一的用例），从历史上看，这就是命名空间中使用频率较低的一种用例，数百种之多。

我们最多只需要两个项目和数据库实例（两个Firestore本机实例）：

生产
阳光下所有其他非生产的东西：“ dev1”， 'dev2'，'test1'，'test2'，'tmp-test-whatever'

对于任何数据库产品，您都只需要一个数据库实例，并且具有一种支持数据和数据定义的隔离和隔离的机制，可以在该数据库内创建任意数量的命名空间。一些数据库产品将每个名称空间都称为数据库。在这里，我想区分我称为“数据库”或“数据库实例”的运行时软件，以及定义和包含数据的区域（名称空间）。

Oracle，PostgreSQL和其他公司将这些隔离的区域称为“方案”。其他数据格式，XML和许多其他格式都支持“命名空间”的概念，以便提供隔离并避免具有相同名称的定义的数据冲突。

Google数据存储区支持名称空间，它们表示可以进行多个租用，但是每个名称空间都不会像其他数据库产品那样受到隔离和保护。有权访问该数据存储实例的任何人都可以使用ALL名称空间进行任何操作，并且无法创建一个完全限制或限制对特定名称空间访问的服务帐户。

有了这个由Firestore支持的项目，在生产中，任何时候都将有多个可独立运行的服务，我们希望将其作为本机模式下的单个Firestore实例。有些将在移动设备上运行，有些将在另一个VM实例上运行（Web应用程序在各种集合/文档上启动了CRUD操作）。所有服务都是同一产品的一部分。其中一些单独的服务具有名称相同的集合。

示例：“用户”集合：

   { service1:      <== 'service1' is the namespace, it has multiple collections, 'users' which is just one for example.
      { users:
         { user: {
            login:  <login_name>
            <other fields>:
         }
      }
    }

现在另一个名称空间也具有一个“用户”集合，具有不同的数据定义和与上述不同的数据集

{ service2:     <== 'service2' is the name space
  { users:
     { user: {
        first_name: <first_name>
        last_name:  <last_name>
        <other fields>:
     }
  }
}
----
and other services that have their own collections.

上面提到的命名空间的其他用例：

环境，例如“ dev”或“ test”，用于修改任何集合，例如在开发过程中添加，重新制作数据模型。
我们要编写的单元测试，它将在临时用于该测试的唯一名称空间中插入数据，将插入数据，测试将运行，最后所有属于该测试的数据临时名称空间将被删除。
产品的移动应用程序部分使用的命名空间
用于支持产品的Web应用程序部分的命名空间，我们正在尝试将一个数据存储产品用于整个产品
用于CI进行各种操作的命名空间环境

我提出了一些在Firestore纯模式下适用于数据模型的方法，但是这是非常不希望的，而且很笨拙，例如在集合名称中包含服务名称和环境：dev1_service1_users，dev1_service2_users等，以区分并避免碰撞。

Firestore本机为您提供了一个名称空间，它们称为默认名称空间，但它根本不是名称空间，完全没有名称空间。

我看到的唯一解决方案是不使用Firestore，而是使用其他一些JSON数据存储，这将使我们接近Firestore本机提供的功能，该解决方案将在云中的VM上安装，更新和管理，并管理所有这些基础架构（负载平衡，还有更多）。

对于有兴趣或有类似问题或讨论的任何人，我都会发布我们的指导。

鉴于其不支持名称空间的Firestore选项

0 个答案: