Pull to refresh

Comments 9

UFO just landed and posted this here
In TiDB, we don't have Atomic clocks and GPS clocks. We are using the Timestamp Allocator introduced in Percolator, a paper published by Google in 2006.

The pros of using the Timestamp Allocator are its easy implementation and no dependency on any hardware. The disadvantage lies in that if there are multiple datacenters, especially if these DCs are geologically distributed, the latency is really high.

pingcap.com/blog/2016-10-17-how-we-build-tidb
Было бы интересно узнать, «почему я должен выбрать это NewSql решение, а не другое». Сейчас можно посмотреть и на CockroachDB, и на FoundationDB.
Внутри Placement Driver используется etcd. Со страницы PD на GitHub:
PD supports distribution and fault-tolerance by embedding etcd.

Вот ещё из интервью инженеров CoreOS:
TiKV uses ETCD to do that. Placement driver to track all servers. To figure out which server can participate in which raft group.

А вот — в исходниках.
Спасибо за развёрнутый ответ, но вроде как etcd сам умеет KV хранить и распределять их. или я путаю его с консулом?
Умеет, но тут (как минимум) масштабы очень разные: если авторы etcd говорят о надёжности хранения в ней «several gigabytes» данных, то в TiKV речь идёт уже о «100+ Тб» (упомянуто в статье).

UPD: «The maximum database size limit for etcd is 10 GiB» (из Announcing etcd 3.3).
Sign up to leave a comment.