Process Model and Parallel Architecture
Parallelism is the key to performance, in particular when I/O waits might stall computation. To maximize throughput, a data processing system (DPS) should have a number of tasks running in parallel to avoid waiting/stalling.
Process models :
- One process per DPS worker :
This is the oldest model where one process is created for each task that the DPS needs to perform. Say for query planning one process will be created. Then for execution one process will be created. The drawback of this approach is that memory is not shared among worker tasks and context switch is expensive. Also the scalability is not good. The software is relatively easier to port because processes are supported by every OS.
Note : When we say a model is not good, we do not say about overall performance. There are many other factors that define the overall performance. For instance, based on this model, the Tandem OLTP engine (HP NONSTOP database) is highly efficient even compared to the thread pool based database engines. This is being used by mission critical applications like stock exchanges, banking systems like VISA, 911 services, etc.
- Thread per DBMS worker :
This is dependent on the OS threading support. a DPS may also implement its own implementation of threads (DBMS threads). This model is preferable when multiple parallel tasks are running and context switches are frequent.
- Process/Thread pool :
This model ensures that the number of parallel tasks does not exceed a threshold, ensuring that the tasks do not starve for resource. Most of the modern day data processor engines implement this approach.
Parallel Memory Architecture :
- Shared Memory : processor core will reside inside one machine. Higher costs for large installations because of the design/hardware complexity. All process models are applicable. Great for OLTP, many implementation form almost every vendor.
- Shared Nothing : Implemented as a cluster of nodes. These require better partitioning, which is suiatble for OLAP workloads (Teradata, Greenplum, DB2 Parallel Edition, etc).
- Shared Disk: Cluster of nodes with a SAN. Simple model, because every node can access all the data. This requires cache-coherence protocols. E.g. Oracle RAC, DB2 SYSPLEX, etc