Health data storage method and device, cloud server and storage medium

Abstract

The invention discloses a health data storage method and device, a cloud server and a storage medium, and relates to the technical field of data storage. The method comprises the steps of obtaining health data, if the health data meets a preset hot data condition, storing the health data into a hot database, or if the health data meets a preset cold data condition, storing the health data into a cold database. According to the method, the health data is subjected to cold and hot separation to be stored in the hot database or the cold database, so that the read-write performance of the health data can be improved.

Description

Technical Field

[0001] This application relates to the technical field of data storage, and more specifically, to a method, device, cloud server, and storage medium for storing health data. Background Art

[0002] Currently, for the health data collected from application programs, wearable devices, etc. by the sports health cloud system, all the data is simply written into a distributed database such as mysql or mongodb database clusters, resulting in poor read and write performance for subsequent health data. Summary of the Invention

[0003] In view of the above problems, this application proposes a method, device, cloud server, and storage medium for storing health data to solve the above problems.

[0004] In a first aspect, an embodiment of this application provides a method for storing health data. The method includes: obtaining health data; if the health data meets a preset hot data condition, storing the health data in a hot database; or if the health data meets a preset cold data condition, storing the health data in a cold database.

[0005] In a second aspect, an embodiment of this application provides a device for storing health data. The device includes: a health data acquisition module for obtaining health data; a first health data storage module for storing the health data in a hot database if the health data meets a preset hot data condition; or a second health data storage module for storing the health data in a cold database if the health data meets a preset cold data condition.

[0006] In a third aspect, an embodiment of this application provides a cloud server, including a memory and a processor. The memory is coupled to the processor, and the memory stores instructions. When the instructions are executed by the processor, the processor executes the above method.

[0007] In a fourth aspect, an embodiment of this application provides a computer-readable storage medium. Program code is stored in the computer-readable storage medium, and the program code can be called by a processor to execute the above method.

[0008] The method, device, cloud server, and storage medium for storing health data provided by the embodiments of this application obtain health data. If the health data meets a preset hot data condition, the health data is stored in a hot database. Or, if the health data meets a preset cold data condition, the health data is stored in a cold database. Thus, by separating hot and cold health data and storing it in a hot database or a cold database, the read and write performance of health data can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those skilled in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0010] Figure 1 It shows a schematic flowchart of a method for storing health data provided by an embodiment of the present application;

[0011] Figure 2 It shows a schematic flowchart of a method for storing health data provided by an embodiment of the present application;

[0012] Figure 3 It shows the Figure 2 schematic flowchart of step S230 of the method for storing the health data shown;

[0013] Figure 4 It shows a schematic diagram of storing a number through a 32-bit integer;

[0014] Figure 5 It shows the Figure 3 schematic flowchart of step S231 of the method for storing the health data shown;

[0015] Figure 6 It shows the Figure 3 schematic flowchart of step S232 of the method for storing the health data shown;

[0016] Figure 7 It shows a schematic diagram of fusing two data fields into a single byte;

[0017] Figure 8 It shows a schematic diagram after compressing a single health data;

[0018] Figure 9 It shows the Figure 6 schematic flowchart of step S2322 of the method for storing the health data shown;

[0019] Figure 10 It shows a schematic diagram of fusing multiple health data;

[0020] Figure 11 It shows a schematic diagram of archiving multiple health data;

[0021] Figure 12 It shows a schematic flowchart of a method for storing health data provided by an embodiment of the present application;

[0022] Figure 13 shows the Figure 12 schematic flowchart of step S340 of the health data storage method shown;

[0023] Figure 14 schematic flowchart of the health data storage method provided by an embodiment of the present application;

[0024] Figure 15 shows the Figure 14 schematic flowchart of step S410 of the health data storage method shown;

[0025] Figure 16 block diagram of the modules of the health data storage device provided by an embodiment of the present application;

[0026] Figure 17 shows the block diagram of the cloud server for executing the health data storage method according to the embodiment of the present application;

[0027] Figure 18 shows the storage unit for saving or carrying the program code for implementing the health data storage method according to the embodiment of the present application. Detailed implementation manners

[0028] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application.

[0029] Currently, for the health data collected from application programs, wearable devices, etc. by the sports health cloud system (cloud server) in the industry, all of them are simply written into a distributed database such as mysql or mongodb database clusters. The health data is not compressed according to the business characteristics of the health data, and moreover, cold and hot separation is not performed according to the characteristics of the health data for storage. Therefore, there are at least the following problems in the current storage of health data:

[0030] First, the growth rate of health data is fast and the storage pressure is large. There are many types of health data (such as sleep, blood oxygen, blood pressure, steps, etc.), and the health data grows too fast. The single table corresponding to the health data of a single health type can increase by more than a hundred billion in half a year, the storage pressure is getting bigger and bigger, and the storage cost increases sharply.

[0031] Second, in a single data record, there are many auxiliary description information (such as fields like data ID, timestamp, etc.), and the effective information content is not large.

[0032] Third, the proportion of the disk occupied by the multi-index of records is high. To ensure the query performance of massive data and the storage of healthy data, about 3 to 4 indexes need to be maintained for each record, and the disk proportion of the indexes relative to the healthy data is high.

[0033] Fourth, the proportion of historical old data is high and data access is uneven. As time goes by since the business went online, the proportion of historical old data (such as data from half a year ago) is high but the access volume is small, while the recent data is relatively small but the read and write operations are frequent.

[0034] Fifth, it is impossible to make differential configurations for the servers where the new and old healthy data are located respectively. Since the new and old healthy data are not separated and all the healthy data is stored in the same database cluster, it is impossible to make adjustments to the servers where the new healthy data or the old healthy data is located separately.

[0035] Sixth, the data read and write performance deteriorates. Since the new and old healthy data are stored in the same data cluster, the read and write performance of the healthy data deteriorates. Especially in the scenario of batch pulling of healthy data, the performance drops significantly, and it cannot meet the read and write performance requirements of massive healthy data.

[0036] In view of the above problems, through long-term research, the inventors found and proposed the storage method, device, cloud server and storage medium for healthy data provided in the embodiments of the present application. By separating the healthy data into hot and cold data and storing them in a hot database or a cold database, the read and write performance of the healthy data can be improved. Among them, the specific storage method of the healthy data will be described in detail in the subsequent embodiments.

[0037] Please refer to Figure 1 , Figure 1 which shows a schematic flowchart of the storage method for healthy data provided in an embodiment of the present application. This method can improve the read and write performance of healthy data by separating the healthy data into hot and cold data and storing them in a hot database or a cold database. In a specific embodiment, the storage method of the healthy data is applied to a healthy data storage device 200 as shown in Figure 16 and a cloud server 100 configured with the healthy data storage device 200 ( Figure 17 ). Taking the cloud server as an example, the specific process of this embodiment will be described below. Of course, it can be understood that the cloud server to which this embodiment is applied may include a sports health cloud system, which is not limited here. The following will elaborate on the Figure 1 process shown, and the storage method of the healthy data may specifically include the following steps:

[0038] Step S110: Obtain healthy data.

