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

Abstract

The present application relates to the technical field of data storage, and discloses a health data storage method and device, a cloud server and a storage medium. The method comprises: 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. By performing cold and hot separation on the health data so as to be stored in the hot database or the cold database, the present application can improve the read-write performance of the health data.

Description

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

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to Chinese application No. CN2024101255228, filed on January 29, 2024, the entire contents of which are hereby incorporated by reference for all purposes. Technical Field

[0003] The present application relates to the field of data storage technology, and more specifically, to a method, device, cloud server, and storage medium for storing health data. Background Art

[0004] At present, the sports health cloud system writes all health data collected from applications, wearable devices, etc. into distributed database clusters such as MySQL or MongoDB. Summary of the Invention

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

[0006] In a first aspect, an embodiment of the present application provides a method for storing health data, the method comprising: acquiring 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.

[0007] In a second aspect, an embodiment of the present application provides a device for storing health data, the device comprising: a health data acquisition module for acquiring 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.

[0008] In a third aspect, an embodiment of the present application provides a cloud server comprising a memory and a processor, wherein the memory is coupled to the processor, the memory stores instructions, and when the instructions are executed by the processor, the processor executes the above method.

[0009] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which program code is stored, and the program code can be called by a processor to execute the above method. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0011] FIG1 is a schematic diagram showing a flow chart of a method for storing health data provided in an embodiment of the present application;

[0012] FIG2 is a schematic diagram showing a flow chart of a method for storing health data provided in an embodiment of the present application;

[0013] FIG3 is a flow chart showing step S230 of the health data storage method shown in FIG2 of the present application;

[0014] FIG4 shows a schematic diagram of storing numbers via a 32-bit integer;

[0015] FIG5 is a flow chart showing step S231 of the health data storage method shown in FIG3 of the present application;

[0016] FIG6 is a flow chart showing step S232 of the health data storage method shown in FIG3 of the present application;

[0017] FIG7 shows a schematic diagram of two data fields fused into a single byte;

[0018] FIG8 shows a schematic diagram of a single piece of health data after compression processing;

[0019] FIG9 is a flow chart showing step S2322 of the health data storage method shown in FIG6 of the present application;

[0020] FIG10 shows a schematic diagram of fusing multiple health data;

[0021] FIG11 is a schematic diagram showing archiving of multiple health data;

[0022] FIG12 is a schematic diagram showing a flow chart of a method for storing health data provided in an embodiment of the present application;

[0023] FIG13 is a flow chart showing step S340 of the health data storage method shown in FIG12 of the present application;

[0024] FIG14 is a schematic diagram showing a flow chart of a method for storing health data provided in an embodiment of the present application;

[0025] FIG15 is a flow chart showing step S410 of the health data storage method shown in FIG14 of the present application;

[0026] FIG16 shows a module block diagram of a health data storage device provided by an embodiment of the present application;

[0027] FIG17 shows a block diagram of a cloud server for executing a method for storing health data according to an embodiment of the present application;

[0028] Figure 18 shows a storage unit for storing or carrying program codes for implementing the health data storage method according to an embodiment of the present application. DETAILED DESCRIPTION

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

[0030] Currently, the industry's sports health cloud systems (cloud servers) simply write all health data collected from applications, wearable devices, and other sources into distributed database clusters such as MySQL or MongoDB. These systems fail to compress health data based on its business characteristics, and storage of health data is not separated into hot and cold storage based on the data's characteristics. Consequently, current health data storage faces at least the following issues:

[0031] First, health data is growing rapidly, creating significant storage pressure. There are many types of health data (such as sleep, blood oxygen, blood pressure, and step count), and the data is growing so rapidly that the amount of data in a single table for a single health type can exceed hundreds of billions every six months. This creates increasing storage pressure and a sharp increase in storage costs.

[0032] Second, in a single data record, there is a lot of auxiliary descriptive information (such as data ID, timestamp and other fields), and the effective information capacity is not large.

[0033] Third, the large number of records means a high disk usage for indexes. To ensure query performance for massive amounts of data and to store healthy data, each record requires maintaining approximately three to four indexes, which means that the disk usage for indexes is relatively high compared to that for healthy data.

[0034] Fourth, the proportion of historical data is high and data access is uneven. As the service goes online, historical data (such as six months ago) accounts for a high proportion but has low access volume, while recent data is relatively small but read and written frequently.

[0035] Fifth, it is impossible to make differentiated configurations for the servers where new and old health data reside. Because the new and old health data are not separated and all health data is stored in the same database cluster, it is impossible to make adjustments to the servers where the new or old health data resides separately.

[0036] Sixth, data read and write performance deteriorates. Because new and old health data are stored in the same data cluster, the read and write performance of health data deteriorates. In particular, the performance of batch health data extraction drops significantly, failing to meet the read and write performance requirements of massive health data.

