CN117743206A

CN117743206A - Data storage method and device

Info

Publication number: CN117743206A
Application number: CN202410190438.4A
Authority: CN
Inventors: 吴家旺; 石自军; 于鹏; 刘学卿
Original assignee: Shenzhen Jinzheng Software Technology Co ltd
Current assignee: Shenzhen Jinzheng Software Technology Co ltd
Priority date: 2024-02-21
Filing date: 2024-02-21
Publication date: 2024-03-22
Anticipated expiration: 2044-02-21
Also published as: CN117743206B

Abstract

The application is applicable to the technical field of data processing and provides a data storage method and device. The data storage method comprises the following steps: receiving a current user request and correspondingly generated data to be stored; performing characteristic analysis on the data to be stored based on the current user request, and determining data characteristics of the data to be stored, wherein the data characteristics comprise data quantity, data persistence, data variability and data usability; obtaining a cache allocation strategy; determining a pre-storage cache of data to be stored according to a cache allocation strategy and data characteristics; and storing the data to be stored into the pre-storage cache. According to the embodiment of the application, the data to be stored is distributed into the proper cache according to the cache distribution strategy and the data characteristics by carrying out characteristic analysis on the data to be stored, so that the performance of the cache is fully utilized.

Description

Data storage method and device

Technical Field

The application belongs to the technical field of data processing, and particularly relates to a data storage method and device.

Background

After the service system receives the data, the service system needs to edit the storage position of the data. The cache locations commonly used at present include a server cache, a Redis cache, a database cache, a front-end cache, and the like. Different cache locations have respective characteristics and are suitable for storing different data. In the related art, received data is generally stored in a predetermined buffer location, and the data is not stored in an appropriate buffer location, resulting in underutilization of buffer performance.

Disclosure of Invention

The embodiment of the application provides a data storage method and device, which can solve the problem that data is not stored in a proper cache position in the related art.

In a first aspect, an embodiment of the present application provides a method for storing data, including:

receiving a current user request and correspondingly generated data to be stored;

performing characteristic analysis on the data to be stored based on the current user request, and determining data characteristics of the data to be stored, wherein the data characteristics comprise data quantity, data persistence, data variability and data usability;

obtaining a cache allocation strategy;

determining a pre-storage cache of data to be stored according to a cache allocation strategy and data characteristics;

and storing the data to be stored into the pre-storage cache.

In a second aspect, an embodiment of the present application provides a data storage device, including:

the receiving module is used for receiving the current user request and the corresponding generated data to be stored;

the analysis module is used for carrying out characteristic analysis on the data to be stored based on the current user request, and determining the data characteristics of the data to be stored, wherein the data characteristics comprise data quantity, data persistence, data variability and data usability;

The acquisition module is used for acquiring a cache allocation strategy;

the determining module is used for determining a pre-storage cache of the data to be stored according to the cache allocation strategy and the data characteristics;

the storage module is used for storing the data to be stored into the pre-storage buffer.

In a third aspect, an embodiment of the present application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements steps of a method for storing data as described above when the processor executes the computer program.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described data storage method.

In a fifth aspect, embodiments of the present application provide a computer program product, which when run on a terminal device, causes the terminal device to perform the above-mentioned data storage method.

Compared with the prior art, the beneficial effects of the embodiment of the application are as follows: according to the embodiment of the application, the data characteristics of the data to be stored are determined by receiving the current user request and the correspondingly generated data to be stored, performing characteristic analysis on the data to be stored based on the current user request, acquiring a cache allocation strategy, determining a pre-storage cache of the data to be stored according to the cache allocation strategy and the data characteristics, and finally storing the data to be stored into the pre-storage cache. According to the embodiment of the application, the data to be stored is distributed into the proper cache according to the cache distribution strategy and the data characteristics by carrying out characteristic analysis on the data to be stored, so that the performance of the cache is fully utilized.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required for the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic implementation flow chart of a data storage method according to an embodiment of the present application;

FIG. 2 is a schematic diagram of an implementation flow of determining a pre-storage buffer of data to be stored according to an embodiment of the present application;

FIG. 3 is a schematic diagram of an implementation flow of determining whether data to be stored is stored in a pre-storage buffer according to an embodiment of the present application;

FIG. 4 is a flowchart of a specific implementation of determining a pre-storage buffer of data to be stored according to an embodiment of the present application;

FIG. 5 is a schematic flow chart of one implementation of determining data characteristics of data to be stored according to an embodiment of the present application;

FIG. 6 is a flowchart of another implementation of determining data characteristics of data to be stored according to an embodiment of the present disclosure;

fig. 7 is a schematic implementation flow chart of determining a fourth sub-correspondence provided in an embodiment of the present application;

Fig. 8 is a schematic flowchart of an implementation of determining a fifth sub-correspondence provided in an embodiment of the present application;

