第六章節： application layer 協助處理極端情況的 skew- Jay Chen

[Jay0328]

如今，大多数数据系统无法自动补偿这种高度偏斜的负载，因此应用程序有责任减少偏斜。例如，如果一个主键被认为是非常火爆的，一个简单的方法是在主键的开始或结尾添加一个随机数。只要一个两位数的十进制随机数就可以将主键分散为 100 种不同的主键，从而存储在不同的分区中。

然而，将主键进行分割之后，任何读取都必须要做额外的工作，因为他们必须从所有 100 个主键分布中读取数据并将其合并。此技术还需要额外的记录：只需要对少量热点附加随机数；对于写入吞吐量低的绝大多数主键来说是不必要的开销。因此，你还需要一些方法来跟踪哪些键需要被分割。

根據這段所說，要處理一個百萬追以上追隨者使用的操作時，在寫入的部分看起來是可以自行加入一些額外參數去控制分區，但是在 query 的部分感覺就十分麻煩，想問問大家有處理過這類問題的經驗可以分享嗎？

[Parkerhiphop]

J 神經驗：Partition 的場景通常是 TimeStamp 下去切。

照上述手法不在同一個分區的話，Query 起來程式面會需要做什麼處理呢？

可能會分兩個步驟

1. 拿使用者的資料去 Filter
2. 在每個使用者之下再去拿

像是訂單會有併發的情況，設定的 Sharding 是由 Hash of User + 隨機碼去弄。 基本上隨機碼不建議超過 3 碼，避免造成 Query 時過多的負擔。

因為是隨機碼，只能知道隨機碼的數量，能做得可能就是全部去找，但是限制隨機碼的數量。

（上述只是個想法，可能還有其他作法）