DBAtlas · Атлас эксплуатации баз данных

Таблицы в памяти / ускорение

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 ускоряет аналитику, держа часто запрашиваемые таблицы в памяти в колоночном формате (отдельная лицензия). Для OLTP Buffer Cache и пул KEEP также держат часто используемые блоки в памяти. Решение in-memory сохраняет надёжность за счёт строкового формата на диске.

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 не предлагает отдельного движка таблиц в памяти; таблица UNLOGGED пропускает запись в WAL, ускоряя запись (содержимое теряется при сбое; не надёжна). Таблицы TEMP живут в пределах сессии и по возможности держатся в памяти через temp_buffers. Горячие данные кэшируются в shared_buffers.

MySQL

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

Движок хранения MEMORY (ранее HEAP) в MySQL держит данные таблицы целиком в RAM; очень быстр, но данные теряются при перезапуске сервера (структура сохраняется). Не поддерживает BLOB/TEXT и использует фиксированный размер строки. Для надёжных горячих данных предпочтителен 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);

SQL Server In-Memory OLTP (Hekaton) обеспечивает высококонкурентный OLTP с таблицами, оптимизированными для памяти (MEMORY_OPTIMIZED=ON), и структурами без латчей. DURABILITY=SCHEMA_AND_DATA сохраняет данные надёжно; SCHEMA_ONLY сохраняет только схему. Требуется файловая группа, оптимизированная для памяти.

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 нет отдельного типа таблиц в памяти (старый In-Memory Storage Engine был только в Enterprise и объявлен устаревшим). Движок по умолчанию WiredTiger повышает скорость чтения, держа часто используемые данные и индексы в своём кэше в памяти; файловый кэш ОС тоже помогает.

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 держит все данные в RAM; это по замыслу и есть источник его скорости. Сохранность обеспечивают RDB (снимки) и/или AOF (журнал команд). Лимит maxmemory и политика вытеснения (LRU/LFU/random) определяют поведение при заполнении памяти.

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 хранит данные на диске (сегменты Lucene); отдельного движка таблиц в памяти нет. Для скорости он опирается на файловый кэш ОС (page cache), doc_values и архитектуру hot-warm-cold. Достаточный объём RAM и настройки heap критичны для производительности.

Открыть в DBAtlas →