fig. 9 is a schematic flowchart of an implementation process for determining a sixth sub-correspondence provided in an embodiment of the present application;

FIG. 10 is a schematic diagram of a data storage device according to an embodiment of the present disclosure;

fig. 11 is a schematic structural diagram of a terminal device provided in an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, are intended to be protected herein.

It is noted that the terms "comprising," "including," and "having," and any variations thereof, in the description and claims of the present application and in the foregoing figures, are intended to cover non-exclusive inclusions. For example, a process, method, terminal, article, or apparatus that comprises a list of steps or elements is not limited to only those listed steps or elements but may include other steps or elements not listed or inherent to such process, method, article, or apparatus. In the claims, specification, and drawings of this application, relational terms such as "first" and "second," and the like are used solely to distinguish one entity/operation/object from another entity/operation/object without necessarily requiring or implying any such real-time relationship or order between such entities/operations/objects.

Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present application. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments.

In view of this, in the embodiment of the present application, the data to be stored is allocated to the appropriate cache according to the cache allocation policy and the data characteristics by performing the characteristic analysis on the data to be stored, so as to make full use of the performance of the cache.

In order to illustrate the technical solution of the present application, the following description is made by specific examples.

Fig. 1 is a schematic implementation flow chart of a data storage method according to an embodiment of the present application, where the method may be applied to a terminal device. The terminal device may be a mobile phone, tablet computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, etc.

Specifically, the method for storing data may include the following steps S101 to S105.

Step S101, receiving a current user request and corresponding generated data to be stored.

The current user request is a request generated after the user clicks a related button on the front-end interactive interface at the current time. It can be understood that after the user clicks the related button, the terminal device may obtain the corresponding data, and in some scenarios, the data needs to be stored, and the data that needs to be stored is the data to be stored.

In the embodiment of the application, the terminal device may receive a current user request generated after the user clicks the related button on the front-end interactive interface, and acquire data to be stored generated according to the current user request.

Step S102, based on the current user request, characteristic analysis is performed on the data to be stored, and the data characteristics of the data to be stored are determined.

The data characteristics may include, among other things, data volume, data persistence, data variability, and data usability. The data size may be used to reflect the size of the data to be stored, and may include characteristics of large data size, small data size, and the like. The data persistence may be used to reflect the number of calls of the data to be stored over a long period of time, and may include characteristics of strong data persistence, weak data persistence, and the like. The data variability may be used to reflect the magnitude of variability of the data to be stored, and may include characteristics of large data variability, small data variability, and the like. The data variability may be used to reflect whether the data to be stored is commonly used in a short period of time, and may include characteristics of low data availability, high data availability, and the like.

In the embodiment of the application, the terminal device can perform characteristic analysis on the data to be stored according to the current user request, and analyze data characteristics such as data quantity, data persistence, data variability, data usability and the like of the data to be stored.

Step S103, obtaining a cache allocation strategy.

The buffer allocation policy may be used to determine to which buffer the data to be stored is allocated, and may be preset in the memory of the terminal device.

In the embodiment of the application, the terminal device may directly invoke the cache allocation policy stored in the memory.

Step S104, according to the buffer allocation strategy and the data characteristics, the pre-storage buffer of the data to be stored is determined.

The pre-storage cache is a suitable cache location for the data to be stored, and may include a server cache, a dis cache, a database cache, a front-end cache, and the like.

In the embodiment of the present application, the terminal device may determine the pre-storage cache of the data to be stored according to the cache allocation policy and the data characteristics of the data to be stored.

Step S105, the data to be stored is stored in the pre-storage buffer.

In an embodiment of the present application, after determining the pre-storage buffer of the data to be stored, the terminal device may store the data to be stored into the corresponding pre-storage buffer. For example, if the pre-storage cache of the data to be stored is determined to be the server cache, the terminal device may store the data to be stored into the server cache. The same is true for other pre-stored caches.

As shown in fig. 2, in some embodiments of the present application, the determining the pre-storage cache of the data to be stored according to the cache allocation policy and the data characteristics may specifically include step S201 and step S202.

Step S201, determining whether the data to be stored is stored in the pre-storage buffer according to the data persistence and the data usage.

It will be appreciated that the data to be stored may or may not be suitable for storage in the cache. For the data to be stored which is suitable for being stored in the cache, it is required to determine which cache the data to be stored is suitable for being stored in, and for the data to be stored which is unsuitable for being stored in the cache, the data to be stored can be directly displayed on the front-end interactive interface without being stored.

As shown in fig. 3, in some embodiments of the present application, the determining whether the data to be stored is stored in the pre-storage buffer according to the data persistence and the data usage may specifically include step S301 and step S302.

In step S301, when the data characteristics of the data to be stored are different, the data durability is weak and the data usability is low, it is determined to store the data to be stored into the pre-storage buffer.

