Firebase RTDB：拆分数据访问的最优方案及权限控制探讨

1. 仅通过app-id限制客户数据访问的实现方式 #

Firebase Realtime Database的安全规则可以直接获取请求来源的app-id（request.app.id），你可以按以下步骤实现数据隔离：

• 在数据库中维护一个映射表，比如/appIdToCustomer，键是每个白标版本的Firebase app-id，值是对应的客户节点名称（如customerA、customerB）。这个映射表仅允许你通过控制台或后端修改，禁止客户端读写。
• 编写安全规则，判断当前请求的app-id对应的客户节点，是否与访问的节点一致：

{
  "rules": {
    "$customerNode": {
      ".read": "root.child('appIdToCustomer').child(request.app.id).val() === $customerNode",
      ".write": "root.child('appIdToCustomer').child(request.app.id).val() === $customerNode"
    },
    "appIdToCustomer": {
      ".read": false,
      ".write": false
    }
  }
}

注意：每个白标版本必须在Firebase控制台注册为独立的Android应用，这样每个版本的app-id才会被Firebase识别，request.app.id才能正确取值。

2. 是否需要拆分至独立数据库？ #

针对30个客户的规模，优先选择单个数据库+安全规则隔离，原因如下：

• 管理成本更低：无需维护多个数据库实例，统一监控、备份、配置。
• 配额共享更灵活：单个数据库的配额可在客户间动态分配，避免单个客户流量波动影响全局。

如果出现以下情况，再考虑拆分到独立数据库：

• 部分客户有严格合规要求，需要数据物理隔离。
• 单个客户的数据量或访问量极大，占用大部分配额影响其他客户。
• 未来客户数量会大幅增长（如超过100个），单个数据库的规则复杂度会显著上升。

3. 单个Firebase项目可创建的Realtime Database数量 #

单个Firebase项目最多可创建100个Realtime Database实例（包含默认创建的第一个实例）。30个客户的需求完全在这个限制范围内，无需担心数量不足。

内容的提问来源于stack exchange，提问作者Konstantin Konopko