cloud firestore 变得非常慢

今天golang学习网给大家带来了《cloud firestore 变得非常慢》，其中涉及到的知识点包括等等，无论你是小白还是老手，都适合看一看哦~有好的建议也欢迎大家在评论留言，若是看完有所收获，也希望大家能多多点赞支持呀！一起加油学习~

到目前为止，我使用 cloud sql 作为后端数据库构建了一个项目。

由于数据是由相当小的记录构成的，我认为文档存储会更适合它 - 特别是因为 postgres 不容易扩展。所以我想尝试 datastore - 它已被弃用并被 firestore 取代 - 很好。

我将一个文档插入一个集合，在云 sql 上使用一张表创建一个测试 sql 数据库并插入相同的记录，然后在 go 中运行一个简单的基准测试。

soooo：**cloud sql postgres 可以在 firebase 管理大约 66 个响应（17.006.551 ns/op）的同时返回 6000 个（198.650 ns/op）响应。**

我一定是做错了什么。即使 postgres 无法扩展，在接近包含一个文档的一个集合上的一个索引的 firestore 的性能之前，它也会减慢 100 倍。

我使用以下标志从 4 核、8gb ram 计算实例 运行基准测试：

go test -bench=. -benchtime=1s -test.parallel=1 -cpu=1

这是我用于 firestore 的基准：

func benchmark_fetchsingle(b *testing.b) {

    ctx := context.background()

    client, _ := firestore.newclient(ctx, "project-123", option.withcredentialsfile("key.json"))
    defer client.close()
    for n := 0; n < b.n; n++ {
        c,_ := client.collection("documents").doc("documentid").get(ctx)
        c = c
    }
}

这是云 sql (postgres) 的：

func Benchmark_sql(b *testing.B) {
    psqlInfo := fmt.Sprintf("host=%s port=%s user=%s password=%s dbname=%s " +
        "sslmode=require sslrootcert=server.chain.cert sslcert=client.cert sslkey=client.key",
        "ip.address.0.0", "5432", "user", "password", "database")
    sqldb, _ := sql.Open("postgres", psqlInfo)
    stmt, _ := sqldb.Prepare(`select property1, property2 from documents where pk = $1;`)
    defer sqldb.Close()

    for n := 0; n < b.N; n++ {
        rows, _ := stmt.Query("DOCUMENTPK")

        rows.Next()
        stuff := struct{
            P1 string
            P2 string}{}
        rows.Scan(&(stuff.P1), &(stuff.P2))
        stuff = stuff
        rows.Close()
    }
}

firestore 是否配置错误？ 我认为还有 spanner 和 bigtable 作为无 sql 的替代品 - 但它们的成本对于我的简单用例来说是巨大的（至少是估计，我发现这是相当不透明的）

解决方案

如果不讨论如何衡量事物，就很难帮助解决性能问题，这在 Stack Overflow 上是题外话。因此，我将尝试解释如何理解 Firestore 的性能特征，并希望您能够将其映射回您看到的结果。

Firestore 的主要（也是相当独特的）性能保证是性能取决于结果集的大小，而不是集合的大小。简单来说：如果从（比如说）1,000 个文档的集合中检索 10 个文档需要 1 秒，那么当集合包含 1,000,000 或 1,000,000,000 个文档时，检索这 10 个文档也需要 1 秒。

请注意，这并没有说明实际性能，因为这取决于许多其他因素。它仅仅说明了随着集合的增长而发生的性能变化。例如：在这种情况下，性能不会改变。因此，虽然大多数数据库在底层数据库增长时性能会下降（通常在 O(n log n) 左右），但 Firestore 的性能持平（在检索 10 个文档的示例中为 O(1) 或 O(10)） .

终于介绍完啦！小伙伴们，这篇关于《cloud firestore 变得非常慢》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！