I work remotely and I've decided that ON is the right choice for me. I made this choice when I started joining a lot of calls where they had to be in English because of me. I figured camera on was a good way to show I was paying attention.
However one of the perks of being a male is that society only ever expects me to take a shower to be presentable. So I'm totally cool if a colleague wants to leave the camera off even if it's a 1 on 1.
You are correct, it is a disk-format issue, and MySQL officially supports in-place upgrade between versions.
It's actually quite hard to fix bugs in charset/collations, because any changes to the sort order implicitly could affect the on-disk format (indexes are sorted).
One detail that is not always obvious is how much work goes into limiting regressions. The work to switch to utf8mb4 really started in MySQL 5.6 by not allocating the sort buffer in full (and then further improved in 5.7). 8.0 then added a new temptable storage engine for variable length temp tables.
These are not small cases either: When you compare to latin1 because the _profile_ of queries could change from all in memory to on disk, we could be talking about 10x regressions. In MySQL 8.0 it is more like 11% https://www.percona.com/blog/2019/02/27/charset-and-collatio...
Edit: Also forgot to mention, switching the default character set broke over 600 tests. It's not as easy as it sounds!
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 :-)
Morgan from the TiDB team here. We are working on at rest encryption now - stay tuned.
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.
Morgan from the TiDB team here. Thank you for the feedback, and I agree with you. We actually took this line out from the same copy in the docs: https://pingcap.com/docs/
(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:
Hi Rafuino, send me an email at [firstname]@pingcap.com and I'll connect you with the benchmark author.
Just to expand a little bit on this comment:
> The expected data volume for TiDB is larger than memory.
There is both total data volume, and working set (workload dependent). This point was in regards to some databases use data structures which require the total data to be memory resident.
The working set is a longer discussion - it could just be a few percent of the total volume, and some working sets have a "long tail" of cache misses vs. short tail. And it can vary for a B+tree vs. an LSM tree too. RocksDB uses compression which helps a lot.
It is not clear in this benchmark if the working set fits entirely in memory. Thanks for bringing it to my attention - I will follow up and make sure we do a better job of communicating what is being tested.
Yes, that is correct. I hope to see FOREIGN KEY constraints added in the future.
In the interim though, when comparing TiDB to (application) sharded systems, it is important to clarify that FOREIGN KEYS will only be available locally to a single server. So it is a limitation that some of the large deployments we encounter are already familiar with.
- We suggest you use TiDB for "adhoc OLAP", and Spark for more complicated cases. While parallel, the data is still stored in a row-format (more on that next year!), so an OLAP-only solution may still have performance advantages. TiDB also supports hash joins/aggregation/sort merge joins etc. So compared to MySQL for example, you should see quite a performance improvement.
TiDB is an open source NewSQL database that speaks the MySQL protocol. You can scale it horizontally by adding nodes.
It is a relational DB (not time series). To describe a couple of differentiators from its peers:
- It aims to optimize both OLTP and OLAP workloads (aka HTAP)
- It uses a component-based architecture (the TiDB server is stateless and speaks the MySQL protocol. TiKV is the distributed storage layer. Thus, you can scale either independently. You can also connect to tikv directly from Spark).
However one of the perks of being a male is that society only ever expects me to take a shower to be presentable. So I'm totally cool if a colleague wants to leave the camera off even if it's a 1 on 1.