我用一個簡單的鍵和值填充了100M行的數據庫。主鍵只是一個隨機的32字節字符串,值是一個32字節的字符串。 (這與YCSB非常相似,儘管更小)。Cloud Spanner中的低讀取吞吐量
我看到單點讀取點的吞吐量非常不一致。我看到單個節點高達15k QPS,但有時我看到的吞吐量更低。較高的QPS似乎是查詢一小部分密鑰的結果。是否有可能遇到一些奇怪的緩存行爲?
我用一個簡單的鍵和值填充了100M行的數據庫。主鍵只是一個隨機的32字節字符串,值是一個32字節的字符串。 (這與YCSB非常相似,儘管更小)。Cloud Spanner中的低讀取吞吐量
我看到單點讀取點的吞吐量非常不一致。我看到單個節點高達15k QPS,但有時我看到的吞吐量更低。較高的QPS似乎是查詢一小部分密鑰的結果。是否有可能遇到一些奇怪的緩存行爲?
緩存(即從輔助存儲緩存數據)不應嚴重影響您的性能,並且在雲端扳手的大多數性能討論中通常都可以忽略它。但是,Cloud Spanner確實有query cache,這可能是此問題的一部分。
有可能會影響你的表現如此嚴重的幾個因素:
1)如果你正在使用你的觀點SQL查詢讀取,確保您使用的查詢參數。換句話說,請確保您的executeSql請求中填充了params
和paramTypes
字段。這將提高查詢性能並提供更好的安全性。有關查詢性能的更多信息,請參閱此whitepaper。
2)如果您正在運行負載測試,請確保您至少運行30分鐘的工作負載,以確保Spanner有機會通過在節點間平衡(並創建新的)分割來優化數據分佈。
請注意,您應該能夠在任何新鮮度級別(例如Strong Reads)都能看到出色的讀取性能,並且如果使用Bounded-Staleness,則可能會看到輕微顛簸。