In the embodiment of the present application, when the data characteristics of the data to be stored are different, that is, when the data characteristics of the data to be stored are strong in data durability and high in data usability, or when the data characteristics of the data to be stored are strong in data durability and low in data usability, or when the data characteristics of the data to be stored are weak in data durability and high in data usability, it may be indicated that the data to be stored needs to be stored in the cache, and at this time, the terminal device may determine that the data to be stored needs to be stored in the pre-storage cache.

In step S302, when the data characteristics of the data to be stored are both weak in data persistence and low in data usability, it is determined that the data to be stored is not stored in the pre-storage buffer.

In the embodiment of the application, when the data characteristics of the data to be stored are weak in data persistence and low in data usability, it may be indicated that the data to be stored does not need to be stored in the cache, and the terminal device may determine not to store the data to be stored in the pre-storage cache and directly display the data to be stored on the front-end interactive interface.

In step S202, if it is determined that the data to be stored is stored in the pre-storage buffer, the pre-storage buffer of the data to be stored is determined according to the buffer allocation policy.

In the embodiment of the present application, if it is determined that the data to be stored needs to be stored in the pre-storage buffer, the terminal device may determine, according to the data characteristics of the data to be stored and the buffer allocation policy, which buffer is suitable for storing the data to be stored.

Specifically, as shown in fig. 4, in some embodiments of the present application, the determining the pre-storage cache of the data to be stored according to the cache allocation policy may specifically further include steps S401 to S404.

Wherein, the pre-storing cache may include: server cache, redis cache, database cache, and front-end cache. The cache allocation policy may include: a first cache allocation policy, a second cache allocation policy, a third cache allocation policy, and a fourth cache allocation policy.

Server caching is understood to mean caching on a Web server, such as the page cache of Apache. When a user requests a Web page, the Web server will first check if the HTML file of the page already exists in the cache, if so, directly return the cached HTML file, otherwise, go to generate the HTML file and return to the user. The caching mechanism can reduce the load on the back-end database and the server, thereby improving the performance and the response speed. Redis caches an open source memory data structure storage system that can be used as a database, cache, and message broker. The Redis cache is used for storing data in a Redis database, when the data needs to be queried, the data is queried from the Redis, and if the data cannot be found, the data is queried in the database. Redis caches are typically used to store frequently accessed data, such as user login information for a website, website configuration information, and the like. Database caching is the storage of frequently used data in a database, from which it is directly retrieved when it is needed, without the need for recalculation or querying. Such a caching mechanism may increase query speed and response time. Common database caching techniques include indexing, viewing, storing procedures, and the like. The front-end caching refers to caching performed at a browser end, and when a user accesses a website, the browser caches the content and resources of the website locally. When the user accesses the website again, the browser firstly checks whether the cache exists locally, if so, the cached content is directly used, otherwise, the user accesses the server to acquire the latest content. Front-end caches typically use HTTP header information to Control the caching policies, e.g., use header information such as Expires and Cache-Control to specify the time and manner of caching.

In step S401, data to be stored whose data characteristics satisfy the first cache allocation policy is allocated to the server cache.

The data characteristics corresponding to the first cache allocation policy are small data size and large data variability.

In the embodiment of the application, when the data characteristic of the data to be stored is that the data size is small and the data variability is large, the data to be stored meets the first cache allocation policy, and at this time, the data characteristic of the data to be stored is more suitable for the server cache. That is, when the data characteristic of the data to be stored satisfies the first cache allocation policy, the terminal device may allocate the data to be stored to the server cache.

Step S402, the data to be stored with the data characteristics meeting the second cache allocation policy is allocated to the Redis cache.

The data characteristics corresponding to the second cache allocation policy are large data volume and large data variability.

In the embodiment of the application, when the data characteristic of the data to be stored is that the data amount is large and the data variability is large, the data to be stored meets the second cache allocation policy, and at this time, the data characteristic of the data to be stored is more suitable for the dis cache. That is, when the data characteristic of the data to be stored satisfies the second cache allocation policy, the terminal device may allocate the data to be stored to the dis cache.

Step S403, the data to be stored with the data characteristics meeting the third cache allocation policy is allocated to the database cache.

The data characteristics corresponding to the third cache allocation policy are large data volume and small data variability.

In the embodiment of the application, when the data characteristic of the data to be stored is that the data amount is large and the data variability is small, the data to be stored meets the third cache allocation policy, and at this time, the data characteristic of the data to be stored is more suitable for the database cache. That is, when the data characteristic of the data to be stored satisfies the third cache allocation policy, the terminal device may allocate the data to be stored to the database cache.

Step S404, the data to be stored with the data characteristics satisfying the fourth cache allocation policy is allocated to the front-end cache.

The data characteristics corresponding to the fourth cache allocation policy are small data volume and small data variability.

