Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KV Store Spike: TiKV vs Google Trillian #202

Open
6 tasks
guacamole opened this issue Oct 21, 2022 · 0 comments
Open
6 tasks

KV Store Spike: TiKV vs Google Trillian #202

guacamole opened this issue Oct 21, 2022 · 0 comments
Labels
enhancement New feature or request P1 P1 label is used for this that we see of highest priority. Critical bugs, security issues, etc

Comments

@guacamole
Copy link
Member

Datastore in OpenRegistry is a small piece of software that enables persistence of records like user info (so they can login), container image content hash mappings, ACLs (so that a user can choose who can access their container images), etc.

We already have an implementation of this store using PostgreSQL. While Postgres is favourite for a large tech community, it's also difficult to manage. Especially when it comes to things like deployments and scaling. Another thing to consider is OpenRegistry's nature as a Web3 native container registry. We will eventually have to introduce blockchain-related features for stuff like container image ownership, and encryption of container images and ease of their sharing.

Having a document with a reproducible benchmarking tests would be most ideal for comparing the following two tools:

Both of these stores are very different from each other. TiKV allows distributed, cluster based deployments. This makes providing capabilities like high availability very easy. On the other hand, Google Trillian allows for storing data in cryptographically verifiable way. This makes a very strong case for using Trillian for blockchain data and OpenRegistry store.

Essentially what we need to do here is the following:

  • Create a document on both of these databases, capture API, deployments, overhead
  • Write basic CRUD ops with both operate in binary data, i.e, all the methods/functions take binary data to store and return binary data.
  • Implement the store.Store interface for both of these stores
  • Run benchmarks against both of them. This will give us a great understanding of which of these options suits better for out data needs and do we have any performance toll while using their primary features.
@guacamole guacamole added this to the IPFS Milestone 2 milestone Oct 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request P1 P1 label is used for this that we see of highest priority. Critical bugs, security issues, etc
Projects
Status: Backlog
Development

No branches or pull requests

1 participant