On the granularity of vertical splitting vertical sharding

The granularity of vertical segmentation refers to allowing a few levels of associated tables to be placed in a shard when doing vertical segmentation. This problem has a great impact on application and sharding implementations.

The more the association interrupts, the more the affected join operations, the more compromises the application makes, but the simpler the routing of a single table, and the smaller the relevance to the business, the easier it is to use the uniform mechanism. An extreme scenario in this direction is to interrupt all connections, each with a routing rule, which can be handled automatically using a unified mechanism or framework. For example, a framework such as amoeba can be routed and can only be routed through SQL features such as the ID of a table.

Conversely, if the association interrupts less, the less restrictive the join operation is, the smaller the compromise the application needs to make, but the more complex the routing of the table is, and the greater the association with the business, the more difficult it is to use the uniform mechanism, and the need to implement the route individually for each data request. The extreme scenario in this direction is that all tables are in a shard, i.e. there is no vertical segmentation, so that no correlation is interrupted. Of course this is very extreme, unless the whole database is very simple, the number of tables is very small.

The actual granularity control needs to combine the "business tightness" and "tabular data volume" Two factors, generally speaking: if the form of a close relationship, and the amount of data is not large, the growth rate is very slow, it is appropriate to put in a shard, no need for horizontal segmentation; If the table is grouped together with large amount of data and rapid growth, it is bound to vertical segmentation on the basis of horizontal segmentation, horizontal segmentation means that the original single shard will be subdivided into a number of smaller Shard, Each shard has a primary table (that is, a table that will hash with that table ID) and multiple relative tables associated with it.

In a word, the granularity of vertical segmentation presents the advantages and disadvantages coexist in two opposite directions and play game with each other. What the architect needs to do is to achieve a balance between maximizing the benefits of the project in conjunction with the actual situation.

Original link: http://blog.csdn.net/bluishglc/article/details/6274841