The amount of data you can process with the HEAVY.AI database depends primarily on the amount of GPU RAM and CPU RAM available across HEAVY.AI cluster servers. For zero-latency queries, the system caches compressed versions of the row- and column-queried fields into GPU RAM. This is called hot data (see Hot Records and Columns). Semi-hot data utilizes CPU RAM for certain parts of the data.
System Examples show example configurations to help you configure your system.
Optimal GPUs on which to run the HEAVY.AI platform include:
NVIDIA Tesla A100
NVIDIA Tesla V100 v2
NVIDIA Tesla V100 v1
NVIDIA Tesla P100
NVIDIA Tesla P40
NVIDIA Testa T4
The following configurations are valid for systems using any of these GPUs as the building blocks of your system. For production systems, use Tesla enterprise-grade cards. Avoid mixing card types in the same system; use a consistent card model across your environment.
Primary factors to consider when choosing GPU cards are:
The amount of GPU RAM available on each card
The number of GPU cores
Memory bandwidth
Newer cards like the Tesla V100 have higher double-precision compute performance, which is important in geospatial analytics. The Tesla V100 models support the NVLink interconnect, which can provide a significant speed increase for some query workloads.
For advice on optimal GPU hardware for your particular use case, ask your HEAVY.AI sales representative.
Before considering hardware details, this topic describes the HeavyDB architecture.
HeavyDB is a hybrid compute architecture that utilizes GPU, CPU, and storage. GPU and CPU are the Compute Layer, and SSD storage is the Storage Layer.
When determining the optimal hardware, make sure to consider the storage and compute layers separately.
Loading raw data into HeavyDB ingests data onto disk, so you can load as much data as you have disk space available, allowing some overhead.
When queries are executed, HeavyDB optimizer utilizes GPU RAM first if it is available. You can view GPU RAM as an L1 cache conceptually similar to modern CPU architectures. HeavyDB attempts to cache the hot data. If GPU RAM is unavailable or filled, HeavyDB optimizer utilizes CPU RAM (L2). If both L1 and L2 are filled, query records overflow to disk (L3). To minimize latency, use SSDs for the Storage Layer.
You can run a query on a record set that spans both GPU RAM and CPU RAM as shown in the diagram above, which also shows the relative performance improvement you can expect based on whether the records all fit into L1, a mix of L1 and L2, only L2, or some combination of L1, L2, and L3.
The Hardware Sizing Schedule table refers to hot records, which are the number of records that you want to put into GPU RAM to get zero-lag performance when querying and interacting with the data. The Hardware Sizing Schedule assumes 16 hot columns, which is the number of columns involved in the predicate or computed projections (such as, column1 / column2) of any one of your queries. A 15 percent GPU RAM overhead is reserved for rendering buffering and intermediate results. If your queries involve more columns, the number of records you can put in GPU RAM decreases, accordingly.
The server is not limited to any number of hot records. You can store as much data on disk as you want. The system can also store and query records in CPU RAM, but with higher latency. The hot records represent the number of records on which you can perform zero-latency queries.
HeavyDB does not require all queried columns to be processed on the GPU. Non-aggregate projection columns, such as SELECT x, y FROM table
, do not need to be processed on the GPU, so can be stored in CPU RAM. The Hardware Sizing Schedule CPU RAM sizing assumes that up to 24 columns are used in only non-computed projections, in addition to the Hot Records and Columns.
The amount of CPU RAM should equal four to eight times the amount of total available GPU memory. Each NVIDIA Tesla P40 has 24 GB of onboard RAM available, so if you determine that your application requires four NVIDIA P40 cards, you need between 4 x 24 GB x 4
(384 GB) and 4 x 24 GB x 8
(768 GB) of CPU RAM. This correlation between GPU RAM and CPU RAM exists because the HeavyDB uses CPU RAM in certain operations for columns that are not filtered or aggregated.
A HEAVY.AI deployment should be provisioned with enough SSD storage to reliably store the required data on disk, both in compressed format and in HEAVY.AI itself. HEAVY.AI requires 30% overhead beyond compressed data volumes. HEAVY.AI recommends drives such as the Intel® SSD DC S3610 Series, or similar, in any size that meets your requirements.
For maximum ingestion speed, HEAVY.AI recommends ingesting data from files stored on the HEAVY.AI instance.
Most public cloud environments’ default storage is too small for the data volume HEAVY.AI ingests. Estimate your storage requirements and provision accordingly.
This schedule estimates the number of records you can process based on GPU RAM and CPU RAM sizes, assuming up to 16 hot columns (see Hot Records and Columns). This applies to the compute layer. For the storage layer, provision your application according to SSD Storage guidelines.
If you already have your data in a database, you can look at the largest fact table, get a count of those records, and compare that with this schedule.
If you have a .csv file, you need to get a count of the number of lines and compare it with this schedule.
HEAVY.AI uses the CPU in addition to the GPU for some database operations. GPUs are the primary performance driver; CPUs are utilized secondarily. More cores provide better performance but increase the cost. Intel CPUs with 10 cores offer good performance for the price. For example, so you could configure your system with a single NVIDIA P40 GPU and two 10-core CPUs. Similarly, you can configure a server with eight P40s and two 10-core CPUs.
Suggested CPUs:
Intel® Xeon® E5-2650 v3 2.3GHz, 10 cores
Intel® Xeon® E5-2660 v3 2.6GHz, 10 cores
Intel® Xeon® E5-2687 v3 3.1GHz, 10 cores
Intel® Xeon® E5-2667 v3 3.2GHz, 8 cores
GPUs are typically connected to the motherboard using PCIe slots. The PCIe connection is based on the concept of a lane, which is a single-bit, full-duplex, high-speed serial communication channel. The most common numbers of lanes are x4, x8, and x16. The current PCIe 3.0 version with an x16 connection has a bandwidth of 16 GB/s. PCIe 2.0 bandwidth is half the PCIe 3.0 bandwidth, and PCIe 1.0 is half the PCIe 2.0 bandwidth. Use a motherboard that supports the highest bandwidth, preferably, PCIe 3.0. To achieve maximum performance, the GPU and the PCIe controller should have the same version number.
The PCIe specification permits slots with different physical sizes, depending on the number of lanes connected to the slot. For example, a slot with an x1 connection uses a smaller slot, saving space on the motherboard. However, bigger slots can actually have fewer lanes than their physical designation. For example, motherboards can have x16 slots connected to x8, x4, or even x1 lanes. With bigger slots, check to see if their physical sizes correspond to the number of lanes. Additionally, some slots downgrade speeds when lanes are shared. This occurs most commonly on motherboards with two or more x16 slots. Some motherboards have only 16 lanes connecting the first two x16 slots to the PCIe controller. This means that when you install a single GPU, it has the full x16 bandwidth available, but two installed GPUs each have x8 bandwidth.
HEAVY.AI recommends installing GPUs in motherboards with support for as much PCIe bandwidth as possible. On modern Intel chip sets, each socket (CPU) offers 40 lanes, so with the correct motherboards, each GPU can receive x8 of bandwidth. All recommended System Examples have motherboards designed for maximizing PCIe bandwidth to the GPUs.
HEAVY.AI does not recommend adding GPUs to a system that is not certified to support the cards. For example, to run eight GPU cards in a machine, the BIOS register the additional address space required for the number of cards. Other considerations include power routing, power supply rating, and air movement through the chassis and cards for temperature control.
For an emerging alternative to PCIe, see NVLink.
NVLink is a bus technology developed by NVIDIA. Compared to PCIe, NVLink offers higher bandwidth between host CPU and GPU and between the GPU processors. NVLink-enabled servers, such as the IBM S822LC Minsky server, can provide up to 160 GB/sec bidirectional bandwidth to the GPUs, a significant increase over PCIe. Because Intel does not currently support NVLink, the technology is available only on IBM Power servers. Servers like the NVIDIA-manufactured DGX-1 offer NVLink between the GPUs but not between the host and the GPUs.
A variety of hardware manufacturers make suitable GPU systems. For more information, follow these links to their product specifications.
GPU
Memory/GPU
Cores
Memory Bandwidth
NVLink
A100
40 to 80 GB
6912
1134 GB/sec
V100 v2
32 GB
5120
900 GB/sec
Yes
V100
16 GB
5120
900 GB/sec
Yes
P100
16 GB
3584
732 GB/sec
Yes
P40
24GB
3840
346 GB/sec
No
T4
16GB
2560
320 GB/sec
GPU Count
GPU RAM (GB)
CPU RAM (GB)
“Hot” Records
(NVIDIA P40)
8x GPU RAM
L1
1
24
192
417M
2
48
384
834M
3
72
576
1.25B
4
96
768
1.67B
5
120
960
2.09B
6
144
1,152
2.50B
7
168
1,344
2.92B
8
192
1,536
3.33B
12
288
2,304
5.00B
16
384
3,456
6.67B
20
480
3,840
8.34B
24
576
4,608
10.01B
28
672
5,376
11.68B
32
768
6,144
13.34B
40
960
7,680
16.68B
48
1,152
9,216
20.02B
56
1,344
10,752
23.35B
64
1,536
12,288
26.69B
128
3,072
24,576
53.38B
256
6,144
49,152
106.68B