US20130318119A1

US20130318119A1 - Processing structured and unstructured data using offload processors

Info

Publication number: US20130318119A1
Application number: US13/900,295
Authority: US
Inventors: Parin Bhadrik Dalal
Original assignee: Xocketts IP LLC
Current assignee: XOCKETS Inc; Xockets IP LLC
Priority date: 2012-05-22
Filing date: 2013-05-22
Publication date: 2013-11-28
Also published as: US11080209B2; WO2013177316A2; US20130347110A1; WO2013177313A2; US9665503B2; US20170237624A1; WO2013177313A3; US9258276B2; US20130318275A1; US20130318276A1; WO2013177310A2; US20140157396A1; US9619406B2; US20130346469A1; US10223297B2; WO2013177316A3; WO2013177310A3; US9495308B2; US20170237714A1; US20130318084A1

Abstract

A data processing system for unstructured data is disclosed. A plurality of modules can be connected to a memory bus, each including at least one processor. A central processing unit (CPU) can be connected to the modules by the memory bus, with the CPU configured to process computationally intensive data processing tasks while directing parallel computation tasks to a plurality of the modules.

Description

PRIORITY CLAIMS

This application claims the benefit of U.S. Provisional Patent Application 61/650,373 filed May 22, 2012, the contents all of which are incorporated by reference herein.

TECHNICAL FIELD

The present disclosure relates generally to servers capable of efficiently processing structured and unstructured data. More particularly, systems supporting offload or auxiliary processing modules that can be physically connected to a system memory bus to process data independent of a host processor of the server are described.

BACKGROUND

Enterprises store and process their large amounts of data in a variety of ways. One manner in which enterprises store data is by using relational databases and corresponding relational database management systems (RDBMS). Such data, usually referred to as structured data, may be collected, normalized, formatted and stored in an RDBMS. Tools based on standardized data languages such as the Structured Query Language (SQL) may be used for accessing and processing structured data. However, it is estimated that such formatted structured data represents only a tiny fraction of an enterprise's stored data. Organizations are becoming increasingly aware that substantial information and knowledge resides in unstructured data (i.e., “Big Data”) repositories. Accordingly, simple and effective access to both structured and unstructured data are seen as necessary for maximizing the value of enterprise informational resources.
However, conventional platforms that are currently being used to handle structured and unstructured data can substantially differ in their architecture. In-memory processing and Storage Area Network (SAN)-like architectures are used for traditional SQL queries, while commodity or shared nothing architectures (each computing node, consisting of a processor, local memory, and disk resources, shares nothing with other nodes in the computing cluster) are usually used for processing unstructured data. An architecture that supports both structured and unstructured queries can better handle current and emerging Big Data applications.

SUMMARY

A structured data processing system can include a plurality of modules connected to a memory bus in a first server, each including at least one processor, and at least one module configured to provide an in-memory database; and a central processing unit (CPU) in the first server connected to the in-line modules by the memory bus, with the CPU configured to process and direct structured queries to the plurality of in-line modules.
Further, a data processing system for unstructured data can include a plurality of modules connected to a memory bus, each including at least one processor; and a central processing unit (CPU) connected to the modules by the memory bus, with the CPU configured to process computationally intensive data processing tasks while directing parallel computation tasks to a plurality of the modules.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows illustrates an embodiment suitable to process structured queries.

FIGS. 2-1 and 2-2 are diagrams showing the workflow and distributed architecture used to implement a data processing software.

FIG. 3-1 is flow diagram showing a data processing method according to an embodiment.

FIG. 3-2 shows a data processing architecture according to an embodiment.

FIG. 4-1 shows a cartoon schematically illustrating a data processing system according to an embodiment, including a removable computation module for offload of data processing.

FIG. 4-2 shows an example layout of an in-line module (referred to as a “XIMM”) module according to an embodiment.

FIG. 4-3 shows two possible architectures for a XIMM in a simulation (Xockets MAX and MIN).

