tikv / rfcs

RFCs for changes to TiKV and its ecosystem

TiKV RFCs

Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow.

Some changes though are "substantial", and we ask that these be put through a bit of a design process and produce a consensus among the TiKV community.

The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project, so that all stakeholders can be confident about the direction the project is evolving in.

How to submit an RFC

1. Copy template.md into text/PRID-my-feature.md.
2. Write the document and fill in the blanks.
3. Submit a pull request.

Timeline of an RFC

1. An RFC is submitted as a PR.
2. Discussion takes place, and the text is revised in response.
3. The PR is accepted or rejected when at least two project maintainers reach consensus.
4. If accepted, create a tracking issue, refer it in the RFC, and finalize by merging.

Style of an RFC

We follow lint rules listed in markdownlint.

Run lints (you must have Node.js installed):

# Install linters: npm install
npm run lint

License

This content is licensed under Apache License, Version 2.0, (LICENSE or http://www.apache.org/licenses/LICENSE-2.0)

Contributions

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

rfcs's Issues

request for RFC: keyspace partitioning pattern

When multiple applications store data in TiKV, there should be a clear pattern for avoiding conflicting use of the keyspace.

I have seen a directory concept in FoundationDB: a logical hierarchy with non-hierarchical physical representation.

FoundationDB links

• Namespace
• Subspace
• Directory

FoundationDB does not use RocksDB. Column families from RocksDB may make our solutions easy to implement. However, we may want to support other storage engines that don't have column families: we may also need to consider how we would implement a column family abstraction for them.

move some design docs to rfcs

We have written many design docs internally, and we need to public them to let users know TiKV deeply.

• Raft merge
• Batch split #6
• ReadPool optimization
• Remove region meta from etcd
• Distributed GC
• Batch message
• Coprocessor chunk
• Raft Local reader
• Region heartbeat optimization
• Follower/Leader read
• Scheduling based on priority
• API check for compatibility rolling update
• Titan - a new engine for RocksDB
• Titan GC
• Joint consensus
• lightning
• PD simulator
• PD schedule limit
• Threaded Raftstore
• Failpoint
• Region Consistency check

Should we give each RFC an numeric identifier?

I see in other projects' RFCs, they usually mark RFCs with a simple number. Then when they references to a certain RFC, they simply says "RFC #1234". And the number usually is the pull request ID that proposes that RFC. Should we also do like this?

Include titles in RFC

Currently our RFC don't have titles. I suggest to change the template to include a title for the RFC:

# Title

## Summary

...

## Motivation

...