扳手中选择/插入的延迟非常高

如何解决扳手中选择/插入的延迟非常高

对于spanner 中的简单查询（通过主键更新或选择），我得到了大约 50-100 毫秒的延迟。从同一项目/地区连接到扳手。这是预期的行为吗？我预计这些延迟会低得多。

解决方法

不，使用主键的简单选择的延迟应该比这低很多。

我使用以下简单程序根据您在上面提供的信息进行了快速基准测试：

package main

import (
    "context"
    "fmt"
    "math/rand"
    "time"

    "cloud.google.com/go/spanner"
    "github.com/montanaflynn/stats"
    "google.golang.org/api/iterator"
)

func main() {
    fmt.Printf("Simple Spanner benchmarking...\n")
    source := rand.NewSource(time.Now().UnixNano())
    rnd := rand.New(source)
    client,err := spanner.NewClient(context.Background(),"projects/my-project/instances/my-instance/databases/my-database")
    if err != nil {
        fmt.Printf("Client creation failed: %v",err)
        return
    }
    var times stats.Float64Data
    for i := 0; i < 25; i++ {
        id := rnd.Int63n(1000) + 100000
        statement := spanner.NewStatement("SELECT * FROM Singers WHERE SingerId=@id")
        statement.Params["id"] = id
        start := time.Now()
        iter := client.Single().Query(context.Background(),statement)
        for {
            row,err := iter.Next()
            if err == iterator.Done {
                break
            }
            if err != nil {
                fmt.Printf("Query failure: %v",err)
                break
            }
            var fullName string
            row.ColumnByName("FullName",&fullName)
            fmt.Printf("Singer name: %s\n",fullName)
            elapsed := time.Since(start)
            fmt.Printf("Time: %v\n",elapsed)
            times = append(times,float64(elapsed.Milliseconds()))
        }
        iter.Stop()
    }
    median,_ := stats.Median(times)
    avg,_ := stats.Mean(times)
    p90,_ := stats.Percentile(times,90)
    fmt.Printf("Median: %v\n",median)
    fmt.Printf("P90: %v\n",p90)
    fmt.Printf("Avg: %v\n",avg)
}

该应用程序在与 Spanner 实例位于同一区域的尽可能小的 Google Cloud Compute Engine 虚拟机上执行。结果是：

Simple Spanner benchmarking...
Singer name: FirstName LastName 100960
Time: 374.627846ms
Singer name: FirstName LastName 100865
Time: 4.102019ms
Singer name: FirstName LastName 100488
Time: 3.479059ms

...

Singer name: FirstName LastName 100542
Time: 3.986866ms
Singer name: FirstName LastName 100822
Time: 3.978838ms
Singer name: FirstName LastName 100235
Time: 4.511711ms
Singer name: FirstName LastName 100020
Time: 3.476673ms
Singer name: FirstName LastName 100234
Time: 3.191529ms
Singer name: FirstName LastName 100219
Time: 4.451639ms

Median: 3
P90: 4
Avg: 18.44

因此，大约 50-100 毫秒的执行时间听起来很多。在这个（简单的）测试用例中，单行选择的正常执行时间约为 3-4ms（除了第一个请求，因为它也会初始化后备会话池）。

• 会不会是您的表有一个使用单调递增值的主键？这可能在主键的后备索引中create hotspots。
• 您是否会在每次查询之间关闭并创建一个新客户端？这需要为每个新查询重新初始化会话池吗？
• 您的查询是否使用一次性只读事务？或者您是否使用其他类型的事务来读取数据？

---

能否请您提供一些有关您如何准确执行查询的其他详细信息（最好提供代码示例）？

• 您在使用客户端库吗？如果有，是哪一个？ （Java、Node、Go，...？）
• 您是否只测量启动应用程序后执行的第一个查询？第一个查询会比后面的查询慢，因为客户端库需要先创建一个会话，然后再执行查询。
• 您写道，您是从同一个项目/地区连接的。这是否意味着您的客户端代码在 Google Cloud 虚拟机或类似设备上运行？