[0039] In this embodiment, health data can be obtained. Optionally, the health data can be collected through an application, the health data can be collected through a smart watch, the health data can be collected through a smart bracelet, the health data can be collected through a smart phone, etc., which are not limited herein. Among them, the number of the health data can be one (one record) or multiple (multiple records).

[0040] In some embodiments, health data can be obtained in real time, health data can be obtained at preset time intervals; health data can be obtained at preset time points; health data can be obtained according to other preset rules, etc., which are not limited herein.

[0041] As an implementable manner, the health data can be obtained in advance and stored in a hot database, and accordingly, the health data can be obtained from the hot database; or, the health data can be obtained in advance and written into a cloud server, and accordingly, the health data can be obtained from the cloud server, which are not limited herein.

[0042] Step S120: If the health data meets the preset hot data condition, store the health data in the hot database.

[0043] In some embodiments, a preset hot data condition and a preset cold data condition can be set and stored in advance, and both the preset hot data condition and the preset cold data condition are used as the judgment basis for health data. Therefore, in this embodiment, when the health data is obtained, the health data can be compared with the preset hot data condition and the preset cold data condition respectively to determine whether the health data meets the preset hot data condition or whether it meets the preset cold data condition.

[0044] Optionally, if it is determined that the health data meets the preset hot data condition, the health data can be considered as "hot data". Among them, hot data refers to data with a high access frequency and key to business and applications. Usually, it needs to be accessed and processed quickly and efficiently. Therefore, it needs to be stored on a high-performance and low-latency storage device or database. Hot data is suitable for data that is immediately distributed to users, that is, after being grabbed from the data source and processed, it needs to be immediately stored in a storage medium that can be quickly distributed for use by application programs or systems directly facing users. Hot data needs to focus on ensuring service quality and stability. In order to ensure the timeliness of data, it is also data with a high priority in data processing.

[0045] Optionally, if it is determined that the health data meets the preset cold data condition, the health data can be considered as "cold data". Herein, cold data refers to data with a low access frequency and less importance to business and applications. Such data usually needs to be stored for a long time but does not require frequent access and processing, so it can be stored on storage devices or databases with lower costs and larger capacities. Cold data is usually suitable for offline analysis, such as model training in machine learning or big data analysis.

[0046] In some embodiments, when the health data is obtained, the current time and the generation time of the health data can be determined, and the time difference between the current time and the generation time can be determined. If the time difference does not reach the time difference threshold, it is determined that the health data meets the preset hot data condition; or, if the time difference reaches the time difference threshold, it is determined that the health data meets the preset cold data condition.

[0047] Among them, as an implementable manner, the time difference threshold can be preset and stored, and the time difference threshold can be used as a judgment basis for the time difference between the current time and the generation time of the health data. Optionally, the time difference threshold can include three months, half a year, etc., which are not limited herein. In this embodiment, when the health data is obtained, the generation time of the health data can be obtained (for example, the obtained health data can carry the timestamp corresponding to its generation), and the time difference between the generation time and the current time can be calculated, and the time difference between the generation time and the current time can be compared with the time difference threshold to determine whether the time difference reaches the time difference threshold. Among them, if it is determined that the time difference does not reach the time difference threshold, it can be considered that the generation time of the health data is relatively close to the current time and belongs to new data, and it is determined that the health data meets the preset hot data condition; if it is determined that the time difference reaches the time difference threshold, it can be considered that the generation time of the health data is relatively far from the current time and belongs to old data, and it is determined that the health data meets the preset cold data condition.

[0048] In some embodiments, when the health data is obtained, the read-write frequency of the health data within a recent preset duration can be determined. If the read-write frequency reaches the frequency threshold, it is determined that the health data meets the preset hot data condition; or, if the read-write frequency does not reach the frequency threshold, it is determined that the health data meets the preset cold data condition.

[0049] Among them, as an implementable manner, a frequency threshold can be preset and stored in advance, and this frequency threshold can be used as a basis for judging the read / write frequency of health data. In this embodiment, when health data is obtained, the read / write frequency of this health data within a preset time period (such as one week, one month, etc.) can be obtained, and this read / write frequency is compared with the frequency threshold to determine whether this read / write frequency reaches the frequency threshold. Among them, if it is determined that the read / write frequency reaches the frequency threshold, it can be considered that the health data is frequently read and written within the preset time period, belongs to key data, and it is determined that this health data meets the preset hot data condition; if it is determined that the read / write frequency does not reach the frequency threshold, it can be considered that the health data is not frequently read and written within the preset time period, belongs to non-key data, and it is determined that this health data meets the preset cold data condition.

[0050] In this embodiment, if it is determined that the health data meets the preset hot data condition, this health data can be stored in a hot database (hot database cluster).

[0051] Step S130: If the health data meets the preset cold data condition, store the health data in a cold database.

[0052] In this embodiment, if it is determined that the health data meets the preset cold data condition, the health data can be stored in a cold database (cold database cluster). Based on this, the health data can be stored in a hot database or a cold database according to its characteristics, different configurations can be made for the health data in different databases, and both the storage cost and the read / write performance of massive data can be taken into account.

[0053] Among them, the hot database and the cold database belong to two different types of databases. The hot database is used to store health data belonging to "hot data", and the cold database is used to store health data belonging to "cold data". There are differences between the hot database and the cold database in terms of data access frequency, processing method, storage device, and application scenario.

[0054] The health data storage method provided by an embodiment of the present application obtains health data. If the health data meets the preset hot data condition, the health data is stored in a hot database, or if the health data meets the preset cold data condition, the health data is stored in a cold database. Thus, by separating the health data into hot and cold and storing it in a hot database or a cold database, the read / write performance of the health data can be improved.

[0055] Please refer to Figure 2 , Figure 2 which shows a schematic flowchart of the health data storage method provided by an embodiment of the present application. The following will elaborate in detail on the Figure 2 flow shown. The health data storage method can specifically include the following steps:

[0056] Step S210: Obtain health data.

[0057] Step S220: If the health data meets the preset hot data condition, store the health data in the hot database.

[0058] For the specific descriptions of steps S210 - S220, please refer to steps S110 - S120, which will not be elaborated here.

[0059] Step S230: If the health data meets the preset cold data condition, perform compression processing on the health data and then store it in the cold database.

[0060] Among the health data (single health data record), there are many auxiliary description information (such as fields like data ID, timestamp, etc.), the amount of valid information (such as data fields) is not large, and for each piece of health data, about 3 to 4 indexes need to be maintained, and the indexes account for a high proportion of the disk, resulting in a high storage cost. In view of the above situation, in this embodiment, if it is determined that the health data meets the preset cold data condition, the health data can be compressed and then stored in the cold database, thereby reducing the storage volume of the health data to reduce the storage cost.

[0061] As an implementable manner, a target compression processing method can be preset and stored. When it is determined that the health data meets the preset cold data condition, it can be considered that the probability of accessing this health data is low, and the health data can be compressed through the target compression processing method to obtain the compressed health data, and the compressed health data is stored in the cold database.

