Sub-database and sub-table is to solve the problem of query efficiency. A little idea, whether you can understand
1 in this way. The most sensitive to the query speed is the user, giving priority to the segmentation by the user ID, optimizing the query speed of the front-end user
2. Store ID and order ID create a separate redundant table to establish an association
3. There is a many-to-many relationship between orders and goods, which can be divided into ID tables, and redundant tables can be associated with
4. Can other technologies be introduced, such as mongodb, E Search

my idea:
1. The next single person id is user_id, the user table must be put in the main database, and the commodity table does not seem to think of the corresponding shard_nodes, then I also put it in the main database.
2. The store I understand should be associated with users, so you can use user_id as shard_nodes to store it in the sub-database area, and then use es as the participle.
3. Since placing an order is a user-related behavior, use user_id as shard_nodes to store it in the repositories

then the effect comes. Since it is a sub-database, there will certainly be no excessive expansion of the corresponding table data in a single shard database (for example, placing an order table, if it is all stored in the main database, assuming that the query with an order accumulation of 100w is a 100w Filter operation, and if it is vertically split according to user_id and shard_routing into 20 sub-libraries, the average sub-database will also issue order data in 5w, which must be much faster)

to sum up, go to the sub-database to obtain the order data of the users corresponding to the user_id, and then take the remaining fields to the goods / stores and so on to get the data.
like