Mail system based on time sequence database and object storage and data processing method

Abstract

The invention discloses a mail system based on a time sequence database and object storage and a data processing method.The system is constructed based on a three-layer network architecture including a metadata storage layer, a content storage layer and a service interaction layer, and correspondingly comprises a metadata storage module which is used for creating an independent data table for each user, storing associated fields in combination with a hot partition and a cold partition, and storing the associated fields in the data table; meanwhile, a secondary index is established for index optimization, and multi-condition combined query is supported; the content storage module is used for creating a text storage sub-module and an attachment storage sub-module in the object storage, respectively storing a mail text and an attachment, and configuring an attachment hash duplicate removal mechanism and a redundancy storage strategy; and the service interaction module is configured with a plurality of functional modules to guarantee data transmission security and stable operation of the system. According to the scheme, real linear expansion, cost reduction and efficiency improvement are realized in a high-concurrency and high-load mailbox scene, and the reliability and the user experience are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of email system technology, and in particular to an email system and data processing method based on time-series databases and object storage. Background Technology

[0002] Once an enterprise email system reaches 20,000 users, it commonly adopts an NFS network file system mounted on local disks for storage to achieve multi-node data sharing. However, this solution has unavoidable drawbacks in high-concurrency scenarios: (1) Business anomalies caused by cache inconsistency: In a scenario where a government and enterprise customer sends an email to all employees (18,000 users in a single message), due to the failure of the NFS client cache to be refreshed in time, 23% of users were still unable to read the email within 5 minutes after it was sent, and 1.2% of users experienced the problem of "read email mark invalidated". It was necessary to manually trigger cache cleanup to restore the status, which affected office efficiency. (2) The throughput capacity cannot be linearly scaled: When the cluster nodes are expanded from 3 to 6, the peak email delivery rate of the system only increases from 800 emails / second to 1050 emails / second (theoretically it should double). As the NFS server becomes the performance bottleneck, the more nodes there are, the more intense the competition becomes, resulting in the phenomenon of "expansion leading to reduced efficiency". (3) Data reliability risk: A financial institution once experienced a single point of failure in its NFS server, which resulted in the inability to write email data for 2 hours. Although the data was recovered through backup, more than 300 emails were lost and had to be manually resent, which did not meet the industry compliance requirements.

[0003] Traditional architectures bind email bodies and attachments for storage, resulting in a severe "write amplification" problem in mass email scenarios. For example, if a company sends 100 "all-employee emails with 100MB attachments" per month (10,000 users), each mass email requires writing 10,000 copies of the 100MB attachments, generating an additional 100TB of redundant storage per month (when only 10GB is actually needed). Based on an enterprise-level storage cost of 0.3 yuan / GB / month, the annual wasted cost reaches 36,000 yuan. The repeated writing of attachments also increases the delivery time, with the delivery latency for mass emails with 100MB attachments increasing from 0.8 seconds per user to 12.5 seconds, significantly degrading the user experience.

[0004] Some existing solutions (such as ElasticSearch) adopt a "distributed database + object storage" architecture, but still have adaptation defects: they use column family storage, which supports distributed expansion, but cannot achieve physical isolation by user. Under high concurrency, multi-user metadata queries interfere with each other, and the P99 latency reaches 1.2 seconds, which cannot meet the "low latency for single user" requirement of email systems; they lack time partitioning capabilities, and historical emails (such as those older than 1 year) are stored together with new emails. When searching, a full table scan is required, and the latency of opening historical emails reaches 3.5 seconds, which is much higher than the 0.5 seconds of this solution. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides an email system and data processing method based on time-series databases and object storage, which solves the problems of cache inconsistency defects, duplicate attachment storage, and inability to linearly scale throughput caused by relying on NFS shared storage when the number of users exceeds 20,000 in traditional email systems.