[0062] As another implementable manner, multiple compression processing methods can be preset and stored, and each of the multiple compression processing methods is used to compress different health types of health data. When it is determined that the health data meets the preset cold data condition, the health type corresponding to the health data can be obtained, and then the compression processing method corresponding to the health type of the health data is determined from the multiple compression processing methods as the target compression processing method, and the health data is compressed through the target compression processing method to obtain the compressed health data, and the compressed health data is stored in the cold database.

[0063] Please refer to Figure 3 , Figure 3 which shows Figure 2 a schematic flowchart of step S230 of the storage method of the health data shown in this application. The following will elaborate in detail on the Figure 2 flow shown. In this embodiment, the health data includes multiple first data fields, and the method may specifically include the following steps:

[0064] Step S231: If the health data meets the preset cold data condition, perform bit-by-bit compression on each of the multiple first data fields to obtain multiple second data fields, where there is a one-to-one correspondence between the multiple first data fields and the multiple second data fields.

[0065] Among them, health data usually adopts a field-by-field storage method, and the data type of the field needs to be a type supported by the database. For example, when storing the "device type", it is usually stored as an integer of 32 bits (4 bytes, 32bit) or 64 bits (8 bytes, 64bit). However, in the actual business of health data, there may be only 3 or 4 device types, and it is very difficult to exceed 15 device types in the long-term plan. Even if there are 30 device types according to twice the number, then it is completely sufficient to use 5 bits for storage, and there is no need to use 4 bytes (32bit) and 8 bytes (64bit) for storage.

[0066] As Figure 4 shown, it stores the number 3 through a 32-bit integer, which requires 4 bytes. However, only the low two bits are 1, and the high bits are all 0. When storing integer values from decimal 0 to 30, only the low 5 bits are used, and the high 27 bits can be considered "redundant". Therefore, for health data, most field values have their range values (such as altitude, steps, heart rate, etc.), and bit-by-bit compression of the field can be used for processing. Among them, bit-by-bit compression of the field means that for data fields with data types such as integer and long integer, and with a clear data range, according to the business scenario, a few binary bits (Bits) are used to represent the field value.

[0067] Optionally, the health data may include multiple first data fields. Of course, the health data may also include multiple redundant fields, such as user ID, device ID, etc., which are not limited here. In this embodiment, if it is determined that the health data meets the preset cold data condition, bit-by-bit compression can be performed on each of the multiple first data fields to obtain multiple second data fields, where there is a one-to-one correspondence between the multiple first data fields and the multiple second data fields. It can be understood that bit-by-bit compression of the field is for compressing the data field. For example, the original first data field (such as the "steps" field stores the number 3 as a 32-bit integer), this number 3 needs to be stored in 4 bytes of space on the computer. The second data field obtained by performing bit-by-bit compression only needs 4 bits or 5 bits to store. Then, the second data field compresses the storage space compared to the first data field.

[0068] Please refer to Figure 5 , Figure 5 which shows the Figure 3Flow diagram of step S231 of the storage method for the health data shown below. Next, a detailed description will be given of Figure 5 the process shown below. The method may specifically include the following steps:

[0069] Step S2311: If the health data meets the preset cold data condition, determine the health type corresponding to the health data.

[0070] In some embodiments, if it is determined that the health data meets the preset cold data condition, the health type corresponding to the health data may be determined. Optionally, the health type may include: steps, heart rate, blood pressure, blood oxygen, etc., which are not limited herein.

[0071] As an implementable manner, when it is determined that the health data meets the preset cold data condition, the data identifier corresponding to the health data may be obtained, and based on the data identifier corresponding to the health data, the health type corresponding to the health data may be determined.

[0072] As another implementable manner, when it is determined that the health data meets the preset cold data condition, the data source corresponding to the health data may be obtained, and based on the data source corresponding to the health data, the health type corresponding to the health data may be determined.

[0073] Step S2312: Determine the bitwise compression rule corresponding to the health type.

[0074] In some embodiments, when the health type corresponding to the health data is determined, the bitwise compression rule corresponding to the health type may be determined.

[0075] As an implementable manner, a mapping relationship may be preset and stored in advance. The mapping relationship may include the corresponding relationships between multiple health types and multiple bitwise compression rules. Among them, the corresponding relationship may include: one health type corresponding to one bitwise compression rule, multiple health types corresponding to one bitwise compression rule, or one health type corresponding to multiple bitwise compression rules, etc., which are not limited herein. In this embodiment, when the health type corresponding to the health data is determined, based on the mapping relationship, the bitwise compression rule corresponding to the health type corresponding to the health data may be determined. Optionally, the compression ratios (compression degrees) corresponding to multiple bitwise compression rules are different.

[0076] As an example, if the health type corresponding to the health data is "step type", the bitwise compression rule may be determined as the first press compression rule; if the health type corresponding to the health data is "heart rate type", the bitwise compression rule may be determined as the second press compression rule, where the first bitwise compression rule and the second bitwise compression rule are different.

[0077] Step S2313: Perform field-by-bit compression on the multiple first data fields respectively according to the bitwise compression rule to obtain the multiple second data fields.

[0078] In some embodiments, when determining the bitwise compression rule corresponding to the health type, the multiple first data fields can be respectively subjected to field-by-bit compression according to this bitwise compression rule to obtain multiple second data fields. Based on this, the field-by-bit compression for the first data fields can be made more adaptable and the field-by-bit compression effect can be better.

[0079] Step S232: Perform field fusion on the multiple second data fields and store them in the cold database.

[0080] In this embodiment, when obtaining multiple second data fields, the multiple second data fields can be subjected to field fusion and then stored in the cold database.

[0081] In some embodiments, when obtaining multiple second data fields, the multiple second data fields can be concatenated to complete the field fusion of the multiple second data fields, and after completing the field fusion of the multiple second data fields, they are stored in the cold database.

[0082] In some embodiments, when obtaining multiple second data fields, the respective sizes corresponding to the multiple second data fields can be obtained, and based on the respective sizes corresponding to the multiple second data fields, the multiple second data fields are subjected to field fusion and then stored in the cold database.

[0083] Among them, when obtaining multiple second data fields, it can be considered that the health data may include multiple second data fields and the redundant fields respectively corresponding to the multiple second data fields, and the redundant fields respectively corresponding to the multiple second data fields are the same. Based on this, the redundant fields respectively corresponding to the multiple second data fields can be extracted, and one redundant field is retained. The multiple second data fields are subjected to field fusion, and one redundant field and the multiple second data fields after field fusion are stored in the cold database in an associated manner.

[0084] Please refer to Figure 6 , Figure 6 which shows Figure 3 a schematic flowchart of step S232 of the storage method of the health data shown in the present application. The following will elaborate in detail on Figure 6 the flow shown. The method may specifically include the following steps:

[0085] Step S2321: Perform field fusion on the multiple second data fields to obtain a third data field corresponding to one or more bytes.

[0086] Among them, the basic unit of the capacity size in a computer is the byte. For the convenience of encoding and storage, on the basis of obtaining multiple second data fields (stored in bits), multiple second data fields can be fused into a single or multiple bytes for storage. Therefore, in this embodiment, when multiple second data fields are obtained, the multiple second data fields can be field-fused to obtain a third data field corresponding to one or more bytes.

