Saltearse al contenido
NamiDB NamiDB

Filesystem local (file://)

Para desarrollo, despliegues de una sola máquina y fixtures de CI.

import namidb as tg


client = tg.Client("file:///var/lib/namidb?ns=prod")


# Los paths relativos también funcionan:
client = tg.Client("file://./data?ns=dev")

Cómo funciona CAS en un filesystem

NamiDB implementa CAS del manifest sobre un filesystem local vía:

  • flock(2) por namespace para la serialización del lado de write
  • rename(2) atómico para el swap del manifest

Esto pasa la misma suite de tests de concurrencia que s3://. Single-writer-per-namespace + epoch fencing aplica de forma idéntica.

Cuándo usarlo

  • Fixtures de CI — durable, sin red, rápido.
  • Producción de una sola máquina — cuando “todos mis datos entran en un disco y un proceso” es la forma correcta.
  • Desarrollo local — cuando se quiere testear el ciclo completo de LSM (flush, compaction, vida de snapshot) sin levantar MinIO.

Layout en disco

/var/lib/namidb/{namespace}/
├── manifest.json
├── manifest.lock      ← target de flock
├── wal/
└── sst/

Se puede hacer aws s3 sync entre paths file:// y s3:// para migrar.

Qué se resigna

  • Durabilidad más allá del disco. Sin replicación, sin multi-AZ, sin versioning. Lo que el filesystem y la estrategia de backup den, eso es lo que NamiDB da.
  • Lecturas multi-máquina. Un namespace file:// lo posee un solo host. Dos hosts montando el mismo path NFS / EFS no están soportados (las semánticas de flock de NFS no son lo suficientemente estrictas).

Ver también