Tabelas em memória / aceleração

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;

O Oracle Database In-Memory acelera analytics mantendo em memória, em formato colunar, as tabelas consultadas com frequência (licença separada). Para OLTP, o Buffer Cache e o KEEP pool também mantêm em memória os blocos acessados com frequência. A solução in-memory preserva a durabilidade pelo formato de linha em 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;

O PostgreSQL não oferece um engine dedicado de tabelas em memória; uma tabela UNLOGGED pula a gravação no WAL para acelerar as escritas (o conteúdo é perdido em um crash; não é durável). Tabelas TEMP duram a sessão e ficam em memória sempre que possível via temp_buffers. Os dados quentes ficam em cache no shared_buffers.

MySQL

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

O storage engine MEMORY (antes HEAP) do MySQL mantém os dados da tabela inteiramente na RAM; é muito rápido, mas os dados são perdidos quando o servidor reinicia (a estrutura permanece). Não suporta BLOB/TEXT e usa tamanho de linha fixo. Para dados quentes duráveis, prefere-se o InnoDB buffer pool.

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);

O In-Memory OLTP (Hekaton) do SQL Server fornece OLTP altamente concorrente com tabelas memory-optimized (MEMORY_OPTIMIZED=ON) e estruturas latch-free. DURABILITY=SCHEMA_AND_DATA mantém os dados duráveis; SCHEMA_ONLY preserva apenas o schema. Requer um filegroup memory-optimized.

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

O MongoDB não tem um tipo separado de tabela em memória (o antigo In-Memory Storage Engine era exclusivo do Enterprise e foi descontinuado). O engine padrão WiredTiger melhora a velocidade de leitura mantendo em seu cache de memória os dados e índices acessados com frequência; o cache de arquivos do SO também contribui.

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

O Redis mantém todos os dados na RAM; por design, essa é a fonte de sua velocidade. A persistência é fornecida por RDB (snapshots) e/ou AOF (log de comandos). O limite maxmemory e a política de eviction (LRU/LFU/random) determinam o comportamento quando a memória fica cheia.

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" }

O Elasticsearch armazena os dados em disco (segmentos Lucene); não oferece um engine dedicado de tabelas em memória. Para velocidade, depende do cache de arquivos do SO (page cache), dos doc_values e de uma arquitetura hot-warm-cold. RAM suficiente e configurações de heap adequadas são críticas para o desempenho.