TiDB open sources its MySQL/MariaDB compatible data migration tool
github.com
github.com
Furthermore, column-stores are so different than row-stores in their ideal implementation that they are effectively completely different systems with the same outer interface (SQL). Daniel Abadi wrote a fantastic paper [1] in which he showed that fast column stores must use completely different strategies at every layer of query processing.
You should be very skeptical of any database claiming to be good at both transaction processing and analytical workloads. Such as system would effectively be two different databases hiding behind the same SQL interface, and would not be as useful as you might expect, for devops reasons.
I agree that column and row store have very different characteristics, but what I think is worth mentioning is that some hybrid solutions actually store as both row and columnar and have a query optimizer that can pick between them. For example: Oracle DB In-Memory, SQL Server Columnstore index.
At the same event as this announcement, we also announced that we are working on TiFlash which will do similar. Stay tuned for a blog post with more details :-)
I think the OLAP scenario is pretty well covered these days while scalable relational OLTP is still new and would likely be the better focus.
Here are some links that might be helpful:
- the typical use cases: https://pingcap.com/blog/architecture-and-use-cases-of-a-clo...
- the key differences between MySQL and TiDB
https://pingcap.com/blog/5-key-differences-between-mysql-and...
- the current case studies: https://pingcap.com/success-stories/
TiDB (The pronunciation is: /'taɪdiːbi:/ tai-D-B, etymology: titanium) is an open-source distributed scalable Hybrid Transactional and Analytical Processing (HTAP) database. It features infinite horizontal scalability, strong consistency, and high availability. TiDB is MySQL compatible and serves as a one-stop data warehouse for both OLTP (Online Transactional Processing) and OLAP (Online Analytical Processing) workloads.
It may seem trivial, but claims like that are why I prefer CockroachDB when it comes to NewSQL systems. They’re at least very upfront with its compromises and areas needing improvement.
I’ve never see anything from Pingcap explaining the compromises that the DB makes. A “when should you not use this” type overview, and to me those are the most important things when deciding on a technology.
It may be good technology, but it’s marketed like modern day snake oil.
(We must have missed a spot, and I will follow up and make sure it is addressed).
We try to be transparent about the differences from MySQL. On the compatibility page, there are a few cases described such as large transactions, small transactions and single threaded workloads:
w.r.t. nested transactions, this is not something that MySQL currently offers (TiDB is MySQL 5.7 compatible). Sometimes this is emulatable via savepoints, which is a feature we plan to add in the future.
I believe SqlAlchemy defaults to READ-COMMITTED, whereas TiDB defaults to (and recommends) MySQL's default of REPEATABLE-READ.