[0037] To address the above issues, the inventors, after extensive research, have discovered and proposed the health data storage method, device, cloud server, and storage medium provided in the embodiments of this application. By separating health data into hot and cold databases and storing them in either a hot or cold database, the read and write performance of health data can be improved. The specific health data storage method will be described in detail in the subsequent embodiments.

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

[0039] Step S110: Obtain health data.

[0040] In this embodiment, health data can be obtained. Optionally, the health data can be collected and obtained through an application, the health data can be collected and obtained through a smart watch, the health data can be collected and obtained through a smart bracelet, the health data can be collected and obtained through a smartphone, etc., without limitation. The number of health data can be one (one record) or multiple (multiple records).

[0041] In some implementations, health data may be acquired in real time, at preset time intervals, at preset time points, or according to other preset rules, etc., which are not limited here.

[0042] As an implementable method, the health data can be pre-acquired and stored in a hot database, and the health data can be obtained from the hot database accordingly; or, the health data can be pre-acquired and written to a cloud server, and the health data can be obtained from the cloud server accordingly, which is not limited here.

[0043] Step S120: If the health data meets the preset hot data condition, the health data is stored in a hot database.

[0044] In some embodiments, preset hot data conditions and preset cold data conditions may be pre-set and stored, and both of these conditions may be used as a basis for determining health data. Therefore, in this embodiment, when health data is acquired, the health data may be compared with the preset hot data conditions and the preset cold data conditions, respectively, to determine whether the health data satisfies the preset hot data conditions or the preset cold data conditions.

[0045] Optionally, if it is determined that the health data meets the preset hot data conditions, the health data can be considered as "hot data". Among them, hot data refers to data that is accessed frequently and is critical to business and applications. It usually needs to be accessed and processed quickly and efficiently, and therefore needs to be stored on high-performance, low-latency storage devices or databases. Hot data is suitable for immediate distribution to users, that is, after being captured from the data source and processed, it needs to be immediately stored in a storage medium that can be quickly distributed for use by applications or directly user-oriented systems. Hot data needs to focus on ensuring service quality and stability. In order to ensure the timeliness of the data, it is also high-priority data in data processing.

[0046] Optionally, if health data is determined to meet pre-defined cold data criteria, it can be considered "cold data." Cold data refers to data that is infrequently accessed and less critical to business and applications. This data typically requires long-term storage but doesn't require frequent access or processing. Therefore, it can be stored on lower-cost, higher-capacity storage devices or databases. Cold data is often suitable for offline analysis, such as model training in machine learning or big data analysis.

[0047] In some embodiments, when 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.

[0048] As an implementable method, a time difference threshold can be pre-set and stored. The time difference threshold can be used as a basis for judging the time difference between the current time and the generation time of the health data. Optionally, the time difference threshold can include three months, six months, etc., which are not limited here. 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 its corresponding generation timestamp), 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. 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 close to the current time and is new data, and the health data is determined to meet 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 far from the current time and is old data, and the health data is determined to meet the preset cold data condition.

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

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

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

[0052] Step S130: If the health data meets the preset cold data condition, the health data is stored in the cold database.

[0053] In this embodiment, if the health data meets the preset cold data conditions, 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, and health data in different databases can be configured differently, which can balance storage costs and the read and write performance of massive data.

[0054] Among them, hot databases and cold databases belong to two different types of databases. Hot databases are used to store health data that belongs to "hot data", and cold databases are used to store health data that belongs to "cold data". Hot databases and cold databases differ in data access frequency, processing methods, storage devices and application scenarios.

[0055] A method for storing health data provided by an embodiment of the present application obtains health data and, if the health data meets a preset hot data condition, stores the health data in a hot database, or, if the health data meets a preset cold data condition, stores the health data in a cold database. Thus, by separating the health data into hot and cold data and storing them in a hot database or a cold database, the read and write performance of the health data can be improved.

[0056] Please refer to Figure 2, which shows a schematic diagram of a process flow of a method for storing health data provided by an embodiment of the present application. The process shown in Figure 2 will be described in detail below. The method for storing health data may specifically include the following steps:

[0057] Step S210: Obtain health data.

[0058] Step S220: If the health data meets the preset hot data condition, the health data is stored in the hot database.

[0059] For the detailed description of steps S210 to S220, please refer to steps S110 to S120, which will not be repeated here.

[0060] Step S230: If the health data meets the preset cold data condition, the health data is compressed and stored in the cold database.

