shenli3514

I think most of the slow queries can be identified and fixed by simple rules with a proper tool. Like https://docs.percona.com/percona-toolkit/pt-query-digest.htm... . Have you done any benchmark about the accuracy of your tool?

This is an interesting product. Any comparison with other DBA tools? There are many tools can fix the slow queries, based on rule+statistics.

discussions here: https://x.com/bcherny/status/2077929379661844559?s=20

Idempotency is what bites me most in practice — I've been driving these against an unreleased database I work on. The main trap is using the op_id as the idempotency key rather than a business key the client reuses on retry. When they're the same thing, the checker is trivially true and the test passes without testing anything.

No-lost-ack is conceptually the same shape with a simpler property (every acked write shows up at the end), but it breaks the same way most checkers break — if the recorder treats timeouts as success or failure instead of "unknown," real lost writes silently disappear.

Recovery after partial failure is where the AI-agent angle gets shaky honestly. Quiescence is the hard part. Agents will declare a system "recovered" while compaction is still running in the background. The skill forces a three-part check (no in-flight ops, no pending background work, replicas converged) before the invariant runs. How reliably that holds up against a specific SUT, I'm still figuring out.

The availability of Claude service is terrible :(

It is sad to see this. MySQL has no future under Oracle. The open-source community is dead. The community should turn to alternatives.

https://www.tldl.io/newsletters/720001

GPT-o1, Claude-3.5 new,... those models are capable to write quite good code. I think it just need a workflow (make be Github Action) to make it possible.

https://www.tldl.io/newsletters/150001

Went thru the document: https://slatedb.io/docs/introduction/#use-cases I can not understand why are they targeting the following use cases with this architecture. * Stream processing * Serverless functions * Durable execution * Workflow orchestration * Durable caches * Data lakes

ChatGPT definitely can do the work. I used Google search for git command when I was a beginner. But I met the situation of losing all the changes with a single git command. This tool may be helpful for beginners. It can explain commands and also raise red flags for risky commands.

Thanks for the feedback. I made a few updates. Would you mind having another try? The new version give you more options to tune the generation, including analyzing your social account posts (support HN, working on X and Linkedin). https://www.gitdevtool.com/social-share

I think for some engineers, great engineering blog posts can build their technical reputation.

I think ChatGPT Plus should be the main driver for revenue growth.

A free course designed for people with some coding experience, who want to learn how to apply deep learning and machine learning to practical problems.

Our findings reveal that while unsupervised fine-tuning offers some improvement, RAG consistently outperforms it, both for existing knowledge encountered during training and entirely new knowledge. Moreover, we find that LLMs struggle to learn new factual information through unsupervised fine-tuning, and that exposing them to numerous variations of the same fact during training could alleviate this problem.

Chroma looks good. https://github.com/chroma-core/chroma 10k+ stars, very easy to use, and can be used as an embedding database

The SQL Murder Mystery is designed to be both a self-directed lesson to learn SQL concepts and commands and a fun game for experienced SQL users to solve an intriguing crime.

Shocked to hear about this. Rest In Peace Bob.

I use ChatGPT a lot.

There will be a series of blog post about distrbited SQL database. This is the first one.

Thanks for mentioning TiDB here. It is mysql compatible HTAP database. But different with AlloyDB. We do not reuse the code of MySQL/PostgreSQL. So there is no legacy code and more suitable for the HTAP scenario. It is easy to scale out and available on any cloud. More information here: https://docs.pingcap.com/tidb/dev/quick-start-with-htap

No. Because database will still be the core of the IT service, enterprises still need engineers have the expertise about database. But I think the responsibility of DBA is changing, due to evolution of the database technology and the movement to public cloud service. Since the third-party vendor will provide better and better database service (I would like to use service than product, because the rise of DBaaS on cloud), DBAs could shift some of their time from DB layer to the platform/application layer. Maybe there will be a new name for DBA, like DB/Data engineer.

Thanks for the clarification. There is not automatically way to enlarge the length. And I think that is not the things should be done by the database itself. That's my own opinion. But I think it would be helpful to show a warning to DBA when the allocated value is close to the upper limit.

For the following question, the answer is in seconds. To enlarge the column length, TiDB just need to modify the meta data. "how long does it take to enlarge a pk column using alter table on a database that has a significant fraction of 4 billion rows?"

Thanks for your comment. Yes, there is only one of the issues are actually related to scalability. So I mentioned Chaos-Mash as well. Hope it would be helpful to test large scale distributed system. Both of them can not solve all the issues. But I hope they would be helpful for some of the issues.

Do you mean Chaos-Mesh or TiDB? For Chaos-Mesh, it is not a suitable tool for deterministic unit test case (like inserting an overflow value and expect to get an error). For TiDB, it is easy to use `Alter Table` statement to enlarge the length of a integer column with zero impact on the online business.

I'm the VP of Engineering from PingCAP.

As a devoted customer and a big fan of GitHub, it’s devastating to see service interruptions and our business impacted by these problems; as the team behind TiDB, we (PingCAP) believe there is something we can do to help solve the database high availability and scalability problem. We would like to propose the database team in GitHub to consider the TiDB platform. TiDB and TiKV can work as a scale-out MySQL and it has been battle-tested in all kinds of hyper-scale scenarios.

Additionally, just in case you didn’t do this, we also recommend GitHub considering the Chaos-Mesh project (https://github.com/pingcap/chaos-mesh) to do Chaos Engineering. Chaos Mesh was our internal chaos engineering platform and we open-sourced it on Dec. 31, 2019. It can be used for simulating different kinds of failures including network partition, flaky disk, node outage. You can easily use it to simulate failures in a test environment and confirm that the high availability works as expected.

May I know how many instances are there in crdb/tidb cluster and the concurrency in the benchmark? We found that for small clusters (for example 3 instances), CRDB could be fast in read-only workload. Because CRDB is single binary, about 1/3 read operation will not involve RPC. TiDB need to involve a RPC for every request. For larger scale cluster or high concurrency, it is a different story.

I think they are created using google slides.

Do you mean 1PC transaction?