Tuning
La mayoría de los workloads corren bien con defaults. Recurrir a estas perillas cuando se midió un bottleneck específico.
Cuando la latencia es el problema
-
Profilear por etapa:
Ventana de terminal export NAMIDB_PROFILE_DUMP=1Esto identifica si el tiempo está en parse, lower, optimise o execute.
-
EXPLAIN VERBOSEpara ver el plan y las estimaciones de selectividad. -
Si execute domina y el plan se ve razonable, probar factorization:
Ventana de terminal export NAMIDB_FACTORIZE=1Gran ganancia en queries con muchos paths (IC09, IC11) donde los resultados intermedios explotan bajo evaluación no factorizada.
Cuando la memoria es el problema
Limitar los caches:
export NAMIDB_ADJACENCY_BUDGET_MB=256export NAMIDB_NODE_CACHE_BUDGET_MB=256export NAMIDB_SST_CACHE_BUDGET_MB=512Los tres están acotados por evicción — nunca exceden el presupuesto.
O desactivar uno por completo:
export NAMIDB_ADJACENCY=offexport NAMIDB_NODE_CACHE=offPara el caso de uso embebido dentro de contenedores chicos / Lambdas, un perfil común es “NodeCache chico, sin SstCache, AdjacencyCache completo”.
Cuando el write throughput es el problema
-
Bulk-stage en lugar de
CREATEpor fila — usarmerge_nodes/merge_edgesdesde Python, oupsert_node/upsert_edgedesde Rust. Estos amortizan un solocommit_batch()sobre miles de filas. -
Aumentar el intervalo de flush en
namidb-serversi se hacen workloads de write en ráfaga:Ventana de terminal --flush-interval 5mMemtables más grandes → menos SSTs L0 → menos trabajo de compaction.
-
Shardear por namespace. Cada namespace tiene un solo writer. Dos workloads no relacionados sobre dos namespaces duplican el write throughput.
Cuando la latencia de cold-read es el problema
Esto está dominado por el fetch de SST desde el bucket. Opciones:
- Acercar el daemon al bucket. Misma región, misma VPC.
- Pre-calentar con una query única que toque el working set — las queries subsiguientes pegan en el SST cache.
- Subir
NAMIDB_SST_CACHE_BUDGET_MBpara que el working set entre.