Silent user data access method and system using ice pool

Abstract

The invention relates to the field of data storage, and provides a silent user data access method and system using an ice pool. The method comprises the steps of performing activeness analysis on user operation records according to user behavior logs, performing screening to obtain a silent user set, and generating a frozen user library; performing hierarchical storage on the user accounts in the frozen user library according to freezing duration to obtain a multi-level account library; target users meeting migration conditions are extracted from the multi-level account library, file information of the multiple target users is summarized, and a user file migration list is generated; and migrating file data in the user file migration list from a hot storage pool to an ice storage pool.

Description

Technical Field

[0001] This invention belongs to the field of data storage technology, and in particular relates to a method and system for accessing silent user data using an ice pool. Background Technology

[0002] With the rapid popularization of digital transformation and cloud computing, enterprise data storage is experiencing explosive growth. To reduce storage costs amidst this massive amount of data, the industry has proposed data tiering storage technology, storing frequently accessed (hot) data on high-performance storage media and migrating infrequently accessed (cold) data to low-cost storage media. Ice storage technology, as an emerging cold data storage solution, features low cost, low energy consumption, and high density, providing enterprises with a new technological path to optimize their storage architecture.

[0003] In current technologies, most enterprise object storage systems rely primarily on hot storage pools, failing to fully utilize low-cost storage media such as ice storage, resulting in persistently high storage costs. Furthermore, existing data tiering solutions typically lack mechanisms linking to user account status, hindering intelligent data migration management for inactive users. When users haven't logged in for extended periods, their data continues to occupy costly hot storage resources, leading to wasted storage capacity. Simultaneously, the lack of robust user account tiering management and data recovery mechanisms during data migration makes it difficult to balance storage cost optimization with user experience assurance, and fails to effectively resolve the conflict between low-cost storage and rapid recovery of inactive user data. Summary of the Invention

[0004] In view of the shortcomings of the prior art, the purpose of the invention is to provide a method and system for accessing silent user data using an ice pool.

[0005] This invention provides a method for accessing silent user data using an ice pool, comprising:

[0006] S1: Analyze the activity of user operation records based on user behavior logs, filter to obtain a set of silent users, and generate a frozen user database based on the set of silent users;

[0007] S2: Store user accounts in the frozen user database in a hierarchical manner according to the freezing duration to obtain a multi-level account database;

[0008] S3: Extract target users that meet the migration conditions from the multi-level account database, summarize the file information of multiple target users, and generate a user file migration list;

[0009] S4: Migrate the file data in the user file migration list from the hot storage pool to the ice storage pool to complete the ice pool access operation.

[0010] According to the present invention, a method for accessing silent user data using an ice pool, step S1 further includes:

[0011] S11: Retrieve operation log data for all users;

[0012] S12: Based on the operation log data, calculate the time span of each user's operation timestamp, and use the time difference between the last operation time and the current time as the no-operation duration;

[0013] S13: Determine the inactivity duration based on a preset activity threshold, and filter out users whose inactivity duration exceeds the activity threshold as silent users;

[0014] S14: Write the silent user identifier into the frozen user database, and trigger the account freezing process and generate a freeze notification message.

[0015] According to the present invention, a method for accessing silent user data using an ice pool is provided, wherein the operation log data in step S11 includes user identifier, operation timestamp, and operation type.

[0016] According to the present invention, a method for accessing silent user data using an ice pool, step S2 further includes:

[0017] S21: Establish a three-level account database structure, including a first-level account database, a second-level account database, and a third-level account database;

[0018] S22: Store the user accounts corresponding to the silent users into the first-level account database, and record the freeze start time for each user account;

[0019] S23: Monitor the freezing duration of user accounts in the first-level account database through a scheduled task. When the freezing duration of a user account exceeds the preset migration duration threshold, migrate the current user account to the second-level account database.

[0020] S24: When an account in the second-level account database initiates an unfreezing request, the user account requesting unfreezing is transferred to the third-level account database and marked as data recovery status, thus obtaining a multi-level account database.

[0021] According to the present invention, a method for accessing silent user data using an ice pool, step S3 further includes:

[0022] S31: Query the user accounts in the second-level account database whose freezing time meets the data migration conditions, and obtain the list of users to be migrated;

[0023] S32: For each user in the list of users to be migrated, retrieve all file metadata associated with the user through the file index database;

