“海量”数据的Firebase

Question

我们计划将我们的应用程序迁移到Firebase，以获得实时功能并提高性能。这是一个销售应用程序，用于存储客户产品和销售数据。我们的客户(我们称之为集团)一般每个都有10家商店(我们称之为公司)。

处理这么多数据没什么大不了的。但最近我们和一家大集团达成了一笔交易，该集团拥有1.000+门店(每月新增20家)。

我的问题是，如何在不出现性能问题的情况下组织这些数据，并保持实时特性？

我认为如果我们专注于如何构建集团-公司，我们可以处理其他部分(销售，产品等)

"Groups": {
    "Group1": {
      "name": "Historical Tech Pioneers"
    },
    "Group2": { ... }
}

"Stores": {
    "Store1": {
      "name": "abc",
      "group" "Group1"
    },
    "Store2": {
      "name": "def",
      "group" "Group1"
    },
}

这种数据结构可以每次处理数千条记录吗？

如果我每次都要查询超过1.000家商店，我会非常担心Firebase的性能。每个人都说1.000条记录对Firebase来说不算什么，但我做了一些测试，发现检索1.000条记录并不像他们说的那样流畅。

Answer 1

所以我有一个na 建议的，那就是组织这样的firebase数据为例：

"Groups": {
    "Group1": {
        "name": "Historical Tech Pioneers"
        "Stores": {
            "Store1": {
                "name": "abc"
            },          
            "Store2": {
                "name": "def"
            }
        },
    },
    "Group2": { ... }
}

要打开商店，只需将其发送到Groups>Group1>Stores即可。为了获得更好的性能，将页面添加到firebase数据中，例如每页10个存储。

注意：只是一个建议。

Answer 2

由于在数据库中的某个位置获取数据还会检索其所有子节点，因此您希望尽可能保持数据库结构的扁平化。您的建议类似于docs中的结构。在我看来你走对了路。

看看你的例子，我可能会重新构造Stores-node，以轻松获得一个组的所有Store：

"Stores": {
    "Group1": {
        "Store1": {
            "name": "abc"
        },
        "Store2": {
            "name": "def"
        },
        ...
    },
    ...        
}

在文档(一个example)中，我读到了反规范化是一个关键字。为了加快读取速度，不要害怕复制数据。你打算如何使用你的数据应该决定你如何组织你的数据。

作为Chris Esplin wrote

“我们必须根据我们想要使用数据的方式，不断地权衡归一化(浅层结构)和反归一化(深层结构)。”