[0006] This invention is achieved using the following technical solution: Firstly, the email system based on time-series databases and object storage is constructed using a three-layer network architecture consisting of a metadata storage layer, a content storage layer, and a business interaction layer, and includes the following modules: Metadata storage module: Creates an independent data table for each user, combines hot and cold partitions to store related fields, and builds secondary indexes for index optimization, supporting multi-condition combined queries; Content storage module: Create a text storage submodule and an attachment storage submodule in object storage to store email text and attachments respectively, and configure attachment hash deduplication mechanism and redundant storage strategy; Business interaction module: Configured with multiple functional modules to ensure data transmission security and stable system operation.

[0007] Specifically, the table names in the metadata storage module adopt the format of user ID_email table, and the core fields include basic identifier fields, business attribute fields, and storage association fields.

[0008] Specifically, the basic identifier fields include a globally unique email ID, a user ID, and a session association ID; the business attribute fields include the sender's email address and name, a list of recipients, the email subject, the sending timestamp, the email status, and the email priority; and the storage association fields include the storage link of the body object, a list of attachment hash values, a list of attachment object storage links, and the attachment size.

[0009] Specifically, the attachment hash deduplication mechanism in the content storage module is as follows: When a user sends an email with an attachment, the SHA-256 hash value of the attachment is calculated first. Check if the object corresponding to the hash value exists in the attachment storage submodule. If it exists, reuse the storage link of the object and increment the attachment reference count by 1. If it does not exist, upload the attachment to the attachment storage submodule, generate a storage link and set the reference count to 1. When a user deletes an email, the citation count of the corresponding attachment is updated synchronously. If the count drops to 0, a delayed deletion task is triggered to avoid data loss due to accidental deletion. If a new email references the attachment during the delay period, the citation count is restored and the deletion operation is canceled.

[0010] Specifically, the functional modules in the business interaction module include: Load balancing module: Based on the user ID hash modulo algorithm, it evenly distributes user data tables to different nodes of the time-series database cluster; Read / Write Link Control Module: Includes read link and write link. The write link adopts the order of storing content first and then writing metadata. The read link only interacts with the metadata storage layer and adopts the process of querying metadata, retrieving links, and reading content from the source. The security authorization module uses the principle of least privilege to control data access. At the time-series database level, data is isolated by user ID, allowing users to access only their own data tables. At the object storage level, authorization is granted through pre-signed URLs or STS temporary credentials. Simultaneously, email content is encrypted during transmission and storage. Operation and maintenance monitoring module: Establish a full-link monitoring indicator system. The core monitoring indicators include performance indicators, cost indicators and reliability indicators. The reliability indicators include data consistency verification success rate, object storage 5xx error rate and node failure recovery time.

[0011] Specifically, in the three-layer network architecture, metadata and content are separated, and write links and read links are separated. Each layer is as follows: Metadata storage layer: Centered on a time-series database, it undertakes the tasks of storing and retrieving email metadata. Through a one-user-one-table isolation design, it avoids data interference from multiple users. It partitions emails based on their receiving time to achieve tiered management of hot and cold data, supporting low-latency queries under high concurrency. Content storage layer: An object storage system is used to store email bodies and attachments, and a deduplication mechanism based on attachment hashing is used to eliminate redundant storage waste; Business Interaction Layer: This layer comprises four main modules: load balancing, read / write link control, security authorization, and operation and maintenance monitoring. It is responsible for receiving user email sending / reading requests, scheduling underlying storage resources, ensuring data transmission security and stable system operation, and providing multi-protocol compatibility to adapt to existing email clients and office systems.

[0012] On the other hand, the email system data processing method based on time-series databases and object storage includes email delivery and email retrieval. Email delivery specifically includes the following steps: Step A1: The business interaction layer receives email delivery requests sent by users through email clients, and parses the sender information, recipient list, email subject, body content and attachment files in the request; Step A2: The content storage module processes the attachment file, calculates the SHA-256 hash value of the attachment, and checks whether the object corresponding to the hash value exists in the attachment storage submodule. If it exists, it obtains the storage link of the object and increments the attachment reference count by 1. If it does not exist, it uploads the attachment to the attachment storage bucket, generates a storage link, and sets the reference count to 1. Step A3: The content storage module uploads the email body to the body storage submodule and generates a body storage link using the globally unique ID of the email as the object name; Step A4: The business interaction layer generates a globally unique email ID; Step A5: The metadata storage module writes the email metadata into the data tables of each recipient in the time-series database; Step A6: After the data is successfully written, the business interaction layer sends a successful email response to the user; if the writing fails, a retry mechanism is triggered, and if the retry fails, an error message is returned and logged.