[0024] S33: Group all file metadata of multiple users according to the user dimension, and generate a file list file containing file path, file size and file identifier for each group of file metadata;

[0025] S34: Export the file list in a preset format to form a user file migration list.

[0026] According to the present invention, a method for accessing silent user data using an ice pool, step S4 further includes:

[0027] S41: Perform size analysis on the files in the user file migration list, classify and package the files according to the file size threshold, and generate file packages;

[0028] S42: Invoke the data migration tool to download the source files and file packages in the hot storage pool to the transfer storage area through the object storage interface;

[0029] S43: Upload the file data in the transit storage area to the designated storage location of the ice storage pool to complete the data migration operation.

[0030] According to the present invention, a method for accessing silent user data using an ice pool is provided. In step S41, when the file size is less than a preset small file threshold, the current file is determined to be a small file; multiple small files are merged into a single file package, and the original paths and unpacking index information of the multiple small files are recorded in the metadata of the file package.

[0031] According to the present invention, a method for accessing silent user data using an ice pool, after step S43, further includes:

[0032] S44: Calculate the MD5 hash value and file size of the migrated target file, and compare and verify it with the metadata of the source file to confirm data consistency;

[0033] S45: After the verification is successful, update the storage location information in the file index database and delete the source file in the hot storage pool.

[0034] According to the present invention, a method for accessing silent user data using an ice pool is provided. After the user data in the third-level account database is recovered, the user file data in the ice storage pool is migrated back to the hot storage pool through a reverse migration process.

[0035] The present invention also provides a silent user data access system using an ice pool, comprising:

[0036] The filtering module is used to perform activity analysis on user operation records based on user behavior logs, filter to obtain a set of inactive users, and generate a frozen user database based on the set of inactive users.

[0037] Storage module: used to store user accounts in the frozen user database in a hierarchical manner according to the duration of freezing, thereby obtaining a multi-level account database;

[0038] The aggregation module is used to extract target users that meet the migration conditions from the multi-level account database, aggregate the file information of multiple target users, and generate a user file migration list.

[0039] Migration module: Used to migrate file data in the user file migration list from the hot storage pool to the ice storage pool.

[0040] This invention provides a method and system for storing and retrieving dormant user data using an ice pool. First, by analyzing and filtering user behavior logs to obtain a set of dormant users, it can accurately identify long-term inactive user accounts, avoiding resource waste caused by indiscriminate processing of all user data. Second, by establishing a multi-level account database for hierarchical storage management of frozen users, it achieves differentiated processing strategies for users with different freeze durations. This ensures both a rapid self-service recovery experience for short-term frozen users and low-cost storage of long-term frozen user data, effectively balancing user experience and cost control. Third, by generating a file migration list by user dimension and grouping it, this invention significantly improves the organization and execution efficiency of data migration, reducing file retrieval time during the migration process. Fourth, by packaging small files before performing migration operations, this invention greatly reduces the impact of frequent read / write operations on system performance, improving overall migration efficiency. Finally, this invention uses a dual verification mechanism of MD5 hash value and file size to ensure the integrity and consistency of data during migration, effectively preventing the risk of file loss or corruption.

[0041] Overall, this invention migrates dormant user data from hot storage pools to ice storage pools, allowing enterprises to significantly reduce storage costs, especially in scenarios with massive amounts of user data, where cost savings are even more pronounced. At the same time, it provides users with a comprehensive data recovery mechanism, enabling them to quickly restore data access capabilities through a reverse migration process when their accounts are reactivated. Attached Figure Description

[0042] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. It is obvious that the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings.

[0043] Figure 1 This is a schematic flowchart of a method for accessing silent user data using an ice pool, provided by an embodiment of the present invention.

[0044] Figure 2 This is a schematic diagram of a silent user data access system using an ice pool, provided as an embodiment of the present invention. Detailed Implementation

[0045] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0046] Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts disclosed in this invention.

[0047] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The terms "installed," "connected," and "linked" should be interpreted broadly; for example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0048] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of methods and systems consistent with some aspects of the invention as detailed in the appended claims.

[0049] To better understand this invention, the technical terms appearing in the embodiments of this invention will be explained in detail below.

[0050] Ice storage (Ice Storage for Data) is a cold data storage technology based on low-temperature environments or phase change materials (such as ice). It is mainly used for long-term storage of data that is rarely accessed (cold data). Its core features are low cost, low energy consumption, and high density. It is suitable for scenarios that require long-term archiving but do not require frequent reading and writing.

