Data storage method, server and storage medium

Abstract

The application provides a data storage method, a server and a storage medium. The method comprises the following steps: the server can acquire the number of system users, the number of estimated participating users in a current activity and the number of allowed participating projects in the current activity. The server can calculate the ratio of the number of system users to the number of estimated participating users. When the ratio is greater than a preset threshold, the server can store the participation information in the current activity in the form of a bitmap. The server can calculate the target number of fragments of each bitmap according to the number of system users, the number of estimated participating users and the number of allowed participating projects. The server can fragment the bitmap according to the target number of fragments, and record the participation information of the system users in the current activity by using the fragmented bitmap. The method provided by the application improves the utilization rate of the storage space and improves the efficiency of data storage and reading.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a data storage method, server, and storage medium. Background Technology

[0002] With the development of computer technology, more and more technologies are being applied in the financial sector, and the traditional financial industry is gradually transforming into Fintech, including marketing campaigns. However, due to the massive number of users in the financial industry's systems, higher demands are placed on technology. In marketing campaigns, electronic benefits have replaced traditional paper benefits, allowing for more convenient promotion and use. Simultaneously, the data management backend can record the number of participants and the distribution of benefits in marketing campaigns.

[0003] In existing technologies, data management backends can use bitmap algorithms to record marketing campaign information. For example, the data management backend can create a bitmap for each benefit. The size of each bitmap can be set according to the number of users in the system. Each system user corresponds to one bit in a bitmap. When user A in the system acquires benefit B, the data management backend can set the value of the bit corresponding to user A in the bitmap for benefit B to 1, thus recording user A's acquisition of benefit B.

[0004] However, the size of each bitmap in this bitmap algorithm typically needs to be set based on the number of users in the system. When the number of users in the system is very large, but the number of users actually participating in the marketing campaign is relatively small, it can easily lead to a waste of a large amount of data space in each bitmap, resulting in low data storage efficiency. Summary of the Invention

[0005] This application provides a data storage method, server, and storage medium to address the problem that when the number of users actually participating in a marketing campaign is relatively small, it can easily lead to a waste of a large amount of data space in each graph, resulting in low data storage efficiency.

[0006] In a first aspect, this application provides a data storage method, including:

[0007] Obtain the number of system users, the estimated number of participating users in the current activity, and the number of allowed items in the current activity; wherein, each activity item corresponds to a bitmap;

[0008] When the ratio of the number of system users to the estimated number of participating users is greater than a preset threshold, the target number of slices for each bit of the graph is determined based on the number of system users, the estimated number of participating users, and the number of allowed participating projects.

[0009] The bitmap is fragmented according to the target number of fragments, and the fragmented bitmap is used to record the participation information of system users in the current activity.

[0010] Optionally, determining the target number of slices for each bit of the graph based on the number of system users, the estimated number of participating users, and the number of allowed participating projects specifically includes:

[0011] The range of the number of shards is determined based on the estimated number of participating users;

[0012] Based on the range of the number of fragments, enumerate the bitmap space occupancy corresponding to each of the number of fragments within the range;

[0013] Compare the bitmap space occupancy corresponding to each of the stated fragment numbers, and determine the fragment number corresponding to the minimum bitmap space occupancy as the target fragment number.

[0014] Optionally, the bitmap space occupancy corresponding to each number of fragments within the range specifically includes:

[0015] The bitmap space occupancy corresponding to the number of fragments is determined based on the number of system users, the estimated number of participating users, the number of allowed participating projects, and the number of fragments.

[0016] Optionally, determining the bitmap space occupancy corresponding to the number of shards based on the number of system users, the estimated number of participating users, the number of allowed participating projects, and the number of shards specifically includes:

[0017] The total keyword length of each bitmap is determined based on the number of allowed participating projects, the number of fragments, and the fixed keyword length; wherein each fragment corresponds to one keyword.

[0018] The total space occupancy of all the segments of each bitmap is determined based on the average segment length of each segment, the probability value that each segment occupies 50% of the storage space, the average storage space saved by each segment, and the number of segments.

[0019] The bitmap space occupancy is determined based on the total length of the keywords in each bitmap, the space occupancy of all the fragments in each bitmap, and the number of allowed participating items.

[0020] Optionally, recording the system user's participation information in the current activity specifically includes:

[0021] The number of projects participated in by the system user is determined based on the value of the system user in each slice of the graph.

[0022] When the number of participating projects is less than the allowed number of participating projects, the value of the system user in the one-dimensional graph segment is modified from the first data to the second data.

[0023] When the number of participating projects is greater than or equal to the allowed number of participating projects, the system user is denied participation in the project.

[0024] Optionally, the method further includes: fragmenting the bitmap according to the target number of fragments, and using the fragmented bitmap to record the system user's participation information in the current activity.

[0025] The bitmap space occupancy is determined based on the number of system users, the estimated number of participating users, the number of allowed participating projects, and the target number of fragments.

[0026] The key-value pair space usage is determined based on the number of system users, the estimated number of participating users, and the number of allowed participating projects;

[0027] When the space occupied by the key-value pair is less than the space occupied by the bitmap, the key-value pair is used to record the participation information of the system user in the current activity.

[0028] Optionally, the method further includes:

[0029] Retrieve the number of projects participated in by the system user from the key-value pairs corresponding to the system user;

[0030] When the number of participating projects is less than the allowed number of participating projects, the number of participating projects for the system user will be increased by one unit value;

[0031] When the number of participating projects is greater than or equal to the allowed number of participating projects, the system user is denied participation in the project.

[0032] Secondly, this application provides a data storage device, comprising:

[0033] The acquisition module is used to acquire the number of system users, the estimated number of participating users in the current activity, and the number of allowed items in the current activity; wherein, each activity item corresponds to a bitmap;

[0034] The processing module is used to determine the target number of slices for each bitmap when the ratio of the number of system users to the estimated number of participating users is greater than a preset threshold, based on the number of system users, the estimated number of participating users, and the number of allowed participating items; to slice the bitmap according to the target number of slices; and to use the sliced ​​bitmap to record the participation information of system users in the current activity.

[0035] Optionally, the processing module is specifically used for:

[0036] The range of the number of shards is determined based on the estimated number of participating users;

[0037] Based on the range of the number of fragments, enumerate the bitmap space occupancy corresponding to each of the number of fragments within the range;

[0038] Compare the bitmap space occupancy corresponding to each of the stated fragment numbers, and determine the fragment number corresponding to the minimum bitmap space occupancy as the target fragment number.

[0039] Optionally, the processing module is specifically used for:

[0040] The bitmap space occupancy corresponding to the number of fragments is determined based on the number of system users, the estimated number of participating users, the number of allowed participating projects, and the number of fragments.

[0041] Optionally, the processing module is specifically used for:

[0042] The total keyword length of each bitmap is determined based on the number of allowed participating projects, the number of fragments, and the fixed keyword length; wherein each fragment corresponds to one keyword.

[0043] The total space occupancy of all the segments of each bitmap is determined based on the average segment length of each segment, the probability value that each segment occupies 50% of the storage space, the average storage space saved by each segment, and the number of segments.

[0044] The bitmap space occupancy is determined based on the total length of the keywords in each bitmap, the space occupancy of all the fragments in each bitmap, and the number of allowed participating items.

[0045] Optionally, the processing module is specifically used for:

[0046] The number of projects participated in by the system user is determined based on the value of the system user in each slice of the graph.

[0047] When the number of participating projects is less than the allowed number of participating projects, the value of the system user in the one-dimensional graph segment is modified from the first data to the second data.

[0048] When the number of participating projects is greater than or equal to the allowed number of participating projects, the system user is denied participation in the project.

[0049] Optionally, before recording the system user's participation information in the current activity using the fragmented bitmap, the processing module is further configured to:

[0050] The bitmap space occupancy is determined based on the number of system users, the estimated number of participating users, the number of allowed participating projects, and the target number of fragments.

[0051] The key-value pair space usage is determined based on the number of system users, the estimated number of participating users, and the number of allowed participating projects;

[0052] When the space occupied by the key-value pair is less than the space occupied by the bitmap, the key-value pair is used to record the participation information of the system user in the current activity.

[0053] Optionally, the processing module is further configured to:

[0054] Retrieve the number of projects participated in by the system user from the key-value pairs corresponding to the system user;

[0055] When the number of participating projects is less than the allowed number of participating projects, the number of participating projects for the system user will be increased by one unit value;

[0056] When the number of participating projects is greater than or equal to the allowed number of participating projects, the system user is denied participation in the project.

[0057] Thirdly, this application provides a server, including: a memory and a processor;

[0058] The memory is used to store computer programs; the processor is used to execute the first aspect and any possible data storage method in the design of the first aspect according to the computer programs stored in the memory.

[0059] Fourthly, this application provides a computer-readable storage medium storing a computer program, wherein when at least one processor of a server executes the computer program, the server executes the data storage method of the first aspect and any possible design of the first aspect.

[0060] Fifthly, this application provides a computer program product comprising a computer program that, when at least one processor of a server executes the computer program, enables the server to execute the first aspect and any possible data storage method in the design of the first aspect.

[0061] The data storage method provided in this application improves storage space utilization, avoids overly concentrated access to storage space, and enhances data storage and retrieval efficiency by: obtaining the number of system users; determining the estimated number of participating users based on the current activity; obtaining the number of allowed items in the current activity, with each item in the current activity corresponding to a bitmap; calculating the ratio of the number of system users to the estimated number of participating users; comparing this ratio with a preset threshold; storing the participation information of the current activity using a bitmap when the ratio is greater than the preset threshold; calculating the target number of fragments for each bitmap based on the number of system users, the estimated number of participating users, and the number of allowed items; fragmenting the bitmap according to the target number of fragments; and using the fragmented bitmaps to record the participation information of system users in the current activity. Attached Figure Description

[0062] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0063] Figure 1 A bitmap schematic diagram provided for one embodiment of this application;

[0064] Figure 2 A bitmap illustration of an embodiment of this application;

[0065] Figure 3 A schematic diagram illustrating a scenario for distributing activity benefits, provided as an embodiment of this application;

[0066] Figure 4 A flowchart illustrating a data storage method provided in one embodiment of this application;

[0067] Figure 5 A flowchart illustrating a data storage method provided in one embodiment of this application;

[0068] Figure 6 A flowchart illustrating a data storage method provided in one embodiment of this application;

[0069] Figure 7 A flowchart illustrating a data storage process provided in one embodiment of this application;

[0070] Figure 8 This is a schematic diagram of the structure of a data storage device provided in an embodiment of this application;

[0071] Figure 9This is a schematic diagram of the hardware structure of a server provided in one embodiment of this application. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0073] The terms "first," "second," "third," "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be used interchangeably where appropriate. For example, without departing from the scope of this document, first information can also be referred to as second information, and similarly, second information can also be referred to as first information.

[0074] Depending on the context, the word "if" as used here can be interpreted as "when," "when," or "in response to determination."

[0075] Furthermore, as used herein, the singular quantifiers “a,” “one,” and “the” are intended to also include plural quantifiers, unless the context indicates otherwise.

[0076] It should be further understood that the terms “comprising” or “including” indicate the presence of features, steps, operations, elements, components, items, kinds, and / or groups, but do not exclude the presence, occurrence, or addition of one or more other features, steps, operations, elements, components, items, kinds, and / or groups.

[0077] The terms “or” and “and / or” as used herein are interpreted as inclusive, or mean any one or any combination thereof. Therefore, “A, B, or C” or “A, B, and / or C” means “any one of the following: A; B; C; A and B; A and C; B and C; A, B, and C”. Exceptions to this definition occur only when combinations of elements, functions, steps, or operations are inherently mutually exclusive in some way.

[0078] With the development of computer technology, more and more technologies are being applied in the financial field, and the traditional financial industry is gradually transforming into Fintech, including marketing activities. However, due to the massive number of users in the financial industry's systems, higher demands are placed on technology. In marketing activities, using electronic benefits instead of traditional paper benefits allows for more convenient promotion and use, while also enabling more precise control over benefit distribution, thereby accurately controlling marketing costs. Benefits can include coupons, discount coupons, membership card discounts, etc. For example, a data management backend can be set up on the server to record information such as the number of users participating in the activity, the distribution of benefits, and the number of benefits obtained by each user. The record of the number of benefits obtained by each user can also verify the maximum number of benefits each user can obtain in this activity, ensuring that the number of benefits obtained by a user in this activity is less than a preset limit.

[0079] In existing technologies, to accurately control the number of benefits issued, servers can use a Redis cluster to store the number of benefits each user has already acquired. Each time benefits are issued, the server can query the number of benefits a user has already acquired stored in Redis and verify it. If the number of benefits is less than a preset limit, the server can send the benefit to the user. Otherwise, the user will not be able to acquire any more benefits. The server can use a key-value pair approach to store the number of benefits each user has acquired in Redis. In this key-value data structure, each user requires storage space for a key and storage space for a value. The key can include information such as the user's ID to uniquely identify the user. The length of the key is usually fixed, typically occupying about 50 bytes of storage space. The number of users participating in the activity is usually directly proportional to the space required to store user participation information. When there are a massive number of users, assuming 100 million users, using a key-value data structure, the space occupied by all users' keys can reach:

[0080] 100,000,000×50(byte)÷1024÷1024≈4768(m)

[0081] Therefore, compared to key-value data structures, bitmaps can save storage space more effectively when dealing with massive numbers of users. In a bitmap, each user requires one bit of storage space. This 1-bit storage space can be set to a value of 0 or 1. This 1-bit storage space can be used to indicate whether the user has already acquired the benefit. Assuming there are 100 million users, the server can allocate 100 million bits of storage space to store whether each of the 100 million users has acquired the benefit. Figure 1 As shown, each cell corresponds to 1 bit. The last cell corresponds to the 100 millionth bit. The storage space occupied by this bitmap is:

[0082] 100,000,000(bit)÷8÷1024÷1024≈12(M)

[0083] That is, when there are 100 million users, a single bitmap requires 12 MB of storage space. When the preset upper limit for the benefits each user receives in this marketing campaign is N, the server can have N bitmaps. That is, its space usage is 12N MB. For example, as... Figure 2 As shown, the first, second, and third coupons correspond to three bitmaps representing three benefits. When a user with an offset of 1 receives all three benefits, the value of the cell with an offset of 1 in each of the three bitmaps is 1. When a user with an offset of 4 receives two benefits, two of the three cells with an offset of 4 in the three bitmaps have a value of 1.