In the embodiment of the application, when the data characteristic of the data to be stored is that the data size is small and the data variability is small, the data to be stored meets the fourth cache allocation policy, and at this time, the data characteristic of the data to be stored is more suitable for front-end cache. That is, when the data characteristic of the data to be stored satisfies the fourth buffer allocation policy, the terminal device may allocate the data to be stored to the front-end buffer.

As shown in fig. 5, in some embodiments of the present application, the foregoing characteristic analysis is performed on the data to be stored based on the current user request, and the determining the data characteristic of the data to be stored may specifically include steps S501 to S506.

Wherein the current user request includes a service type. It can be understood that when the terminal device generates the current user request according to the operation event of the user, the user request includes the corresponding service type.

Step S501, the total corresponding relation between each service type and data characteristic is obtained.

Wherein the total correspondence includes; the method comprises the steps of a first sub-corresponding relation between the service type and the data persistence, a second sub-corresponding relation between the service type and the data variability and a third sub-corresponding relation between the service type and the data usability.

It may be appreciated that, for some data of a specific service type, a developer may know the data characteristics of the data of the specific type, so that the developer may preset a correspondence between the service type and the data characteristics of the data of the specific type and store the correspondence in the memory of the terminal device, for example, for the data a of the service type a, a first sub-correspondence may be set as follows: the service type a corresponds to weak data persistence. Specifically, the terminal device may store in advance a first sub-correspondence between a service type and data persistence, a second sub-correspondence between a service type and data variability, and a third sub-correspondence between a service type and data usability.

In the embodiment of the present application, the terminal device may directly obtain the total correspondence between each service type and the data characteristic from the storage.

Step S502, determining the service type corresponding to the data to be stored.

In the embodiment of the application, after receiving the current user request, the terminal device may parse the service type corresponding to the data to be stored included in the current user request.

Step S503, determining the data amount based on the data amount size of the data to be stored.

In the embodiment of the application, after receiving the data to be stored, the terminal device can read the data size of the data to be stored, so as to determine whether the data to be stored belongs to large data size or small data size.

Step S504, determining the data persistence of the data to be stored according to the service type and the first sub-corresponding relation.

In the embodiment of the present application, after determining the service type corresponding to the data to be stored, the terminal device may determine, according to the service type and the first sub-correspondence, data persistence of the data to be stored. For example, if the data persistence corresponding to the first sub-correspondence is weak, the data to be stored is the data with weak data persistence. If the data persistence corresponding to the first sub-corresponding relation is strong, the data to be stored is the data with strong data persistence.

Step S505, determining the data variability of the data to be stored according to the service type and the second sub-correspondence.

In the embodiment of the present application, after determining the service type corresponding to the data to be stored, the terminal device may determine the data variability of the data to be stored according to the service type and the second correspondence. For example, if the data variability corresponding to the second sub-correspondence is small, the data to be stored is the data with small data variability. If the data variability corresponding to the second sub-corresponding relationship is large, the data to be stored is the data with large data variability.

Step S506, determining the data usability of the data to be stored according to the service type and the third sub-corresponding relation.

In the embodiment of the present application, after determining the service type corresponding to the data to be stored, the terminal device may determine, according to the service type and the third corresponding relationship, data usability of the data to be stored. For example, if the data usability corresponding to the third sub-correspondence is low, the data to be stored is the data with low data usability. If the data usability corresponding to the third sub-corresponding relation is high, the data to be stored is high.

In some business scenarios, a user may frequently initiate a user request for a certain business, at which point the data characteristics corresponding to the user request may change.

Typically, for a certain user request, the data characteristic corresponding to the service type is low in data usability. In some scenarios, the user may frequently call the data of the service type, and at this time, for the user request, the data characteristic corresponding to the service type is high in data usability. If the service type and the data usability are continuously determined according to the corresponding relation of the service type and the data usability, the data usability of the service type is considered to be low, and if the service type is weak in data durability, the data of the service type is considered not to be stored in the cache. In fact, the actual data usage of the service type is high at this time, and even if the data persistence of the service type is weak, the data of the service type should be stored in the cache. That is, when the data characteristics corresponding to the service types are changed, if the corresponding data characteristics are not changed according to the actual situation, the problems of influencing the storage of the data, influencing the use experience of the user, failing to fully utilize the performance of the cache and the like exist.

In view of this, as shown in fig. 6, in some embodiments of the present application, the above-mentioned characteristic analysis is performed on the data to be stored based on the current user request, and the determining the data characteristic of the data to be stored may specifically include steps S601 to S607.

Step S601, obtaining a historical user request within a first preset time.

The first preset time is a period of time before the current time, for example, may be a day before the current time. The historical user request is a user request prior to the current user request. It will be appreciated that upon receipt of a user request, the terminal device may store the user request.

In the embodiment of the application, the terminal device may acquire the historical user request stored in the first preset time.