[0051] Cold data refers to data that is rarely accessed or modified, but still needs to be retained for storage and management.

[0052] The embodiments of the present invention are described below with reference to the figures.

[0053] like Figure 1 As shown, the present invention provides a method for accessing silent user data using an ice pool, comprising:

[0054] S1: Analyze the activity of user operation records based on user behavior logs, filter to obtain a set of silent users, and generate a frozen user database based on the set of silent users.

[0055] Step S1 further includes:

[0056] S11: Obtain operation log data for all users; the operation log data includes user identifier, operation timestamp, and operation type.

[0057] In step S11, the present invention extracts all users' historical operation log records from the system database. Each operation log record contains three core fields: user identifier to uniquely identify each user account, operation timestamp to record the precise time point when the user performed the operation, and operation type to identify the specific behavior category performed by the user, such as login, file upload, file download, file deletion, etc.

[0058] This invention groups and aggregates the extracted raw log data according to user identifiers, and gathers all operation records of the same user under that username, forming a data structure with the user identifier as the index key and the operation record list as the value. Then, this invention sorts the operation record list of each user in descending order according to the operation timestamp, and places the operation record with the latest timestamp at the beginning of the list, thus completing the structured organization of the operation log data.

[0059] S12: Based on the operation log data, calculate the time span of each user's operation timestamp, and use the time difference between the last operation time and the current time as the no-operation duration.

[0060] In step S12, the present invention extracts the first sorted operation record from each user's operation record list, and the operation timestamp of this record is the user's last operation time. Then, the present invention obtains the current system time as the calculation reference point, and calculates the time difference between the current time and the last operation time. Specifically, the calculation method is to subtract the timestamp of the last operation time from the timestamp of the current time to obtain the time difference value in seconds. Subsequently, the present invention converts the time difference value into the no-operation duration in days to obtain the user's no-operation days. Finally, the calculated no-operation duration is associated with the user identifier and stored to form a mapping relationship table between user identifier and no-operation duration.

[0061] S13: Determine the inactivity duration based on a preset activity threshold, and filter out users whose inactivity duration exceeds the activity threshold as silent users.

[0062] In step S13, the present invention sets an activity threshold of 1095 days (i.e., three years), which serves as the criterion for distinguishing between active and inactive users. After setting the threshold, the present invention iterates through the user inactivity duration mapping table generated in step S12, comparing the inactivity duration value of each user with the activity threshold. When a user's inactivity duration exceeds 1095 days, the present invention determines that the user is an inactive user and extracts its user identifier. Subsequently, the present invention summarizes all user identifiers that meet the determination criteria to form a list of inactive user identifiers. This list contains all user account identifiers that need to be frozen, thus completing the screening and identification of inactive users.

[0063] S14: Write the silent user identifier into the frozen user database, and trigger the account freezing process and generate a freeze notification message.

[0064] In step S14, the present invention creates a frozen user database table structure in the database. This table structure includes a user identifier field, a frozen status field, and a frozen time field. Subsequently, each user identifier in the list of silent user identifiers obtained in step S13 is written into the frozen user database table, and the frozen status field is set to "frozen" and the frozen time field is set to the current system time. Then, for each user identifier written into the frozen user database, the present invention calls the account management interface to modify the user's account status to frozen, preventing the user from logging into the system. Simultaneously, the present invention queries the user's contact information, including email address and mobile phone number, from the user information table based on the user identifier, and then calls the message notification service to generate a notification message containing the reason for freezing and an explanation of unfreezing. The freezing notification message is then pushed to the user's email and mobile phone through the email sending interface and the SMS sending interface.

[0065] S2: Store user accounts in the frozen user database in a hierarchical manner according to the duration of freezing to obtain a multi-level account database.

[0066] Step S2 further includes:

[0067] S21: Establish a three-level account database structure, including a first-level account database, a second-level account database, and a third-level account database.

[0068] In step S21, the present invention creates three independent account database tables in the database, named the first-level account database table, the second-level account database table, and the third-level account database table, respectively. The first-level account database table stores user account information with a freeze period of less than one month, the second-level account database table stores user account information with a freeze period exceeding one month, and the third-level account database table stores user account information for which unfreezing / recovery applications are being submitted. Each account database table contains four fields: user identifier, freeze start time, current database level, and data migration status. The current database level field indicates the current database level number of the account, and the data migration status field indicates whether the file data associated with the account has been migrated.