FIG. 4-4 shows a representative the power budget for a XIMMs according to various embodiments.

FIG. 4-5 illustrates data flow operation of one embodiment using an ARM A9 architecture.

DETAILED DESCRIPTION

Data processing and analytics for enterprise server or cloud based data systems, including both structured or unstructured data, can be efficiently implemented on offload processing modules connected to a memory bus, for example, by insertion into a socket for a Dual In-line Memory Module (DIMM). Such modules can be referred to as Xocket™ In-line Memory Modules (XIMMs), and can have multiple “wimpy” cores associated with a memory channel. Using one or more XIMMs it is possible to execute lightweight data processing tasks without intervention from a main server processor. As will be discussed, XIMM modules have high efficiency context switching, high parallelism, and can efficiently process large data sets. Such systems as a whole are able to handle large database searches at a very low power when compared to traditional high power “brawny” server cores. Advantageously, by accelerating implementation of MapReduce or similar algorithms on unstructured data and by providing high performance virtual shared disk for structured queries, a XIMM based architecture capable of partitioning tasks is able to greatly improve data analytic performance.
FIG. 1 illustrates an embodiment to process structured queries according to an embodiment. FIG. 1 depicts two commodity computers which can be rack servers (140,140 a), each of which includes at least one central processing unit (108) and a set of offload processors (112 a to 112 c). The servers (140, 140 a) are preferably present in the same rack and connected by a top of rack (TOR) switch (120). The servers (140, 140 a) are suited for hosting a distributed and shared in-memory assembly (110 a, 110 b) that can handle and respond to structured queries as one large in-memory system.
Traditionally, an in-memory database that handles structured queries looks for the query in its physical memory, and in the absence of the query therein will perform a disk read to a database. The disk read might result in the page cache of the kernel being populated with the disk file. The process might perform a complete copy of the page(s) (in a paged memory system) into its process buffer or it might perform a mmap operation, wherein a pointer to the entry in the page cache storing the pages is created and stored in the heap of the process. The latter is less time consuming and more efficient than the former.
The inclusion of a XIMM supported data retrieval framework can effectively extend the overall available size of the in-memory space available with the assembly. In case a structured query is being handled by one of the said CPUs (108), and the CPU is unable to retrieve it from its main memory, it will immediately trap into a memory map (mmap routine) that will handle disk reads and populate the page cache.
The embodiment described herein can modify the mmap routine of standard operating systems to execute code corresponding to a driver for a removable computation module driver, in this case a XIMM driver. The XIMM driver in turn identifies the query and transfers the query to one or more XIMMs in the form of memory reads/writes. A XIMM can house a plurality of offload processors (112 a to 112 c) that can receive the memory read/write commands containing the structured query. One or more of the offload processors (112 a to 112 c) can perform a search for the query in its available cache and local memory and return the result. According to embodiments, an mmap query can further be modified to allow the transference of the query to XIMMs that are not in the same server but in the same rack. The mmap abstraction in such a case can perform a remote direct memory access (RDMA) or a similar network memory read for accessing data present in a XIMM that is in the same rack. As a second XIMM (i.e., offload processors 112 a to 112 c of server 140 a) is connected to a first XIMM (i.e., offload processors 112 a to 112 c of server 140) through a top of rack switch 120, the latency of a system according to an embodiment can be the combined latency of the network interface cards (NICs) of the two servers (i.e., 100 in 140 and 100 in 140 a), the latency of the TOR switch 120, and a response time of the second XIMM.
Despite the additional hops, embodiments can provide a system that can have a much lower latency than a read from a hard disk drive. The described architecture can provide orders of magnitude improvement over a single structured query in-memory database. By allowing for non-frequently used data of one of the servers to be pushed to another XIMM located in the same rack, the effective in-memory space can be increased beyond conventional limits, and a large assembly having a large physical, low latency memory space can be created. This embodiment may further be improved by allowing for transparent sharing of pages across multiple XIMMs. Embodiments can further improve the latency between server-to-server connections by mediating them by XIMMs. The XIMMs can act as intelligent switches to offload and bypass the TOR switch.
Conventional data intensive computing platforms for handling large volumes of unstructured data can use a parallel computing approach combining multiple processors and disks in large commodity computing clusters connected with high-speed communications switches and networks. This can allow the data to be partitioned among the available computing resources and processed independently to achieve performance and scalability based on the amount of data. A variety of distributed architectures have been developed for data-intensive computing and several software frameworks have been proposed to process unstructured data. One such programming model for processing large data sets with a parallel, distributed algorithm on a multiple servers or clusters is commonly known as MapReduce. Hadoop is a popular open-source implementation of MapReduce that is widely used by enterprises for search of unstructured data.
FIGS. 2-1 and 2-2 show the workflow and distributed architecture used to implement a data processing software, such as Hadoop. Referring to FIG. 2-1, Hadoop MapReduce workloads may be broken into Split, Map, Shuffle, Reduce and Merge phases. The input file (204) is fetched from a file system such as Hadoop Distributed File System (HDFS) (202) and divided into smaller pieces referred to as Splits. Each Split (206) is a contiguous range of the input. Each record in each input split is independently passed to a Map function run by a Mapper (208) hosted on a processor. The Map function accepts a single record as an input and produces zero or more output records, each of which contains a key and a value. In the Shuffle phase (210), the results from the Map functions, referred to as intermediate (key, value) pairs, are rearranged such that all values with the same key are grouped together. The Reduce function run by a Reducer (212) takes in a key value and a list values as the input and produces another list as the output. The output records from Reduce functions are merged to form an Output file (216) which is then stored in the file system (202).
Map and Reduce tasks are computationally intensive and have very tight dependency on each other. While Map tasks are small and independent tasks that can run in parallel, the Reduce tasks include fetching intermediate (key, value) pairs that result from each Map function, sorting and merging intermediate results according to keys and applying Reduce functions to the sorted intermediate results. Reducer (212) can perform the Reduce function only after it receives the intermediate results from all the Mappers (208). Thus, the Shuffle step (210) (communicating the Map results to Reducers) often becomes the bottleneck in Hadoop workloads and introduces latency.
FIG. 2-2 shows a typical computing cluster used to implement Hadoop. A Master Node (222) runs a JobTracker (224) which organizes the cluster's activities. Each of the Worker Nodes (326) run a TaskTracker (228) which organizes the worker node's activities. All input jobs are organized into sequential tiers of tasks (230). The tasks could be map tasks or reduce tasks. The TaskTracker (228) runs a number of map and reduce tasks concurrently and pulls new tasks from the JobTracker (224) as soon as the old tasks are completed. The Hadoop Map-Reduce layer stores intermediate data (232) produced by the map and reduce tasks in the Hadoop Distributed File System (202) discussed in FIG. 2-1. HDFS (202) is designed to provide high streaming throughput to large, write-once-read-many-times files.
In an embodiment, a XIMM based architecture can improve Hadoop (or similar data processing) performance in two ways. Firstly, intrinsically parallel computational tasks can be allocated to the XIMMs (e.g., modules with offload processors), leaving the number crunching tasks to “brawny” (e.g., x86) cores. This is illustrated in more detail in FIG. 3-1.
FIG. 3-1 is flow diagram showing a data processing method according to an embodiment. A method can start (302) and input data can be fetched from a file system (304). In particular embodiments this can include a Direct Memory Access (DMA) operation from an HDFS. In some embodiments, all DMA operations are engineered such that all the parallel Map steps are equitably served with data. The input data can be partitioned into splits in (306) and parsed into records that contain initial (key, value) pairs in (308). Since the tasks involved in steps (304, 306 and 308) are computationally light, they can be performed all, or in part, by the offload processors hosted on the XIMMs (e.g., by wimpy cores). Map operations can then be performed on the initial (key, value) pairs (310). The intermediate (key, value) pairs that result from the Map operations can then be communicated to the Reducers (312). Once the results from all the Map operations are available, Reduce operations can be performed (314). The results from the Reducers are merged into a single output file and written back to the file system (e.g., 302) by offload processors (316). Since Map and Reduce functions are computationally intensive, the steps (310 and 314) can be handled by a CPU (e.g., by brawny cores). Such distribution of workloads to processor cores that are favorably disposed to perform them can reduce latency and/or increases efficiency.
A XIMM based architecture, according to an embodiment, can reduce the intrinsic bottleneck of most Hadoop (or similar data processing) workloads (the Shuffle phase) by driving the I/O backplane to its full capacity. In a conventional Hadoop system, the TaskTracker (228) described in FIG. 2-2 serves hyper-text transport protocol (HTTP) GET requests to communicate Map results to Reduce inputs. Also, the Mappers and Reducers hosted by the individual server CPUs have to communicate using their corresponding top of rack (TOR) switches of the corresponding racks. This slows down the process. Further, the Reducers hosted by the CPU stay idle while the results from Map operations are collected and sorted, introducing further computational inefficiency.
FIG. 3-2 shows a data processing architecture according to an embodiment. In the architecture illustrated in FIG. 3-2, operational modules are labeled to reflect their primary operations as previously noted with respect to FIG. 3-1. In an embodiment, instead of using HTTP to communicate, a publish-subscribe model is used to perform the Shuffling phase as shown in FIG. 3-2. Since the results from the Map step (310) are already stored and available in main memory, they can be collected through DMA operations (312 a) and parsed (312 b) by XIMMs. Since Map results are not required to be written to disk, latency can be reduced. Further, the XIMMs incorporated into the individual servers can define a switch fabric that can be used for Shuffling. The mid-plane defined by the XIMM based switch fabric is capable of driving and receiving the full 240 Gbps capacity of the PCI-3.0 bus and thus offers better speed and bandwidth compared to HTTP. The key is published through the massively parallel I/O mid-plane defined by the XIMMs (312 a). Subscriptions are identified based on the keys and are directed to the Reducers hosted on the CPU through virtual interrupts (312 b). Thus, rack-level locality and aggregation that are typical of conventional Hadoop systems are no longer required in the XIMM based architecture. Instead, intermediate (key, value) pairs are exchanged by all the computing nodes across several different servers through intelligent virtual switching of the XIMMs resulting in efficient processing of Hadoop workloads.
The following example(s) provide illustration and discussion of exemplary hardware and data processing systems suitable for implementation and operation of the foregoing discussed systems and methods. In particular hardware and operation of wimpy cores or computational elements connected to a memory bus and mounted in DIMM or other conventional memory socket is discussed.
FIG. 4-1 is a cartoon schematically illustrating a data processing system 400 including a removable computation module 402 for offload of data processing from x86 or similar main/server processors 403 to modules connected to a memory bus 403. Such modules 402 can be XIMM modules, as described herein or equivalents, and can have multiple computation elements that can be referred to as “offload processors” because they offload various “light touch” processing tasks such HTML, video, packet level services, security, or data analytics. This is of particular advantage for applications that require frequent random access or application context switching, since many server processors incur significant power usage or have data throughput limitations that can be greatly reduced by transfer of the computation to lower power and more memory efficient offload processors.
The computation elements or offload processors can be accessible through memory bus 405. In this embodiment, the module can be inserted into a Dual Inline Memory Module (DIMM) slot on a commodity computer or server using a DIMM connector (407), providing a significant increase in effective computing power to system 400. The module (e.g., XIMM) may communicate with other components in the commodity computer or server via one of a variety of busses including but not limited to any version of existing double data rate standards (e.g., DDR, DDR2, DDR3, etc.)
This illustrated embodiment of the module 402 contains five offload processors (400 a, 400 b, 400 c, 400 d, 400 e) however other embodiments containing greater or fewer numbers of processors are contemplated. The offload processors (400 a to 400 e) can be custom manufactured or one of a variety of commodity processors including but not limited to field-programmable grid arrays (FPGA), microprocessors, reduced instruction set computers (RISC), microcontrollers or ARM processors. The computation elements or offload processors can include combinations of computational FPGAs such as those based on Altera, Xilinx (e.g., Artix™ class or Zynq® architecture, e.g., Zynq® 7020), and/or conventional processors such as those based on Intel Atom or ARM architecture (e.g., ARM A9). For many applications, ARM processors having advanced memory handling features such as a snoop control unit (SCU) are preferred, since this can allow coherent read and write of memory. Other preferred advanced memory features can include processors that support an accelerator coherency port (ACP) that can allow for coherent supplementation of the cache through an FPGA fabric or computational element.
Each offload processor (400 a to 400 e) on the module 402 may run one of a variety of operating systems including but not limited to Apache or Linux. In addition, the offload processors (400 a to 400 e) may have access to a plurality of dedicated or shared storage methods. In this embodiment, each offload processor can connect to one or more storage units (in this embodiments, pairs of storage units 404 a, 404 b, 404 c and 404 d). Storage units (404 a to 404 d) can be of a variety of storage types, including but not limited to random access memory (RAM), dynamic random access memory (DRAM), sequential access memory (SAM), static random access memory (SRAM), synchronous dynamic random access memory (SDRAM), reduced latency dynamic random access memory (RLDRAM), flash memory, or other emerging memory standards such as those based on DDR4 or hybrid memory cubes (HMC).
FIG. 4-2 shows an example layout of a module (e.g., XIMM) such as that described in FIG. 4-1, as well as a connectivity diagram between the components of the module. In this example, five Xilinx™ Zynq® 7020 (416 a, 416 b, 416 c, 416 d, 416 e and 416 in the connectivity diagram) programmable systems-on-a-chip (SoC) are used as computational FPGAs/offload processors. These offload processors can communicate with each other using memory-mapped input-output (MMIO) (412). The types of storage units used in this example are SDRAM (SD, one shown as 408) and RLDRAM (RLD, three shown as 406 a, 406 b, 406 c) and an Inphi™ iMB02 memory buffer 418. Down conversion of 3.3 V to 2.5 volt is required to connect the RLDRAM (406 a to 406 c) with the Zynq® components. The components are connected to the offload processors and to each other via a DDR3 (414) memory bus. Advantageously, the indicated layout maximizes memory resources availability without requiring a violation of the number of pins available under the DIMM standard.
In this embodiment, one of the Zynq® computational FPGAs (416 a to 416 e) can act as arbiter providing a memory cache, giving an ability to have peer to peer sharing of data (via memcached or OMQ memory formalisms) between the other Zynq® computational FPGAs (416 a to 416 e). Traffic departing for the computational FPGAs can be controlled through memory mapped I/O. The arbiter queues session data for use, and when a computational FPGA asks for address outside of the provided session, the arbiter can be the first level of retrieval, external processing determination, and predictors set.
FIG. 4-3 shows two possible architectures for a module (e.g., XIMM) in a simulation (Xockets MAX and MIN). Xockets MIN (420 a) can be used in low-end public cloud servers, containing twenty ARM cores (420 b) spread across fourteen DIMM slots in a commodity server which has two Opteron x86 processors and two network interface cards (NICs) (420 c). This architecture can provide a minimal benefit per Watt of power used. Xockets MAX (422 a) contains eighty ARM cores (422 b) across eight DIMM slots, in a server with two Opteron x86 processors and four NICs (422 c). This architecture can provide a maximum benefit per Watt of power used.
FIG. 4-4 shows a representative power budget for an example of a module (e.g., XIMM) according to a particular embodiment. Each component is listed (424 a, 424 b, 424 c, 424 d) along with its power profile. Average total and total wattages are also listed (426 a, 426 b). In total, especially for I/O packet processing with packet sizes on the order 1 KB in size, module can have a low average power budget that is easily able to be provided by the 22 V_ddpins per DIMM. Additionally, the expected thermal output can be handled by inexpensive conductive heat spreaders, without requiring additional convective, conductive, or thermoelectric cooling. In certain situations, digital thermometers can be implemented to dynamically reduce performance (and consequent heat generation) if needed.
Operation of one embodiment of a module 430 (e.g., XIMM) using an ARM A9 architecture is illustrated with respect to FIG. 4-5. Use of ARM A9 architecture in conjunction with an FPGA fabric and memory, in this case shown as reduced latency DRAM (RLDRAM) 438, can simplify or makes possible zero-overhead context switching, memory compression and CPI, in part by allowing hardware context switching synchronized with network queuing. In this way, there can be a one-to-one mapping between thread and queues. As illustrated, the ARM A9 architecture includes a Snoop Control Unit 432 (SCU). This unit allows one to read out and write in memory coherently. Additionally, the Accelerator Coherency Port 434 (ACP) allows for coherent supplementation of the cache throughout the FPGA 436. The RLDRAM 438 provides the auxiliary bandwidth to read and write the ping-pong cache supplement (435): Block1$ and Block2$ during packet-level meta-data processing.
The following table (Table 1) illustrates potential states that can exist in the scheduling of queues/threads to XIMM processors and memory such as illustrated in FIG. 4-5.

