Is it possible to optimize resource consumption and reduce maintenance complexity for small systems?

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 可否为小系统优化资源消耗和降低运维门槛?

| username: TiDBer_oHpB1az2

For small systems developed and maintained by small teams, with an expected data volume of less than 100 million, or even less than 10 million, within three years, and not much traffic:
If using a single MySQL instance, the memory usage is a few hundred MB. Switching to CockroachDB, with three instances, each instance also uses a few hundred MB of memory.
Looking at the CPU, the CPU usage of both MySQL and CockroachDB is almost negligible.

In contrast, TiDB’s memory usage is measured in GB.

Can TiDB be optimized to reduce resource consumption and lower the maintenance threshold for such systems???

| username: Billmay表妹 | Original post link

Let me give you an analogy,

Suppose the distance between your home and your company is only 2km.
Then you can choose: walking, riding a shared bike, or taking a taxi to the company.

Walking is free, a shared bike costs 1.5 yuan, and the starting fare for a taxi is 12 yuan.
You can’t just say why the starting fare for a taxi can’t be 1.5 yuan, right?

Suppose the distance between your home and your company is 10km,
Then taking a taxi takes 20 minutes, while taking the bus and subway takes 50 minutes.

Taking a taxi costs 20 yuan, and the subway costs 3 yuan. How would you choose?

| username: 啦啦啦啦啦 | Original post link

You can learn about multi-tenancy and migrating multiple MySQL instances to TiDB.

| username: zhanggame1 | Original post link

TiDB is actually not suitable for small systems. Besides having low memory, just the OOM (Out of Memory) issues alone are unbearable.

| username: redgame | Original post link

Look into the distance. Haha.

| username: 有猫万事足 | Original post link

If you have such a system, there’s really no need to use TiDB; the ones you mentioned are quite good. If you have a dozen such systems, then putting them on a TiDB cluster with multi-tenant usage and proper resource management might be a good idea. In this case, you probably wouldn’t mind TiDB consuming more resources.

Technology is meant to solve problems. If you already know clearly how to solve the problem, why take a detour?

| username: 人如其名 | Original post link

I suggest using SQLite. A few hundred MB can support billions of data entries, and its CPU usage is even lower than MySQL. If MySQL’s CPU usage is negligible, SQLite’s CPU usage might be close to zero.

| username: 像风一样的男子 | Original post link

For small data volumes, using TiDB is not cost-effective; MySQL 8.0 is sufficient.

| username: linnana | Original post link

The advantage of TiDB lies in its ability to handle high concurrency with linear scalability, provided that it consumes resources.

| username: Anna | Original post link

Do you have regulatory requirements? Make plans according to the size of the company, step by step. Otherwise, it might be better to outsource this part of the workforce.

| username: 春风十里 | Original post link

What I understand about TiDB is that its core purpose is to address some of the shortcomings of single-node MySQL, such as scalability issues, multi-center high availability solutions with RPO of 0, and performance problems encountered in large-scale databases with many table associations, especially in internet businesses and large customer volumes. For instance, when the database is large, traditional sharding solutions are not very friendly to the application side and do not fully support transactions. Achieving multi-center RPO of 0 with traditional single-node databases is quite challenging. Therefore, TiDB has certain hardware requirements, including high starting memory and mandatory SSDs, and a minimum of 3 nodes for cluster deployment. This makes it unsuitable for very small-scale businesses. It can be said that MySQL fully meets the needs of traditional business databases without a certain scale. If your system grows to a certain extent or has high regulatory or internal requirements, switching to TiDB is not too late, as TiDB is almost fully compatible with MySQL.