[0084] However, when there are a massive number of system users but a small number of users actually participating in activities, this key-value data structure is more space-efficient. This is because in a bitmap, once a user with a large ID participates in the activity, the size of the bitmap needs to be adjusted according to that user ID. In other words, the memory occupied by the bitmap is determined by the maximum offset. Even if the bitmap only stores information for one user, if that user ID is very large, it will still occupy a significant amount of space. For example, when the 100 millionth user participates in the activity, such as... Figure 1 As shown, the bitmap size is 12MB. In an extreme case, assuming only the 100 millionth user participates in the activity, a significant amount of storage space within this 12MB will be wasted. The key-value data structure, however, is different. The server can create a key-value pair for each user participating in the activity. That is, when only the 100 millionth user participates, the server only needs 50 bytes of storage space. It is evident that when the number of users in the system is very large, but the actual number of users participating in the marketing activity is relatively small, it can easily lead to a large waste of data space in each bitmap, resulting in low data storage efficiency.

[0085] To address the aforementioned issues, this application proposes a data storage method based on bitmap sharding. The server can divide a bitmap into L shards, each with an offset of maximum offset / L. The participation information of users from the 1st to maximum offset / L is stored in the first shard, the participation information of users from maximum offset / L+1 to 2 (maximum offset / L) is stored in the second shard, and so on. For example, when the system has 100 million users and only the 100 millionth user participates, only the bit corresponding to the maximum offset of the last shard is used, while the memory of other shards is not occupied. Therefore, the actual storage space used is only 12 / L (M). Even if there is a large offset, only the space of one shard will be wasted. This sharding method greatly improves memory utilization. Furthermore, this sharding method can also achieve load balancing, thereby avoiding excessive concentration of requests to access storage space, which could lead to reduced data processing efficiency.

[0086] After sharding the bitmap, the server needs to set a key in Redis for each shard. This key allows the server to quickly find the corresponding shard. The value corresponding to this key stores one shard of the bitmap. Therefore, the more shards there are, the more keys there are in Redis, and the more memory they consume. Currently, there is no reliable algorithm specifically for calculating the number of shards. The existing limit on the number of shards is only related to the number of nodes in the Redis cluster. The server only needs to ensure that the number of shards exceeds the number of nodes in the Redis cluster so that requests are not concentrated on a single node. Obviously, this setting of the number of shards is not optimal. Therefore, in this application, the server can determine the target number of shards for each bitmap based on the number of system users, the estimated number of participating users, and the allowed number of participating projects. This target number of shards is the optimal number of shards. The server can shard the bitmap according to this target number of shards to record user participation information.

[0087] For example, suppose there are 100 million users, with user IDs increasing from 1 to 100 million. After fragmenting the bitmap, each fragment can store information for 2^20 ≈ 1,050,000 users. The server can divide a bitmap into 95 fragments.

[0088] The server can use the Redis command SETBIT(key, offset, value) to set the activity participation information of a system user when the user's activity participation information changes.

[0089] The server can calculate the slice number (sliceNo) of the system user, and the calculation formula is as follows:

[0090] sliceNo = userId / (2^20)

[0091] That is, when the user ID is less than 2^20, sliceNo = 0. When the user ID is between 2^20 and 2^21, sliceNo = 1, and so on.

[0092] The server can calculate the offset of a system user on its corresponding slice using the following formula:

[0093] offset = userId % (2^20)

[0094] The server can determine the shard number and offset using the two formulas mentioned above. Based on this shard number and offset, the Redis command can be transformed into: SETBIT(key+sliceNo,offset,value).

[0095] To configure settings for the 100 millionth user, the command is: `SETBIT(key+95,385280,1)`. This command controls the server to configure the state of the 100 millionth user at position 385280 in the 95th shard. When only the 100 millionth user is participating in the current activity, and the other 94 shards are not in use, the amount of storage space occupied can be:

[0096] 385280 / 8 / 1024 / 1024≈43.37kb

[0097] As can be seen, fragmenting a bitmap can effectively save bitmap storage space when the number of participants in an event is small.

[0098] The technical solutions of this application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0099] Figure 3 This illustration shows a scenario illustrating the distribution of activity benefits according to an embodiment of this application. Figure 3As shown, the server can be associated with third-party channels, application product transaction functions, and application customer behavior. When the server detects that a user clicks to view a marketing campaign on a third-party channel, the server can issue benefits to that user. Alternatively, when the server detects that a user completes a product transaction within the application, the server can issue benefits to that user. Or, when the server detects that a user performs a corresponding action within the application, the server can issue benefits to that user. After determining that benefits need to be issued to a user, the server can call the coupon issuance interface in MES-SERVICE to implement the issuance of benefits. Subsequently, the server can query the number of benefits already obtained by the user in the Redis cluster. The server can call MES-SERVICE to verify the number of benefits. If the user's number of benefits is less than a preset limit, the server can issue the benefits to the user. At the same time, the server can also write the benefit issuance record to the transaction table in the MES database (mesdb). The server can update the number of benefits already obtained by the user in Redis. Additionally, the service can use Redis synchronization rules to synchronize this information in the Redis cluster.

[0100] In this application, a server is used as the executing entity to perform the data storage method of the following embodiments. Specifically, the executing entity can be a hardware device of the server, a software application implementing the following embodiments in the server, a computer-readable storage medium on which the software application implementing the following embodiments is installed, or code implementing the software application of the following embodiments.

[0101] Figure 4 A flowchart illustrating a data storage method according to an embodiment of this application is shown. Figure 3 Based on the illustrated embodiments, as Figure 4 As shown, with the server as the execution entity, the method in this embodiment may include the following steps:

[0102] S101. Obtain the number of system users, the estimated number of participating users for the current activity, and the number of allowed items for the current activity. Each activity item corresponds to a bitmap.

[0103] In this embodiment, the server can obtain the number of system users. For example, in the financial sector such as banking, the number of system users could be the number of users who have opened accounts at that bank. Similarly, in an application, the number of system users could be the number of users who have completed registration within that application.

[0104] The server can also determine the estimated number of participating users based on the current activity. Optionally, this estimated number of participating users can be the number estimated by the server based on the historical number of participants for the activity. Alternatively, the estimated number of participating users can also be the number of users who meet the participation rules of the current activity, as selected by the server based on the participation criteria of the current activity.

[0105] The server can also obtain the number of allowed participation items in the current activity. This allowed participation item number represents the number of items each user is permitted to participate in during the current activity. For example, if the current activity may include 20 activities, and each user can participate in a maximum of 6 activities during the activity, then the allowed participation item number is 6. Alternatively, if the current activity includes 5 ways to distribute benefits, with each benefit distributed in 6 installments, and to control activity costs, each user can obtain a maximum of 8 benefits during the activity, then the allowed participation item number is 8.

[0106] S102. When the ratio of the number of system users to the estimated number of participating users is greater than a preset threshold, determine the target number of slices for each graph based on the number of system users, the estimated number of participating users, and the number of allowed participating projects.

