json - Firestore 选项，因为它不支持命名空间
问题描述
那里有什么东西（云 JSON 数据存储产品，支持移动应用程序），在本机模式下与 GCP Firestore 一样性能和功能丰富，但提供命名空间？
由于软件开发周期的性质、多种环境需求（开发、测试、生产）、连续部署和交付管道、使用命名空间的 JSON 数据模型等等。
如果不是，在您真正的大型 Firestore 项目中，您正在做什么来创建人们可以工作的开发、测试、集成环境或区域，或者支持在生产中单独运行相关应用程序，每个应用程序都需要自己的命名空间或设置定义的集合，无需创建和管理大量项目、Firestore 本机实例和服务帐户（每个项目/Firestore 实例都需要创建一个服务帐户 .json 文件、分发给开发人员、安全存储），每个附加实例增加了更多的管理开销，并且无需在 GCP Datastore 模式下运行 Firestore，在哪种模式下，您会失去所有优势、功能和主要卖点，从而导致您选择 Firestore 来支持您的应用程序？
选读：背景/背景：
我最近加入了一个新项目，被要求为构成整体的各种服务（独立运行的程序）创建 JSON 数据模型，并为多个运行时环境（如“dev1”、“dev2”、“test”）设置示例数据, 'prod'，其中数据模型可能在一段时间内不断变化，或者在 'dev' 或 'test' 中有所不同，直到更新数据模型的下一次生产部署。我过去曾使用 GCP Datastore 和其他所有类型的数据库（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 等等都支持“命名空间”的概念，以便提供隔离并避免同名定义的数据冲突。
谷歌数据存储支持命名空间，他们说多租户，但是每个命名空间都不是孤立的，像其他数据库产品一样受到保护。任何有权访问该 Datastore 实例的人都可以对所有命名空间执行任何操作，并且无法创建完全限制或限制对特定命名空间的访问的服务帐户。
有了这个 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 上安装、更新和管理的解决方案，并管理所有基础设施（加载平衡，+更多）。
我将发布我们采取的方向，以供任何有兴趣或有类似问题或讨论的人使用。