[0087] In some embodiments, when multiple second data fields are obtained, the sizes of the multiple second data fields can be obtained, and the multiple second data fields can be field-fused based on the sizes of the multiple second data fields to obtain a third data field corresponding to one or more bytes.

[0088] As an implementable way, when multiple second data fields are obtained, the bit values corresponding to the multiple second data fields can be determined, and the multiple second data fields can be field-fused according to the bit values corresponding to the multiple second data fields to obtain a third data field corresponding to one or more bytes. Among them, when multiple second data fields are obtained, the bit values (bits) corresponding to the multiple second data fields can be determined, the sum of the bit values corresponding to the multiple second data fields can be calculated to obtain the total bit value, the smallest byte whose corresponding bit value is equal to or greater than the total bit value can be determined, and the third data field of the smallest byte can be obtained.

[0089] As Figure 7 shown, as an example, assume there are two second data fields. Among them, the first second data field is stored in 5 bits ( Figure 5 which represents the stored value 3), and the second second data field is stored in 3 bits ( Figure 5 which represents the stored value 4). Then, the total bit value corresponding to the two second data fields can be determined to be 8 bits, and the two second data fields can be fused into one byte (8 bits) to store the two second data fields, that is, a third data field corresponding to one byte is obtained.

[0090] As another example, assume there are two second data fields. Among them, the first second data field is stored in 5 bits, and the second second data field is stored in 6 bits. Then, the total bit value corresponding to the two second data fields can be determined to be 11 bits, and the two second data fields can be fused into two bytes (16 bits) to store the two second data fields, that is, a third data field corresponding to two bytes is obtained.

[0091] Please refer to Figure 8, as an example, the health data may include string fields such as user ID and device ID (redundant fields), and corresponding fields such as the number of steps and calories in 10 bytes after bitwise compression and field fusion of the fields. The device type and the subscript value of the device ID may correspond to 1 byte, and the timestamp may correspond to 4 bytes. That is, the health data can be fused into 15 bytes.

[0092] Step S2322: Store the third data field in the cold database.

[0093] In this embodiment, when the third data field is obtained, the third data field can be stored in the cold database.

[0094] Please refer to Figure 9 , Figure 9 which shows Figure 6 a schematic flowchart of step S2322 of the storage method of the health data shown in this application. In this embodiment, the number of health data is multiple, and the multiple health data include the same redundant fields. The following will elaborate in detail on Figure 9 the process shown. The method may specifically include the following steps:

[0095] Step S23221: Extract the redundant fields included in each of the multiple health data, and retain one of the redundant fields.

[0096] It can be understood that bitwise compression and field fusion of fields can reduce the storage space of a single health data (a single health data record), and the fusion and archiving of multiple health data (multiple health data records) can reduce the redundant fields of multiple health data (for example, the user ID field and the device ID field need to be redundantly stored for each health data), which can reduce the storage space of the health data query index. At the same time, after fusing and archiving multiple health data, the reading performance of the health data will also be better.

[0097] Optionally, the number of health data is multiple (multiple health data), and the multiple health data include the same redundant fields (such as the same user ID and device ID), that is, each health data among the multiple health data includes the same redundant fields and different third data fields.

[0098] In this embodiment, redundant fields included in each of multiple health data can be extracted, and one redundant field can be retained. It can be understood that since the redundant fields included in each of the multiple health data are the same, when the redundant fields included in each of the multiple health data are extracted, one redundant field can be randomly retained, and the remaining redundant fields can be deleted. Among them, redundant fields generally refer to user IDs, device IDs, etc., which have the same value in each original health data and are usually strings and do not require (nor can they be) compression processing. Just extract these redundant fields, and after extraction, there is no need to redundantly store each health data.

[0099] Step S23222: Merge the third data fields included in each of the multiple health data to obtain a fourth data field.

[0100] In this embodiment, when the third data fields included in each of the multiple health data are obtained, the third data fields included in each of the multiple health data can be merged to obtain a fourth data field.

[0101] In some embodiments, when the third data fields included in each of the multiple health data are obtained, the third data fields included in each of the multiple health data can be concatenated to complete the merging of the third data fields included in each of the multiple health data and obtain a fourth data field.

[0102] It can be understood that the third data fields included in each of the multiple health data all correspond to one or more bytes. Therefore, when the third data fields included in each of the multiple health data are merged, the multiple bytes can be merged (concatenated) to form a fourth data field corresponding to larger bytes.

[0103] In some embodiments, merging the third data fields included in each of the multiple health data to obtain a fourth data field may include: determining the generation time of the third data fields included in each of the multiple health data, merging the multiple third data fields according to the inclusion relationship between the generation time and multiple preset time periods to obtain multiple fifth data fields, and archiving the multiple fifth data fields to obtain a fourth data field.

[0104] Optionally, multiple preset time periods can be set in advance. Among them, the multiple preset time periods can be set according to business requirements. For example, the multiple preset time periods can include the first day, the second day... the Nth day; the multiple preset time periods can include the first week, the second week... the Nth week, etc., which are not limited here. Based on this, the generation time of the third data fields included in each of the multiple health data can be determined, the inclusion relationship between the generation time of the third data fields included in each of the multiple health data and the multiple preset time periods can be determined, and the multiple third data fields can be fused according to this inclusion relationship to obtain multiple fifth data fields. After that, the multiple fifth data fields are archived to obtain the fourth data field.

[0105] As an implementable manner, fusing the multiple third data fields according to the inclusion relationship between the generation time and the multiple preset time periods to obtain multiple fifth data fields may include: fusing the third data fields in the multiple third data fields whose corresponding generation times belong to the same preset time period among the multiple preset time periods to obtain multiple fifth data fields. For example, if the multiple preset time periods include the first day, the second day... the Nth day, the third data fields belonging to the first day in the multiple third data fields can be fused to obtain the first fifth data field among them, the third data fields belonging to the second day in the multiple third data fields can be fused to obtain the second fifth data field among them... the third data fields belonging to the Nth day in the multiple third data fields can be fused to obtain the Nth fifth data field among them, so as to obtain multiple fifth data fields.

[0106] Please refer to Figure 10 , such as Figure 10 shown, which shows one of the fifth data fields with a preset time period of 1 day. It can be understood that the fifth data field may include multiple third data fields whose generation times belong to this 1 day.

[0107] As another implementable manner, archiving the multiple fifth data fields to obtain the fourth data field may include: archiving the multiple fifth data fields according to the preset time period to obtain the fourth data field. For example, if the multiple preset time periods include the first day, the second day... the Nth day, the multiple fifth data fields within one month can be archived together to obtain the fourth data field; the multiple fifth data fields within three months can be archived together to obtain the fourth data field, etc., which are not limited here.

[0108] Please refer to Figure 11 , such as Figure 11As shown, it shows that among them, multiple fifth data fields with a preset time period of 1 day are archived according to N days to obtain a fourth data field. It can be understood that the fourth data field may include multiple fifth data fields corresponding to different preset time periods, and each fifth data field includes multiple third data fields corresponding to the same preset time period.

[0109] Step S23223: Associatively store one said redundant field and the fourth data field into the cold database.