[0107] In this embodiment, during data storage, if the number of system users is large while the estimated number of participating users is small, storing the participation information of the current activity using key-value pairs can more effectively save storage space. As the estimated number of participating users increases, the storage space consumed by key-value pairs will increase linearly. However, the storage space required by a bitmap is relatively fixed. Therefore, when the number of system users remains constant while the estimated number of participating users is large, using a bitmap algorithm to store the participation information of the current activity can save more storage space. Therefore, the server can calculate the ratio of the number of system users to the estimated number of participating users. With a constant number of system users, the larger the estimated number of participating users, the smaller the ratio. Based on this characteristic, the server can compare this ratio with a preset threshold. When the ratio is greater than the preset threshold, it indicates that the estimated number of participating users is large, and the server can use a bitmap to store the participation information of the current activity.

[0108] In one example, when the ratio is less than or equal to a preset threshold, it indicates that the estimated number of participating users is low. In this case, the server can store the participation information of the current activity in key-value pairs. This process can be specifically described as follows: Figure 6 As shown in step S304.

[0109] When it's determined that the server will use a bitmap to store participation information, the number of system users is often too large, while the estimated number of participating users is smaller than the system user count. Therefore, when the server decides to use a bitmap algorithm to store the participation information for the current activity, there are usually many unused bits in the bitmap. To further improve the utilization of the bitmap's storage space, the server can calculate the target number of fragments for each bit of the bitmap based on the system user count, the estimated number of participating users, and the allowed number of participating items. The server can then fragment each bit of the bitmap according to this target number of fragments, thereby saving storage space. The specific process of the server calculating the target number of fragments can be described as follows: Figure 5 As shown.

[0110] S103. Divide the bitmap into fragments according to the target number of fragments, and use the fragmented bitmap to record the participation information of system users in the current activity.

[0111] In this embodiment, the server can partition each bitmap according to the target number of partitions calculated in step S102. The server can store the partitioned bitmap using key-value pairs. The key stores the partitioning information, which includes at least the bitmap sequence number and the partition requirement. For example, when there are 3 bitmaps and the target number of partitions is 10, a key value with a bitmap requirement of 1 and a partition requirement of 5 is used to store the bitmap information of the fifth partition in the first bitmap. The value stores the bitmap information of that partition. The maximum storage space occupied by each partition is the ratio of the number of system users to the target number of partitions. Therefore, the bitmap information of each partition includes the participation information of the number of system users / the target number of partitions (bits).

[0112] In one example, when a server needs to record a system user's participation information in the current activity, the specific steps may include:

[0113] Step 1: The server determines the number of projects a system user participates in based on the value of the system user in each graph segment.

[0114] In this step, the server can determine the corresponding shard and offset for each bit in the bitmap based on the user's user ID. The user ID is a numeric code used to uniquely identify a system user. For example, when there are 100 million system users, the user ID of the 100 millionth system user could be 100,000,000. When the target number of shards is 100, each shard records the participation information of 1 million system users. Therefore, each shard can include 1 million bits. The 100 millionth user's shard number is on the 10th shard, and the offset is 1 million. That is, the 100 millionth user can be stored in the 1 millionth bit of the 10th shard. Based on the shard number and the offset, the server can obtain the value corresponding to the system user in each bitmap. The server can determine the number of projects the system user participated in based on this value. Since in the bitmap, when a user participates in an activity, their value is set to the second data, the server can directly count the number of these second data. Since each bit only contains two values, 0 and 1, the second data is 1. Therefore, the server can directly calculate the number of projects participated in by users of the system by accumulating the results.

[0115] Step 2: When the number of participating projects is less than the allowed number of participating projects, the server modifies the system user's value in the one-dimensional graph slice from the first data to the second data. When the number of participating projects equals the allowed number of participating projects, the server rejects the system user's participation in the project.

[0116] In this step, the server compares the number of projects a system user has participated in with the allowed number of projects. Since the allowed number of projects is the same as the number of bitmaps, the maximum calculated number of projects participated in is equal to the allowed number. When the number of projects participated in equals the allowed number, it means the system user has acquired all the allowed benefits and participated in all the activities available in the current event. Therefore, when the number of projects participated in equals the allowed number, the server refuses the system user's continued participation in the current event. The server will no longer issue new benefits to the system user. Otherwise, when the number of projects participated in is less than the allowed number, it means the system user has not yet acquired all the allowed benefits. Alternatively, the system user can continue to participate in other projects in the current event. Therefore, when the number of projects participated in is less than the allowed number, the server can change the value in a bitmap from the first data to the second data. For example, when there are 5 bitmaps and the user has acquired 2 benefits, 2 of the 5 bitmaps have values ​​in the second data. In this case, the server can randomly select a bitmap from the other 3 bitmaps with values ​​in the first data and change the value corresponding to the system user from the first data to the second data. In a bitmap, each bit has a value of either 0 or 1. Typically, the first bit is 0 and the second bit is 1. The first bit indicates that the user has not yet acquired the benefit, while the second bit indicates that the user has already acquired the benefit.

[0117] The data storage method provided in this application allows the server to obtain the number of system users. The server can also determine the estimated number of participating users based on the current activity. The server can also obtain the number of allowed items in the current activity. Each item in the current activity corresponds to a bitmap. The server can calculate the ratio of the number of system users to the estimated number of participating users. The server can compare this ratio with a preset threshold. When the ratio is greater than the preset threshold, the server can store the participation information of the current activity using a bitmap. The server can calculate the target number of fragments for each bitmap based on the number of system users, the estimated number of participating users, and the number of allowed items. The server can fragment the bitmap according to the target number of fragments and use the fragmented bitmap to record the participation information of system users in the current activity. In this application, by calculating the number of fragments, fragmented storage of the bitmap is achieved, improving the utilization of storage space, avoiding overly concentrated access to storage space, and improving the efficiency of data storage and retrieval.

[0118] Figure 5 A flowchart illustrating a data storage method according to an embodiment of this application is shown. Figure 3 and Figure 4 Based on the embodiments, such as Figure 5As shown, with the server as the execution entity, the calculation process for the target number of shards in this embodiment may include the following steps:

[0119] S201. Determine the range of the number of shards based on the estimated number of participating users.

[0120] In this embodiment, the server can determine the maximum number of shards based on the estimated number of participating users. This maximum number of shards is equal to the estimated number of participating users. For example, when there are 100 system users and the estimated number of participating users is 10, the maximum number of shards is 10. The minimum number of shards is 1. When a bitmap includes one shard, it is not sharded. When there are 100 system users and the estimated number of participating users is 10, in the worst case, the system users participating in the current activity are evenly distributed among all system users. In this case, if there are 10 shards, each shard contains one user, and all 10 shards will be used. If there are 20 shards, since there are only 10 users, only 10 shards will be used. Since each shard, in addition to the storage space occupied by the bitmap shard, also corresponds to a key, the space occupied by this key will increase as the number of bitmap shards increases. Therefore, the lower limit of the number of shards is 1, and the upper limit is the estimated number of participating users.

[0121] S202. Based on the range of the number of fragments, calculate the bitmap space occupied for each fragment within the range.

[0122] In this step, after determining the range of the number of shards, the server can use the number of shards within that range, along with the number of system users, the estimated number of participating users, and the allowed number of participating projects, to calculate the bitmap space usage corresponding to each number of shards. For example, when the lower limit of the number of shards is 1 and the upper limit is 1000, the server can calculate the bitmap space usage for shards of 1, 2, ..., 1000 respectively. The calculated data can be shown in Table 1. Table 1 enumerates the bitmap space usage (Mem) corresponding to each number of shards when the number of system users remains constant. The unit of this bitmap space usage (Mem) is bytes.

