TiDB – cloud-native, distributed SQL database written in Go

https://github.com/pingcap/tidb

by philonoist • 2 years ago

72 65 2 years ago

github.com

peterson_lock2• 2 years ago

I was able to get a small TiDB cluster running in my homelab last night! Looking forward to using it :)

Reference: https://docs.pingcap.com/tidb-in-kubernetes/stable/get-start...

otterley• 2 years ago

TiDB is 8 years old now; what's new?

alpb• 2 years ago

Yeah that and the actual core storage engine is a key-value store library called https://github.com/tikv/tikv which is written in Rust. I suspect the Go part only handles the replication component, MVCC, query planner, server etc.

tapirl• 2 years ago

Is tikv (still) a wrapper of RocksDB?

willvarfar• 2 years ago

Hardly hear about TiDB. How is it faring and how does it stack up to more well know competition?

xmichael909• 2 years ago

Same as before, excellent when you little little data and limited transactions. Once things get big and you lose sync, everything goes to shit.

sgarland6• 2 years ago

They claimed they successfully onboarded a customer with 1 PB of data at KubeCon NA.

I have strong doubts about distributed DBs in general, but I also can’t see them blatantly lying in a talk.

PeterCorless5• 2 years ago

Note that TiDB did subject itself to Jepsen testing (relatively) early. Here's their 2019 results:

https://jepsen.io/analyses/tidb-2.1.7

The devil is in the details, and anyone who is looking to implement TiDB for data correctness should read through not just this but other currently-open correctness-related Github issues:

e.g., https://github.com/pingcap/tidb/issues?q=is%3Aissue%20state%...

TiDB currently has 74 open issues related to "correctness," and has closed 163.

https://github.com/pingcap/tidb

std_reply9• 2 years ago

This is quite an ignorant comment. TiDB routinely handles 100s of TB of data. Go watch LinkedIn’s presentation on why they choose TiDB as their strategic db going forward.

jitl• 2 years ago

I hear through the grapevine they’ve got a bunch of companies using it. I think Airbnb migrated to it.

travem4• 2 years ago

There are quite a few. Pinterest, LinkedIn, Plaid, Mercari, and Rakuten shared their experiences with TiDB at PingCAP's annual event last year (2024) - https://www.pingcap.com/htap-summit/.

In the previous event (2023) there were speakers from Airbnb, Databricks, Flipkart, PayPay, and others sharing their experiences as well - https://www.pingcap.com/htap-summit/sept-2023/

Disclosure: Employee of PingCAP the company behind TiDB

srameshc• 2 years ago

I love these new distributed DBs. CockroachDB is one of them. Still I think a managed Postgres/MySQL is a better choice. My primary concern is how challenging will it be if you have to eventually move your data out to a RDBMS for cost or other reasons. Does anyone have any experience ? I am not talking enterprise scale but data about size of 50 - 100GB scale.

convolvatron• 2 years ago

why do you think that would be harder? assume for the moment that the reader here is going to run at the effective rate of a single node and not that we're going to try to parallelize that. Assuming we have transaction isolation, that reader is going to get a consistent snapshot.

a distributed database is potentially more complicated to operate, and optimize, and because its new and potentially has more sharp edges maybe less reliable (?) but the extraction of moderate sized datasets doesn't really seem to be an obvious failing.

std_reply9• 2 years ago

I would argue the opposite, distributed databases are much easier to operate at large scale. Truly online distributed DDL, at least in TIDB, strong consistency etc.

People who bang on about Postgres replication have rarely setup replication in Postgres themselves and that too in the 100a of Pb scale.

MySQL replication works well and can be scaled more easily (relative to Postgres) but has its own problems. eg., DDL is still a nightmare, lag is a real problem, usually masked by async replication. But then eventual consistency makes the application developers life more complicated.

sgarland6• 2 years ago

Distributed DBs and traditional RDBMS serve different purposes. Most – by which I mean the overwhelming majority – companies do not need a distributed DB, they need better schema and queries.

My fear is companies without in-house RDBMS expertise see these products as a way to continue to avoid getting that expertise.

debarshri• 2 years ago

I think it is mostly three folds. Availability, to be cloud agnostic and scale of few tbs to few hundred TBs. I have been seeing cockroach and yugabyte in an on prem setup where you don't get the benefits of a cloud provider but you can get the availability guarantees and fault tolerance.

eikenberry5• 2 years ago

VC backed database company with a CLA on their "open source" project. Red flag. Is there a community fork yet?

zhouzhao• 2 years ago

Thank you for the warning. Whats the source on the VC part?

russell_h• 2 years ago

I don't share OP's hostility to VC-funded databases, but PingCAP is definitely VC-funded: https://www.pingcap.com/press-release/pingcap-the-company-be...

hbbio• 2 years ago

How would you fund the open source development of a database?

TiDB is Apache licensed, that should be enough no? Because if we ban all projects from VC-backed startups, you're going to clear your tech stack pretty quickly.

