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

我认为，由于数据是用很小的记录构成的，因此文档存储将更适合它-特别是因为postgres不容易扩展。所以我想尝试数据存储-已淘汰，并替换为 firestore -很好。

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

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

我在这里一定做错了。即使postgres不扩展，它也可以减慢100倍，使其接近Firestore的性能，在一个包含一个文档的集合上只有一个索引。

我使用以下标志从4-core,8GB ram compute instance运行基准测试：

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作为no-sql的替代品-但它们的成本对于我的简单用例来说是巨大的（至少是估计，我发现这是不透明的）