[0123] Table 1

[0124]

[0125] In one example, to improve computational efficiency, the server can pre-calculate a sharding table for different numbers of system users, different estimated number of participating users, and different sharding quantities. When the number of system users remains constant, this table can be as shown in Table 2. Here, U represents the estimated number of participating users, t represents the number of shards, and Mem (byte) represents the bitmap space usage in bytes.

[0126] Table 2

[0127]

[0128] In one example, the specific process by which the server calculates the bitmap space occupancy after determining the number of system users, the estimated number of participating users, the number of allowed projects, and the number of shards may include:

[0129] Step 1: The server determines the total keyword length for each graph based on the allowed number of participating projects, the number of shards, and the fixed keyword length. Each shard corresponds to one keyword.

[0130] In this step, the sharded bitmap needs to store two parts in Redis: key and value. The storage space occupied by these two parts is divided into two parts: Mem(key) and Mem(value). The value stores the bitmap information for each shard, and each shard can correspond to one key. Therefore, as the number of shards increases, the occupied storage space will increase linearly with the number of shards. That is, the number of shards in Mem(key) is directly proportional to the occupied storage space.

[0131] The storage space occupied by the key is:

[0132] Mem(key) = Storage space occupied by each key × Number of shards

[0133] In a Redis bitmap structure, the key primarily consists of the system ID, activity ID, bitmap sequence number, and shard sequence number. The bitmap sequence number is determined based on the allowed number of participating projects. The shard sequence number is determined based on the target number of shards. The system ID is determined based on the server's system ID. The activity ID is determined based on the current activity's activity ID. This activity ID is used to uniquely identify the current activity.

[0134] The storage space occupied by a single key is as follows:

[0135] Mem(key) = SDS(9) + System ID + Activity ID + Bitmap ID + Fragment ID

[0136] Its unit can be bytes. Since the system number and activity number are fixed for the current activity, the three parts SDS(9), system number, and activity number in the above formula can be calculated as constants. Among them, SDS(9) is the storage space that the key needs to use. This constant value can be written as:

[0137] Mem key =SDS(9) + System Number + Activity Number

[0138] The storage space occupied by the keys of all fragments of the entire bitmap can be represented as:

[0139]

[0140] Among them, Mem(Ct) key Mem represents the total length of the keys for all slices of the graph. key This represents a constant value indicating the storage space required for a single fragment. t represents the number of fragments. This represents the storage space occupied by all fragment numbers in a bitmap. For example, when there are 10 fragments, t = 10. The fragment numbers needed can include 1, 2, ..., 10. Since data can be stored in binary, the server can use log2(i) + 1 to determine the number of bits required for the fragment number i. For example, when i = 3, log2(i) + 1 = 2.58. After rounding, it can be determined that 2 bits are needed to store the fragment number with the value 3. Similarly, when i = 9, log2(i) + 1 = 4017. After rounding, it can be determined that 4 bits are needed to store the fragment number with the value 9. Calculating and summing the values ​​for each fragment number, we get that when t = 10, the storage space occupied by that fragment number is 29 bits. The calculation of the space occupied by the bitmap sequence number is actually omitted in this calculation. In practice, to control costs, the number of items allowed is usually a small number. For example, the allowed number of participating projects can be 3, 5, 6, etc. Therefore, the storage space occupied by the bitmap numbers of all bitmaps has a very small impact compared to the total storage space occupied by all bitmaps. For example, when including 100 million system users, the storage space occupied by one bitmap is 12MB. However, when including 10 bitmaps, the storage space occupied by the bitmap numbers of these 10 bitmaps is only 29 bits. Therefore, for ease of calculation, the calculation of this bitmap number is directly omitted in this application.

[0141] Step 2: The server determines the total space usage of each bit graph's total fragments based on the average fragment length of each fragment, the probability that each fragment occupies 50% of the storage space, the average storage space saved by each fragment, and the number of fragments.

[0142] In this step, the storage space occupied by the value can be estimated using probability. For example, one user might occupy a size of m bits. Figure 1 The probability of half-storage space is 50%. And when the number of users is m / 2, the occupied space... Figure 1 The probability of half-memory usage is 100%. This shows that the actual number of users is directly proportional to the probability of occupying 50% of the shard's storage space. That is, the number of shards in Mem(value) is inversely proportional to the storage space occupied. In the Redis bitmap, `value` stores the amount of issued benefits for each user. Each bitmap position represents a user, with 1 representing issued benefits and 0 representing unissued benefits. The storage space occupied by `value` is:

[0143]

[0144] The probability of occupying 50% of the storage space × the actual number of fragments occupied by the user.

[0145] The storage space occupied by a single value can be represented as follows:

[0146] Mem(value) = SDS(25) + maximum bitmap offset

[0147] Its unit can be bytes. SDS(25) represents the fixed storage space required for this key. The maximum offset of the bitmap is the offset of the system user with the largest possible ID in this fragment. The storage space occupied by the value of all fragments of the entire bitmap can be represented as:

[0148]

[0149] Among them, Mem(Ct) value Let be the total space occupied by all fragments of each bit graph. S is the number of system users. U is the estimated number of participating users. t is the number of fragments. Here, e represents the maximum length of each fragment. The formula for calculating e is:

[0150]

[0151] The server can determine the average maximum memory space occupied by each slice based on the value of 'e'. This maximum memory space occupied by each slice can be represented as Mem(e). For example, when the maximum length of each slice is 100, Mem(e) is 100 bits. This value represents the probability of occupying 50% of the storage space in a shard. For example, the probability of a user appearing in any position within a shard is 1 / e. Using the middle position of the shard as a boundary, the probability of a user appearing in the first 50% and the last 50% of the storage space in that shard are both 50%. When the number of users participating in the current activity is e / 2, the probability of occupying 50% of the storage space in that shard is 100%.

[0152] in, For each additional shard, the average amount of wasted space is reduced. In the worst-case scenario of storage space usage, U system users are evenly distributed among S system users. In this case, the average interval between two system users is... Therefore, with each new shard added, there will likely be empty spaces on the new shard. The storage space. Alternatively, it can be considered that with each additional shard, the amount of storage space that may be freed up on the new shard is between 0 and... Between. To cover the possibility of extreme cases, the median is used in this embodiment. This can be considered as potentially free storage space. For example, consider the bitmap shown in Table 3. This bitmap contains 20 bits, which can correspond to 20 system users. Among them, system users 1, 3, 9, 12, and 19 have already acquired benefits, while the remaining system users have not yet acquired benefits. After dividing this bitmap into 4 fragments, we can obtain the four fragments of the bitmap shown in Table 4.

[0153] Table 3

[0154] 1 0 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 1 0

[0155] Table 4

[0156] 1 0 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 1 0

[0157] In Table 4, the gray area represents the space that can be saved for each slice. Since the 1-bit storage space corresponding to the last dark gray cell in the bitmap shown in Table 3 can already be saved within the bitmap, the 1-bit storage space corresponding to that dark gray cell in the fourth slice shown in Table 4 does not belong to the storage space optimization brought about by the slice. Therefore, in actual calculations, the average storage space of each slice will be multiplied by t-1 to calculate the storage space optimization brought by the bitmap slice to the first t-1 slices.