foota2• 2 years ago

I think the concern is that the company would relicense future versions, as allowed by the CLA, under pressure from VCs.

eikenberry5• 2 years ago

How would you fund the open source development of a database?

I think the best way would be something similar to the Linux Foundation. Companies in need of a certain type of database would pool resources to develop and maintain it.

PostgreSQL was a community developed database that was funded in something approaching this way as most of the developers were either students or worked for someone who paid them while they worked on it.

TiDB is Apache licensed, that should be enough no?

It's good enough to use it with the knowledge that it isn't truly free (libre) because the CLA gives the owning company the right to change that at any time. So you can use it but don't build a business around it or make it a critical part of your infrastructure as they might pull the rug out from under you.

benatkin2• 2 years ago

With it under the Apache 2 license, misuse of a CLA to get free contributions from the community that aren't shared back to the community isn't currently a problem.

rpaik4• 2 years ago

Is your main issue with the VC funding, the CLA, or the combination of both. Doesn’t Kubernetes (hosted by the Linux Foundation) also have a CLA?

hodgesrm• 2 years ago

CLAs are not necessarily a bad thing. In fact, they are pretty much necessary for software companies. We have one for our open source projects. It has language to ensure there's no dispute about our right to the code. That's important, because we indemnify our customers against IP infringement. It's a standard part of contracts for software and services.

cube2222• 2 years ago

IANAL but you can have that without getting yourself a full copyright license to all contributions - as CLAs generally do, and what enables license changes.

A popular more lightweight solution is the DCO[0].

[0] https://developercertificate.com/

nuphonenuacc• 2 years ago

What is that first paragraph? "This implementation proves the CAP theorem as wrong"? Doesn't tell me what your drawbacks are. This is mongodb all over again. Will only ever consider if the customer really wants it. (My guess performance)

(Also, bold move to write a db without fully being able to manage memory).

travem4• 2 years ago

I do want to clarify a few points, on the project page it does provide the following information:

Distributed Transactions: TiDB uses a two-phase commit protocol to ensure ACID compliance, providing strong consistency. Transactions span multiple nodes, and TiDB's distributed nature ensures data correctness even in the presence of network partitions or node failures.
High Availability: Built-in Raft consensus protocol ensures reliability and automated failover. Data is stored in multiple replicas, and transactions are committed only after writing to the majority of replicas, guaranteeing strong consistency and availability, even if some replicas fail. Geographic placement of replicas can be configured for different disaster tolerance levels.

See https://github.com/pingcap/tidb?tab=readme-ov-file#key-featu...

Correctness has been a focus for a long time for TiDB, including working on passing Jepsen Tests back in 2019, see https://www.pingcap.com/blog/tidb-passes-jepsen-test-for-sna... and https://jepsen.io/analyses/tidb-2.1.7

Disclosure: Employee of PingCAP the company behind TiDB

fipar• 2 years ago

I can't find that first paragraph, and it seems that readme file was last modified 3 months ago, though you're using quotes, so perhaps you are paraphrasing?

The first paragraph I find under Key Features is:

Distributed Transactions: TiDB uses a two-phase commit protocol to ensure ACID compliance, providing strong consistency. Transactions span multiple nodes, and TiDB's distributed nature ensures data correctness even in the presence of network partitions or node failures.

It claims to ensure correctness in the presence of partitions, not availability, so I don't think that's a claim that CAP is wrong? I would expect it to be unavailable if it can't provide a consistent response.

I don't know about memory management. It seems go may not be used for the storage layer, but in any case, it wouldn't be the first attempt at a DB on a garbage collected runtime. I can think of at least Cassandra on the jvm and CockroachDB also on Go. I do prefer that DBs do their own memory management (as well as storage) but this is not as unique as it used to be though.

std_reply9• 2 years ago

Go is used for the SQL layer, it’s a modern optimizer that can do distributed joins etc. ie. Issue parallel reads to the storage nodes.

Additionally, it can push down the DAG to the TiKV storage nodes, written in Rust, to reduce movement of data and work closer to the physical data.

std_reply9• 2 years ago

TiDB has four main components:

1. SQL front end nodes 2. Distributed shared nothing storage (TiKV) 3. Meta data server (PS) 4. TiFlash column store

1 and 3 are written in Go 2 is written in Rust and uses RocksDB 4 is written in C++

2 & 3 are graduated CNCF projects maintained by PingCAP.

Disclaimer: I work for PingCAP

oa335• 2 years ago

Interview with TiDB developer explaining some of the architecture of the DB : https://youtu.be/mmzoSkEhYrA?si=5eIppYzqKvOxWDtv

tonymet• 2 years ago

Does "cloud native" mean "has kubernetes config" or is there something else to it?

geenat• 2 years ago

Not having a single binary distribution like CockroachDB is hurting adoption of TiDB.

std_reply9• 2 years ago

Have you looked at tiup?

https://tiup.io

TiDB – cloud-native, distributed SQL database written in Go

Related Stories