Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Graduated Project Lightning Talk: Time to Live (TTL) Support for TiKV - Bokang Zhang

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Graduated Project Lightning Talk: Time to Live (TTL) Support for TiKV - Bokang Zhang

Time to live (TTL) is a beneficial feature for developers to invalidate keys automatically. RocksDB supports TTL natively but with a limitation that all keys should be of the same TTL. This may cause inconvenience for developers who may have the demand to set different TTL for each key. This issue happens to TiKV, a distributed key value database built on RocksDB with Raft. To solve it, TiKV team achieved more flexible TTL support in TiKV level instead of using RocksDB’s TTL. In this talk, Bokang Zhang will walk through the TiKV architecture and talk about how they supported TTL in TiKV by leveraging the hook of RocksDB’s compaction filter and user defined properties, and how they made the disk space of TTL key-values recycled in time.

A

Hello: everyone, it's very honored, to have you here during this lighting talk today.

A

This is spoken from the technv community, I'm an infrastructure engineer at pincap, also a core contributor to the type tv project. Besides I'm a maintainer of titan, which is roxdb plugin for key value separation. Inspired by whiskey, I'm going to give a presentation of how we support gtl in thai tv first. What is thai tv techyv is an open source distributed transactional key value database.

A

It became a graduated since that project last year. So far, we have over 9 000 stars and 300 contributors on github and there are over 1 500 adopters in production across multiple industries. Worldwide techyv is based on the design of google spanner and each base but simpler to manage and without the dependency on any distributed file systems.

A

Here is a picture showing the overall architecture of tel tv. The full data range is split into small areas called region, and there are three replicas in a region by default. The replicas are scattered around in two different types of nodes and keep confident by route.

A

The placement driver stores the metadata of regions to provide clients with region, routine information, and it is also responsible for auto charging and low balance.

A

Type tv use roxdb as the underlying storage energy. On top of that, it provides horizontal stability and high availability based on raft and, unlike other traditional nosql systems, tech tv not only provides classic cookie value apis.

A

Here we call it later roki way, but also both optimistic and pessimistic distributed transaction, namely transaction kb. Besides it impulse the kubernetes api, which is similar to each base to support the distributed computing, and it also provides the ability of elastic scheduling and the geo replication.

A

For detail we talked about is mainly supported in the local way.

A

Okay, what is ttl ttl stands for time. To live, which means data will be deleted automatically without a flight time. In minor user cases, the value of the data is highly temporal. Correlation, as time goes by the value of the data declines. User may need to delete data manual manually periodically, which caused extra overhead with tdl. The data can be dropped in the database automatically without any mental burden, as mentioned before, taikv is built on top of roxdb.

A

Rock db supports tdl natively, but with the limitation that all keys should be of the same tdr, whereas zero's demand to cite different ttl for each k and the song keys are of non-ttl, that is to say, the mixture of ttl with non-ttl.

A

Besides, there is no guarantee that the expired entry won't be returned and no api to query how long the ttl left for one key in rough cb to meet the demand. We decided to support tdl in tactically instead of using roxdb ttl feature directly.

A

Here comes the first question where to put the ttl information, there's no metadata for k, so it's just to append it as 8 bytes to the value. When writing ttl type tv calculates the desired experience unix times, then by adding ttl to the current unix timestamp, and when reading the key technique checks the expiry timestamp to see if the current timestamp exceeds that, if yes, it returns not found just like the key is deleted.

A

Otherwise it returns the value with stripping the template, since that's all for it, but in the distributed system we should take a linearizability into a cart. The check in the clock in different type ev instance, may now be synchronized. Consider the case of getting an expert key on the leader. The leader is transferred to another instance with a slow clock due to some reason, such as crash a second get on the key may return value then, which breaks the linearizability.

A

In this case we can utilize. The global metamic increase in timestamp is best from the placement driver which is used for transaction, though considered bring. The performance overhead is not used by default.

A

Now we get the ttl functionality, but how can the space be reclaimed for background information?

A

Data in roxdb are organized in multiple sst files and the compaction is to merge this to merge out the old files into newer wires.

A

So when we leverage the compaction filter of roxdb to literally drop the expert entries in the precise of compaction, the compassion filter goes through the key and the value and checks the experience handstand in the unix 10 stand if it exceeds just drop the key value. In this way, we can do the slash recommendation without any extra read and write.

A

But there's still a problem: what, if compaction, is not wrong some accessories, yet the space reclamation may not happen in time to solve that type. We utilize the user, collect property of roxdb to record the maximum expiry timestamp in each sst.

A

With that a worker cloud ttl checker checks the status of sst one by one periodically.

A

If the max is battery, timestamp exceeds the current timestamp, it triggers the compaction manually by roxdb compact files api to perform the compaction filter logic. Thus, most of the expired entries are promoted, promised to be dropped in time.

A

Okay, that's all for this talk, hope you enjoyed it. If you are interested in thai tv project or have questions feel free to contact us through the following channels, including twitter, github and slash channel. Thank you. Everybody.