[0158] Step 3: The server determines the bitmap space usage based on the total length of the keywords in each bitmap, the total space usage of all fragments in each bitmap, and the number of allowed participating items.

[0159] In this step, the server can determine the total length Mem(Ct) of each key in the graph according to the steps described above. key ) and the total space occupied by each piece of the graph Mem(Ct) value After that, based on the total length of the keyword Mem(Ct) key The total space occupied by the entire fragment, Mem(Ct) value The bitmap space usage is determined by the number of allowed projects and the number of projects that can participate. The formula can be:

[0160] Mem(Ct) = [Mem(Ct)] key )+Mem(Ct value )]×N

[0161] Where N is the number of bitmaps, i.e. the number of projects allowed to participate.

[0162] S203. Compare the bitmap space occupied by each number of fragments, and determine the number of fragments corresponding to the minimum bitmap space occupied as the target number of fragments.

[0163] In this step, after determining the bitmap space usage corresponding to each number of fragments according to the steps above, the server sorts the data based on this bitmap space usage. The server can select the number of fragments corresponding to the minimum bitmap space usage as the target number of fragments. The server can then use this number of fragments to complete the bitmap fragmentation. The server can then record the participation information for the current activity in the fragmented bitmap.

[0164] The data storage method provided in this application allows the server to determine the maximum number of shards based on the estimated number of participating users, thereby determining a range for the number of shards. The server can use each shard number within this range, along with the number of system users, the estimated number of participating users, and the allowed number of participating items, to calculate the bitmap space occupancy corresponding to each shard number. The server can then sort the shards based on this bitmap space occupancy. The server can select the shard number corresponding to the minimum bitmap space occupancy as the target shard number. This application achieves the optimal shard number calculation by calculating the bitmap space occupancy corresponding to each possible shard number, thereby improving the space utilization of the current activity's participation information during storage. Simultaneously, the sharding method also improves the storage efficiency of the current activity's participation information during storage.

[0165] Figure 6 A flowchart illustrating a data storage method according to an embodiment of this application is shown. Figures 3 to 5 Based on the illustrated embodiments, as Figure 6 As shown, with the server as the execution entity, the method in this embodiment may include the following steps:

[0166] S301. Obtain the number of system users, the estimated number of participating users for the current activity, and the number of allowed items for the current activity. Each activity item corresponds to a bitmap.

[0167] S302. Determine the target number of slices for each graph based on the number of system users, the estimated number of participating users, and the number of projects allowed to participate.

[0168] In this embodiment, steps S301 and S302 are... Figure 2 Steps S101 and S102 in this embodiment are implemented in a similar manner, and will not be described again here. Figure 7 As shown, this step is equivalent to S401. The server can obtain the estimated number of participating users U and the allowed number of items N for the current activity.

[0169] S303. Determine the bitmap space usage based on the number of system users, the estimated number of participating users, the number of allowed participating projects, and the target number of fragments.

[0170] In this embodiment, the server can, for example, Figure 5 In the illustrated embodiment, after determining the target number of fragments, the minimum bitmap space occupancy is calculated based on the number of system users, the estimated number of participating users, the allowed number of participating projects, and the target number of fragments. This step is equivalent to... Figure 7 S403 in the middle.

[0171] S304. Determine the space usage of key-value pairs based on the number of system users, the estimated number of participating users, and the number of projects allowed to participate.

[0172] In this embodiment, the server can use the structural information in the key-value structure to calculate the space occupied by the key-value pairs. This step is equivalent to... Figure 7 S402 in the flowchart. The execution order of S303 and S304 and the execution order of S402 and S403 are not restricted by the flowchart and can be arbitrarily interchanged.

[0173] In key-value pairs, the key includes the system ID, activity ID, and user ID. In key-value pair storage, the server can create a key-value pair when a system user participates in the current activity and use this key-value pair to record the user's participation information. Therefore, besides the system ID identifying the server and the activity ID identifying the current activity, the key only needs to store the user ID. This user ID is a unique identifier for the system on the server. For example, when there are 100 million system users, the user ID of the 100 millionth user could be 100,000,000. In the key-value pair, the value stores the number of benefits the user has acquired or the number of projects they have participated in. For example, if a user has acquired 3 benefits, the value is 3. Similarly, if a user has participated in 6 projects, the value is 6.

[0174] For example, the key-value data could be:

[0175] key=6069: act01: openIdA; value=1

[0176] key=6069: act01: openIdB; value=3

[0177] key=6069: act01: openIdC; value=2

[0178] Similar to calculating the space occupied by a bitmap, the calculation of the space occupied by this key-value pair also requires calculating the storage space of the key and the storage space of the value separately. The method for calculating the storage space occupied by the key can be as follows:

[0179] Mem(key) = SDS(9) + System ID + Activity ID + User ID

[0180] The unit is bytes. When the system has 100 million users, the storage space for a user's key value is approximately 20 bytes. The storage space usage for each user's key is relatively fixed. Therefore, the server can determine the total storage space required for the key in the current activity based on the estimated number of participating users and the key's storage space usage.

[0181] The storage space occupied by the value can be calculated as follows:

[0182] Mem(value) = SDS(25) + log2(n)

[0183] Its unit is bytes. Here, n represents the number of projects each system user is allowed to participate in or the number of benefits they can obtain, as stipulated in the activity participation rules. log2(n) is used to calculate the number of digits. Since the value is accumulated in `value`, meaning only one value is stored in `value` at any given time, the storage space required for `value` is maximized when the value in `value` is n. `log2(n)` is the number of digits needed to store the value n. Since the number of allowed projects is generally in the single digits, the value of `log2(n)` in `value` can be simplified to I bytes. The formula for calculating the storage space occupied by `value` can be simplified as follows:

[0184] Mem(value) = SDS(25) + 1 byte

[0185] Based on the above Mem(key) and Mem(value), the server can calculate the space occupied by the key-value pair, Mem(kv), using the following formula:

[0186] Mem(kv)=[Mem(key)+Mem(value)]*U

[0187] Where U is the estimated number of participating users, i.e., the maximum number of participants in the activity. SDS(25) is a fixed constant value of memory occupied by Redis when storing data using a key-value structure. SDS(25) corresponds to 25 bytes.

[0188] S305. When the space occupied by the key-value pair is less than the space occupied by the bitmap, the key-value pair is used to record the participation information of the system user in the current activity.

[0189] In this embodiment, the server can compare the bitmap space occupancy calculated in step S303 with the key-value pair space occupancy calculated in step S304. This step is equivalent to... Figure 7 S404. When the space occupied by key-value pairs is less than the space occupied by the bitmap, the server determines to use key-value pairs to record the user's participation information in the current activity. That is, when the space occupied by key-value pairs is less than the space occupied by the bitmap, the server will continue execution. Figure 7 S414. Otherwise, if the key-value pair space occupancy is greater than or equal to the bitmap space occupancy, the server may continue to execute step S306. Alternatively, the server may continue to execute... Figure 7 S405 in the middle.

[0190] In one example, when the server determines that it needs to use key-value pairs to record the participation information of a Geely system user in the current activity, the specific process of recording the participation information may include the following steps:

[0191] Step 1: The server retrieves the number of projects participated in by the system user from the key-value pairs corresponding to the system user.