TABLE 1

Queue/Thread State	HW treatment

Waiting for Ingress	All ingress data has been processed and thread
Packet	awaits further communication.
Waiting for MMIO	A functional call to MM hardware (such as HW
	encryption or transcoding) was made.
Waiting for Rate-limit	The thread's resource consumption exceeds limit,
	due to other connections idling.
Currently being	One of the ARM cores is already processing this
processed	thread, cannot schedule again.
Ready for Selection	The thread is ready for context selection.

These states can help coordinate the complex synchronization between processes, network traffic, and memory-mapped hardware. When a queue is selected by a traffic manager a pipeline coordinates swapping in the desired L2 cache (440), transferring the reassembled IO data into the memory space of the executing process. In certain cases, no packets are pending in the queue, but computation is still pending to service previous packets. Once this process makes a memory reference outside of the data swapped, a scheduler can require queued data from a network interface card (NIC) to continue scheduling the thread. To provide fair queuing to a process not having data, the maximum context size is assumed as data processed. In this way, a queue must be provisioned as the greater of computational resource and network bandwidth resource, for example, each as a ratio of an 800 MHz A9 and 3 Gbps of bandwidth. Given the lopsidedness of this ratio, the ARM core is generally indicated to be worthwhile for computation having many parallel sessions (such that the hardware's prefetching of session-specific data and TCP/reassembly offloads a large portion of the CPU load) and those requiring minimal general purpose processing of data.

Essentially zero-overhead context switching is also possible using modules as disclosed in FIG. 4-5. Because per packet processing has minimum state associated with it, and represents inherent engineered parallelism, minimal memory access is needed, aside from packet buffering. On the other hand, after packet reconstruction, the entire memory state of the session can be accessed, and so can require maximal memory utility. By using the time of packet-level processing to prefetch the next hardware scheduled application-level service context in two different processing passes, the memory can always be available for prefetching. Additionally, the FPGA 436 can hold a supplemental “ping-pong” cache (435) that is read and written with every context switch, while the other is in use. As previously noted, this is enabled in part by the SCU 432, which allows one to read out and write in memory coherently, and ACP 434 for coherent supplementation of the cache throughout the FPGA 436. The RLDRAM 438 provides for read and write to the ping-pong cache supplement (435): (shown as Block1$ and Block2$) during packet-level meta-data processing. In the embodiment shown, only locally terminating queues can prompt context switching.
In operation, metadata transport code can relieve a main or host processor from tasks including fragmentation and reassembly, and checksum and other metadata services (e.g., accounting, IPSec, SSL, Overlay, etc.). As IO data streams in and out, L1 cache 437 can be filled during packet processing. During a context switch, the lock-down portion of a translation lookaside buffer (TLB) of an L1 cache can be rewritten with the addresses corresponding to the new context. In one very particular implementation, the following four commands can be executed for the current memory space.

- MRC p15,0,r0,c10,c0,0; read the lockdown register
- BIC r0,r0,#1; clear preserve bit
- MCR p15,0,r0,c10,c0,0; write to the lockdown register;
- write to the old value to the memory mapped Block RAM

This is a small 32 cycle overhead to bear. Other TLB entries can be used by the XIMM stochastically.
Bandwidths and capacities of the memories can be precisely allocated to support context switching as well as applications such as Openflow processing, billing, accounting, and header filtering programs.
For additional performance improvements, the ACP 434 can be used not just for cache supplementation, but hardware functionality supplementation, in part by exploitation of the memory space allocation. An operand can be written to memory and the new function called, through customizing specific Open Source libraries, so putting the thread to sleep and a hardware scheduler can validate it for scheduling again once the results are ready. For example, OpenVPN uses the OpenSSL library, where the encrypt/decrypt functions 439 can be memory mapped. Large blocks are then available to be exported without delay, or consuming the L2 cache 440, using the ACP 434. Hence, a minimum number of calls are needed within the processing window of a context switch, improving overall performance.
It should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.
It is also understood that the embodiments of the invention may be practiced in the absence of an element and/or step not specifically disclosed. That is, an inventive feature of the invention may be elimination of an element.
Accordingly, while the various aspects of the particular embodiments set forth herein have been described in detail, the present invention could be subject to various changes, substitutions, and alterations without departing from the spirit and scope of the invention.

Claims

What is claimed is:

1. A structured data processing system, comprising:

a plurality of modules connected to a memory bus in a first server, each including at least one processor, and at least one module configured to provide an in-memory database; and

a central processing unit (CPU) in the first server connected to the in-line modules by the memory bus, with the CPU configured to process and direct structured queries to the plurality of in-line modules.

2. The structured data processing system of claim 1, wherein the modules are configured to communicate with each other without requiring access to the CPU of the first server.

3. The structured data processing system of claim 1, wherein the modules are mounted on different servers in a same rack, and further comprising a top of the rack switch to mediate communication therebetween.

4. The structured data processing system of claim 1, further including a module driver configured to execute a memory mapping function to transfer a query from the CPU to at least one module in the form of a memory read or writes.

5. The structured data processing system of claim 1, wherein the modules are configured for insertion into a dual-in-line-memory module (DIMM) socket, and the module further comprises the processors being connected to memory and a computational field programmable gate array (FPGA).

6. A data processing system for unstructured data, comprising:

a plurality of modules connected to a memory bus, each including at least one processor; and

a central processing unit (CPU) connected to the modules by the memory bus, with the CPU configured to process computationally intensive data processing tasks while directing parallel computation tasks to a plurality of the modules.

7. The data processing system for unstructured data of claim 6, wherein a Map/Reduce algorithm is processed, with results of a Map step being stored and available in main memory, and collected through DMA operations and parsed by the modules.

8. The data processing system for unstructured data of claim 6, wherein the modules together define a massively parallel input/output (I/O) mid-plane defined by the modules.

9. The data processing system for unstructured data of claim 6, further including:

the modules are disposed on multiple servers;

a Map/Reduce algorithm is processed by the multiple servers, and the servers are configured exchange intermediate (key, value) pairs across the multiple servers through switching of the modules.

10. The data processing system for unstructured data of claim 6, wherein each module is configured for insertion into a dual-in-line-memory-module (DIMM) socket, and each module further comprises offload processors connected to memory and a computational field programmable gate array (FPGA).