Step S602, determining a fourth sub-correspondence between the service type corresponding to the history user request and the data variability based on the history user request.

The fourth sub-corresponding relation is used for representing the corresponding relation between the service type corresponding to the historical user request and the data variability.

As shown in fig. 7, in some embodiments of the present application, the determining, based on the historical user request, the fourth sub-correspondence between the service type corresponding to the historical user request and the data variability may specifically include steps S701 to S703.

In step S701, a first historical user request accessing the same URL address in the historical user requests is acquired.

Wherein the first historical user request is a historical user request to access the same URL address.

In the embodiment of the application, the terminal device can analyze the historical user request and extract the first historical user request accessing the same URL address from the historical user request.

Step S702, determining the same number of times the Json data is returned according to the first historical user request.

It can be understood that after the terminal device accesses the address of the same URL according to the first historical user request, the returned Json data can be obtained, and the Json data returned corresponding to different historical user requests may be the same or different.

In the embodiment of the application, the terminal device may acquire the returned Json data according to the first historical user request, and determine the number of times of occurrence of the same Json data in all the returned Json data.

Step S703, comparing the same number of times with a first preset value to obtain a first comparison result, and determining a fourth sub-correspondence between the service type corresponding to the first historical user request and the data variability according to the first comparison result.

The first preset value may be set according to the actual situation, for example, may be set 50 times.

In the embodiment of the present application, the terminal device may compare the same number of times with the first preset value to obtain a first comparison result. If the first comparison result is that the same number of times is greater than a first preset value, it may be determined that the data variability corresponding to the service type corresponding to the first historical user request is large, that is, it is determined that the fourth sub-correspondence is: the service type has large variability corresponding to the data. Otherwise, the fourth sub-correspondence relationship may be determined as: the service type has small data variability.

Step S603, determining a fifth sub-correspondence between the service type corresponding to the history user request and the data persistence based on the history user request.

The fifth sub-corresponding relation is used for representing the corresponding relation between the service type corresponding to the historical user request and the data persistence.

As shown in fig. 8, in some embodiments of the present application, the determining, based on the historical user request, the fifth sub-correspondence between the service type corresponding to the historical user request and the data persistence may specifically include steps S801 to S803.

Step S801, a second history user request invoking the same interface from the history user requests is acquired.

Wherein the second historical user request is a historical user request invoking the same interface.

In the embodiment of the application, the terminal device can also analyze the historical user request and extract a second historical user request calling the same interface from the historical user request.

Step S802, obtaining a first calling number of calling the same interface according to a second historical user request in a second preset time.

Wherein the time span required for judging the data persistence is relatively large, for example, one day is required. Thus, the second preset time may be set according to the judgment need for the data persistence, for example, may be set as one day. The first number of calls may be used to characterize the number of times the same interface is called.

It will be appreciated that for the same data, the terminal device may acquire the data at different times by invoking the same interface, and thus may determine the persistence of data corresponding to the historical user request by invoking the same interface a number of times.

In the embodiment of the application, the terminal device may acquire the number of times of calling the same interface according to the second historical user request in the second preset time.

Step 803, comparing the first calling times with a second preset value to obtain a second comparison result, and determining a fifth sub-correspondence between the service type corresponding to the second historical user request and the data persistence according to the second comparison result.

The second preset value may be set according to the actual situation, for example, may be set 50 times.

In the embodiment of the application, the terminal device may compare the first calling number with a second preset value to obtain a second comparison result. If the second comparison result is that the first calling number is greater than the second preset value, it can be determined that the data persistence corresponding to the service type corresponding to the second historical user request is strong, that is, it is determined that the fifth sub-corresponding relationship is: the service type corresponds to the data with strong durability. Otherwise, the fifth sub-correspondence relationship may be determined as: the traffic type corresponds to weak data persistence.

Step S604, determining a sixth sub-correspondence between the service type corresponding to the history user request and the data usability based on the history user request.

The sixth sub-corresponding relation is used for representing the corresponding relation between the service type corresponding to the historical user request and the data use.

As shown in fig. 9, in some embodiments of the present application, determining, based on the historical user request, a sixth sub-correspondence between the service type corresponding to the historical user request and the data usability may specifically include steps S901 to S903.

Step S901, a third history user request invoking the same interface from the history user requests is obtained.

Wherein the third historical user request is a historical user request invoking the same interface.

In the embodiment of the application, the terminal device can also analyze the historical user request and extract a third historical user request calling the same interface from the historical user request.

Step S902, obtaining a second calling number of calling the same interface according to a third historical user request in a third preset time.

Wherein the time span required for judging the usability of the data is relatively small, for example, one minute is required. Therefore, the third preset time may be set according to the judgment need for the usability of the data, and may be set to one minute, for example. The second number of calls may be used to characterize the number of times the same interface is called.

