The evolution of user participation in record storage _php tutorial

There is a scenario where the user has two consecutive operations A and B, must be operation a completed before the operation B, if action A is not completed to trigger action B, then the user needs to perform action A, that is, the operation B execution needs to query operation A is performed. The problem here is that recording the user participation record provides a query method for the user and the operation. When different amounts of data are stored, our storage solutions can vary greatly, and as data grows, the solutions evolve.

1, the data volume is small, the user operation behavior fixed:
Storage: MySQL
Scenario: We have a UID key, a row of users, each user included as a column storage, such as uid=100, fixed storage for operation A and Operation B, the table structure is as follows:
Table_operation
UID Operation_a Operation_b
100 1 1

If we want to query whether the user participates in a or B, the direct use of Sql:select * from Table_operation WHERE uid=100 and Action_a=1 can achieve the goal.

Problem: The user operation is fixed, the expansion is difficult, if need to increase the user action behavior, you need to increase the field or add table storage, the method of increasing the field at a certain level of data (such as 1 million) is feasible, if the behavior is unrelated, the performance of the table storage scheme will be very good.

2, the data volume is small, the user operation behavior is not fixed:
Compared with scenario 1, the current scene, in addition to the UID of this variable, adds user action variables, that is, we need to focus on user and user operation of two variables.
Storage: MySQL
Scenario 1: Add the action table, generate the Operation ID, and the User Action behavior table stores the UID and OID. Inserts a record in the action behavior table when the user performs a new operation. Its table structure is roughly as follows:

Table_operation_info
OID Name
1 operation_a
2 Operation_b

Table_operation
UID OID
1 1
1 2

When you need to query whether user 1 has performed action A, use Sql:select * from Table_operation WHERE oid=1 and oid=1.
Problem: When the user's operation behavior is more, the user action behavior grows fast, the data quantity also is increasing gradually, possibly MySQL single table cannot load. The solution is described in a subsequent scenario.

3, large data volume, fixed user behavior
Storage: MySQL
Scenario: Compared to scene 1, the current scene is different from the data volume is larger than scene 1, the data volume is large to the MySQL single table load does not come over. This solution is to solve this problem, when the single table is too large, cost-effective method is generally the use of a sub-table. The variable of our current scene is the UID, as long as the horizontal table according to the UID.

4, the data volume is large, the user behavior is not fixed
Storage: MySQL
Scenario 1: This scenario applies to the user's operation behavior can be categorized, that is, in the scene 1 based on the addition of two sub-table operations, according to the operation of the class table and by the user table. We need to deal with two variables in the current scenario: Operation Behavior and user. Two sub-tables corresponding to these two variables, according to business rules to do operation behavior of the table operation, according to the user ID level segmentation to reduce the amount of data.

Scenario 2: This scenario is a complete horizontal table operation, based on the scenario 2 scenario, split by user level.

5, the amount of data is very large
Storage: MySQL
Scenario 1: Sub-database sub-table, at this time a library has been unable to meet the requirements, the rules based on the previous scenario implementation, according to the actual requirements can be considered to put different libraries on different machines.
Scenario 2: On the basis of the sub-database table, bitwise storage, because an operation behavior has not executed is a state, that is, 0,1 state, so we can use a bit to store, 64 bits can store 64 operation behavior of the tag.

Other storage
Key-value Database
Our needs actually do not need too many relational database functions, simple K-V database can realize our function, and in performance will be improved, after all, do less, will be fast.
First, whether it is the choice of memory-based, or non-memory (can be based on actual needs to choose, can also be hot data in memory, silent data in non-memory), suppose we have enough space to store.
Scenario 1:
With Uid+oid as the key, the value can be stored in the state, or can only be stored in (0 and 1), but there will be too many keys, especially when the amount of data is very large, the number of UID *oid, may be you can not resemble the magnitude.
Scenario 2:
In general, the user action behavior of the amount of data is completely less than the user's magnitude, and user action behavior data controllable. If we want to reduce the number of keys, we can use the Oid+ user partition index ID as key, here the so-called User Partition Index refers to the user in a certain number of partitions, all the users are recorded in this interval, such as 10000 for a range, The user with the UID 1 to 9999 is divided into interval 0, where the user can store 1 and 0 for this operation, and a key corresponding to value initialization stores 10,000 0. When a user of uid=100 performs an action, the 100th 0 is set to 1.
Scenario 3:
On the basis of Scenario 2, 10,000 0 are converted to 10,000 01 bits, assuming that a bit stores 50 bits, then a total of only 200 is required.
Scenario 4:
When the user volume is very large, most of the users may not be involved in an operation, then on the basis of scenario 3 we add a simple sparse matrix compression, to each storage bit index, when the storage value is not 0 o'clock will be stored.
Scenario 5:
I didn't expect you to share it.

Summary

• With the increase in the amount of data, the total idea is to divide the metallurgical, when a table to make the time table, when a library to do irregular sub-library, when a machine does not regularly add machines.
• For different storage media choices you need to consider costs and requirements, all of which are balanced results.
• Space-saving, bitwise storage.
• Do not optimize prematurely.

http://www.bkjia.com/PHPjc/444587.html www.bkjia.com true http://www.bkjia.com/PHPjc/444587.html techarticle There is a scenario where a user has two consecutive operations A and B, which must be done by operation A to perform action B, and if action A is not completed, action B is displayed, the user is shown ...