[0192] In this step, the server can directly search for the key corresponding to the system user in Redis based on the system user's user ID. After determining the key, the server can determine the value in the key-value pair. This value can include the number of projects the system user has participated in. This number of projects represents the amount of benefits already acquired. This step can be performed as follows: Figure 7 The step S415 is shown in the diagram. The instruction for the server to obtain the number of projects participated in by system users can be:

[0193] Value=GET(6069:act01:openIdA);

[0194] Step 2: When the number of participating projects is less than the allowed number of participating projects, the server will increase the number of participating projects for the system user by one unit value.

[0195] In this step, the server compares the number of participating projects with the allowed number of participating projects. If the number of projects a user has already participated in is less than the allowed number of participating projects, the server allows the user to participate in that project and increments the user's participating project count by a unit value. This unit value can be 1. For example, if a user has already acquired 3 benefits, and the maximum number of benefits allowed is 6, the server can determine that the user can continue to acquire benefits. The server can then distribute the benefits to the user and update the record in Redis showing the number of benefits the user has already acquired. This step is equivalent to... Figure 7 S417 in the context of Redis. Specifically, the command for the server to write the number of participating projects (equity amount) back to Redis can be:

[0196] SET(6069:act01:openIdA,value+1);

[0197] Step 3: When the number of participating projects is greater than or equal to the allowed number of participating projects, the server will refuse the system user's participation in the project.

[0198] In this step, if a system user has already participated in the required number of projects, the server determines that the user has completed participation in the current activity. The server can refuse the user's continued participation. For example, if a system user has already acquired 6 benefits, and the maximum number of benefits allowed per user is 6, the server can determine that the user has acquired all benefits. The server can refuse the user's request to acquire benefits again. This step is equivalent to... Figure 7 The operation when S416 is not satisfied.

[0199] S306. Divide the bitmap into fragments according to the target number of fragments, and use the fragmented bitmap to record the participation information of system users in the current activity.

[0200] Among them, step S306 and Figure 2 The implementation of step S103 in this embodiment is similar, and will not be repeated here. The specific implementation process of S306 can be as follows: Figure 7 The steps S405 to S413 are as follows: The server can determine the fragment number and offset of the system user based on the user ID. The server can then determine the value corresponding to the system user in each bitmap based on this fragment number and offset. The server can perform a bitwise AND operation on these values. When the result is 1, it means that all values ​​in these bitmaps are 1. When all values ​​for the system user in each bitmap are 1, it means that the system user has acquired all available benefits or participated in all available activities. Otherwise, when the result is 0, it means that at least one value in these bitmaps is 0. This result indicates that the system user can continue to acquire benefits or participate in activities. When a user acquires benefits or participates in activities, the server can set the value of one bitmap with a value of 0 to 1.

[0201] The storage structure of the fragmented bitmap can be:

[0202] Bit Figure 1 :

[0203] Bitmap slice 1: key = 6069: bitmap: act01: 1: sliceNo; value = 1 0 1 0 0 0 0 0…

[0204] Bitmap slice 2: key = 6069: bitmap: act01: 1: sliceNo; value = 1 0 1 0 0 0 0 0…

[0205] …

[0206] Bitmap slice M: key = 6069: bitmap: act01: 1: sliceNo; value = 1 0 1 0 0 0 0 0…

[0207] Bit Figure 2 :

[0208] Bitmap slice 1: key = 6069: bitmap: act01: 2: sliceNo; value = 1 0 1 0 0 0 0 0…

[0209] Bitmap slice 2: key = 6069: bitmap: act01: 2: sliceNo; value = 1 0 1 0 0 0 0 0…

[0210] …

[0211] Bitmap slice M: key = 6069: bitmap: act01: 2: sliceNo; value = 1 0 1 0 0 0 0 0…

[0212] When the user ID is X, the shard number is SLICE. NO The calculation formula can be:

[0213]

[0214] The formula for calculating the offset of a user on a particular slice in this system can be:

[0215] offset = X%e

[0216] Once the server determines the fragment number and offset, it can retrieve the value of the user in the N bitmap fragments. The retrieval command can be:

[0217] value1=GETBIT("6069: bitmap: act01: 1: (X / e)", (X%e));

[0218] value2=GETBIT("6069: bitmap: act01: 2: (X / e)", (X%e));

[0219] value3=GETBIT("6069: bitmap: act01: 3: (X / e)", (X%e);

[0220] …

[0221] valueN=GETBIT("6069: bitmap: act01: N: (X / e)", (X%e));

[0222] The server can calculate the number of projects a user in the system has participated in based on the value of each element in the graph. The calculation formula is as follows:

[0223] count=value1+value2+value3...+valueN

[0224] The server can also perform a bitwise AND operation on all values ​​to more quickly determine whether the user has reached the maximum number of projects they are participating in. The calculation formula is as follows:

[0225] result=value1&value2&value3&....&valueN

[0226] When the value of `resule` is 1, it indicates that the number of projects a user can participate in under this system has reached its limit. Otherwise, it indicates that the number of projects a user can participate in under this system has not yet reached its limit. The specific logic for this judgment process can be as follows:

[0227] if (1 == result) {

[0228] No rights or benefits will be issued.

[0229] }else{

[0230] Issuance of rights;

[0231] }

[0232] The data storage method provided in this application allows the server to obtain the number of system users, the estimated number of participating users in the current activity, and the allowed number of items in the current activity. The server can determine the target number of bitmap fragments based on these factors. After determining the target number of fragments, the server can calculate the minimum bitmap space occupancy based on these factors. The server can use the structural information in the key-value structure to calculate the space occupancy of key-value pairs. The server can compare the key-value pair space occupancy with the bitmap space occupancy. When the key-value pair space occupancy is less than the bitmap space occupancy, the server determines to use key-value pairs to record the system users' participation information in the current activity. When the key-value pair space occupancy is greater than or equal to the bitmap space occupancy, the server can fragment the bitmap according to the target number of fragments and use the fragmented bitmap to record the system users' participation information in the current activity. In this application, by comparing the space occupied by key-value pairs and the space occupied by bitmaps, the optimal storage method is selected to record the participation information of the current activity based on different system user numbers, estimated number of participating users, and allowed number of participating projects, thereby improving the storage efficiency of participation information and storage space utilization.

[0233] Figure 8 A schematic diagram of the structure of a data storage device according to an embodiment of this application is shown, as follows: Figure 8 As shown, the data storage device 10 of this embodiment is used to implement the operation corresponding to the server in any of the above method embodiments. The data storage device 10 of this embodiment includes:

[0234] The acquisition module 11 is used to acquire the number of system users, the estimated number of participating users in the current activity, and the number of allowed items in the current activity. Each activity item corresponds to a bitmap.

[0235] Processing module 12 is used to determine the target number of bitmap segments based on the number of system users, the estimated number of participating users, and the number of allowed participating projects when the ratio of the number of system users to the estimated number of participating users exceeds a preset threshold. The bitmap is then segmented according to the target number of segments, and the segmented bitmap is used to record the participation information of system users in the current activity.

[0236] Optionally, processing module 12 is specifically used for:

[0237] The range of the number of shards is determined based on the estimated number of participating users.

[0238] Based on the range of the number of fragments, enumerate the bitmap space usage corresponding to each number of fragments within the range.

[0239] Compare the bitmap space usage corresponding to each number of fragments, and determine the number of fragments corresponding to the minimum bitmap space usage as the target number of fragments.

[0240] Optionally, processing module 12 is specifically used for:

[0241] The bitmap space occupancy corresponding to the number of fragments is determined based on the number of system users, the estimated number of participating users, the number of allowed projects, and the number of fragments.

[0242] Optionally, processing module 12 is specifically used for:

[0243] The total keyword length for each graph is determined based on the number of allowed projects, the number of slices, and the fixed keyword length. Each slice corresponds to one keyword.

[0244] The total space usage of each bit graph is determined based on the average bit length of each bit, the probability that each bit occupies 50% of the storage space, the average storage space saved by each bit, and the number of bits.

[0245] The bitmap space usage is determined based on the total length of the keywords in each bitmap, the space usage of all fragments in each bitmap, and the number of projects allowed to participate.

[0246] Optionally, processing module 12 is specifically used for:

[0247] The number of projects a system user participates in is determined based on the value of the system user in each graph segment.

[0248] When the number of participating projects is less than the allowed number of participating projects, the value of the system user in the one-dimensional graph segment is changed from the first data to the second data.

[0249] When the number of projects a user participates in is greater than or equal to the allowed number of projects, the user's participation in the project will be denied.

[0250] Optionally, before fragmenting the bitmap according to the target number of fragments and using the fragmented bitmap to record the system user's participation information in the current activity, the processing module 12 is further used for:

[0251] The bitmap space occupancy is determined based on the number of system users, the estimated number of participating users, the number of allowed projects, and the target number of fragments.

[0252] Determine the space usage of key-value pairs based on the number of system users, the estimated number of participating users, and the number of projects allowed to participate.

[0253] When the space occupied by key-value pairs is less than the space occupied by bitmaps, key-value pairs are used to record the participation information of system users in the current activity.

[0254] Optionally, the processing module 12 is also used for:

[0255] Retrieve the number of projects participated in by the system user from the key-value pairs corresponding to the system user.

[0256] When the number of participating projects is less than the allowed number of participating projects, the number of participating projects for system users will be increased by one unit value.

[0257] When the number of projects a user participates in is greater than or equal to the allowed number of projects, the user's participation in the project will be denied.

[0258] The data storage device 10 provided in this application embodiment can execute the above method embodiment. Its specific implementation principle and technical effect can be found in the above method embodiment, and will not be repeated here.

[0259] Figure 9 A schematic diagram of the hardware structure of a server provided in an embodiment of this application is shown. Figure 9 As shown, the server 20 is used to implement the operations corresponding to the server in any of the above method embodiments. The server 20 in this embodiment may include: a memory 21 and a processor 22.

[0260] The memory 21 is used to store computer programs. The memory 21 may include high-speed random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0261] Processor 22 is used to execute computer programs stored in memory to implement the data storage method in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments. The processor 22 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0262] Alternatively, the memory 21 can be either standalone or integrated with the processor 22.

