in memory computing database analytics

**In-Memory and Near-Memory Computing for Databases** is the **database acceleration paradigm that eliminates the memory bottleneck by keeping all active data in DRAM (in-memory databases) or moving computation physically adjacent to memory arrays (near-memory/PIM processing) — achieving 10-1000× speedup over disk-based or PCIe-bottlenecked databases by eliminating the data movement that dominates query execution time in analytical workloads**. **In-Memory Databases** All data resides in DRAM rather than disk or SSD: - **SAP HANA**: column-store in-memory HTAP (handles both OLTP and OLAP in unified engine), dictionary encoding for compression, SIMD-accelerated scan, parallel aggregation. - **VoltDB**: in-memory OLTP (partition-to-core mapping, single-threaded partitions eliminate locking overhead, stored procedures as atomic transactions). - **Redis**: key-value store, data structures in memory, sub-millisecond latency. - **MemSQL/SingleStore**: distributed in-memory SQL with disk overflow, rowstore + columnstore hybrid. **Column-Store Advantages for Analytics** Analytical queries (SUM, GROUP BY, filter) access few columns across many rows: - Column storage reads only needed columns (vs row store reads entire row). - SIMD vectorized scan over dense integer/float columns. - Compression (run-length encoding, dictionary) further reduces memory bandwidth. - MonetDB, DuckDB, ClickHouse: column-store for OLAP. **Near-Memory Processing (NMP/PIM)** Move computation to where data resides in DRAM/HBM: - **Samsung Aquabolt-XL HBM-PIM**: logic layer inside HBM stack, performs GEMV and GELU operations without sending data over HBM bus. 2× bandwidth effective for ML inference. - **UPMEM DPU DIMM**: DDR4 DIMM with 8 DPU cores per chip (2048 DPU in a system), each DPU has fast access to local DRAM. Applications: database scan/filter (20× speedup over CPU for string matching). - **Samsung AxDIMM**: DDR4 DIMM with ARM cores near DRAM, targets recommendation system embedding table lookup (embedding lookup is bandwidth-bound). **HTAP (Hybrid Transactional/Analytical Processing)** Single system handles both: - OLTP: short transactions, row updates, low latency. - OLAP: long analytical queries, aggregations, full scans. - Approaches: delta store (fresh OLTP data) + main store (compressed columnar) with merge; or MVCC with snapshot isolation for analytics on consistent OLTP snapshot. - Systems: SAP HANA, TiDB, CockroachDB, Greenplum. **Memory Bandwidth vs Latency** - DRAM bandwidth (DDR5): 51 GB/s per channel; HBM3: 819 GB/s per stack. - For full in-memory database scan (1 TB data): DDR5 × 8 channels = 408 GB/s → ~2.5 seconds minimum for sequential scan. - PIM eliminates the CPU-DRAM bus hop: computation done in memory, only results transferred. - CXL memory expansion: adds capacity beyond CPU memory slots, with modest latency penalty (~80 ns extra vs local DRAM). In-Memory and Near-Memory Computing is **the architectural revolution that relocates the database bottleneck from disk I/O to memory bandwidth and then eliminates that bottleneck by moving computation to where data lives — fundamentally changing the economics of analytical query performance from storage-bound to compute-bound**.