[0013] Specifically, the email reading process includes the following steps: Step B1: The business interaction layer receives the email read request sent by the user through the email client, and parses the user ID and email globally unique ID in the request; Step B2: The load balancing module determines the corresponding time-series database node based on the user ID hash modulo. Step B3: The metadata storage module sends a query request to the target time-series database node to obtain the metadata of the globally unique ID of the corresponding email in the user table, and extracts the body storage link and attachment storage link; Step B4: The security authorization module generates pre-signed URLs for storing links in the body and attachments; Step B5: The business interaction layer returns the pre-signed URL to the user client; Step B6: The user client directly initiates a content read request to the object storage system via the pre-signed URL. After verifying the validity of the pre-signed URL, the object storage system returns the main text and attachment content. Step B7: The user client receives and displays the email content, completing the email reading process.

[0014] The beneficial effects of this invention are as follows: The email system and data processing method based on time-series databases and object storage proposed in this invention, through four core designs—"metadata-content separation storage," "user-level time-series table isolation," "attachment hash deduplication," and "read-write link decoupling"—combining the time partitioning characteristics of time-series databases and the elastic scalability of object storage, achieves performance improvement, cost reduction, and reliability assurance in high-concurrency scenarios, meeting the email service needs of large-scale government and enterprise users, and has the following technical advantages: (1) Performance improvement: The peak email delivery rate reaches 2500 emails / second, which is 138% higher than the traditional NFS architecture and 39% higher than the existing Cassandra distributed architecture; the P99 latency for reading new emails is 0.3 seconds, which is 67% lower than the traditional architecture and 75% lower than the existing distributed architecture. (2) Cost reduction: The attachment storage cost is RMB 3,000 per year (for 100 times / month of sending 100MB attachments in a group), which is 92% lower than the traditional architecture and 62% lower than the existing distributed architecture; at the same time, through the tiering of hot and cold data, the storage cost is further reduced by 30%-40%; (3) Enhanced reliability: 72 hours of high-concurrency testing without failure, data reliability reaches 99.999999999%, which is a significant improvement over the traditional NFS architecture (45 hours without failure) and the existing distributed architecture (68 hours without failure), meeting the extremely high data reliability requirements of scenarios such as finance, government and enterprises; (4) Scalability optimization: It supports the expansion of the user scale from 20,000 to more than 1 million, and the expansion of the cluster nodes from 3 to dozens of nodes. The expansion process does not require service interruption, realizing "expansion on demand" and solving the problem of "expansion leading to reduced efficiency" in traditional architecture. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of an email system based on a time-series database and object storage in an embodiment of the present invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments 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, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0018] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0019] The following is in conjunction with the appendix Figure 1The following describes some embodiments of the present invention in detail. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0020] This invention proposes an email system and data processing method based on time-series databases and object storage. The email system architecture based on time-series databases and object storage adopts a "three-layer, two-separation" design concept. The three layers are a metadata storage layer, a content storage layer, and a business interaction layer. The two separations are "separation of metadata and content" and "separation of write link and read link". In this embodiment, the functions and collaborative logic of each layer are as follows: Metadata storage layer: Based on the time-series database TDengine, it undertakes the task of storing and retrieving email metadata. Through the isolation design of "one table per user", it avoids data interference from multiple users. At the same time, it partitions based on email receiving time to realize the hierarchical management of cold and hot data and support low-latency queries under high concurrency. Content storage layer: An object storage system (such as AWS S3, Alibaba Cloud OSS, etc.) is used to store email body and attachments. The multi-replica redundancy and elastic expansion features of object storage are used to solve the storage capacity and reliability bottlenecks of traditional local disks; and the attachment hash deduplication mechanism is used to eliminate the waste of duplicate storage. Business Interaction Layer: This layer comprises four main modules: load balancing, read / write link control, security authorization, and operation and maintenance monitoring. It is responsible for receiving user email sending / reading requests, scheduling underlying storage resources, ensuring data transmission security and stable system operation, and providing multi-protocol (SMTP / IMAP / POP3 / HTTP) compatibility capabilities to adapt to existing email clients and office systems.