It will be appreciated that for the same data, the terminal device may acquire the data at different times by invoking the same interface, and thus may also determine the usability of the data corresponding to the historical user request by invoking the same interface a number of times.

In the embodiment of the application, the terminal device may obtain the number of times of calling the same interface according to the third historical user request in a third preset time.

Step S903, comparing the second calling times with a third preset value to obtain a third comparison result, and determining a sixth sub-correspondence between the service type corresponding to the third historical user request and the data usability according to the third comparison result.

The third preset value may be set according to the actual situation, for example, may be set to 50 times.

In the embodiment of the present application, the terminal device may compare the second call number with a third preset value to obtain a third comparison result. If the third comparison result is that the second calling number is greater than the third preset value, it may be determined that the data usability corresponding to the service type corresponding to the third historical user request is low, that is, it is determined that the sixth sub-correspondence is: the service type corresponds to low data usage. Otherwise, the sixth sub-correspondence relationship may be determined as: the service type corresponds to high data usability.

Step S605, determining the data variability of the data to be stored according to the service type and the fourth sub-correspondence.

In the embodiment of the present application, after the fourth sub-correspondence is obtained, the terminal device may determine the data variability of the data to be stored according to the service type and the fourth sub-correspondence.

Step S606, determining the data persistence of the data to be stored according to the service type and the fifth sub-corresponding relation.

In the embodiment of the present application, after obtaining the fifth sub-corresponding relationship, the terminal device may determine data persistence of the data to be stored according to the service type and the fifth sub-corresponding relationship.

In step S607, the data usability of the data to be stored is determined according to the service type and the sixth sub-correspondence.

In the embodiment of the present application, after obtaining the sixth sub-corresponding relationship, the terminal device may determine, according to the service type and the sixth sub-corresponding relationship, data usability of the data to be stored.

Fig. 10 is a schematic structural diagram of a data storage device according to an embodiment of the present application, where the data storage device 10 may be configured on a terminal device, and specifically, the data storage device 10 may include:

the receiving module 1001 is configured to receive a current user request and corresponding generated data to be stored.

The analysis module 1002 is configured to perform characteristic analysis on data to be stored based on a current user request, and determine data characteristics of the data to be stored, where the data characteristics include data amount, data persistence, data variability, and data usability.

An obtaining module 1003, configured to obtain a cache allocation policy.

The determining module 1004 is configured to determine a pre-storage cache of the data to be stored according to the cache allocation policy and the data characteristics.

The storage module 1005 is configured to store data to be stored in the pre-storage buffer.

In some embodiments of the present application, the determining module 1004 may be further configured to: determining whether the data to be stored is stored in a pre-storage cache according to the data persistence and the data usability; if the data to be stored is determined to be stored in the pre-storage cache, the pre-storage cache of the data to be stored is determined according to the cache allocation strategy.

In some embodiments of the present application, the determining module 1004 may be further configured to: when the data characteristics of the data to be stored are different, the data durability is weak and the data usability is low, determining to store the data to be stored into the pre-storage cache; when the data characteristics of the data to be stored are weak in data durability and low in data usability, it is determined that the data to be stored is not stored in the pre-storage cache.

In some embodiments of the present application, the pre-storing cache includes: server cache, redis cache, database cache, and front-end cache, the cache allocation policy includes: the determining module 1004 may further be configured to: the data to be stored, the data characteristics of which meet a first cache allocation strategy, are allocated to a server cache, and the data characteristics corresponding to the first cache allocation strategy are small in data quantity and large in data variability; the data to be stored, the data characteristics of which meet the second cache allocation strategy, are allocated to the Redis cache, and the data characteristics corresponding to the second cache allocation strategy are large in data quantity and large in data variability; the data to be stored, the data characteristics of which meet a third cache allocation strategy, are allocated to the database cache, and the data characteristics corresponding to the third cache allocation strategy are large in data quantity and small in data variability; and distributing the data to be stored, the data characteristics of which meet the fourth cache distribution strategy, to the front-end cache, wherein the data characteristics corresponding to the fourth cache distribution strategy are small in data quantity and small in data variability.

In some embodiments of the present application, the current user request includes a service type, and the analysis module 1002 may be further configured to: acquiring a total corresponding relation between each service type and data characteristics, wherein the total corresponding relation comprises; a first sub-corresponding relation between the service type and the data persistence, a second sub-corresponding relation between the service type and the data variability, and a third sub-corresponding relation between the service type and the data usability; determining a service type corresponding to data to be stored; determining a data amount based on a data amount size of data to be stored; determining data persistence of the data to be stored according to the service type and the first sub-corresponding relation; determining the data variability of the data to be stored according to the service type and the second sub-corresponding relation; and determining the data usability of the data to be stored according to the service type and the third sub-corresponding relation.