[0110] In some embodiments, when obtaining one redundant field and a fourth data field, one redundant field and the fourth data field can be associatively stored into the cold database.

[0111] Among them, the storage structure of associatively storing one redundant field and the fourth data field into the cold database can be as follows:

[0112]

[0113] Among them, the redundant field refers to: "user", "device array", "start time", "end time", and the fourth data field refers to "the first day", "the second day"... "the Nth day".

[0114] It can be understood that the archived health data is a record within the range of "start time" and "end time". In this record, except for the redundant fields, it is the compressed and fused data of each day. Here, each day corresponds to a data field, and N days correspond to N data fields. N days depends on the range of "start time" and "end time". The setting of the time range can depend on the scale of business data. (Although storing one record can reduce disk storage, it is impossible to store all data in only one record, and there must be an upper limit. Therefore, in the business, this range can be set to half a year. Of course, the time can be adjusted flexibly, such as one month or three months.)

[0115] It can be understood that the fusion and archiving of health data have at least the following benefits:

[0116] Reduce the number of records (the number of data items), thereby reducing the storage of redundant fields (redundancy means extra. For many records, their values are the same, but in order to associate this record, redundant fields must be added), and reducing the storage of indexes (in the scenario of massive data, in order to find this data within milliseconds, indexes are needed to speed up the search speed), thereby saving the disk storage cost.

[0117] The speed of batch reading / pulling data is accelerated. For scenarios where health applications / smartwatches usually need to batch pull historical health data on a daily basis. Before data fusion and archiving were carried out, health data was discretely distributed in different parts of the database, and batch reading was relatively slow. After fusion and archiving in this embodiment, if it is necessary to read health data for a certain day or a certain period of time, one or several fields of this record can be directly read.

[0118] A storage method for health data provided by an embodiment of the present application, obtains health data, if the health data meets a preset hot data condition, then stores the health data in a hot database, or, if the health data meets a preset cold data condition, then performs compression processing on the health data and stores it in a cold database. Compared with Figure 1 the storage method for health data shown, this embodiment also performs compression processing on health data that meets the preset cold data condition and stores it in a cold database, which can reduce the storage cost of the disk.

[0119] Please refer to Figure 12 , Figure 12 shows a schematic flowchart of a storage method for health data provided by an embodiment of the present application. The following will elaborate in detail on the Figure 12 flow shown. The storage method for health data may specifically include the following steps:

[0120] Step S310: Obtain health data.

[0121] Step S320: If the health data meets the preset hot data condition, then store the health data in a hot database.

[0122] Among them, for the specific descriptions of steps S310 - S320, please refer to steps S110 - S120, and details will not be repeated here.

[0123] Step S330: If the health data meets the preset cold data condition, then start storing the health data in a cold database, and during the process of storing the health data in the cold database, perform anomaly monitoring on the health data.

[0124] Among them, since the migration of health data is executed in production, in the scenario of massive health data, various abnormalities may occur in the processing of health data (i.e., failures / error reports in the code during the migration process), and it cannot be guaranteed that it will succeed every time. Therefore, in this embodiment, abnormal monitoring can be performed on the process of storing health data in the cold database, and the health data for which these abnormalities have not been processed can be recorded to facilitate subsequent compensation operations. Optionally, scenarios where abnormalities may occur: A. Abnormalities occur when reading health data from the hot database (such as timeout when reading health data, flow limiting of the hot database (a protection measure to avoid the collapse of the hot database when the traffic of the hot database is too large), etc.); B. Abnormalities occur when compressing health data (for example, when compressing a batch of health data, an abnormality occurs halfway through; or code problems in its business, etc.); C. Abnormalities occur when writing health data to the cold database (similar to reading timeouts, when the traffic of the cold database is too large or other problems will cause writing abnormalities).

[0125] In this embodiment, if it is determined that the health data meets the preset cold data conditions, the health data can be started to be stored in the cold database, and during the process of storing the health data in the cold database, abnormal monitoring can be performed on the health data. As an implementable method, at the code level, the outermost layer that executes the processing of health data will monitor the code. When the above-mentioned abnormalities occur during the code execution, the outermost layer of the code will catch them. Therefore, it is possible to determine whether the health data is abnormal by monitoring the code.

[0126] Step S340: If it is monitored that the health data has an abnormality, the health data is compensated for abnormal data and then stored in the cold database.

[0127] In this embodiment, if it is monitored through the above method that the health data has an abnormality, if it is ignored, problems such as inconsistent and missing health data will occur. Therefore, the health data can be compensated for abnormal data, and the health data after compensating for abnormal data is stored in the cold database, thereby solving the abnormal problems of the health data.

[0128] Please refer to Figure 13 , Figure 13 which shows the schematic flow chart of step S340 of the storage method of the health data shown in the present application. The following will elaborate in detail on the Figure 12 flow shown. The method may specifically include the following steps: Figure 13 The method may specifically include the following steps:

[0129] Step S341: If it is monitored that the health data includes first data with an abnormality and second data without an abnormality, the first data is marked to obtain a target mark, and the second data is stored in the cold database.

[0130] Optionally, the quantity of health data may be multiple.

[0131] In some embodiments, if it is monitored that the health data includes first data with anomalies and second data without anomalies, the first data may be marked to obtain a target mark, and the second data may be stored in a cold database. It can be understood that through the above method, not only will it not interrupt or affect the storage of the second data without anomalies in the health data into the cold database, but it can also record the first data with anomalies in the health data for subsequent anomaly compensation processing, improving the storage effect of the health data.

[0132] Among them, it can be understood that the target mark can be used to uniquely identify the first data. Optionally, the target identifier may be a string, a number, etc., which is not limited herein.

[0133] Step S342: Re-obtain the first data based on the target mark, and store the re-obtained first data in the cold database.

[0134] In some embodiments, in the case of obtaining the target mark corresponding to the health data with anomalies, subsequently, the first data is re-obtained based on the target mark, and the re-obtained first data is stored in the cold database.

[0135] As an implementable method, in the case of obtaining the target mark corresponding to the health data with anomalies, the first data may be re-obtained from the data source (hot database or cloud server) corresponding to the health data based on the target mark, and the re-obtained first data is stored in the cold database.

[0136] As another implementable method, in the case of obtaining the target mark corresponding to the health data with anomalies, the first data may be re-obtained based on the target mark, and the first data is compressed and then stored in the cold database.

[0137] The health data storage method provided by an embodiment of the present application obtains health data. If the health data meets the preset hot data conditions, the health data is stored in the hot database. Or, if the health data meets the preset cold data conditions, the health data starts to be stored in the cold database, and during the process of storing the health data in the cold database, anomaly monitoring is performed on the health data. If it is monitored that the health data has anomalies, after anomaly data compensation, the health data is stored in the cold database. Compared with Figure 1 the health data storage method shown, this embodiment also performs anomaly monitoring on the process of storing health data in the cold database, and performs anomaly data compensation when anomalies are detected, which can improve the accuracy of health data storage.

[0138] Please refer to Figure 14 , Figure 14 which shows a schematic flowchart of a method for storing health data provided by an embodiment of the present application. The following will elaborate in detail on the Figure 14 flow shown, and the method for storing health data may specifically include the following steps:

[0139] Step S410: Obtain health data.

[0140] For the specific description of step S410, please refer to step S110 and will not be elaborated here.

[0141] Please refer to Figure 15 , Figure 15 which shows a schematic flowchart of step S410 of the method for storing health data of the present application Figure 14 shown. The following will elaborate in detail on the Figure 15 flow shown, and the method may specifically include the following steps:

[0142] Step S411: Determine the switch state corresponding to the configuration switch.

[0143] Optionally, the data source of the health data may include a hot database or a cloud server. Among them, there may be two data sources corresponding to the health data. One is that the historical application / smartwatch, etc. reported to the cloud server and the cloud server has stored it in the hot database, then the corresponding data source is the hot database; the other is that the application / smartwatch, etc. reports to the cloud server and the cloud server has not yet stored it in the hot database, and moreover, this health data may have been collected a long time ago and not reported, then the corresponding data source is the cloud server. Therefore, the data source corresponding to the obtained health data may be the hot database or the cloud server.

[0144] In this embodiment, a configuration switch may be set, and this configuration switch is used to control obtaining health data from the hot database or from the cloud server. Optionally, the configuration switch may be pre-configured with a first state and a second state. When the configuration switch is configured in the first state, it is determined to use the hot database as the data source and obtain health data from the hot database; when the configuration switch is configured in the second state, it is determined to use the cloud server as the database and obtain health data from the cloud server. Therefore, the switch state corresponding to the configuration switch can be determined, that is, it is determined whether the switch state corresponding to the configuration switch is the first state or the second state.

[0145] Step S412: If the switch state is the first state, obtain the health data from the hot database.

[0146] In some embodiments, when it is determined that the switch state of the configuration switch is the first state, indicating that the determined data source is a hot database, health data can be obtained from the hot database.

[0147] Step S413: If the switch state is the second state, obtain the health data from the cloud.

[0148] In some embodiments, when it is determined that the switch state of the configuration switch is the second state, indicating that the determined data source is a cloud server, health data can be obtained from the cloud server.

[0149] As an implementable way, the switch state of the configuration switch can be first set to the first state to obtain health data from the hot database, and the health data that meets the preset cold data conditions in the health data obtained from the hot database can be migrated to the cold database. After it is determined that the health data (compressed processing) that meets the preset cold data conditions in the hot database has been migrated to the cold database, the switch state of the configuration switch can be changed from the first state to the second state. Subsequently, health data can be obtained from the cloud server, and the health data that meets the preset hot data conditions in the health data obtained from the cloud server can be stored in the hot database, and the health data (compressed processing) that meets the preset cold data conditions in the health database obtained from the cloud server can be stored in the cold database.

[0150] Step S420: If the health data meets the preset hot data conditions, store the health data in the hot database.

[0151] Step S430: If the health data meets the preset cold data conditions, store the health data in the cold database.

[0152] For the specific descriptions of steps S420 - S430, please refer to steps S120 - S130 and will not be elaborated here.

[0153] Step S440: Determine the data source corresponding to the health data.

[0154] Among them, the exceptions of the health data set in the above embodiments are exceptions during the code execution process and can be discovered during execution. There is another type of exception that may be missing data migration (the reason for the missing data may be that it is not scanned during data reading, and this situation exists in high-concurrency massive data scenarios. Because while reading user data, it is possible that users are writing data at the same time). In this case, "data verification" needs to be performed to discover this exception and perform a compensation operation on the missing data.

[0155] Therefore, in this embodiment, after obtaining the health data from the data source corresponding to the health data and storing the health data in the cold database, "data verification" can be performed on the health data to determine whether there are any anomalies during the data migration process. In this embodiment of the present year, the data source corresponding to the health data can be determined. For example, it can be determined whether the data source corresponding to the health data is a hot database or a cloud server.

[0156] Step S450: Read the health data from the data source as the first health data, and read the health data from the cold database as the second health data.

[0157] In this embodiment, when the data source corresponding to the health data is determined, the health data can be read from the data source as the first health data, and the health data can be read from the cold database as the second health data. For example, if the data source is a cloud server, the health data can be read from the cloud server as the first health data, and the health data can be read from the cold database as the second health data. Another example is that if the data source is a hot database, the health data can be read from the hot database as the first health data, and the health data can be read from the cold database as the second health data.

[0158] In some embodiments, if the health data has been compressed during the process of storing the health data in the cold database, when the health data is read from the cold database, the health data can be decompressed and used as the second health data.

[0159] Step S460: If the first health data and the second health data are inconsistent, delete the health data stored in the cold database, and re-obtain the health data from the data source and store it in the cold database.

[0160] In some embodiments, when the first health data and the second health data are obtained, the first health data and the second health data can be compared to determine whether the first health data and the second health data are consistent. Among them, if it is determined that the first health data and the second health data are consistent, it indicates that there is no data loss during the migration of the health data from the data source to the cold database; if it is determined that the first health data and the second health data are inconsistent, it indicates that there is data loss during the migration of the health data from the data source to the cold database.

[0161] In this embodiment, if it is determined that the first health data and the second health data are inconsistent, it can be considered that there is data loss during the migration of the health data from the data source to the cold database. It is necessary to reprocess the health data based on the health data in the data source. Therefore, the health data stored in the cold database can be deleted, and the health data (after compression processing) can be retrieved from the data source and stored in the cold database again.

[0162] Step S470: If the first health data and the second health data are consistent, delete the health data stored in the data source.

[0163] In this embodiment, if it is determined that the first health data and the second health data are consistent, it can be considered that there is no data loss during the migration of the health data from the data source to the cold database, and the health data has been successfully migrated from the data source to the cold database. The health data stored in the data source can be deleted to reduce the storage pressure of the data source.

[0164] The storage method of health data provided by an embodiment of the present application includes: obtaining health data; if the health data meets the preset hot data condition, storing the health data in the hot database, or if the health data meets the preset cold data condition, storing the health data in the cold database; determining the data source corresponding to the health data; reading the health data from the data source as the first health data, and reading the health data from the cold database as the second health data; if the first health data and the second health data are inconsistent, deleting the health data stored in the cold database, and retrieving the health data from the data source and storing it in the cold database again; if the first health data and the second health data are consistent, deleting the health data stored in the data source. Compared with Figure 1 the storage method of health data shown, this embodiment also performs verification of health data after the migration of health data, which can improve the accuracy of health data storage.

[0165] Please refer to Figure 16 , Figure 16 which shows the block diagram of the storage device of health data provided by an embodiment of the present application. The following will elaborate on the Figure 16 block diagram shown. The storage device 200 of health data includes: a health data acquisition module 210, a first health data storage module 220, and a second health data storage module 230, where:

[0166] The health data acquisition module 210 is used to acquire health data.

[0167] Further, the health data acquisition module 210 includes: a switch state determination sub-module, a first health data acquisition sub-module, and a second health data acquisition sub-module, where:

[0168] A switch state determination sub-module, which is used to determine the switch state corresponding to the configuration switch.