[0069] S22: Store the user account corresponding to the silent user into the first-level account database, and record the freeze start time for each user account.

[0070] Furthermore, this invention reads the user identifiers of all dormant users from the frozen user database generated in step S14, and inserts a new record for each user identifier into the first-level account database table. When inserting a record, this invention sets the user identifier field to the currently processed user identifier value, sets the freeze start time field to the freeze time value of the user retrieved from the frozen user database table, sets the current database level field to the value 1 indicating that the account is located in the first-level account database, and initializes the data migration status field to "not migrated". After completing the batch insertion operation of all dormant user accounts, this invention establishes an index structure with the user identifier as the primary key on the first-level account database table, accelerating subsequent account query operations.

[0071] S23: Monitor the freezing duration of user accounts in the first-level account database through a scheduled task. When the freezing duration of a user account exceeds the preset migration duration threshold, migrate the current user account to the second-level account database.

[0072] In step S23, the present invention sets up a timed task scheduler and configures the task execution cycle. When the timed task starts, the present invention queries all account records from the first-level account database table, extracts the freeze start time field value for each record, calculates the time difference between the current system time and the freeze start time, and obtains the number of days the account is frozen.

[0073] Subsequently, this invention presets a migration duration threshold, and then compares the calculated freeze duration in days with the migration duration threshold. When the freeze duration in days exceeds the migration duration threshold, this invention determines that the account needs to be migrated to the second-level account database. For accounts that meet the migration conditions, this invention performs a database transaction operation. First, it deletes the account record from the first-level account database table, and then inserts the complete information of the account into the second-level account database table. During insertion, the user identifier and freeze start time fields remain unchanged, and the current database level field is updated to the value 2, completing the migration of the account between different database levels.

[0074] S24: When an account in the second-level account database initiates an unfreezing request, the user account requesting unfreezing is transferred to the third-level account database and marked as data recovery status, thus obtaining a multi-level account database.

[0075] In step S24, the present invention provides an entry point for the unfreezing application function in the user interface. When a user in the second-level account database submits an unfreezing application through the manual review process, the system receives an unfreezing request message containing the user's identifier. Subsequently, the present invention queries the user's account record in the second-level account database table based on the user identifier in the unfreezing request message and extracts all field information of the record. Then, the present invention performs a database transaction operation, that is, deletes the user's account record from the second-level account database table, inserts the user's account information into the third-level account database table, updates the current database level field to the value 3 during insertion, adds a data recovery status field and sets it to the "recovering" identifier, and records the unfreezing application time as the current system time.

[0076] After the account record migration is completed, the data recovery process is triggered. The user identifier is added to the data recovery task queue, and the data recovery module asynchronously executes the Ice Pool data migration operation, ultimately forming a multi-level account database structure containing three levels of account databases.

[0077] S3: Extract target users that meet the migration conditions from the multi-level account database, summarize the file information of multiple target users, and generate a user file migration list.

[0078] Step S3 further includes:

[0079] S31: Query the user accounts in the second-level account database whose freeze duration meets the data migration conditions to obtain a list of users to be migrated.

[0080] In step S31, this invention reads all account records from the second-level account database table, extracts the freeze start time field for each record, calculates the time difference between the current system time and the freeze start time, and obtains the actual freeze duration in days for that account. This invention presets a data migration condition that the freeze duration exceeds a threshold. Then, it compares the freeze duration in days for each account with the threshold. When the freeze duration in days exceeds the threshold, the account is determined to meet the data migration condition. Subsequently, this invention extracts the user identifier field from all account records that meet the condition, and summarizes them into a list of users to be migrated. This list is stored in an array structure, where each element is a user identifier string, completing the extraction operation of the target users.

[0081] S32: For each user in the list of users to be migrated, retrieve all file metadata associated with the user through the file index database.

[0082] In step S32, the present invention iterates through the list of users to be migrated. For each user identifier in the list, an SQL query operation is performed in the file metadata table. The query conditions are that the user identifier field is equal to the current user identifier and the storage location field is marked as a hot storage pool. The obtained query result returns all file records of the user in the hot storage pool, and each record contains complete metadata information of the file. Subsequently, the present invention binds the obtained set of file records with the corresponding user identifier to form a mapping relationship between user identifier and file metadata set. This mapping relationship is stored in a hash table data structure in memory, with the key being the user identifier and the value being the list of file metadata of the user.