[0061] Among them, in health data (a single health data record), there is a lot of auxiliary descriptive information (such as data ID, timestamp and other fields), and the effective information (such as data fields) is not large. In addition, each health data needs to maintain about 3 to 4 indexes, and the index occupies a high proportion of the disk, resulting in high storage costs. In response to the above situation, in this embodiment, if it is determined that the health data meets the preset cold data conditions, the health data can be compressed and stored in a cold database, thereby reducing the storage capacity of the health data and reducing storage costs.

[0062] As an implementable method, a target compression processing method can be pre-set and stored. When it is determined that the health data meets the preset cold data conditions, it can be considered that the probability of the health data being accessed is low. The health data can be compressed using the target compression processing method to obtain the compressed health data, and the compressed health data can be stored in the cold database.

[0063] As another feasible method, multiple compression processing methods can be pre-set and stored, and each of the multiple compression processing methods is used to compress and process health data of different health types. When it is determined that the health data meets the preset cold data conditions, the health type corresponding to the health data can be obtained, and then the compression processing method corresponding to the health type corresponding to the health data can be determined from the multiple compression processing methods as the target compression processing method. The health data is compressed using the target compression processing method to obtain the compressed health data, and the compressed health data is stored in the cold database.

[0064] Please refer to Figure 3, which shows a schematic flow chart of step S230 of the method for storing health data shown in Figure 2 of the present application. The process shown in Figure 2 will be described in detail below. In this embodiment, the health data includes multiple first data fields, and the method may specifically include the following steps:

[0065] Step S231: If the health data meets the preset cold data condition, the multiple first data fields are respectively compressed bit by bit 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.

[0066] Among them, health data is usually stored in a field-by-field manner, and the data type of the field must be a type supported by the database. For example, when storing "device type", it is usually stored through 32-bit (4 bytes, 32 bits) or 64-bit (8 bytes, 64 bits) integers. However, the actual business for health data may only include 3 or 4 device types, and it is difficult to exceed 15 device types in long-term planning. Even if the number of device types is doubled to 30, then using 5 bits for storage is actually sufficient, and there is no need to use 4 bytes (32 bits) and 8 bytes (64 bits) for storage.

[0067] As shown in Figure 4, storing the number 3 using a 32-bit integer requires 4 bytes. However, only the lower two bits are 1, and the upper bits are all 0. If you need to store a decimal integer value from 0 to 30, only the lower 5 bits are used, and the upper 27 bits can be considered "redundant." Therefore, for health data, most field values ​​have a range of values ​​(such as altitude, number of steps, heart rate, etc.), and field bitwise compression can be used for processing. Field bitwise compression refers to using a smaller number of binary bits (bits) to represent the field value for data fields with a clear data range, such as integers and long integers, based on the business scenario.

[0068] 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, the multiple first data fields can be compressed bit by bit 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. It can be understood that field bit compression is compression of the data field. For example, the original first data field (such as the "number of steps" field stores a 32-bit integer number 3). This number 3 requires 4 bytes of space to store on the computer. The second data field obtained by field bit compression only requires 4 bits (bits) or 5 bits (bits) to store. Then, the second data field has compressed storage space relative to the first data field.

[0069] Please refer to Figure 5, which shows a schematic flow chart of step S231 of the health data storage method shown in Figure 3 of the present application. The process shown in Figure 5 will be described in detail below. The method may specifically include the following steps:

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

[0071] 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 can be determined. Optionally, the health type can include: number of steps, heart rate, blood pressure, blood oxygen, etc., which are not limited here.

[0072] As an implementable method, when it is determined that the health data meets the preset cold data conditions, the data identifier corresponding to the health data can be obtained, and the health type corresponding to the health data can be determined based on the data identifier corresponding to the health data.

[0073] As another feasible method, when it is determined that the health data meets the preset cold data conditions, the data source corresponding to the health data can be obtained, and the health type corresponding to the health data can be determined based on the data source corresponding to the health data.

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

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

[0076] As an implementable manner, a mapping relationship can be pre-set and stored, and the mapping relationship can include a correspondence between multiple health types and multiple bitwise compression rules, wherein the correspondence can include: one health type corresponds to one bitwise compression rule, multiple health types correspond to one bitwise compression rule, or one health type corresponds to multiple bitwise compression rules, etc., which are not limited here. In this embodiment, when determining the health type corresponding to the health data, the bitwise compression rule that has a corresponding relationship with the health type corresponding to the health data can be determined based on the mapping relationship. Optionally, the compression rates (compression levels) corresponding to the multiple bitwise compression rules are different.

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

[0078] Step S2313: performing bitwise compression on the multiple first data fields respectively according to the bitwise compression rule to obtain the multiple second data fields.

[0079] In some implementations, after determining a bitwise compression rule corresponding to a health type, multiple first data fields can be subjected to field bitwise compression according to the bitwise compression rule to obtain multiple second data fields. This can make the field bitwise compression of the first data fields more adaptable and achieve a better field bitwise compression effect.