[0169] A first health data acquisition sub-module, which is used to acquire the health data from the hot database if the switch state is the first state.

[0170] A second health data acquisition sub-module, which is used to acquire the health data from the cloud if the switch state is the second state.

[0171] A first health data storage module 220, which is used to store the health data in the hot database if the health data meets the preset hot data conditions.

[0172] A second health data storage module 230, which is used to store the health data in the cold database if the health data meets the preset cold data conditions.

[0173] Further, the second health data storage module 230 includes: a health data storage sub-module, where:

[0174] The health data storage sub-module is used to perform compression processing on the health data and then store it in the cold database if the health data meets the preset cold data conditions.

[0175] Further, the health data includes a plurality of first data fields, and the health data storage sub-module includes: a second data field acquisition unit and a second data field storage unit, where:

[0176] The second data field acquisition unit is used to perform bit-by-bit compression on the plurality of first data fields respectively to obtain a plurality of second data fields if the health data meets the preset cold data conditions, where there is a one-to-one correspondence between the plurality of first data fields and the plurality of second data fields.

[0177] Further, the second data field acquisition unit includes: a health type determination sub-unit, a bit-by-bit compression rule determination sub-unit, and a second data field acquisition sub-unit, where:

[0178] The health type determination sub-unit is used to determine the health type corresponding to the health data if the health data meets the preset cold data conditions.

[0179] The bit-by-bit compression rule determination sub-unit is used to determine the bit-by-bit compression rule corresponding to the health type.

[0180] The second data field acquisition sub-unit is used to perform bit-by-bit compression on the plurality of first data fields respectively according to the bit-by-bit compression rule to obtain the plurality of second data fields.

[0181] A second data field storage unit for storing the fused multiple second data fields into the cold database.

[0182] Further, the second data field storage unit includes: a third data field obtaining subunit and a third data field storing subunit, where:

[0183] The third data field obtaining subunit is configured to perform field fusion on the multiple second data fields to obtain a third data field corresponding to one or more bytes.

[0184] Further, the third data field obtaining subunit includes: a bit value determining sub-subunit and a third data field obtaining sub-subunit, where:

[0185] The bit value determining sub-subunit is configured to determine the bit values corresponding to the multiple second data fields respectively.

[0186] The third data field obtaining sub-subunit is configured to perform field fusion on the multiple second data fields according to the bit values corresponding to the multiple second data fields respectively to obtain a third data field corresponding to one or more bytes.

[0187] The third data field storing subunit is configured to store the third data field into the cold database.

[0188] Further, the number of the health data is multiple, and the multiple health data include the same redundant fields. The third data field storing subunit includes: a redundant field extracting sub-subunit, a fourth data field obtaining sub-subunit, and a fourth data field storing sub-subunit, where:

[0189] The redundant field extracting sub-subunit is configured to extract the redundant fields included in the multiple health data respectively and retain one of the redundant fields.

[0190] The fourth data field obtaining sub-subunit is configured to fuse the third data fields included in the multiple health data respectively to obtain a fourth data field.

[0191] Further, the fourth data field obtaining sub-subunit includes: a generation time determining sub-sub-subunit, a fifth data field obtaining sub-sub-subunit, and a fourth data field obtaining sub-sub-subunit, where:

[0192] The generation time determining sub-sub-subunit is configured to determine the generation times of the third data fields included in the multiple health data respectively.

[0193] The fifth data field obtaining sub-sub-subunit is configured to fuse the multiple third data fields according to the inclusion relationship between the generation time and multiple preset time periods to obtain multiple fifth data fields.

[0194] Further, the fifth data field obtaining sub-sub-sub unit includes: a fifth data field obtaining sub-sub-sub-sub unit, wherein:

[0195] The fifth data field obtaining sub-sub-sub-sub unit is configured to fuse the third data fields among the multiple third data fields whose corresponding generation times belong to the same preset time period among the multiple preset time periods, to obtain the multiple fifth data fields.

[0196] The fourth data field obtaining sub-sub-sub unit is configured to archive the multiple fifth data fields to obtain the fourth data field.

[0197] The fourth data field storing sub-sub unit is configured to associatively store one of the redundant fields and the fourth data field into the cold database.

[0198] Further, the second health data storage module 230 includes: an anomaly monitoring sub-module and an anomaly data compensation sub-module, wherein:

[0199] The anomaly monitoring sub-module is configured to perform anomaly monitoring on the health data during the process of storing the health data into the cold database.

[0200] The anomaly data compensation sub-module is configured to, if it is monitored that the health data is abnormal, perform anomaly data compensation on the health data and then store it into the cold database.

[0201] Further, the anomaly data compensation sub-module includes: an anomaly data marking unit and an anomaly data compensation unit, wherein:

[0202] The anomaly data marking unit is configured to, if it is monitored that the health data includes first data with anomalies and second data without anomalies, mark the first data to obtain a target mark, and store the second data into the cold database.

[0203] The anomaly data compensation unit is configured to re-obtain the first data based on the target mark, and store the re-obtained first data into the cold database.

[0204] Further, the storage device 200 of the health data further includes: a data source determination module, a health data reading module, and a health data comparison module, wherein:

[0205] The data source determination module is configured to determine the data source corresponding to the health data.

[0206] A health data reading module, configured to read the health data from the data source as the first health data, and read the health data from the cold database as the second health data.

[0207] A health data comparison module, configured to, if the first health data is inconsistent with the second health data, delete the health data stored in the cold database, and re-obtain the health data from the data source and store it in the cold database.

[0208] Further, the storage device 200 of the health data further includes: a health data deletion module, where:

[0209] The health data deletion module is configured to, if the first health data is consistent with the second health data, delete the health data stored in the data source.

[0210] Further, the storage device 200 of the health data further includes: a time difference determination module, a first condition determination module, and a second condition determination module, where:

[0211] The time difference determination module is configured to determine the current time and the generation time of the health data, and determine the time difference between the current time and the generation time.

[0212] The first condition determination module is configured to, if the time difference does not reach the time difference threshold, determine that the health data meets the preset hot data condition.

[0213] The second condition determination module is configured to, if the time difference reaches the time difference threshold, determine that the health data meets the preset cold data condition.

[0214] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the foregoing method embodiments, and will not be described herein again.

[0215] In several embodiments provided by the present application, the coupling between modules can be electrical, mechanical, or other forms of coupling.

[0216] In addition, in each embodiment of the present application, the various functional modules can be integrated into one processing module, or each module can exist physically alone, or two or more modules can be integrated into one module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software functional modules.

[0217] Please refer to Figure 17, which shows a structural block diagram of a cloud server 100 provided by an embodiment of the present application. The cloud server 100 may be a cloud server such as a smart phone, a tablet computer, an e-book, etc. that can run application programs. The cloud server 100 in the present application may include one or more of the following components: a processor 110, a memory 120, and one or more application programs, where one or more application programs may be stored in the memory 120 and configured to be executed by one or more processors 110, and one or more programs are configured to execute the methods described in the foregoing method embodiments.