[0083] S33: Group all file metadata of multiple users according to the user dimension, and generate a file list file containing file path, file size and file identifier for each group of file metadata.

[0084] In step S33, this invention extracts three key pieces of information from each file metadata record: the file path field, the file size field, and the file identifier field. The extracted values ​​are then concatenated into a string using a fixed format: "file path|file size|file identifier," with each file occupying one line. During concatenation, this invention concatenates all file information strings for the same user line by line to form a complete file list text for that user. This text content is then written into a TXT format file list file, named "user identifier_filelist.txt". Each user generates an independent file list file, thus completing the grouping of file information and the generation of the file list file.

[0085] S34: Export the file list in a preset format to form a user file migration list.

[0086] Furthermore, this invention iterates through all file list files in the exported directory, reads the filename and file path information of each file, and summarizes this information into a master index file. The master index file is stored in JSON format, where the key of the JSON object is the user identifier, and the value is the complete path of the file list file corresponding to that user. This invention names the generated master index file "migration_manifest.json". This file, together with the file list files of each user, constitutes the user file migration list. The migration list contains the file information and organizational structure of all users to be migrated, for subsequent use by the migration module.

[0087] S4: Migrate the file data in the user file migration list from the hot storage pool to the ice storage pool to complete the ice pool access operation.

[0088] Step S4 further includes:

[0089] S41: Perform size analysis on the files in the user file migration list, classify and package the files according to the file size threshold, and generate file packages.

[0090] In step S41, when the file size is less than the preset small file threshold, the current file is determined to be a small file; multiple small files are merged into a single file package, and the original paths and unpacking index information of the multiple small files are recorded in the metadata of the file package.

[0091] Specifically, the present invention presets a small file threshold of 10MB. In step S41, the present invention reads the file list file of each user from the user file migration list, and parses the file size field of each record in the file list; after reading, the file size value is compared with the 10MB threshold. When the file size is less than 10MB, the present invention marks the file as a small file and adds it to the small file set; when the file size is greater than or equal to 10MB, it is marked as a large file and added to the large file set.

[0092] For small file sets, this invention groups them according to user dimensions, writing the path information of multiple small files from the same user into a packaging manifest list. Then, this invention calls a file packaging tool to read and merge the multiple small files from the packaging manifest list into a single TAR format file package, named "user identifier_small_files.tar". Additionally, this invention records the original path string of each small file and its offset position within the file package in the file package's metadata area, forming unpacking index information to complete the packaging process for small files. Large files retain their original file format and are not packaged.

[0093] S42: Invoke the data migration tool to download the source files and file packages in the hot storage pool to the transfer storage area through the object storage interface.

[0094] In step S42, this invention extracts the source file path and file package path from the user file migration list and passes this path information to the data migration tool. The data migration tool initiates a file download request to the hot storage pool via a GET interface, with the request parameters including the complete storage path and access credentials of the file. After receiving the request, the hot storage pool returns the binary data stream of the file. The data migration tool writes the received data stream to the disk space of the local transfer storage area, the path of which is pre-specified in the configuration file. In this invention, the download operation is performed sequentially for each file or file package in the file list until all files are downloaded and stored in the transfer storage area, thus completing the data transfer from the hot storage pool to the transfer storage area.

[0095] S43: Upload the file data in the transit storage area to the designated storage location of the ice storage pool to complete the data migration operation.

[0096] In step S43, the present invention reads the downloaded file data from the transit storage area, obtains the local storage path of each file, and then determines the target storage location of the ice storage pool according to preset migration rules. This location includes the bucket name and object key path of the ice pool, with the object key path formatted as "user ID / filename". Subsequently, the present invention calls the PUT interface to read the file data from the transit storage area as a binary stream, specifies the bucket name and object key path of the ice storage pool in the PUT request, and uploads the binary data stream as the request body to the ice storage pool. After receiving the upload request, the ice storage pool writes the file data to the specified storage location and returns an upload success response message. After the present invention performs the upload operation sequentially for each file in the transit storage area, the data migration from the transit storage area to the ice storage pool is completed, and all files are stored in the specified location of the ice storage pool.

[0097] Step S43 is followed by:

[0098] S44: Calculate the MD5 hash value and file size of the migrated target file, and compare and verify it with the metadata of the source file to confirm data consistency.

