Truke KF se ejecuta como un único proceso autocontenido. Los dos componentes que determinan el dimensionado del hardware son la base de datos (SQLite) y el servidor web (HTTP en Go).
KF almacena todos los ítems, relaciones y documentos en un único fichero SQLite. Los siguientes ajustes se aplican al arrancar y determinan el perfil de memoria y de E/S:
| Ajuste | Valor | Efecto |
|---|---|---|
journal_mode | WAL | Lecturas concurrentes mientras hay una escritura en curso |
mmap_size | 1 GB | Mapea la base de datos en el espacio de direcciones virtual; evita la sobrecarga de llamadas al sistema en las lecturas |
cache_size | 64 MB | Caché de páginas en el proceso |
page_size | 32 KB | Las páginas grandes reducen la profundidad del árbol en almacenes grandes |
synchronous | NORMAL | Duradero ante un corte de corriente; más rápido que FULL |
Los ítems se almacenan como OGDL binario y no como texto UTF-8: filas más pequeñas y más objetos alojados dentro de una misma página.
La tabla log es WITHOUT ROWID, lo que reduce una búsqueda a un único recorrido de
árbol B en lugar de dos. Eso solo es seguro porque KF usa UUID v7: su prefijo
ordenado en el tiempo hace que las inserciones sean monótonas y evita las divisiones de
página que provocarían claves UUID v4 aleatorias con el mismo diseño.
La búsqueda a texto completo usa el motor FTS5 de SQLite con ordenación BM25. Las actualizaciones del índice las escribe de forma asíncrona un proceso en segundo plano —una cola con capacidad para 4 096 entradas, agrupadas en lotes de hasta 200 actualizaciones por transacción y volcadas al menos cada 200 ms—, de modo que las ráfagas de escritura no bloquean la interfaz. Si la cola llegara a llenarse, la escritura pasa a actualizar el índice de forma síncrona en lugar de descartarlo.
Las escrituras se serializan mediante un único mutex. Las lecturas son concurrentes y se benefician directamente de la E/S mapeada en memoria y de la caché de páginas.
El servidor incluye dos herramientas:
dbtext2bin migra una base de datos creada antes del cambio a OGDL binario.
Escribe un fichero nuevo y nunca modifica el original.dbwal realiza un checkpoint TRUNCATE, plegando el registro de escritura
anticipada dentro del fichero principal para que la base de datos pueda enviarse o
archivarse como un único .db.| Ítems | Resultado | Hardware de prueba |
|---|---|---|
| 100 000 | Rápido — sin retardo perceptible | i5-9400 @ 2,9 GHz, 32 GB RAM, SSD NVMe |
| 1 000 000 | Utilizable — algunas operaciones notablemente lentas | el mismo |
La ralentización con 1 M de ítems se concentra en los recorridos de árbol completo y en la búsqueda BM25 sobre el índice completo. Las lecturas y escrituras a nivel de ítem siguen siendo rápidas a esa escala.
El servidor HTTP de Go crea una gorutina (~4 KB de pila) por petición y no mantiene un hilo por petición. El almacén de sesiones en memoria admite hasta 10 000 sesiones. Una caché de resultados de consulta (hasta 10 000 entradas, TTL de 60 segundos) protege a la base de datos de lecturas idénticas repetidas.
Para un producto de gestión del conocimiento usado por un equipo de ingeniería, la carga es intensiva en lectura: la mayoría de los usuarios navegan por ítems y documentos a la vez, mientras que las escrituras (editar ítems, añadir acciones) son ocasionales. Con ese perfil, el servidor web no es el cuello de botella — el límite práctico de rendimiento en escritura es el bloqueo de escritor único de SQLite.
Estimación aproximada de usuarios concurrentes sostenibles en el hardware recomendado con un almacén de 100 K ítems:
| Carga de trabajo | Usuarios concurrentes |
|---|---|
| Solo lectura (navegación, búsqueda) | 100 – 200 |
| Mixta lectura/escritura (edición activa) | 20 – 50 |
Son estimaciones de orden de magnitud. Las cifras reales dependen del tamaño de los ítems, de la longitud de los documentos y de la frecuencia de las consultas de búsqueda.
| Escenario | CPU | RAM | Almacenamiento |
|---|---|---|---|
| Evaluación / equipo pequeño (≤ 10 K ítems) | Cualquier doble núcleo | 4 GB | Cualquier SSD |
| Equipo en producción (≤ 100 K ítems, ≤ 50 usuarios) | 4 núcleos, 2,5 GHz+ | 8 GB | SSD |
| Almacén grande (≤ 500 K ítems, ≤ 100 usuarios) | 8 núcleos | 16 GB | SSD NVMe |
| Almacén muy grande (≥ 1 M ítems) | 8 núcleos o más | 32 GB | SSD NVMe |
La RAM es la dimensión más importante. La ventana de 1 GB de mmap_size significa
que un almacén de hasta ~1 GB cabe entero en memoria virtual; más RAM permite al sistema
operativo mantener esas páginas calientes y evita releer del disco. Para almacenes
mayores que la RAM disponible, un disco NVMe rápido pasa a ser crítico.
La CPU importa para la búsqueda BM25 a gran escala y para atender peticiones concurrentes, pero rara vez es el primer cuello de botella.
El almacenamiento debe ser siempre SSD. El modo WAL de KF emite escrituras pequeñas y frecuentes (anexado de tramas WAL y checkpoints periódicos); los discos mecánicos introducen una latencia que afecta directamente al tiempo de respuesta en escritura.
KF funciona en Linux, Windows y macOS. Para despliegues en producción se recomienda
Linux: el rendimiento de mmap de SQLite es mejor en Linux, y las herramientas de
aislamiento y monitorización de procesos (systemd, cgroups) están más maduras.