Tables en mémoire / accélération

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 accélère l'analytique en gardant en mémoire, au format colonne, les tables fréquemment interrogées (licence séparée). Pour l'OLTP, le Buffer Cache et le pool KEEP gardent aussi en mémoire les blocs fréquemment consultés. La solution en mémoire préserve la durabilité via le format ligne sur disque.

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 n'offre pas de moteur de tables en mémoire dédié ; une table UNLOGGED évite les écritures WAL pour accélérer l'écriture (son contenu est perdu en cas de crash ; non durable). Les tables TEMP vivent le temps de la session et sont gardées en mémoire si possible via temp_buffers. Les données chaudes sont mises en cache dans shared_buffers.

MySQL

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

Le moteur de stockage MEMORY (anciennement HEAP) de MySQL garde les données de la table entièrement en RAM ; il est très rapide, mais les données sont perdues au redémarrage du serveur (la structure reste). Il ne prend pas en charge BLOB/TEXT et utilise une taille de ligne fixe. Pour des données chaudes durables, le buffer pool InnoDB est préférable.

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 (Hekaton) de SQL Server offre un OLTP hautement concurrent avec des tables optimisées en mémoire (MEMORY_OPTIMIZED=ON) et des structures sans latch. DURABILITY=SCHEMA_AND_DATA garde les données durables ; SCHEMA_ONLY ne préserve que le schéma. Nécessite un 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

MongoDB n'a pas de type de table en mémoire distinct (l'ancien In-Memory Storage Engine était réservé à Enterprise et a été déprécié). Le moteur WiredTiger par défaut améliore la vitesse de lecture en gardant les données et index fréquemment consultés dans son cache mémoire ; le cache de fichiers de l'OS contribue aussi.

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 garde toutes les données en RAM ; c'est par conception la source de sa rapidité. La persistance est assurée par RDB (snapshots) et/ou AOF (journal des commandes). La limite maxmemory et la politique d'éviction (LRU/LFU/random) déterminent le comportement lorsque la mémoire est pleine.

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 stocke les données sur disque (segments Lucene) ; il n'offre pas de moteur de tables en mémoire dédié. Pour la vitesse, il s'appuie sur le cache de fichiers de l'OS (page cache), les doc_values et une architecture hot-warm-cold. Une RAM suffisante et des réglages de heap adaptés sont essentiels pour les performances.