[0218] Among them, the processor 110 may include one or more processing cores. The processor 110 uses various interfaces and lines to connect various parts within the entire cloud server 100, and by running or executing instructions, programs, code sets, or instruction sets stored in the memory 120, and calling data stored in the memory 120, it executes various functions of the cloud server 100 and processes data. Optionally, the processor 110 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 110 may integrate one or a combination of several of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes the operating system, user interface, application programs, etc.; the GPU is responsible for rendering and drawing the content to be displayed; the modem is used to process wireless communication. It can be understood that the above-mentioned modem may not be integrated into the processor 110 and may be implemented separately through a communication chip.

[0219] The memory 120 may include random access memory (RAM), and may also include read-only memory. The memory 120 can be used to store instructions, programs, codes, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for implementing functions (such as touch functions, sound playback functions, image playback functions, etc.), instructions for implementing the following method embodiments, etc. The data storage area may also store data created during the use of the cloud server 100 (such as phone books, audio and video data, chat record data, etc.).

[0220] Please refer to Figure 18, which shows a structural block diagram of a computer-readable storage medium provided by an embodiment of the present application. Program code is stored in the computer-readable medium 300, and the program code can be called by a processor to execute the method described in the above method embodiment.

[0221] The computer-readable storage medium 300 can be an electronic memory such as a flash memory, EEPROM (electrically erasable programmable read-only memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 300 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 300 has a storage space for the program code 310 that executes any method step in the above method. These program codes can be read out from or written into one or more computer program products. The program code 310 can be compressed in an appropriate form, for example.

[0222] In summary, for the health data storage method, device, cloud server, and storage medium provided by the embodiments of the present application, health data is obtained. If the health data meets the preset hot data condition, the health data is stored in the hot database. Or, if the health data meets the preset cold data condition, the health data is stored in the cold database. Thus, by separating the health data into hot and cold and storing it in the hot database or the cold database, the read and write performance of the health data can be improved.

[0223] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for storing health data, characterized in that, The method comprises: Access to health data; If the health data meets the preset hot data condition, storing the health data in the hot database; or If the health data meets the preset cold data condition, the health data is stored in the cold database.

2. The method according to claim 1, characterized in that If the health data meets the preset cold data condition, storing the health data in the cold database includes: If the health data meets the preset cold data condition, the health data is compressed and stored in the cold database.

3. The method according to claim 2, wherein The health data includes a plurality of first data fields; if the health data satisfies the preset cold data condition, compressing the health data and storing it in the cold database includes: If the health data meets the preset cold data condition, performing field bitwise compression on the multiple first data fields to obtain multiple second data fields, wherein there is a one-to-one correspondence between the multiple first data fields and the multiple second data fields; The multiple second data fields are subjected to field fusion and stored in the cold database.

4. The method according to claim 3, characterized in that If the health data meets the preset cold data condition, the plurality of first data fields are respectively subjected to bitwise compression to obtain a plurality of second data fields, including: If the health data meets the preset cold data condition, determining the health type corresponding to the health data; Determine a bitwise compression rule corresponding to the health type; The plurality of first data fields are respectively subjected to field bitwise compression according to the bitwise compression rule to obtain the plurality of second data fields.

5. The method according to claim 3, characterized in that, The performing field fusion on the plurality of second data fields and storing the fields in the cold database includes: Performing field fusion on the multiple second data fields to obtain a third data field corresponding to one or more bytes; The third data field is stored in the cold database.

6. The method according to claim 5, characterized in that, The performing field fusion on the plurality of second data fields to obtain a third data field corresponding to one or more bytes includes: Determine a bit value corresponding to each of the plurality of second data fields; The multiple second data fields are field-fused according to the bit values corresponding to each of the multiple second data fields to obtain a third data field corresponding to one or more bytes.

7. The method according to claim 5, characterized in that, There are multiple health data, and the multiple health data include the same redundant field. Storing the third data field in the cold database includes: extracting the redundant fields respectively included in the plurality of health data and retaining one redundant field; Merging the third data fields included in each of the plurality of health data to obtain a fourth data field; One of the redundant fields and the fourth data field is associated and stored in the cold database.

8. The method according to claim 7, characterized in that The fusing of the third data fields included in each of the plurality of health data to obtain the fourth data field comprises: determining a generation time of a third data field included in each of the plurality of health data; Merging the plurality of third data fields according to the inclusion relationship between the generation time and the plurality of preset time periods to obtain a plurality of fifth data fields; The plurality of fifth data fields are archived to obtain the fourth data field.

9. The method according to claim 8, characterized in that The plurality of third data fields are merged according to the inclusion relationship between the generation time and the plurality of preset time periods to obtain the plurality of fifth data fields; The third data fields whose corresponding generation times belong to the same preset time period among the plurality of preset time periods are merged to obtain the plurality of fifth data fields.

10. The method according to any one of claims 1 to 9, characterized in that Storing the health data in a cold database includes: During the process of storing the health data in the cold database, performing abnormality monitoring on the health data; If the health data is detected to be abnormal, the health data is compensated for the abnormal data and then stored in the cold database.

11. The method according to claim 10, characterized in that If the health data is detected to be abnormal, the abnormal data is compensated for and stored in the cold database, including: If it is monitored that the health data includes first data with abnormalities and second data without abnormalities, marking the first data to obtain a target mark, and storing the second data in the cold database; The first data is retrieved based on the target marker, and the retrieved first data is stored in the cold database.

12. The method according to any one of claims 1 to 9, characterized in that After storing the health data in the cold database if the health data meets the preset cold data condition, the method further includes: Determining a data source corresponding to the health data; Reading the health data from the data source as first health data, and reading the health data from the cold database as second health data; If the first health data and the second health data are inconsistent, the health data stored in the cold database is deleted, and the health data is re-acquired from the data source and stored in the cold database.

13. The method according to claim 12, characterized in that The method further comprises: If the first health data and the second health data are consistent, the health data stored in the data source is deleted.

14. The method according to claim 12, wherein The data source includes the hot database or the cloud server.

15. The method according to claim 14, characterized in that The obtaining of health data includes: Determine the switch state corresponding to the configuration switch; If the switch state is the first state, obtaining the health data from the thermal database; or If the switch state is the second state, the health data is obtained from the cloud server.

16. The method according to any one of claims 1-9, characterized in that, After obtaining the health data, the method further includes: Determining a current time and a generation time of the health data, and determining a time difference between the current time and the generation time; If the time difference does not reach the time difference threshold, determining that the health data meets the preset hot data condition; or If the time difference reaches the time difference threshold, it is determined that the healthy data meets the preset cold data condition.

17. A storage device for health data, characterized in that, The device comprises: A health data acquisition module is used to acquire health data; A first health data storage module is configured to store the health data in a hot database if the health data meets a preset hot data condition; or The second health data storage module is configured to store the health data in a cold database if the health data meets a preset cold data condition.

18. A cloud server, characterized in that, Comprising a memory and a processor, the memory is coupled to the processor, and the memory stores instructions that, when executed by the processor, cause the processor to execute the method according to any one of claims 1-16.

19. A computer-readable storage medium, characterized in that, Program code is stored in the computer-readable storage medium, and the program code can be called by the processor to execute the method according to any one of claims 1-16.

Images