[0080] Step S232: performing field fusion on the plurality of second data fields and storing the resultant data in the cold database.

[0081] In this embodiment, when a plurality of second data fields are obtained, the plurality of second data fields may be fused and then stored in the cold database.

[0082] In some embodiments, when multiple second data fields are obtained, the multiple second data fields can be spliced ​​to complete field fusion of the multiple second data fields, and stored in the cold database after the field fusion of the multiple second data fields is completed.

[0083] In some embodiments, when multiple second data fields are obtained, the sizes corresponding to the multiple second data fields can be obtained, and the multiple second data fields can be fused based on the sizes corresponding to the multiple second data fields and then stored in the cold database.

[0084] In the case of obtaining multiple second data fields, it can be considered that the health data may include multiple second data fields and redundant fields corresponding to each of the multiple second data fields, and the redundant fields corresponding to each of the multiple second data fields are the same. Based on this, the redundant fields corresponding to each of the multiple second data fields can be extracted, and one redundant field can be retained. The multiple second data fields can be fused, and the one redundant field and the multiple second data fields after the fusion are associated and stored in the cold database.

[0085] Please refer to Figure 6, which shows a schematic flow chart of step S232 of the health data storage method shown in Figure 3 of the present application. The process shown in Figure 6 will be described in detail below. The method may specifically include the following steps:

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

[0087] The basic unit of computer capacity is byte. To facilitate encoding and storage, after obtaining multiple second data fields (stored in bits), the multiple second data fields can be merged 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 merged to obtain a third data field corresponding to one or more bytes.

[0088] 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.

[0089] As an practicable approach, when multiple second data fields are obtained, bit values ​​corresponding to each of 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 each of the multiple second data fields to obtain a third data field corresponding to one or more bytes. Specifically, when multiple second data fields are obtained, bit values ​​corresponding to each of the multiple second data fields can be determined, the sum of the bit values ​​corresponding to each of the multiple second data fields can be calculated to obtain a total bit value, the minimum byte whose corresponding bit value is equal to or greater than the total bit value can be determined, and the third data field corresponding to the minimum byte can be obtained.

[0090] As shown in FIG7 , as an example, assuming that there are two second data fields, wherein the first second data field is stored using 5 bits (indicated by the storage value 3 in FIG5 ), and the second second data field is stored using 3 bits (indicated by the storage value 4 in FIG5 ), then it can be determined that the total bit value corresponding to the two second data fields is 8 bits, and the two second data fields can be merged into one byte (8 bits) to store the two second data fields, that is, a third data field corresponding to one byte is obtained.

[0091] As another example, assuming that there are two second data fields, where the first second data field is stored using 5 bits and the second second data field is stored using 6 bits, then it can be determined that the total bit value corresponding to the two second data fields is 11 bits, and the two second data fields can be merged into two bytes (16 bits) to store the two second data fields, that is, a third data field corresponding to two bytes is obtained.

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

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

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

[0095] Please refer to Figure 9, which shows a flow chart of step S2322 of the health data storage method shown in Figure 6 of the present application. In this embodiment, there are multiple health data items, and the multiple health data items include the same redundant fields. The process shown in Figure 9 will be described in detail below. The method may specifically include the following steps:

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

[0097] Among them, it can be understood that the storage space of a single health data (a single health data record) can be reduced through field bitwise compression and field fusion, 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 require each health data to be redundantly saved), which can reduce the storage space of the health data query index. At the same time, after the multiple health data are fused and archived, the reading performance of the health data will also be better.

[0098] Optionally, the number of health data is multiple (multiple health data), and the multiple health data include the same redundant fields (user ID, device ID, etc. are the same), that is, each health data in the multiple health data includes the same redundant fields and different third data fields.

[0099] In this embodiment, redundant fields included in each of the 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 ID, device ID, etc., which have the same value in each of the original health data, and are usually strings, and do not need to be compressed (and cannot be compressed). It is sufficient to extract these redundant fields. After extraction, there is no need to store each health data redundantly.

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

[0101] In this embodiment, when the third data field included in each of the plurality of health data is obtained, the third data field included in each of the plurality of health data may be fused to obtain the fourth data field.

[0102] In some embodiments, when obtaining the third data fields respectively included in multiple health data, the third data fields respectively included in the multiple health data can be spliced ​​to complete the fusion of the third data fields respectively included in the multiple health data to obtain the fourth data field.

[0103] Among them, it can be understood that the third data field included in each of the multiple health data corresponds to one or more bytes. Therefore, when the third data fields included in each of the multiple health data are fused, the multiple bytes can be fused (spliced) to form a fourth data field corresponding to a larger byte.

[0104] In some embodiments, fusing the third data fields included in each of the multiple health data to obtain the fourth data field may include: determining the generation time of the third data field included in each of the multiple health data, fusing 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 the fourth data field.

