小编Chr*_*ter的帖子

自8个月以来,我们在Google Cloud Spanner中运行一小部分生产数据,用于测试和学习有关Cloud Spanner的信息.

粗糙的特点:

• 1个表,40亿行,大约600GB存储大小,每天添加25条线,没有从表中删除.
• 我们用低读取和简单读取来编写大量数据.
• 每天写入的数据量不断增加,但不是很多
• 节点数:1(这不建议用于生产,但对我来说有趣的是CPU利用率的相对变化 - 使用3个削减利用率不超过三分之一)
• 我们确实有一些但不是很多非常大的分裂,可能会超过建议的分割大小'some GB',因为它们大约是20GB左右

我们首先注意到的是夜间CPU利用率与我们生产的负载没有直接对应.我认为这是一种像Cassandra那样的重组任务.所以没想到......

一周前,事情开始发生变化,CPU利用率也在上升.存储大小开始缩小.这很有趣,因为我们只添加数据.(见图)

我在想什么:

• 也许一些新版本的云扳手会引发一些全球性的重组
• 我们的大分裂会在重组过程中产生问题

有没有人知道这可能背后的信息？

使用主键快速执行的现有查询在没有通知的情况下大幅减慢（10 毫秒 -> 8 秒），因为现在会自动使用为另一个用例创建的二级索引。

Cloud-Spanner-Web-Query 的“说明”告诉我使用了二级索引。如果我更改顺序（仅用于测试目的）或提供 FORCE_INDEX 查询再次快速。

我可以通过使用Cloud Spanner 查询语法文档中记录的FORCE_INDEX=_BASE_TABLE来“修复”这个问题。

我的问题是：我真的必须为每个查询都这样做以避免这种影响吗？

这将查询定义与索引定义混合在一起，恕我直言，这不是一件好事。

带有主索引的表：

CREATE TABLE change_history (
    userId INT64 NOT NULL,
    createdAtUnique INT64 NOT NULL,
    itemId STRING(512) NOT NULL,
    newValue FLOAT64 NOT NULL,
    oldValue FLOAT64 NOT NULL,
) PRIMARY KEY (userId, itemId, createdAtUnique DESC)

二级指标：

CREATE INDEX ch_userid_createdatunique_all ON change_history (
    userId,
    createdAtUnique
) STORING (
    newValue,
    oldValue
)

原始查询：

SELECT * FROM change_history WHERE                         
    userId = 2563
    AND itemId = "215414"
    AND createdAtUnique …