In some embodiments of the present application, the current user request includes a service type, and the analysis module 1002 may be further configured to: acquiring a historical user request within a first preset time; determining a fourth sub-corresponding relation between the service type corresponding to the historical user request and the data variability based on the historical user request; determining a fifth sub-corresponding relation between the service type corresponding to the historical user request and the data persistence based on the historical user request; determining a sixth sub-corresponding relation between the service type corresponding to the historical user request and the data usability based on the historical user request; determining the data variability of the data to be stored according to the service type and the fourth sub-corresponding relation; determining data persistence of the data to be stored according to the service type and the fifth sub-corresponding relation; and determining the data usability of the data to be stored according to the service type and the sixth sub-corresponding relation.

In some embodiments of the present application, the analysis module 1002 may also be configured to: acquiring a first historical user request accessing the same URL address in the historical user requests; determining the same number of times Json data is returned according to the first historical user request; and comparing the same times with a first preset value to obtain a first comparison result, and determining a fourth sub-corresponding relation between the service type corresponding to the first historical user request and the data variability according to the first comparison result.

In some embodiments of the present application, the analysis module 1002 may also be configured to: acquiring a second historical user request which invokes the same interface in the historical user requests; acquiring first calling times for calling the same interface according to a second historical user request in a second preset time; and comparing the first calling times with a second preset value to obtain a second comparison result, and determining a fifth sub-corresponding relation between the service type corresponding to the second historical user request and the data persistence according to the second comparison result.

In some embodiments of the present application, the analysis module 1002 may also be configured to: acquiring a third historical user request which invokes the same interface in the historical user requests; acquiring second calling times for calling the same interface according to a third historical user request in a third preset time; and comparing the second calling times with a third preset value to obtain a third comparison result, and determining a sixth sub-corresponding relation between the service type corresponding to the third historical user request and the data usability according to the third comparison result.

Fig. 11 is a schematic diagram of a terminal device according to an embodiment of the present application. The terminal device 11 may include: a processor 1101, a memory 1102, and a computer program 1103, such as a stored program of data, stored in the memory 1102 and executable on the processor 1101. The processor 1101 implements the steps in the above-described embodiment of the method for storing the respective data when executing the computer program 1103, for example, steps S101 to S105 shown in fig. 1. Alternatively, the processor 1101 may implement the functions of the modules/units in the above-described device embodiments when executing the computer program 1103, for example, the receiving module 1001, the analyzing module 1002, the obtaining module 1003, the determining module 1004, and the storing module 1005 shown in fig. 10.

The computer program may be divided into one or more modules/units, which are stored in the memory 1102 and executed by the processor 1101 to complete the present application. The one or more modules/units may be a series of computer program instruction segments capable of performing the specified functions, which instruction segments are used for describing the execution of the computer program in the terminal device.

The terminal device may include, but is not limited to, a processor 1101, a memory 1102. It will be appreciated by those skilled in the art that fig. 11 is merely an example of a terminal device and is not meant to be limiting, and that more or fewer components than shown may be included, or certain components may be combined, or different components may be included, for example, the terminal device may also include input and output devices, network access devices, buses, etc.

The processor 1101 may be a central processing unit (Central Processing Unit, CPU), other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The storage 1102 may be an internal storage unit of the terminal device, such as a hard disk or a memory of the terminal device. The memory 1102 may also be an external storage device of the terminal device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like. Further, the memory 1102 may also include both an internal storage unit and an external storage device of the terminal device. The memory 1102 is used for storing the computer program and other programs and data required by the terminal device. The memory 1102 may also be used to temporarily store data that has been output or is to be output.

It should be noted that, for convenience and brevity of description, the structure of the above terminal device may also refer to a specific description of the structure in the method embodiment, which is not repeated herein.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.

Embodiments of the present application also provide a computer readable storage medium storing a computer program that, when executed by a processor, may implement steps in a method of storing data as described above.

Embodiments of the present application provide a computer program product that, when executed on a mobile terminal, enables the mobile terminal to perform the steps in the method for storing data described above.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/terminal device and method may be implemented in other manners. For example, the apparatus/terminal device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical function division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated modules/units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiment, or may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each method embodiment described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth. It should be noted that the computer readable medium contains content that can be appropriately scaled according to the requirements of jurisdictions in which such content is subject to legislation and patent practice, such as in certain jurisdictions in which such content is subject to legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunication signals.

The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims

1. A method of storing data, comprising:

obtaining a cache allocation strategy;

determining a pre-storage cache of the data to be stored according to the cache allocation strategy and the data characteristics;

and storing the data to be stored into the pre-storage cache.

2. The method for storing data according to claim 1, wherein said determining a pre-storage cache of said data to be stored according to said cache allocation policy and said data characteristics comprises:

determining whether the data to be stored is stored in the pre-storage cache according to the data persistence and the data usability;

