In-Memory-Tabellen / Beschleunigung

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 beschleunigt Analytik, indem häufig abgefragte Tabellen spaltenorientiert im Speicher gehalten werden (separate Lizenz). Für OLTP halten auch der Buffer Cache und der KEEP-Pool häufig genutzte Blöcke im Speicher. Die In-Memory-Lösung wahrt die Dauerhaftigkeit über das Zeilenformat auf Platte.

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 bietet keine dedizierte In-Memory-Tabellen-Engine; eine UNLOGGED-Tabelle überspringt WAL-Schreibvorgänge und beschleunigt so das Schreiben (Inhalt geht bei einem Crash verloren; nicht dauerhaft). TEMP-Tabellen leben für die Dauer der Session und werden über temp_buffers nach Möglichkeit im Speicher gehalten. Häufig genutzte Daten werden in shared_buffers gecacht.

MySQL

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

Die MySQL-Storage-Engine MEMORY (früher HEAP) hält Tabellendaten vollständig im RAM; sie ist sehr schnell, aber die Daten gehen beim Neustart des Servers verloren (die Struktur bleibt). Sie unterstützt kein BLOB/TEXT und nutzt eine feste Zeilengröße. Für dauerhafte häufig genutzte Daten wird der InnoDB Buffer Pool bevorzugt.

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

SQL Server In-Memory OLTP (Hekaton) bietet hochgradig nebenläufiges OLTP mit speicheroptimierten Tabellen (MEMORY_OPTIMIZED=ON) und latch-freien Strukturen. DURABILITY=SCHEMA_AND_DATA hält die Daten dauerhaft; SCHEMA_ONLY bewahrt nur das Schema. Erfordert eine speicheroptimierte Dateigruppe.

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 hat keinen separaten In-Memory-Tabellentyp (die alte In-Memory Storage Engine gab es nur in Enterprise, sie ist veraltet). Die Standard-Engine WiredTiger verbessert die Lesegeschwindigkeit, indem sie häufig genutzte Daten und Indizes in ihrem Speicher-Cache hält; auch der Dateicache des Betriebssystems trägt bei.

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 hält alle Daten im RAM; darauf beruht seine Geschwindigkeit. Persistenz bieten RDB (Snapshots) und/oder AOF (Befehlsprotokoll). Das Limit maxmemory und die Eviction Policy (LRU/LFU/random) bestimmen das Verhalten bei vollem Speicher.

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 speichert Daten auf Platte (Lucene-Segmente); eine dedizierte In-Memory-Tabellen-Engine gibt es nicht. Für Geschwindigkeit stützt es sich auf den Dateicache des Betriebssystems (Page Cache), doc_values und eine Hot-Warm-Cold-Architektur. Ausreichend RAM und passende Heap-Einstellungen sind für die Performance entscheidend.