c4pt0r

CTO of TiDB here. TLDR, yes, DBA is still a good job, but to embrace new technologies.

From a database developer's point of view, I have always admired the work of DBA, although I can develop the kernel of the database, I can also write a SQL engine, never been good at writing complex and efficient SQL, totally different skills.

I have noticed a trend in the database field in recent years: Everything goes to the cloud.

Because of cloud is more and more popular, and the cloud is providing fully managed database service, it is hard to say the trend of traditional DBA job is getting less and less, the DBA expert is still extremely popular, However DBA will alive and can be more welcome, because there are more and more new technologies are evolving fast, just like what we're proudly building: TiDB, an HTAP database provides SQL interface, support complex analytic workloads, as well as the OLTP load. DBA could reuse their skills, and even better, they are not just DBA, they can also act as a data expert, help application developers to optimize SQL queries, and schema design, and help them to design and optimize systems.

A good example is my recent little side project: https://ossinsight.io/, although the architecture is simple, it contains some complex SQL in there, I turned to my DBA friends to get this application done correctly and efficiently.

I think YDB's architecture is more like TiDB

TiDB/TiKV's CTO here. I don't think so, the co-founding team is not ex-Googlers, but we're all big fans of the papers published by Google, especially, the Spanner/F1/BigTable...So it's no surprise that this project has a little bit `Google flavor`

Ref: https://tikv.org/docs/3.0/concepts/overview/

Thank you for pointing out, this place is indeed a typo, what I want to say here is: because in our implementation, the split operation of a raft group is treated as a special raft log, because raft is a quourum-based algorithm, so in the case of network isolation, there may be followers that cannot receive the split command. I added a practical example after the paragraph. The solution to this problem is written behind, using the epoch + logic clock to ensure that the system is able to confirm the newest leader for specific raft group at any time.

Right, TiDB developer here, TiDB is more suitable for the scenarios that the data cannot fit in one machine. I would say sharding may bring extra maintenance cost and code refactoring, and sometimes the storage change is almost transparent to the application layer (well, that depends what’s the workload), but if the application can live with that, TiDB would be a good alternative for large MySQL sharding cluster

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...

I think the team is working on it right now.

TiDB doesn't want to solve all the problems, no silver bullet, right? And I think it's all about workload, some analytical workload requires CPU/Network resource instead of I/O, and OLAP workload isn't that frequently. Storage layer and computing layer are separated in TiDB stack, I think it's possible for some workload.

Hahahah, you're right. We picked Rust cuz our CEO and I think it's cool... XD

which is used in this project (Cpp_Redis)

https://github.com/Cylix/tacopie an interesting network library.

TiDB developer here, this is one of our early adoption user who is already used TiDB in production for over 6 months, this case is quite a 'hybrid' scenario, the workload contains both OLTP and OLAP but to the developer, only MySQL dialect.

I love sqlite, and I also love MySQL/MongoDB/PG/HBase/TiDB...just use the right tool for different job.

Thanks, that means a lot to us, btw happy Chinese new year! 新年快乐! :)

Hi from TiDB developer, we have many users in China, some of them have already used TiDB in production. Most of them treat TiDB as a drop-in replacement of MySQL sharding solution, and some of them use TiDB as an Ad-Hoc OLAP database with transactional insert/update/delete support.

What the ariticle does not say

1. This is not something 'hacking'. It is just a javascript running in chrome that checks the text on a button. If it changes to 'buy' then hits the button again and again. The unexpeced thing is, after hitting the buy button, the site does not jump to the payment page, instead, it just increases the item number! That's why four people can order more than a hundred mooncakes.

2. They didn't pay the abnormal orders. One of the four unlucky men said he had called the administration immediately after he found the problem and wanted to cancel the abnormal order. What happened next? He got an interview with a HR after 30 minutes, at 16:30. And at 18:30, he had been officially fired.

Here I do not want to judge if it is too tough to fire the four peoples so quickly. Let's see another old news of Alibaba

https://www.quora.com/unanswered/What-do-you-think-of-Alibab...

Last year, not that old. Can you guess the result? The HR who faked the exit interview just got an 'internal punish'. God knows what is an 'internal punish' but she was not fired. And the three developer who wrote the system got a 3.25 on his KPI which means 'just leave the company you rubbish' because the employee should not see the comment of the HR in the system.

See? No matter what happen, the coders are always the people who get punished in Alibaba.

Is Alibaba a great company? Yes, no doubt, it is a company with 250B USD market value. But as a coder, I do not want to join a company that lacks of respect for coders. Money is not everything.

That's all.

I like the idea, I think the author is trying to create a dead-simple css framework, but dont call it 'hack' please.

Looks very useful, I think it's time to replace my zsh.

The transaction model is similar to Google's Percolator, and with some performance improvements.

After months of hard work, we are excited to announce the alpha release of TiDB. With this milestone, TiDB becomes an ACID compliant distributed RDBMS.

TL;DR:

1. Use HBase with a cross-row transaction layer as underlying KV storage.

2. MySQL protocol server is ready.

3. Asynchronous schema update.

Aha! You got it. And we also want to build the distributed kv part in a proper way.

We choose MySQL protocol first because it's widely used and we are more similar with the tool chain and protocol in comparison with PostgresSQL. About the performance, Golang is design for building distributed system in Google, and the development productivity is perfect, InfluxDB's performance problem is partly caused by other reason.

very good news for android developer

something like BSON?