[0105] Optionally, multiple preset time periods can be pre-set, wherein the multiple preset time periods can be set according to business needs. 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 field included in each of the multiple health data can be determined, and the inclusion relationship between the generation time of the third data field included in each of the multiple health data and the multiple preset time periods can be determined. The multiple third data fields are merged according to the inclusion relationship to obtain multiple fifth data fields. Afterwards, the multiple fifth data fields are archived to obtain the fourth data field.

[0106] As an practicable approach, fusing multiple third data fields based on the inclusion relationship between the generation time and multiple preset time periods to obtain multiple fifth data fields may include fusing the third data fields whose corresponding generation times fall within the same preset time period among the multiple preset time periods to obtain the multiple fifth data fields. For example, if the multiple preset time periods include the first day, the second day, ..., and the Nth day, the third data fields belonging to the first day among the multiple third data fields may be fused to obtain the first fifth data field, the third data fields belonging to the second day among the multiple third data fields may be fused to obtain the second fifth data field, and finally the third data fields belonging to the Nth day among the multiple third data fields may be fused to obtain the Nth fifth data field, thereby obtaining the multiple fifth data fields.

[0107] Please refer to FIG. 10 . As shown in FIG. 10 , one of the fifth data fields with a preset time period of 1 day is shown. It can be understood that the fifth data field may include multiple third data fields whose generation time belongs to the 1 day.

[0108] As another practicable approach, archiving the plurality of fifth data fields to obtain the fourth data field may include archiving the plurality of fifth data fields according to a preset time period to obtain the fourth data field. For example, if the plurality of preset time periods include the first day, the second day, ... the Nth day, then the plurality of fifth data fields within a month may be archived together to obtain the fourth data field; the plurality of fifth data fields within three months may be archived together to obtain the fourth data field, and so on, without limitation.

[0109] Please refer to Figure 11. As shown in Figure 11, it shows that 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.

[0110] Step S23223: associate one of the redundant fields with the fourth data field and store them in the cold database.

[0111] In some implementations, when a redundant field and a fourth data field are obtained, the redundant field and the fourth data field may be associated and stored in a cold database.

[0112] The storage structure for associating a redundant field with the fourth data field and storing them in the cold database may be as follows:

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

[0114] It is understandable that the health data after archiving is a record within the range of "start time" and "end time". In addition to redundant fields, this record contains compressed and fused data for 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, this range in the business can be set to half a year. Of course, the time can be flexibly adjusted to one month or three months).

[0115] It is understood that the integration and archiving of health data have at least the following benefits:

[0116] Reducing the number of records (number of data items) reduces the storage of redundant fields (redundancy means redundant, and the values ​​of many records are the same, but they must be added redundantly in order to associate this record) and reduces the storage of indexes (in massive data scenarios, if you want to find this data in milliseconds, you need indexes to speed up the search), thereby saving disk storage costs.

[0117] This speeds up batch reading / pulling of data. Health apps / smartwatches often need to pull historical health data in batches on a daily basis. Before data fusion and archiving, health data was distributed discretely across different locations in the database, making batch reading slow. With this implementation, after fusion and archiving, if you need to read health data for a specific day or period, you can simply read one or several fields from that record.

[0118] One embodiment of the present application provides a method for storing health data. Health data is acquired and, if the health data meets a preset hot data condition, stored in a hot database. Alternatively, if the health data meets a preset cold data condition, the health data is compressed and stored in a cold database. Compared to the health data storage method shown in FIG1 , this embodiment also compresses health data that meets the preset cold data condition and stores it in a cold database, thereby reducing disk storage costs.

[0119] Please refer to Figure 12, which shows a schematic diagram of a process flow of a method for storing health data provided by an embodiment of the present application. The process shown in Figure 12 will be described in detail below. The method for storing 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, the health data is stored in the hot database.

[0122] For the detailed description of steps S310 to S320 , please refer to steps S110 to S120 , which will not be repeated here.

[0123] Step S330: If the health data meets the preset cold data condition, the health data is started to be stored in the cold database, and during the process of storing the health data in the cold database, the health data is monitored for abnormalities.

[0124] Among them, since the migration of health data is performed in production, in the scenario of massive health data, there will be many exceptions in the processing of health data (i.e., failure / code error in the migration process), and it cannot be guaranteed to be successful every time. Therefore, in this embodiment, the process of storing health data in the cold database can be monitored for exceptions, and the health data that have not been processed can be recorded to facilitate subsequent compensation operations. Optionally, the following scenarios may cause exceptions: A. Exceptions when reading health data from the hot database (such as timeouts in reading health data, current limiting in the hot database (a protection measure to avoid crashes of the hot database when the traffic to the hot database is too large), etc.); B. Exceptions when compressing health data (such as: a batch of health data is compressed and an exception occurs halfway through the execution; or there are code problems with its business, etc.); C. Exceptions when writing health data to the cold database (similar to read timeouts, excessive traffic to the cold database or other problems will cause write exceptions).

