TiKV - implementing a work queue

TiDB
1

Hi. This question is specifically about TiKV.

Is it possible to implement a workqueue-like behavior with TiKV?
Specifically, I would like to have this behavior:
If multiple transactions try to concurrently get the next item from the work queue, each transaction will obtain a distinct item from it.

I am thinking about a behavior similar to what I would obtain from a Redis ZSET with ZPOPMIN, or from SELECT FOR UPDATE and SKIP LOCKED in MySQL.

(I also sent this question on the TiDB and TiKV Slack channels, but I am posting here as well.)

1 Like
2

You can do PoC a test to use tidis GitHub - tidb-incubator/tidis: A distributed transactional large-scale NoSQL database powered by TiKV with LIST or ZSET data structure, but the performance may be limited because of the transaction conflicts on the same meta key in TiKV. For ZSET we have splitted the meta key to improve the conflicts.

4

In the context of TiKV, “splitting the meta key” refers to a technique used to manage and optimize the distribution of data across different regions within the TiKV storage engine. This process is part of the broader concept of “Region splitting,” which is crucial for maintaining performance and scalability in distributed databases like TiDB.

  1. Region Splitting: TiKV uses regions as the fundamental unit of data storage. Each region holds a range of keys, and when a region becomes too large or receives too many requests (a hotspot), it can be split into smaller regions. This splitting helps distribute the load more evenly across the TiKV nodes, preventing any single node from becoming a bottleneck.

  2. Meta Key Splitting: While the context does not explicitly define “meta key splitting,” it can be inferred that it involves dividing metadata keys to ensure that they do not become a bottleneck. By splitting these keys, TiKV can reduce transaction conflicts, especially in scenarios involving complex data structures like ZSETs (sorted sets), which may require frequent updates and access patterns that could lead to contention.

  3. Reducing Transaction Conflicts: Splitting regions, including those containing metadata keys, helps in reducing transaction conflicts by ensuring that concurrent transactions are less likely to operate on the same region. This is particularly beneficial for optimistic transactions, which assume no conflicts and only check for them at the end.

Overall, splitting the meta key is part of the strategy to enhance TiKV’s ability to handle high-concurrency workloads by distributing data and metadata more effectively across the storage nodes.

: TiDB Overview | PingCAP Docs
: TiDB Architecture | PingCAP Docs
: Coprocessor Configuration | PingCAP Docs
: Region Splitting | PingCAP Docs