[0099] In step S44, the present invention aims to perform an integrity verification operation on each target file uploaded to the ice storage pool. The present invention queries the metadata information of the target file through the HEAD interface of the S3 protocol and extracts the file size field value from the returned metadata. Subsequently, the present invention downloads the complete binary data of the target file through the GET interface of the S3 protocol, performs MD5 hash calculation on the downloaded data, and generates a 128-bit MD5 hash value.

[0100] After generating the hash value, this invention reads the MD5 value and file size of the source file from the file metadata obtained in step S32, performs a string comparison between the MD5 value of the target file and the MD5 value of the source file, and performs a numerical comparison between the size of the target file and the size of the source file. When the two MD5 values ​​are exactly the same and the two file sizes are equal, this invention determines that the file verification passes and the data consistency verification is successful; otherwise, it determines that the verification fails and records an exception log.

[0101] S45: After the verification is successful, update the storage location information in the file index database and delete the source file in the hot storage pool.

[0102] Furthermore, for each file that passes verification, this invention performs an update operation on the file metadata table of the file index database. Based on the file identifier, this invention locates the metadata record of that file, changes the value of the storage location field from "hot storage pool" to "ice storage pool," and simultaneously updates the file path field to the complete object key path of the file in the ice storage pool. Specifically, the database update operation employs a transaction mechanism. After the transaction is successfully committed, this invention calls the DELETE interface of the S3 protocol to initiate a file deletion request to the hot storage pool, with the request parameters including the complete storage path of the source file. Upon receiving the deletion request, the hot storage pool removes the file from the storage medium and returns a deletion success response message. After receiving the deletion success response, this invention inserts a record into the migration log table, containing user identifier, file identifier, migration time, and migration status fields, with the migration status set to "completed," thus completing the migration process for a single file.

[0103] Once the users in the third-level account database have completed data recovery, the user file data in the ice storage pool is migrated back to the hot storage pool through a reverse migration process.

[0104] When a user performs data recovery, this invention queries the third-level account database for user accounts with a data recovery status of "recovering" and extracts the user's identifier. This invention then queries the file index database for all file records whose storage location is "Ice Storage Pool" and whose user identifier matches, extracts the object key paths of these files in the Ice Storage Pool, and forms the user's Ice Pool file list.

[0105] Subsequently, this invention downloads each file from the file list from the ice storage pool via the GET interface of the S3 protocol, storing the file data in the transit storage area. For small, packaged files, this invention reads the unpacking index information from the file package metadata and decompresses the file package into multiple independent small files based on the index information.

[0106] Subsequently, this invention uploads the files from the transit storage area to the original path location of the hot storage pool via the S3 protocol's PUT interface. After the upload is complete, the storage location field in the file index database is updated to "hot storage pool". After all files have been recovered, this invention updates the data recovery status of the user in the third-level account database to "recovered", and simultaneously deletes the user's account record from the third-level account database, removing the account's frozen status indicator, thus completing the reverse migration process.

[0107] like Figure 2 As shown, the present invention also provides a silent user data access system using an ice pool, comprising:

[0108] Filtering module 100: used to perform activity analysis on user operation records based on user behavior logs, filter to obtain a set of silent users, and generate a frozen user database based on the set of silent users;

[0109] Storage module 200: used to store user accounts in the frozen user database in a hierarchical manner according to the freezing duration, to obtain a multi-level account database;

[0110] Summary module 300: used to extract target users that meet the migration conditions from the multi-level account database, summarize the file information of multiple target users, and generate a user file migration list;

[0111] Migration module 400: Used to migrate file data in the user file migration list from the hot storage pool to the ice storage pool.

[0112] This invention, based on user behavior analysis, marks users with long-term inactivity as "silent users," automatically freezes their accounts, and stores them in an "ice pool." It also provides an account unfreezing function, allowing users to apply for account recovery. Furthermore, this invention uses a multi-database approach for frozen accounts, establishing three user databases to store user freeze status. Silent accounts are sequentially moved to database 1, and after 31 days of freeze, they are moved to database 2. Accounts in database 2 that apply for recovery services are moved to database 3. If a frozen user deletes files or successfully recovers their service, they are removed from databases 1 and 3. This multi-database approach effectively distinguishes account status. During data migration, this invention ensures consistency between source and target files by verifying file metadata such as MD5 hash values ​​and file sizes. Only after all files are verified are the file index information updated, achieving atomic operations and effectively preventing file loss or data inconsistency.

