morgo
Joined 17 years ago
Karma
748
Submissions
294
Member since
Aug 18
Work: Cash App. Previously: TiDB, MySQL, Vitess.
View on Hacker NewsRecent submissions
Comment · 4 years ago
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.
Comment · 4 years ago
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).
Comment · 6 years ago
I really like the workflow GitHub uses for this: https://github.blog/2020-02-14-automating-mysql-schema-migra...
(It makes use of skeema, which allows you to track your schema in a declarative way vs. ALTER TABLE statements.)
Comment · 7 years ago
For MySQL there are better ways to do this:
https://mysql.wisborg.dk/2018/08/10/innodb-progress-informat...
The article is MariaDB specific.
Comment · 7 years ago
An interesting example to bring up mysql_embedded :-)
I was the product manager, and we did have complaints about the size. So it was removed:
https://mysqlserverteam.com/mysql-8-0-retiring-support-for-l...
I don't believe there have been any regrets.
Comment · 7 years ago
If someone uses `utf8` in MySQL 8.0, they will get a warning suggesting they should use `utf8mb4`, because `utf8` will be deprecated.
Redefining `utf8` to mean 4-byte would break the upgrade since existing tables would not be able to join against newly created tables.
This is discussed here: https://mysqlserverteam.com/sushi-beer-an-introduction-of-ut...
Comment · 7 years ago
Hi! Former product manager for MySQL here. The defaults have changed a lot across major releases:
https://mysqlserverteam.com/new-defaults-in-mysql-8-0/
https://dev.mysql.com/doc/refman/5.7/en/added-deprecated-rem...
https://dev.mysql.com/doc/refman/5.6/en/server-default-chang...
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!
Comment · 7 years ago
It should work fine, with one item to note:
I believe SqlAlchemy defaults to READ-COMMITTED, whereas TiDB defaults to (and recommends) MySQL's default of REPEATABLE-READ.
Comment · 7 years ago
Morgan from the TiDB team here.
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 :-)
Comment · 7 years ago
Update: The documentation has now been updated https://github.com/pingcap/tidb/pull/9144
Comment · 7 years ago
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.
Comment · 7 years ago
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:
Comment · 8 years ago
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.
Comment · 8 years ago
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.