[0125] In this embodiment, if it is determined that the health data meets the preset cold data conditions, the health data can be stored in the cold database. During the process of storing the health data in the cold database, the health data can be monitored for abnormalities. As an implementable method, at the code level, the outermost layer that performs health data processing will monitor the code. When the aforementioned abnormality occurs during code execution, the outer layer code will capture it. Therefore, it is possible to determine whether the health data is abnormal by monitoring the code.

[0126] Step S340: 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.

[0127] In this embodiment, if abnormalities are detected in the health data through the above method, if ignored, it will lead to problems such as inconsistent and missing health data. Therefore, the health data can be compensated for the abnormal data, and the health data after abnormal data compensation can be stored in the cold database, thereby solving the abnormality problem of the health data.

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

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

[0130] Optionally, the number of health data can be multiple.

[0131] In some embodiments, if the monitored health data includes first data with abnormalities and second data without abnormalities, the first data can be marked to obtain a target mark, and the second data can be stored in a cold database. It can be understood that through the above method, not only will the storage of the second data without abnormalities in the health data in the cold database not be interrupted or affected, but the first data with abnormalities in the health data can also be recorded to facilitate subsequent abnormality compensation processing, thereby improving the storage efficiency of the health data.

[0132] It is understood that the target tag can be used to uniquely identify the first data. Optionally, the target tag can be a string, a number, etc., which is not limited here.

[0133] Step S342: reacquire the first data based on the target tag, and store the reacquired first data in the cold database.

[0134] In some embodiments, when a target marker corresponding to abnormal health data is obtained, the first data is subsequently re-acquired based on the target marker, and the re-acquired first data is stored in a cold database.

[0135] As an implementable method, when a target mark corresponding to abnormal health data is obtained, the first data can be retrieved from the data source (hot database or cloud server) corresponding to the health data based on the target mark, and the retrieved first data can be stored in the cold database.

[0136] As another feasible method, when a target mark corresponding to abnormal health data is obtained, the first data can be re-acquired based on the target mark, and the first data can be compressed and stored in a cold database.

[0137] The health data storage method provided in one 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. Alternatively, if the health data meets the preset cold data condition, the health data is started to be stored in a cold database. In the process of storing the health data in the cold database, the health data is monitored for abnormalities. If an abnormality is detected in the health data, the health data is compensated for the abnormal data and then stored in the cold database. Compared with the health data storage method shown in FIG1 , this embodiment also monitors the process of storing the health data in the cold database for abnormalities and compensates for the abnormal data when an abnormality is detected, which can improve the accuracy of the health data storage.

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

[0139] Step S410: Obtain health data.

[0140] The detailed description of step S410 can be found in step S110 and will not be repeated here.

[0141] Please refer to Figure 15, which shows a flow chart of step S410 of the health data storage method shown in Figure 14 of the present application. The flow chart shown in Figure 15 will be described in detail below. 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 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 application / smart watch has reported to the cloud server in the past, and the cloud server has stored it in the hot database. In this case, the corresponding data source is the hot database; the other is that the application / smart watch has reported to the cloud server, and the cloud server has not yet stored it in the hot database. In addition, the health data may have been collected a long time ago and not reported. In this case, the corresponding data source is the cloud server. Therefore, the data source corresponding to the acquired health data may be a hot database or a cloud server.

[0144] In this embodiment, a configuration switch may be provided to control whether health data is obtained from a hot database or a 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, the hot database is determined to be the data source, and health data is obtained from the hot database; when the configuration switch is configured in the second state, the cloud server is determined to be the database, and health data is obtained from the cloud server. Therefore, the switch state corresponding to the configuration switch can be determined, that is, 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, the health data is obtained from the thermal database.

[0146] In some implementations, when it is determined that the switch state of the configuration switch is the first state, it indicates that the determined data source is a thermal database, and the health data may be obtained from the thermal database.

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

[0148] In some implementations, 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, the health data can be obtained from the cloud server.

[0149] As an implementable method, 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 obtained from the hot database that meets the preset cold data conditions can be migrated to the cold database. After determining that the health data in the hot database that meets the preset cold data conditions has been migrated to the cold database (compressed), 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 in the health data obtained from the cloud server that meets the preset hot data conditions can be stored in the hot database, and the health data in the health data obtained from the cloud server that meets the preset cold data conditions can be stored in the cold database (compressed).

[0150] Step S420: If the health data meets the preset hot data condition, the health data is stored in the hot database.

