Description:FIELD OF THE INVENTION
This invention relates to System and Method for Time-Series Database Processing Utilizing Near-Data Processing Units and Integrated Query Execution
BACKGROUND OF THE INVENTION
Time-Series Databases (TSDBs) manage enormous volumes of timestamped data from sources like IoT devices or financial markets, requiring frequent queries involving aggregation (like averages over time) or filtering across vast datasets. Traditional computing architectures force these systems to move massive amounts of raw data from storage or memory to the central processing unit (CPU) for calculation. Because many common time-series operations are computationally simple per data point, this excessive data movement – not the computation itself – becomes the major bottleneck, consuming significant time, energy, and bandwidth. This inherent inefficiency limits query speed and increases operational costs for large-scale TSDBs, creating a need for architectures that can perform computations closer to the data's physical location to minimize costly data transfer.
The present commercial practice for handling large-scale Time-Series Databases (TSDBs) primarily relies on optimizing within the traditional compute architecture rather than fundamentally altering data movement patterns. Common strategies include aggressive data compression tailored for time-series (like Gorilla or Zstd), specialized time-based indexing, and widespread use of columnar storage formats; these techniques reduce the amount of data read from storage but still require moving the relevant (often compressed) data blocks to the main CPU for processing. Scaling is typically achieved through distributed database architectures (like InfluxDB Enterprise, TimescaleDB multi-node, ClickHouse), which parallelize processing across multiple machines but still involve significant data movement within each node from storage/memory to the local CPU. While hardware accelerators like GPUs or FPGAs are sometimes used for specific analytical tasks, they also require moving data to the accelerator's memory. The core concept of Near-Data Processing (NDP) or Processing-in-Memory (PIM) exists in academic research and some specialized hardware prototypes (e.g., UPMEM, Samsung HBM-PIM), but integrated systems combining specific NDP hardware optimized for time-series primitives with aware TSDB query execution engines are not standard commercial practice today for general-purpose time-series processing.
The present commercial practice for handling large-scale Time-Series Databases (TSDBs) primarily relies on optimizing within the traditional compute architecture rather than fundamentally altering data movement patterns. Common strategies include aggressive data compression tailored for time-series (like Gorilla or Zstd), specialized time-based indexing, and widespread use of columnar storage formats; these techniques reduce the amount of data read from storage but still require moving the relevant (often compressed) data blocks to the main CPU for processing. Scaling is typically achieved through distributed database architectures (like InfluxDB Enterprise, TimescaleDB multi-node, ClickHouse), which parallelize processing across multiple machines but still involve significant data movement within each node from storage/memory to the local CPU. While hardware accelerators like GPUs or FPGAs are sometimes used for specific analytical tasks, they also require moving data to the accelerator's memory. The core concept of Near-Data Processing (NDP) or Processing-in-Memory (PIM) exists in academic research and some specialized hardware prototypes (e.g., UPMEM, Samsung HBM-PIM), but integrated systems combining specific NDP hardware optimized for time-series primitives with aware TSDB query execution engines are not standard commercial practice today for general-purpose time-series processing.
SUMMARY OF THE INVENTION
This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the invention.
This summary is neither intended to identify key or essential inventive concepts of the invention and nor is it intended for determining the scope of the invention.
To further clarify advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings.
The proposed invention solves the severe data movement bottleneck in Time-Series Databases (TSDBs) by performing common, data-intensive operations like filtering and aggregation directly near the data within memory or storage subsystems, utilizing specialized Near-Data Processing (NDP) hardware units. These hardware units are specifically architected for time-series primitives (e.g., windowed aggregates, filtering) and communicate with the main CPU via an optimized communication protocol for efficient task dispatch and retrieval of significantly reduced result sets. Crucially, the TSDB's software query execution engine is modified to be NDP-aware, featuring an optimizer with a cost model to identify offload opportunities and new execution operators that manage interaction with the NDP hardware via the protocol. By processing bulk data locally, this tightly integrated hardware-software system drastically reduces data transfer volumes, accelerating query performance and lowering energy consumption for large-scale time-series workloads.
BRIEF DESCRIPTION OF THE DRAWINGS
The illustrated embodiments of the subject matter will be understood by reference to the drawings, wherein like parts are designated by like numerals throughout. The following description is intended only by way of example, and simply illustrates certain selected embodiments of devices, systems, and methods that are consistent with the subject matter as claimed herein, wherein:
FIGURE 1: SYSTEM ARCHITECTURE OVERVIEW
FIGURE 2: QUERY EXECUTION FLOW WITH NDP OFFLOAD
FIGURE 3: NDP UNIT CONCEPTUAL BLOCK DIAGRAM
FIGURE 4: COMMUNICATION PROTOCOL EXAMPLE (CONCEPTUAL)
The figures depict embodiments of the present subject matter for the purposes of illustration only. A person skilled in the art will easily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the disclosure described herein.
DETAILED DESCRIPTION OF THE INVENTION
The detailed description of various exemplary embodiments of the disclosure is described herein with reference to the accompanying drawings. It should be noted that the embodiments are described herein in such details as to clearly communicate the disclosure. However, the amount of details provided herein is not intended to limit the anticipated variations of embodiments; on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the present disclosure as defined by the appended claims.
It is also to be understood that various arrangements may be devised that, although not explicitly described or shown herein, embody the principles of the present disclosure. Moreover, all statements herein reciting principles, aspects, and embodiments of the present disclosure, as well as specific examples, are intended to encompass equivalents thereof.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a",” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and/or “including,” when used herein, specify the presence of stated features, integers, steps, operations, elements and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.
It should also be noted that in some alternative implementations, the functions/acts noted may occur out of the order noted in the figures. For example, two figures shown in succession may, in fact, be executed concurrently or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.
In addition, the descriptions of "first", "second", “third”, and the like in the present invention are used for the purpose of description only, and are not to be construed as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. Thus, features defining "first" and "second" may include at least one of the features, either explicitly or implicitly.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which example embodiments belong. It will be further understood that terms, e.g., those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
The proposed invention solves the severe data movement bottleneck in Time-Series Databases (TSDBs) by performing common, data-intensive operations like filtering and aggregation directly near the data within memory or storage subsystems, utilizing specialized Near-Data Processing (NDP) hardware units. These hardware units are specifically architected for time-series primitives (e.g., windowed aggregates, filtering) and communicate with the main CPU via an optimized communication protocol for efficient task dispatch and retrieval of significantly reduced result sets. Crucially, the TSDB's software query execution engine is modified to be NDP-aware, featuring an optimizer with a cost model to identify offload opportunities and new execution operators that manage interaction with the NDP hardware via the protocol. By processing bulk data locally, this tightly integrated hardware-software system drastically reduces data transfer volumes, accelerating query performance and lowering energy consumption for large-scale time-series workloads.
NOVELTY:
The invention's novelty lies in its synergistic system combining Near-Data Processing hardware units specifically micro-architected for primitive time-series database operations with a co-designed communication protocol and an aware database query execution engine modified to intelligently offload and manage these specific operations, thereby optimizing end-to-end time-series query processing.
Figure 1: System Architecture Overview: This drawing would show the main Host System (CPU, Main Memory) connected via a system bus/interconnect to a Memory Subsystem and/or Storage Subsystem. Crucially, it would depict the NDP Units physically located within or directly attached to the Memory/Storage Subsystem blocks. Arrows would show the high-bandwidth local data access between NDP units and the local Memory/Storage, and the distinct communication path (via the Communication Interface) back to the Host CPU/Memory for commands and reduced results.
Figure 2: Query Execution Flow with NDP Offload: A flowchart illustrating the query processing path. It would start with Query Reception, move to the NDP-Aware Query Optimizer. A key decision diamond: "Offload to NDP Unit(s) Beneficial?".
• Yes Branch: Shows steps like "Format NDP Command(s)", "Send Command(s) via Protocol", "NDP Unit(s) Execute Primitive(s) Locally", "Receive Result(s) via Protocol", "Integrate NDP Result(s)".
• No Branch: Shows "Execute Operation on Host CPU".
Both branches would eventually lead to further query processing steps and Final Result generation.
Figure 3: NDP Unit Conceptual Block Diagram: A diagram showing the internal components of a single NDP unit. Inputs would be Commands and access to Local Data (from Memory/Storage). Outputs would be Results (to Host). Internal blocks could include:
• Control Logic/Sequencer (interprets commands).
• Specialized Function Units (SFUs) labeled "Time-Series Aggregator", "Time-Series Filter", "De/Compressor" etc.
• Local Buffer/Scratchpad Memory.
• Interface Logic (to communicate via the protocol).
Figure 4: Communication Protocol Example (Conceptual): Could illustrate the structure of a command packet sent from Host to NDP (e.g., Opcode for 'Aggregate', Data Address Range, Time Window Parameters, Result Destination Address) and a result packet sent from NDP to Host (e.g., Status/Completion Code, Aggregated Value(s)).
ADVANTAGES OF THE INVENTION
The proposed Near-Data Processing (NDP) system fundamentally differs from and improves upon previous solutions by performing computations directly near the data using specialized hardware units optimized for time-series primitives (like aggregation and filtering). This drastically reduces costly data movement, yielding significant advantages in lower query latency and improved energy efficiency compared to traditional CPU-centric processing (even with compression or columnar optimizations) or separate accelerators like GPUs which introduce their own data transfer overhead. A key distinction lies in the deep co-design, where a modified, NDP-aware database query engine intelligently offloads tasks using a specific communication protocol, offering seamless integration unlike prior art's often less integrated or manual approaches. In essence, the invention addresses the root cause—data movement—rather than just mitigating its symptoms. 
, Claims:1. A system for processing time-series database queries, comprising:
a memory or storage subsystem comprising one or more Near-Data Processing (NDP) units configured to execute data-intensive operations;
a main processing unit communicatively coupled to said NDP units via an optimized communication protocol;
a time-series database (TSDB) engine comprising a query execution engine configured to:
 (i) identify offloadable operations using a cost-based optimizer;
 (ii) generate execution plans including NDP-aware operators; and
 (iii) dispatch tasks to said NDP units and retrieve results therefrom;
wherein said NDP units are configured to perform time-series primitives including filtering and windowed aggregation locally on data, thereby reducing data movement and improving query performance.
2. The system as claimed in claim 1, wherein the NDP units comprise specialized hardware accelerators architected for time-series data operations, including support for window functions, range filters, and group-wise aggregation.
3. The system as claimed in claim 1, wherein the optimized communication protocol between the main processing unit and the NDP units supports lightweight command dispatch, batched result transmission, and low-latency synchronization to enhance performance efficiency.
4. A method for accelerating time-series query execution of the system as claimed in claim 1, wherein, the method comprising:
a) receiving a query at a time-series database engine;
b) analyzing the query to identify portions suitable for offloading to Near-Data Processing (NDP) units using a cost model;
c) generating a query execution plan comprising NDP-aware operators;
d) dispatching data-intensive operations such as filtering and aggregation to said NDP units located within a memory or storage subsystem; and
e) retrieving reduced-size result sets from said NDP units for further processing by a central processing unit,
wherein said method reduces data transfer overhead and improves overall query performance.