[0113] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions 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 invention. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the protection scope of the present invention.

Claims

1. A method for accessing silent user data using an ice pool, characterized in that, include: S1: Analyze the activity of user operation records based on user behavior logs, filter to obtain a set of silent users, and generate a frozen user database based on the set of silent users; S2: Store user accounts in the frozen user database in a hierarchical manner according to the freezing duration to obtain a multi-level account database; S3: Extract target users that meet the migration conditions from the multi-level account database, summarize the file information of multiple target users, and generate a user file migration list; S4: Migrate the file data in the user file migration list from the hot storage pool to the ice storage pool to complete the ice pool access operation.

2. The method for accessing silent user data using an ice pool according to claim 1, characterized in that, Step S1 further includes: S11: Retrieve operation log data for all users; S12: Based on the operation log data, calculate the time span of each user's operation timestamp, and use the time difference between the last operation time and the current time as the no-operation duration; S13: Determine the inactivity duration based on a preset activity threshold, and filter out users whose inactivity duration exceeds the activity threshold as silent users; S14: Write the silent user identifier into the frozen user database, and trigger the account freezing process and generate a freeze notification message.

3. A method for accessing silent user data using an ice pool according to claim 2, characterized in that, The operation log data in step S11 includes user identifier, operation timestamp, and operation type.

4. A method for accessing silent user data using an ice pool according to claim 1, characterized in that, Step S2 further includes: S21: Establish a three-level account database structure, including a first-level account database, a second-level account database, and a third-level account database; S22: Store the user accounts corresponding to the silent users into the first-level account database, and record the freeze start time for each user account; S23: Monitor the freezing duration of user accounts in the first-level account database through a scheduled task. When the freezing duration of a user account exceeds the preset migration duration threshold, migrate the current user account to the second-level account database. S24: When an account in the second-level account database initiates an unfreezing request, the user account requesting unfreezing is transferred to the third-level account database and marked as data recovery status, thus obtaining a multi-level account database.

5. A method for accessing silent user data using an ice pool according to claim 4, characterized in that, Step S3 further includes: S31: Query the user accounts in the second-level account database whose freezing time meets the data migration conditions, and obtain the list of users to be migrated; S32: For each user in the list of users to be migrated, retrieve all file metadata associated with the user through the file index database; S33: Group all file metadata of multiple users according to the user dimension, and generate a file list file containing file path, file size and file identifier for each group of file metadata; S34: Export the file list in a preset format to form a user file migration list.

6. A method for accessing silent user data using an ice pool according to claim 1, characterized in that, Step S4 further includes: S41: Perform size analysis on the files in the user file migration list, classify and package the files according to the file size threshold, and generate file packages; S42: Invoke the data migration tool to download the source files and file packages in the hot storage pool to the transfer storage area through the object storage interface; S43: Upload the file data in the transit storage area to the designated storage location of the ice storage pool to complete the data migration operation.

7. A method for accessing silent user data using an ice pool according to claim 6, characterized in that, In step S41, when the file size is less than the preset small file threshold, the current file is determined to be a small file; multiple small files are merged into a single file package, and the original paths and unpacking index information of the multiple small files are recorded in the metadata of the file package.

8. A method for accessing silent user data using an ice pool according to claim 6, characterized in that, Step S43 is followed by: S44: Calculate the MD5 hash value and file size of the migrated target file, and compare and verify it with the metadata of the source file to confirm data consistency; S45: After the verification is successful, update the storage location information in the file index database and delete the source file in the hot storage pool.

9. A method for accessing silent user data using an ice pool according to claim 1, characterized in that, Once the user data in the third-level account database has been recovered, the user file data in the ice storage pool is migrated back to the hot storage pool through a reverse migration process.

10. A silent user data access system using an ice pool, characterized in that, include: The filtering module is used to analyze the activity of user operation records based on user behavior logs, filter to obtain a set of inactive users, and generate a frozen user database based on the set of inactive users. Storage module: used to store user accounts in the frozen user database in a hierarchical manner according to the duration of freezing, thereby obtaining a multi-level account database; The aggregation module is used to extract target users that meet the migration conditions from the multi-level account database, aggregate the file information of multiple target users, and generate a user file migration list. Migration module: Used to migrate file data in the user file migration list from the hot storage pool to the ice storage pool.

Images