[0021] The following is in conjunction with the appendix Figure 1 A detailed explanation of the specifics of an email system based on time-series databases and object storage is provided below: (1) Metadata storage module (TDengine time-series database application) User table design: Create an independent data table for each user, with the table name in the format of "user ID_email table" to ensure physical isolation of user data and avoid resource contention when multiple users query; the data table field design takes into account both business needs and retrieval efficiency, and the core fields include: basic identification fields: globally unique email ID (generated by "server ID + timestamp + random number"), user ID, and session association ID. Business attribute fields: sender's email / name, recipient list (including CC / BCC), email subject, sending timestamp, email status (read / unread / deleted / draft), and email priority. Storage association fields: Text object storage link (including bucket name and object path), attachment hash value list, attachment object storage link list, and attachment size; Time partitioning strategy: User data tables are partitioned by "month". Email data within the last 3 months is stored in the hot partition (using high-performance SSD media) to ensure second-level retrieval of new emails; Email data older than 3 months is automatically migrated to the cold partition (using low-cost HDD or archive storage) and subjected to LZ4 compression, with a compression rate of 30%-50%, reducing storage costs; The cold partition supports further archiving by "quarter", and can be quickly retrieved through the partition loading mechanism when needed.

[0022] Index optimization: Secondary indexes have been created for the fields of "sending timestamp", "email status" and "session association ID" to support multi-condition combined queries (such as "querying read session emails in October 2025"). The index query response time is ≤100ms, meeting users' needs for fast email filtering. (2) Content storage module (object storage and attachment deduplication) Storage structure design: In object storage, create a text storage submodule ("Text Storage Bucket") and an attachment storage submodule ("Attachment Storage Bucket") to store email text and attachments respectively. The storage path adopts a hierarchical structure of "year / month / user ID / object ID" to facilitate data management and access control. The text is named with the "globally unique ID of the email" and the attachment is named with the "SHA-256 hash value" to ensure the uniqueness of the attachment. Attachment hash deduplication mechanism: When a user sends an email with attachments, the system first calculates the SHA-256 hash value of the attachment (hash value generation time ≤ 10ms / 100MB); it then checks if the object corresponding to the hash value exists in the attachment storage bucket. If it exists, the storage link of that object is reused directly, and the attachment reference count is incremented by 1; if it does not exist, the attachment is uploaded to the storage bucket, a storage link is generated, and the reference count is set to 1; when a user deletes an email, the system synchronously updates the reference count of the corresponding attachment. If the count drops to 0, a delayed deletion task is triggered (default delay of 7 days) to avoid data loss due to accidental deletion; if a new email references the attachment during the delay period, the reference count can be restored, and the deletion operation can be canceled. Reliability assurance: Object storage adopts a 3-replica redundant storage strategy, with replicas distributed in different regions or availability zones. If a single replica is damaged, it can be automatically recovered from other replicas, achieving a data reliability of 99.999999999% (11 nines). At the same time, object version control is enabled, supporting historical version rollback and resolving issues such as accidental modification and malicious deletion. (3) Core modules of business interaction layer Load balancing module: Based on the "user ID hash modulo" algorithm, user data tables are evenly distributed to different nodes of the time-series database cluster. For example, when the cluster has 3 nodes, the user ID hash value is modulo 3. User tables with a result of 0 are assigned to node 1, those with a result of 1 are assigned to node 2, and those with a result of 2 are assigned to node 3. When adding a node, only the hash routes of some users need to be recalculated, achieving "seamless scaling". After scaling, the system throughput increases linearly with the number of nodes (e.g., the throughput of 6 nodes is twice that of 3 nodes). Read / Write Link Control Module: The email delivery process follows a "store content first, then write metadata" sequence. The specific steps are: user initiates an email sending request → system extracts the body and attachments → calculates the attachment hash value and uploads it to object storage → obtains the storage link for the body and attachments → generates a globally unique email ID and idempotent identifier → writes the metadata to the corresponding user table in the time-series database → returns a successful delivery response. The entire process avoids duplicate deliveries through the idempotent identifier (generated from "Message-ID + recipient list"). Even if a request is retried due to network fluctuations, duplicate emails will not be generated. Read Link (Email Reading): The process follows the steps of "querying metadata, retrieving the link, and reading content from the source". The specific steps are as follows: the user initiates an email reading request → the system routes the request to the corresponding time-series database node based on the user ID → the system queries the user table to obtain email metadata (including the storage link for the body / attachments) → a pre-signed URL is generated (valid for 1 hour to prevent link leakage) → the user client reads the content from the object storage through the pre-signed URL → the email data is returned to the user. The read link only interacts with the metadata storage layer and does not affect the write link, achieving read and write operations without interfering with each other. Security authorization module: Adopts the "principle of least privilege" to control data access. At the time-series database level, data is isolated by user ID, allowing users to access only their own data tables. At the object storage level, authorization is carried out through pre-signed URLs or STS temporary credentials to avoid the risk of long-term key leakage. At the same time, the email content is encrypted during transmission (TLS1.3) and stored (AES-256) to ensure the security of data during transmission and storage. Operations and maintenance monitoring module: Establishes a full-link monitoring indicator system, with core monitoring indicators including: Performance metrics: peak email delivery (mails / second), email read P99 latency (seconds), time-series database query QPS, object storage read / write throughput; Cost metrics: attachment deduplication rate (actual number of attachments stored / theoretical number of attachments to be stored), ratio of hot and cold data, storage cost (RMB / month); Reliability metrics: data consistency verification success rate, object storage 5xx error rate, node failure recovery time.