[0263] When the memory 21 is a device independent of the processor 22, the server 20 may also include a bus 23. This bus 23 is used to connect the memory 21 and the processor 22. The bus 23 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0264] The server provided in this embodiment can be used to execute the data storage method described above. Its implementation and technical effects are similar, and will not be repeated here.

[0265] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, is used to implement the methods provided in the various embodiments described above.

[0266] The computer-readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of a computer program from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the computer-readable storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the ASIC can reside in a user equipment. Of course, the processor and the computer-readable storage medium can also exist as discrete components in a communication device.

[0267] Specifically, the computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium accessible to general-purpose or special-purpose computers.

[0268] This application also provides a computer program product comprising a computer program stored in a computer-readable storage medium. At least one processor of the device can read the computer program from the computer-readable storage medium, and the at least one processor executes the computer program to cause the device to implement the methods provided in the various embodiments described above.

[0269] This application also provides a chip including a memory and a processor. The memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that a device with the chip installed performs the methods described in the various possible implementations above.

[0270] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0271] The modules can be physically separate, for example, installed in different locations within a single device, installed on different devices, distributed across multiple network units, or distributed across multiple processors. Alternatively, the modules can be integrated, for example, installed in the same device, or integrated into a single codebase. The modules can exist in hardware form, software form, or a combination of both. This application can select some or all of the modules to achieve the objectives of this embodiment based on actual needs.

[0272] When the various modules are implemented as integrated software functional modules, they can be stored in a computer-readable storage medium. The aforementioned software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0273] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0274] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A data storage method, characterized by, The method comprises: acquiring a system user quantity, an estimated participating user quantity of a current activity, and an allowed participating project quantity of the current activity; each project of the current activity corresponds to a bitmap; when a ratio of the system user quantity to the estimated participating user quantity is greater than a preset threshold, determining a target shard quantity of each bitmap according to the system user quantity, the estimated participating user quantity, and the allowed participating project quantity; sharding the bitmap according to the target shard quantity, and recording participation information of a system user in the current activity by using the shard bitmap; wherein, determining the target shard quantity of each bitmap according to the system user quantity, the estimated participating user quantity, and the allowed participating project quantity specifically comprises: determining a range of the shard quantity according to the estimated participating user quantity; determining a total key length of each bitmap according to the range of the shard quantity, the allowed participating project quantity, the shard quantity, and a key fixed length; each shard corresponds to a key; determining a space occupation of all shards of each bitmap according to an average shard length of each shard, a probability value that each shard occupies 50% of a storage space, an average saved storage space value of each shard, and the shard quantity; determining a bitmap space occupation according to the total key length of each bitmap, the space occupation of all shards of each bitmap, and the allowed participating project quantity; comparing the bitmap space occupation corresponding to each shard quantity to determine that a shard quantity corresponding to a minimum value of the bitmap space occupation is the target shard quantity.

2. The method of claim 1, wherein, The recording of the participation information of the system user in the current activity specifically comprises: determining a participating project quantity of the system user according to a value of the system user in each shard of a bitmap; when the participating project quantity is less than the allowed participating project quantity, modifying the value of the system user in a shard of a bitmap from a first data to a second data; when the participating project quantity is greater than or equal to the allowed participating project quantity, rejecting the system user to continue participating in the current activity.

3. The method of claim 1, wherein, Before the sharding of the bitmap according to the target shard quantity and the recording of the participation information of the system user in the current activity by using the shard bitmap, the method further comprises: determining a bitmap space occupation according to the system user quantity, the estimated participating user quantity, the allowed participating project quantity, and the target shard quantity; determining a key-value pair space occupation according to the system user quantity, the estimated participating user quantity, and the allowed participating project quantity; when the key-value pair space occupation is less than the bitmap space occupation, recording the participation information of the system user in the current activity by using a key-value pair.

4. The method of claim 3, wherein, The method further comprises: acquiring a participating project quantity of the system user recorded in a key-value pair corresponding to the system user; when the participating project quantity is less than the allowed participating project quantity, increasing the participating project quantity of the system user by a unit value; When the number of participation projects is greater than or equal to the allowed number of participation projects, the system user is rejected to continue participating in the current activity.

5. A server, characterized by The server comprises a memory and a processor. The memory is configured to store a computer program, and the processor is configured to implement the data storage method according to any one of claims 1 to 4.

6. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is configured to implement the data storage method according to any one of claims 1 to 4 when executed by a processor.

7. A computer program product, characterised in that, The computer program product comprises a computer program, and the computer program is configured to implement the data storage method according to any one of claims 1 to 4 when executed by a processor.

Images