Shared-nothing Massively Parallel Processing (MPP) is a divide-and-conquer processing technique that coordinates processing simultaneously across separate but equal parallel units each with self-contained processing resources (e.g., each unit is a separate server with its own memory, CPU, I/O and interconnect access). PADB utilizes a unique software architecture that takes advantage of commonly available servers and benefits from the raw power of the fabric, which can sustain rates of 150MB per second per node.
This highly efficient MPP grid is implemented on standard hardware to eliminate proprietary lock-in and thereby provide the benefit of sensibly priced components that leverage hardware performance advances as they enter the market. In this divide-and-conquer model, each node operates principally with its own disks’ data against its own memory and CPUs. Only intermediate result sets are transferred across the interconnect to be combined into final result sets to be returned to the application.
ParAccel Interconnect Protocol
The performance of any parallel system is directly tied to the efficiency and scalability of its inter-node communications. PADB’s MPP implementation is further differentiated by the Paraccel Interconnect Protocol (PIP), a highly optimized, custom protocol that is specially designed to leverage low-cost, standard Gigabit Ethernet (GbE) with standard switches more efficiently than other parallel database systems. In contrast, MPP interconnects that are based on standard TCP/IP can suffer up to 95% packet loss during heavy inter-node communication activity that is typical of MPP environments – as packet losses increase, sending attempts increase, performance degrades and, eventually, problem queries impact the performance of otherwise well-behaved queries.
Parallel Data Distribution, Query Planning and Execution
In parallel, shared-nothing systems, the distribution of data is balanced to maximize query processing efficiency. In addition, query planning and optimization methods dynamically evaluate the requirements of a query and the distribution of the data to determine the best processing steps for optimal performance. For example:
- Parallel Server Grid – Using multiple high performance servers in a direct-attached or mixed direct- and SAN-attached storage configuration scales system capacity linearly and balances query performance. The grid is easily extended to adapt to capacity and performance changes over time. When servers are added, PADB rebalances data distribution according to the new configuration.
- Intra- and Inter-Query Parallelization – The advanced scheduling features of PADB ensure that all CPUs, memory, I/O bandwidth, and network switch capacity are fully utilized at all times. Concurrency levels are configurable to balance latency with throughput to suit mixed-use scenarios.
- Balancing and Interleaving – Parallel analytic systems must balance resource utilization to maximize throughput in all of the processing of each query. This involves eliminating CPU overhead and maximizing bandwidth while reading, caching, and moving data. PADB is designed to reduce potential bottlenecks in all of these areas by interleaving movement of data and processing of analytic operations.
Incremental, Linear Scaling
Linear scalability – that is, each added unit of parallelism delivers a full unit’s worth of power – is important for predictability, capacity planning and investment protection. PADB’s MPP implementation ensures scaling simplicity. PADB has demonstrated linear scalability in customer environments and audited industry benchmarks.
To get additional PADB capacity, simply add nodes. When nodes are configured into the system, they are invoked and given their portion of the data. The system is then ready for queries and will run commensurately faster.
Expanding the system can yield much better than linear benefit. Queries that had to shuffle intermediate results to disk on smaller systems can now run more in-memory on larger systems. Thus, a 2X larger system can sometimes have a 5X benefit on performance if the smaller system was under-configured.