[0023] The system supports setting multi-level alarm thresholds based on monitoring metrics (such as triggering a warning if P99 latency exceeds 1 second, and triggering an emergency alarm if it exceeds 2 seconds). Alarm information is pushed through channels such as SMS, email, and WeChat for Enterprise, and is linked to an automatic compensation mechanism (such as automatically routing user requests to a backup node when a time-series database node fails) to ensure stable system operation. This invention also proposes a data processing method for an email system, mainly including an email delivery process and an email retrieval process. The specific steps of the email delivery process include: S1: The business interaction layer receives email delivery requests sent by users through email clients and parses the sender information, recipient list, email subject, body content, and attachment files in the request. S2: The content storage module processes the attachment file: calculates the SHA-256 hash value of the attachment, checks whether the object corresponding to the hash value exists in the attachment storage bucket; if it exists, it obtains the storage link of the object and increments the attachment reference count by 1; if it does not exist, it uploads the attachment to the attachment storage bucket, generates a storage link, and sets the reference count to 1. S3: The content storage module uploads the email body to the body storage bucket and generates a body storage link using the "globally unique email ID" as the object name; S4: The business interaction layer generates a globally unique ID for the email (formatted as “ServerID_YYYYMMDDHHMMSS_Random6”, such as “Node1_20251208153020_123456”) and an idempotent identifier (generated from “Message-ID + recipient list MD5”). S5: The metadata storage module writes email metadata (including globally unique ID, idempotent identifier, sender information, recipient list, subject, timestamp, body link, attachment hash value and link, status, etc.) into the data table of each recipient in the time series database (if it is a mass email, it needs to be written into the data table of each recipient separately). S6: After the metadata is successfully written, the business interaction layer returns a "successfully sent email" response to the user; if the writing fails, a retry mechanism is triggered (up to 3 retries, with an interval of 5 seconds between each retrieval). If the retry fails, an error message is returned and the log is recorded for subsequent manual investigation. In this embodiment, the email reading process specifically includes: S1: The business interaction layer receives email read requests sent by users through email clients and parses the user ID and email globally unique ID in the request; S2: The load balancing module determines the corresponding time-series database node based on the user ID hash modulo. S3: The metadata storage module sends a query request to the target time-series database node to obtain the metadata of the globally unique ID of the corresponding email in the user table, and extracts the body storage link and attachment storage link; S4: The security authorization module generates a pre-signed URL for the storage link of the body / attachment (valid for 1 hour, including user identity information and permission scope). S5: The business interaction layer returns the pre-signed URL to the user client; S6: The user client directly initiates a content read request to the object storage system through the pre-signed URL. After verifying the validity of the pre-signed URL, the object storage system returns the main text and attachment content. S7: The user client receives and displays the email content, completing the email reading process. In this embodiment, the solution has the following characteristics: User-level table isolation design for time-series databases: Breaking through the column family / row storage logic of traditional distributed databases, physical isolation is achieved with "one table per user". Combined with time partitioning, it can ensure low latency for single users and support large-scale user expansion. Combining attachment hash deduplication with reference counting: SHA-256 hash value ensures the uniqueness of attachments, while reference counting accurately manages the lifecycle, completely solving the problem of duplicate attachment storage in mass sending scenarios and reducing storage costs; Read-write link decoupling and idempotency control: The write link "stores content first and then writes metadata" to ensure data consistency, the read link "queries metadata and retrieves content from the source" to avoid read-write interlocking, and the idempotency flag prevents duplicate delivery, thus improving system stability under high concurrency; Hot and cold data tiering combined with elastic scaling: The combination of time-series database time partitioning and object storage elastic scaling not only meets the low latency requirements of hot data, but also reduces costs through cold data compression and archiving. Adding new nodes can linearly increase throughput and adapt to the growth of user scale.

