Database sub-database sub-table

Why do database sub-databases and sub-tables
need to be sub- database? The amount of data in the database is not necessarily controllable. Without sub-database sub-tables, with the development of time and business, the tables in the database will become more and more The amount of data in the table will become larger and larger, and accordingly, the overhead of data operation, addition, deletion, modification and query will also become larger and larger; , disk, memory, IO, etc.) are limited, and eventually the amount of data and data processing capacity that the database can carry will encounter bottlenecks.


Implementation strategy
of sub-database and sub-table There are two types of sub-database sub-table: vertical segmentation and horizontal segmentation:
1. Vertical segmentation, that is, the table is divided according to functional modules and closeness of relationship and deployed to different libraries. For example, we will establish a definition database workDB, commodity database payDB, user database userDB, log database logDB, etc., which are used to store project data definition tables, commodity definition tables, user data tables, log data tables, and so on.
2. What is horizontal segmentation? When the amount of data in a table is too large, we can divide the data in the table according to certain rules, such as userID hashing, and then store it in multiple tables with the same structure, and different on the library.


Problems existing in sub-database and sub-table:
1. Transaction problem:
After the sub-database and sub-table are executed, the database transaction management is difficult because the data is stored in different databases. If you rely on the distributed transaction management function of the database itself to execute the transaction, it will pay a high performance price; if the application is assisted and controlled to form a transaction in the program logic, it will cause a programming burden.

2. Cross-database and cross-table join problem
After sub-database and sub-table are executed, it is difficult to avoid dividing the originally logically related data into different tables and different databases. At this time, the association operation of the table will be affected. Restriction, we cannot join tables located in different sub-databases, nor can we join tables with different sub-table granularities. As a result, the business that can be completed by one query may require multiple queries to complete.

3. Additional data management burden and data computing pressure
The most obvious additional data management burden is the problem of data positioning and the repeated execution of data additions, deletions, modifications and inspections. These can be solved by application programs, but will inevitably lead to additional logical operations. For example, for a user who records user scores In the data table userTable, the business requires to find out the 100 best performers. Before the table is divided, only one order by statement can be done, but after the table is divided, n order by statements will be needed to find out each The data of the top 100 users in a sub-table, and then combined and calculated to obtain the result.