Saltearse al contenido
NamiDB NamiDB

Caches

NamiDB distribuye tres caches process-wide que comparten datos entre snapshots. Los tres son Arc-shared y tienen presupuesto por bytes.

CacheQué contieneRFCVariable de entorno
AdjacencyCacheArrays de CSR adjacency por SST de aristasRFC-018NAMIDB_ADJACENCY
NodeViewCacheLookups de NodeView decodificado (id → label, props)RFC-019NAMIDB_NODE_CACHE
SstCacheCuerpo de SST decodificado + streams de propiedades de aristas + EdgeSstReader parseadoRFC-020NAMIDB_SST_CACHE

Los tres están ON por defecto. Para deshabilitarlos, poner la variable de entorno en 0 o off.

Por qué cross-snapshot

Un workload de escritura long-running produce una nueva versión del manifest en cada commit. Sin caches cross-snapshot, cada transición de snapshot invalidaría el cache entero y volvería a pagar el costo de decode.

Los caches de NamiDB están keyados por el SST id inmutable, no por el snapshot. Mientras un SST esté referenciado por algún snapshot vivo, sus artefactos decodificados se quedan en cache.

Dimensionamiento

Los presupuestos por defecto están tuneados para una “laptop cómoda”: ~512 MiB por cache. Para workloads de servidor, subirlos:

Ventana de terminal
export NAMIDB_ADJACENCY_BUDGET_MB=4096
export NAMIDB_NODE_CACHE_BUDGET_MB=2048
export NAMIDB_SST_CACHE_BUDGET_MB=8192

Para uso embebido, quizás convenga hacerlos más chicos — todos están acotados por evicción.

Observabilidad

El cliente de Python expone:

print(client.cache_stats())
# {
#   "adjacency": {"hits": ..., "misses": ..., "bytes": ...},
#   "node_view": {...},
#   "sst":       {...}
# }

Conectar esto a los dashboards para detectar mismatches de working set vs presupuesto.

Hybrid cache (opcional)

NamiDB embebe foyer para un tier opcional de memoria + NVMe — mantiene el working set caliente en RAM y derrama las páginas tibias a NVMe local. Útil cuando los round-trips al bucket son lentos (cross-region) o caros (fees de egress).

Ver también