[0024] This solution achieves true linear scaling, cost reduction, and efficiency improvement in high-concurrency, high-load email scenarios, while significantly enhancing reliability and user experience. It eliminates shared storage bottlenecks, allowing nodes to scale horizontally with throughput increasing linearly with the number of nodes. Single-user isolation and time partitioning reduce hotspots; write-read decoupling avoids interlocking; P99 latency remains stable under high concurrency; attachment deduplication and hot / cold tiering significantly reduce storage and write amplification; object storage offers elastic billing for precise cost control; and idempotent writes, compensation tasks, reference counting, and inspection mechanisms ensure data integrity and read availability.

[0025] For the foregoing embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to this application.

[0026] The above embodiments describe the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Modifications and variations made by those skilled in the art without departing from the spirit and scope of the invention should be within the protection scope of the appended claims.

Claims

1. An email system based on time-series databases and object storage, characterized in that, The network architecture is built upon a three-layer structure consisting of a metadata storage layer, a content storage layer, and a business interaction layer, and includes the following modules: Metadata storage module: Creates an independent data table for each user, combines hot and cold partitions to store related fields, and builds secondary indexes for index optimization, supporting multi-condition combined queries; Content storage module: Create a text storage submodule and an attachment storage submodule in object storage to store email text and attachments respectively, and configure attachment hash deduplication mechanism and redundant storage strategy; Business interaction module: Configured with multiple functional modules to ensure data transmission security and stable system operation.

2. The email system based on time-series database and object storage as described in claim 1, characterized in that, The table names in the metadata storage module adopt the format of user ID_email table, and the core fields include basic identifier fields, business attribute fields, and storage association fields.

3. The email system based on time-series database and object storage as described in claim 2, characterized in that, The basic identifier fields include a globally unique email ID, a user ID, and a session association ID; the business attribute fields include the sender's email address and name, a list of recipients, the email subject, the sending timestamp, the email status, and the email priority; the storage association fields include the storage link of the body object, a list of attachment hash values, a list of attachment object storage links, and the attachment size.

4. The email system based on time-series database and object storage as described in claim 1, characterized in that, The attachment hash deduplication mechanism in the content storage module is as follows: When a user sends an email with an attachment, the SHA-256 hash value of the attachment is calculated first. Check if the object corresponding to the hash value exists in the attachment storage submodule. If it exists, reuse the storage link of the object and increment the attachment reference count by 1. If it does not exist, upload the attachment to the attachment storage submodule, generate a storage link and set the reference count to 1. When a user deletes an email, the citation count of the corresponding attachment is updated synchronously. If the count drops to 0, a delayed deletion task is triggered to avoid data loss due to accidental deletion. If a new email references the attachment during the delay period, the citation count is restored and the deletion operation is canceled.

