Sub-table sub-database generally means that your business has high concurrency, or the business is split when the amount of data is large. However, the sub-table will bring a series of problems that you can not think of, such as the id allocation problem after sub-table and database we will discuss today.
Before splitting the table, the primary key in your data table can be set to auto-growth and so on. But after splitting the table, the id cannot be repeated in all the splitting tables. For example, my user table, I have a total of 3 tables. Then after the primary key with id 1 exists in u1, u2 and u3 cannot use the same primary key id. Therefore, after the tables are divided, the primary key in each table must not be the same, and the efficiency must be guaranteed.
Here I recommend several methods for your reference.
1. Each table still maintains its own automatic growth, but let them grow differently.
The specific method is to configure different starting values for each table. For example, u1 is configured with auto_increment = 1, and the step size is 3. The u2 configuration start value is 2 and the step length is also 3, the u3 configuration start value is 3, and the step length is also 3. After doing so, the primary key Id can automatically grow, and can be repeated.
2. Generate a unique primary key Id with the help of UUID, Mongo ObjectId, etc.
UUID is generated differently by each microservice system, so it can be considered as the primary key Id after table sharding. In addition, Mongo's ObjectId itself is also the UUID, so it can also be used as the primary key after the table is divided. However, the regularity of the two is relatively poor.
3. With the help of an open source distributed ID generator.
There are many open-source ID generators of this kind. I also wrote a similar article earlier, "A Simple Comparison of the Advantages and Disadvantages of the Top 5 Distributed ID Generators", which has been reprinted by many people.
For example, the famous snowflake, the id it generates is too long. But the efficiency is very high, suitable for ultra-high concurrency scenarios.
Others such as Leaf, sharding-jdbc, and uid-generator all need DB support, which means that additional tables are needed to support them.
The above is the generation strategy of the global ID after sub-table sub-database. What I’m discussing here is relatively simple, specifically combining with my company’s business to make adjustments or adopt other solutions.