Tablas en memoria / aceleración

Oracle

-- Keep the table in memory with Database In-Memory:
ALTER TABLE orders INMEMORY;
-- Memory size (init parameter):
ALTER SYSTEM SET inmemory_size = 4G SCOPE=SPFILE;

Oracle Database In-Memory acelera la analítica manteniendo en memoria, en formato columnar, las tablas consultadas con frecuencia (licencia aparte). Para OLTP, el Buffer Cache y el KEEP pool también mantienen en memoria los bloques de acceso frecuente. La solución en memoria conserva la durabilidad gracias al formato de filas en disco.

PostgreSQL

-- Fast table without durability (writes no WAL):
CREATE UNLOGGED TABLE temp_calc (id int, data text);
-- Session-private temporary table (tends to stay in memory):
CREATE TEMP TABLE session_data (id int) ON COMMIT DELETE ROWS;

PostgreSQL no ofrece un motor de tablas en memoria dedicado; una tabla UNLOGGED omite las escrituras en WAL para acelerar la escritura (su contenido se pierde tras un crash; no es durable). Las tablas TEMP duran lo que la sesión y se mantienen en memoria cuando es posible mediante temp_buffers. Los datos calientes se cachean en shared_buffers.

MySQL

-- Table using the MEMORY (HEAP) storage engine:
CREATE TABLE cache_table (
  id INT PRIMARY KEY,
  data VARCHAR(100)
) ENGINE=MEMORY;

El storage engine MEMORY de MySQL (antes HEAP) mantiene los datos de la tabla íntegramente en RAM; es muy rápido, pero los datos se pierden al reiniciar el servidor (la estructura se conserva). No admite BLOB/TEXT y usa un tamaño de fila fijo. Para datos calientes durables se prefiere el buffer pool de InnoDB.

SQL Server

-- In-Memory OLTP: memory-optimized table
CREATE TABLE dbo.session_state (
  id INT NOT NULL PRIMARY KEY NONCLUSTERED,
  data NVARCHAR(100)
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

In-Memory OLTP de SQL Server (Hekaton) proporciona OLTP de alta concurrencia con tablas optimizadas para memoria (MEMORY_OPTIMIZED=ON) y estructuras sin latches. DURABILITY=SCHEMA_AND_DATA mantiene los datos durables; SCHEMA_ONLY conserva solo el esquema. Requiere un filegroup optimizado para memoria.

MongoDB

-- Hot data is kept in the WiredTiger cache automatically.
-- Set the cache size (default ~50% of RAM):
// mongod --wiredTigerCacheSizeGB 8
// or in the configuration: storage.wiredTiger.engineConfig.cacheSizeGB

MongoDB no tiene un tipo de tabla en memoria aparte (el antiguo In-Memory Storage Engine era exclusivo de Enterprise y está obsoleto). El motor WiredTiger por defecto mejora la velocidad de lectura manteniendo en su caché de memoria los datos e índices de acceso frecuente; la caché de archivos del SO también contribuye.

Redis

# Redis already runs entirely in memory; nothing extra is needed.
# Persistence and memory policy settings:
CONFIG SET maxmemory 4gb
CONFIG SET maxmemory-policy allkeys-lru

Redis mantiene todos los datos en RAM; por diseño, esta es la fuente de su velocidad. La persistencia la proporcionan RDB (snapshots) y/o AOF (log de comandos). El límite maxmemory y la política de eviction (LRU/LFU/random) determinan el comportamiento cuando la memoria está llena.

Elasticsearch

-- Not applicable: there is no fully in-memory table mode.
# Place hot data on fast nodes with a hot/cold architecture:
PUT sale/_settings
{ "index.routing.allocation.require.data": "hot" }

Elasticsearch almacena los datos en disco (segmentos de Lucene); no ofrece un motor de tablas en memoria dedicado. Para la velocidad depende de la caché de archivos del SO (page cache), de doc_values y de una arquitectura hot-warm-cold. Disponer de RAM suficiente y de una configuración de heap adecuada es crítico para el rendimiento.