| TiDB developer here.
Yes, I think TiKV is an alternative to FDB. Compare to FDB Record Layer, TiKV aims to provide a more atomic primitive, just including Get/Set/Transaction in key-value layer, so users can build customized distributed system around it. The main differences between TiKV/TiDB and FDB are: 1. TiKV uses Multi-Raft architecture, I think Raft provides more HA. 2. TiKV's transaction model is inspired by Google Percolator, it's a classical optimistic 2PC transaction model with MVCC support. I'm not a expert of FDB, but I think different transaction models fit for different application scenarios, TiKV's transaction model is good when your workload is mainly small transactions and with a low conflict rate. 3. TiDB is a full-featured SQL layer on top of TiKV, aims to provide a MySQL compatible solution, you know, most of the TiDB users are migrated from the MySQL, so the focus of TiDB will be how to be compatible with these legacy MySQL-based applications. For example, how to read MySQL binlog and then replay on TiDB in real time, let TiDB become a MySQL active replica, or how to support complex SQL queries like distributed join or groupby, you know, building a full-featured SQL optimizer is a huge project. There are some case studies: https://pingcap.com/success-stories/ https://pingcap.com/success-stories/tidb-in-meituan-dianping... There are some quick-start documents you can start with: https://pingcap.com/docs/op-guide/docker-compose/ https://pingcap.com/docs/v2.0/op-guide/migration/#migrate-da... |