and if the data to be stored is determined to be stored in the pre-storage cache, determining the pre-storage cache of the data to be stored according to the cache allocation strategy.

3. The method of claim 2, wherein said determining whether the data to be stored is stored in the pre-storage cache based on the data persistence and the data usage comprises:

when the data characteristics of the data to be stored are different, namely the data durability is weak and the data usability is low, determining to store the data to be stored into the pre-storage cache;

and when the data characteristics of the data to be stored are weak in data durability and low in data usability, determining that the data to be stored is not stored in the pre-storage cache.

4. The method of claim 2, wherein the pre-storing cache comprises: server buffer memory, redis buffer memory, database buffer memory and front end buffer memory, the buffer memory allocation strategy includes: the method for determining the pre-storage cache of the data to be stored according to the cache allocation policy comprises the following steps:

The data to be stored, the data characteristics of which meet a first cache allocation strategy, are allocated to the server cache, and the data characteristics corresponding to the first cache allocation strategy are small in data quantity and large in data variability;

the data to be stored, the data characteristics of which meet a second cache allocation strategy, are allocated to the Redis cache, and the data characteristics corresponding to the second cache allocation strategy are large in data quantity and large in data variability;

the data to be stored, the data characteristics of which meet a third cache allocation strategy, are allocated to the database cache, and the data characteristics corresponding to the third cache allocation strategy are large in data quantity and small in data variability;

and distributing the data to be stored, of which the data characteristics meet a fourth cache distribution strategy, to the front-end cache, wherein the data characteristics corresponding to the fourth cache distribution strategy are small in data quantity and small in data variability.

5. The method for storing data according to claim 1, wherein the current user request includes a service type, the determining the data characteristic of the data to be stored based on the characteristic analysis of the data to be stored by the current user request includes:

Acquiring a total corresponding relation between each service type and the data characteristic, wherein the total corresponding relation comprises; a first sub-corresponding relation between the service type and the data persistence, a second sub-corresponding relation between the service type and the data variability, and a third sub-corresponding relation between the service type and the data usability;

determining the service type corresponding to the data to be stored;

determining the data amount based on the data amount size of the data to be stored;

determining the data persistence of the data to be stored according to the service type and the first sub-corresponding relation;

determining the data variability of the data to be stored according to the service type and the second sub-corresponding relation;

and determining the data usability of the data to be stored according to the service type and the third sub-corresponding relation.

6. The method for storing data according to claim 1, wherein the current user request includes a service type, the characteristic analysis is performed on the data to be stored based on the current user request, and the data characteristic of the data to be stored is determined, further comprising;

acquiring a historical user request within a first preset time;

Determining a fourth sub-corresponding relation between the service type corresponding to the historical user request and the data variability based on the historical user request;

determining a fifth sub-corresponding relation between the service type corresponding to the historical user request and the data persistence based on the historical user request;

determining a sixth sub-corresponding relation between the service type corresponding to the historical user request and the data usability based on the historical user request;

determining the data variability of the data to be stored according to the service type and the fourth sub-corresponding relation;

determining the data persistence of the data to be stored according to the service type and the fifth sub-corresponding relation;

and determining the data usability of the data to be stored according to the service type and the sixth sub-corresponding relation.

7. The method for storing data according to claim 6, wherein determining a fourth sub-correspondence of the service type corresponding to the historical user request and the data variability based on the historical user request comprises:

acquiring a first historical user request accessing the same URL address in the historical user requests;

Determining the same number of times of returning Json data according to the first historical user request;

and comparing the same times with a first preset value to obtain a first comparison result, and determining a fourth sub-corresponding relation between the service type corresponding to the first historical user request and the data variability according to the first comparison result.

8. The method for storing data according to claim 6, wherein determining a fifth sub-correspondence of the service type corresponding to the history user request and the data persistence based on the history user request comprises:

acquiring a second historical user request which invokes the same interface in the historical user requests;

acquiring a first calling number of times of calling the same interface according to the second historical user request in a second preset time;

and comparing the first calling times with a second preset value to obtain a second comparison result, and determining a fifth sub-corresponding relation between the service type corresponding to the second historical user request and the data persistence according to the second comparison result.

9. The method for storing data according to claim 6, wherein determining a sixth sub-correspondence of the service type corresponding to the history user request and the data usability based on the history user request comprises:

Acquiring a third historical user request which invokes the same interface in the historical user requests;

acquiring second calling times for calling the same interface according to the third historical user request in a third preset time;

and comparing the second calling times with a third preset value to obtain a third comparison result, and determining a sixth sub-corresponding relation between the service type corresponding to the third historical user request and the data usability according to the third comparison result.

10. A data storage device, comprising:

the acquisition module is used for acquiring a cache allocation strategy;

and the storage module is used for storing the data to be stored into the pre-storage cache.