5. The email system based on time-series database and object storage as described in claim 1, characterized in that, The functional modules in the business interaction module specifically include: Load balancing module: Based on the user ID hash modulo algorithm, it evenly distributes user data tables to different nodes of the time-series database cluster; Read / Write Link Control Module: Includes read link and write link. The write link adopts the order of storing content first and then writing metadata. The read link only interacts with the metadata storage layer and adopts the process of querying metadata, retrieving links, and reading content from the source. The security authorization module uses the principle of least privilege to control data access. At the time-series database level, data is isolated by user ID, allowing users to access only their own data tables. At the object storage level, authorization is granted through pre-signed URLs or STS temporary credentials. Simultaneously, email content is encrypted during transmission and storage. Operation and maintenance monitoring module: Establish a full-link monitoring indicator system. The core monitoring indicators include performance indicators, cost indicators and reliability indicators. The reliability indicators include data consistency verification success rate, object storage 5xx error rate and node failure recovery time.

6. The email system based on time-series database and object storage as described in claim 1, characterized in that, In the three-layer network architecture, metadata and content are separated, and write links and read links are separated. Each layer is specifically defined as follows: Metadata storage layer: Based on a time-series database, it undertakes the task of storing and retrieving email metadata. Through a one-user-one-table isolation design, it avoids data interference from multiple users. The system partitions data based on email receiving time to achieve hierarchical management of hot and cold data, supporting low-latency queries under high concurrency. Content storage layer: An object storage system is used to store email bodies and attachments, and a deduplication mechanism based on attachment hashing is used to eliminate redundant storage waste; Business Interaction Layer: This layer comprises four main modules: load balancing, read / write link control, security authorization, and operation and maintenance monitoring. It is responsible for receiving user email sending / reading requests, scheduling underlying storage resources, ensuring data transmission security and stable system operation, and providing multi-protocol compatibility to adapt to existing email clients and office systems.

7. A data processing method for an email system based on time-series databases and object storage, implemented based on the email system based on time-series databases and object storage as described in any one of claims 1 to 6, characterized in that, This includes email delivery and email retrieval. Email delivery specifically includes the following steps: Step A1: The business interaction layer receives email delivery requests sent by users through email clients, and parses the sender information, recipient list, email subject, body content and attachment files in the request; Step A2: The content storage module processes the attachment file, calculates the SHA-256 hash value of the attachment, and checks whether the object corresponding to the hash value exists in the attachment storage submodule. If it exists, it obtains the storage link of the object and increments the attachment reference count by 1. If it does not exist, it uploads the attachment to the attachment storage bucket, generates a storage link, and sets the reference count to 1. Step A3: The content storage module uploads the email body to the body storage submodule and generates a body storage link using the globally unique ID of the email as the object name; Step A4: The business interaction layer generates a globally unique email ID; Step A5: The metadata storage module writes the email metadata into the data tables of each recipient in the time-series database; Step A6: After the data is successfully written, the business interaction layer sends a successful email response to the user; if the writing fails, a retry mechanism is triggered, and if the retry fails, an error message is returned and logged.

8. The email system data processing method based on time-series database and object storage as described in claim 7, characterized in that, The email reading process specifically includes the following steps: Step B1: The business interaction layer receives the email read request sent by the user through the email client, and parses the user ID and email globally unique ID in the request; Step B2: The load balancing module determines the corresponding time-series database node based on the user ID hash modulo. Step B3: The metadata storage module sends a query request to the target time-series database node to obtain the metadata of the globally unique ID of the corresponding email in the user table, and extracts the body storage link and attachment storage link; Step B4: The security authorization module generates pre-signed URLs for storing links in the body and attachments; Step B5: The business interaction layer returns the pre-signed URL to the user client; Step B6: The user client directly initiates a content read request to the object storage system via the pre-signed URL. After verifying the validity of the pre-signed URL, the object storage system returns the main text and attachment content. Step B7: The user client receives and displays the email content, completing the email reading process.

Images