[0151] Step S430: If the health data meets the preset cold data condition, the health data is stored in the cold database.

[0152] For the detailed description of steps S420 to S430 , please refer to steps S120 to S130 , which will not be repeated here.

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

[0154] Among them, the anomaly of the health data set in the above embodiment is an anomaly in the code execution process, which is an anomaly that can be discovered during execution. Another anomaly may be missing or omitted in data migration (the reason for the missing may be that the data was not scanned when it was read. This situation exists in high-concurrency and massive data scenarios. Because while reading user data, it is possible that the user is writing data at the same time). In this case, it is necessary to perform "data verification" to discover this anomaly. And compensate for the missing data.

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

[0156] Step S450: 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.

[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. For another example, 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 is compressed when being stored 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, 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.

[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. If it is determined that the first health data and the second health data are consistent, it indicates that there is no data missing in the process of migrating 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 missing in the process of migrating 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 missing in the health data during the migration from the data source to the cold database, and it needs to be reprocessed 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 can be re-obtained from the data source (compressed) and stored in the cold database.

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

[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 missing in the process of migrating the health data from the data source to the cold database, and the health data is 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] An embodiment of the present application provides a method for storing health data, which obtains 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, the data source corresponding to the health data is determined, the health data is read from the data source as the first health data, and the health data is read from the cold database as the 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. If the first health data and the second health data are consistent, the health data stored in the data source is deleted. Compared with the health data storage method shown in FIG1 , this embodiment also verifies the health data after completing the migration of the health data, which can improve the accuracy of the health data storage.

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

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

[0167] Furthermore, the health data acquisition module 210 includes: a switch state determination submodule, a first health data acquisition submodule, and a second health data acquisition submodule, wherein:

[0168] The switch state determination submodule is used to determine the switch state corresponding to the configuration switch.

[0169] The first health data acquisition submodule is configured to acquire the health data from the thermal database if the switch state is the first state.

[0170] The second health data acquisition submodule is configured to acquire the health data from the cloud if the switch state is the second state.

[0171] The first health data storage module 220 is configured to store the health data in a hot database if the health data meets a preset hot data condition.

[0172] The second health data storage module 230 is configured to store the health data in a cold database if the health data meets a preset cold data condition.

[0173] Furthermore, the second health data storage module 230 includes: a health data storage submodule, wherein:

[0174] The health data storage submodule is configured to compress the health data and then store it in the cold database if the health data meets the preset cold data condition.

[0175] Furthermore, the health data includes a plurality of first data fields, and the health data storage submodule includes: a second data field obtaining unit and a second data field storage unit, wherein:

[0176] The second data field obtaining unit is used to perform field bitwise compression on the multiple first data fields respectively to obtain multiple second data fields if the health data meets the preset cold data condition, wherein there is a one-to-one correspondence between the multiple first data fields and the multiple second data fields.

[0177] Furthermore, the second data field obtaining unit includes: a health type determining subunit, a bitwise compression rule determining subunit, and a second data field obtaining subunit, wherein:

[0178] The health type determination subunit is configured to determine the health type corresponding to the health data if the health data meets the preset cold data condition.

[0179] The bitwise compression rule determination subunit is used to determine the bitwise compression rule corresponding to the health type.

[0180] The second data field obtaining subunit is configured to perform field bitwise compression on the plurality of first data fields respectively according to the bitwise compression rule to obtain the plurality of second data fields.

[0181] The second data field storage unit is configured to perform field fusion on the plurality of second data fields and store the resultant data in the cold database.

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

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

[0184] Furthermore, the third data field obtaining sub-unit includes: a bit value determining sub-sub-unit and a third data field obtaining sub-sub-unit, wherein:

[0185] The bit value determination sub-subunit is configured to determine the bit value corresponding to each of the plurality of second data fields.

[0186] The third data field obtaining sub-sub-unit is used to perform field fusion on the multiple second data fields 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.

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

[0188] Furthermore, the number of health data is multiple, and the multiple health data include the same redundant fields, and the third data field storage sub-unit includes: a redundant field extraction sub-sub-unit, a fourth data field acquisition sub-sub-unit, and a fourth data field storage sub-sub-unit, wherein:

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

[0190] The fourth data field obtaining sub-sub-unit is used to merge the third data fields included in each of the multiple health data to obtain a fourth data field.

[0191] Furthermore, the fourth data field obtaining sub-sub-unit includes: a generation time determination sub-sub-unit, a fifth data field obtaining sub-sub-sub-unit, and a fourth data field obtaining sub-sub-sub-unit, wherein:

[0192] The generation time determination sub-sub-sub-unit is used to determine the generation time of the third data field included in each of the multiple health data.

[0193] The fifth data field obtaining sub-sub-sub-unit is configured to fuse 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.

[0194] Furthermore, 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-unit is configured to merge the third data fields whose corresponding generation times belong to the same preset time period among the plurality of preset time periods among the plurality of third data fields to obtain the plurality of fifth data fields.

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

[0197] The fourth data field storage sub-subunit is configured to associate one of the redundant fields with the fourth data field and store them in the cold database.

[0198] Furthermore, the second healthy data storage module 230 includes: an abnormality monitoring submodule and an abnormal data compensation submodule, wherein:

[0199] The abnormality monitoring submodule is used to monitor the health data for abnormalities during the process of storing the health data in the cold database.

[0200] The abnormal data compensation submodule is used to compensate the health data for the abnormal data and then store the health data in the cold database if the health data is detected to be abnormal.

[0201] Furthermore, the abnormal data compensation submodule includes: an abnormal data marking unit and an abnormal data compensation unit, wherein:

[0202] The abnormal data marking unit is used to mark the first data to obtain a target mark if it is monitored that the health data includes first data with abnormalities and second data without abnormalities, and store the second data in the cold database.

[0203] An abnormal data compensation unit is configured to reacquire the first data based on the target marker and store the reacquired first data in the cold database.

[0204] Furthermore, the health data storage device 200 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 used to determine the data source corresponding to the health data.

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

[0207] The health data comparison module is configured to delete the health data stored in the cold database if the first health data and the second health data are inconsistent, and to reacquire the health data from the data source and store it in the cold database.

[0208] Furthermore, the health data storage device 200 further includes a health data deletion module, wherein:

[0209] A health data deletion module is used to delete the health data stored in the data source if the first health data and the second health data are consistent.

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

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

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

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

[0214] Those skilled in the art will 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 aforementioned method embodiments and will not be repeated here.

[0215] In several embodiments provided in this application, the coupling between modules may be electrical, mechanical or other forms of coupling.

[0216] In addition, the functional modules in the various embodiments of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module. The above-mentioned integrated modules may be implemented in the form of hardware or software functional modules.

[0217] Please refer to Figure 17, which shows a block diagram of the structure of a cloud server 100 provided in an embodiment of the present application. The cloud server 100 can be a cloud server capable of running applications, such as a smartphone, tablet computer, or e-book. 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 applications, wherein the one or more applications may be stored in the memory 120 and configured to be executed by the one or more processors 110, and the one or more programs are configured to execute the method described in the aforementioned method embodiment.

[0218] The processor 110 may include one or more processing cores. The processor 110 utilizes various interfaces and circuits to connect various components within the cloud server 100. It executes instructions, programs, code sets, or instruction sets stored in the memory 120, as well as accesses data stored in the memory 120, to perform various functions of the cloud server 100 and process data. Optionally, the processor 110 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 110 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing displayed content; and the modem handles wireless communications. It is understood that the modem may not be integrated into the processor 110 and may be implemented separately via a communication chip.

[0219] The memory 120 may include a random access memory (RAM) or a read-only memory (ROM). The memory 120 may 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, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing functions (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the following various method embodiments, etc. The data storage area may also store data created by the cloud server 100 during use (such as a phone book, audio and video data, chat record data), etc.

[0220] Please refer to Figure 18, which shows a block diagram of a computer-readable storage medium provided in an embodiment of the present application. The computer-readable medium 300 stores program code, which 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, an EEPROM (Electrically Erasable Programmable Read-Only Memory), an EPROM, a hard disk, or a ROM. Alternatively, the computer-readable storage medium 300 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 300 has storage space for program code 310 for executing any of the method steps described above. These program codes can be read from or written to one or more computer program products. The program code 310 can be compressed, for example, in a suitable form.

[0222] To sum up, the health data storage method, device, cloud server and storage medium provided in the embodiments of the present application obtain health data. If the health data meets the preset hot data conditions, the health data is stored in a hot database, or if the health data meets the preset cold data conditions, 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 reading and writing 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, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, 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, characterized in that 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, characterized in that 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 to 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. The method according to any one of claims 1 to 9, characterized in that After obtaining the health data, the method further includes: Determining the frequency of reading and writing the health data within a preset time period; If the read and write frequency reaches the frequency threshold, it is determined that the health data meets the preset hot data condition; or If the read and write frequency does not reach the frequency threshold, it is determined that the healthy data meets the preset cold data condition.

18. A health data storage device, 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.

19. A cloud server, characterized in that: The method comprises a memory and a processor, wherein the memory is coupled to the processor, and the memory stores instructions. When the instructions are executed by the processor, the processor performs the method according to any one of claims 1 to 17.

20. A computer-readable storage medium, characterized in that The computer-readable storage medium stores program code, which can be called by a processor to execute the method according to any one of claims 1 to 17.

Images