> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.
Habilite implementaciones multi-inquilino corrigiendo las discrepancias en los nombres de los parámetros que impiden la personalización de la cola y agregando la parametrización del espacio de claves de Cassandra.
## Contexto de la arquitectura
### Resolución de colas basada en flujos
El sistema TrustGraph utiliza una **arquitectura basada en flujos** para la resolución dinámica de colas, lo que inherentemente admite la multi-inquilinización:
Las **definiciones de flujo** se almacenan en Cassandra y especifican los nombres de las colas a través de definiciones de interfaz.
Los **nombres de las colas utilizan plantillas** con variables `{id}` que se reemplazan con los ID de las instancias de flujo.
Los **servicios resuelven dinámicamente las colas** buscando las configuraciones de flujo en el momento de la solicitud.
**Cada inquilino puede tener flujos únicos** con diferentes nombres de cola, lo que proporciona aislamiento.
**Servicios diseñados correctamente para la multi-inquilinización:**
✅ **Knowledge Management (núcleos)** - Resuelve dinámicamente las colas a partir de la configuración del flujo que se pasa en las solicitudes.
**Servicios que necesitan correcciones:**
🔴 **Config Service** - La falta de coincidencia en el nombre del parámetro impide la personalización de la cola.
🔴 **Librarian Service** - Temas de gestión de almacenamiento codificados (se discute a continuación).
🔴 **Todos los servicios** - No se puede personalizar el keyspace de Cassandra.
## Declaración del problema
### Problema #1: Falta de coincidencia en el nombre del parámetro en AsyncProcessor
**CLI define:** `--config-queue` (nombre poco claro)
**Argparse convierte a:** `config_queue` (en el diccionario de parámetros)
**El código busca:** `config_push_queue`
**Resultado:** El parámetro se ignora, por defecto a `persistent://tg/config/config`
**Impacto:** Afecta a más de 32 servicios que heredan de AsyncProcessor.
**Bloquea:** Los despliegues multi-inquilinos no pueden usar colas de configuración específicas del inquilino.
**Solución:** Cambiar el nombre del parámetro de la CLI a `--config-push-queue` para mayor claridad (el cambio importante es aceptable, ya que la función actualmente está rota).
### Problema #2: Falta de coincidencia en el nombre del parámetro en Config Service
**CLI define:** `--push-queue` (nombre ambiguo)
**Argparse convierte a:** `push_queue` (en el diccionario de parámetros)
**El código busca:** `config_push_queue`
**Resultado:** El parámetro se ignora.
**Impacto:** El servicio de configuración no puede usar una cola de envío personalizada.
**Solución:** Cambiar el nombre del parámetro de la CLI a `--config-push-queue` para mayor coherencia y claridad (el cambio importante es aceptable).
### Problema #3: Keyspace de Cassandra codificado
**Actual:** El keyspace está codificado como `"config"`, `"knowledge"`, `"librarian"` en varios servicios.
**Resultado:** No se puede personalizar el keyspace para los despliegues multi-inquilinos.
**Impacto:** Servicios de configuración, núcleos y bibliotecario.
**Bloquea:** Múltiples inquilinos no pueden usar keyspaces de Cassandra separados.
### Problema #4: Arquitectura de gestión de colecciones ✅ COMPLETADO
**Anterior:** Las colecciones se almacenaban en el keyspace de Cassandra del bibliotecario a través de una tabla de colecciones separada.
**Anterior:** El bibliotecario utilizaba 4 temas de gestión de almacenamiento codificados para coordinar la creación/eliminación de colecciones:
`vector_storage_management_topic`
`object_storage_management_topic`
`triples_storage_management_topic`
`storage_management_response_topic`
**Problemas (Resueltos):**
Los temas codificados no se podían personalizar para los despliegues multi-inquilinos.
Coordinación asíncrona compleja entre el bibliotecario y 4 o más servicios de almacenamiento.
Infraestructura de tabla y gestión de Cassandra separada.
Colas de solicitud/respuesta no persistentes para operaciones críticas.
**Solución implementada:** Se migraron las colecciones al almacenamiento del servicio de configuración, se utiliza el envío de configuración para la distribución.
**Estado:** Todos los backends de almacenamiento se han migrado al patrón `CollectionConfigHandler`.
## Solución
Esta especificación aborda los problemas #1, #2, #3 y #4.
### Parte 1: Corregir las faltas de coincidencia en el nombre del parámetro
#### Cambio 1: Clase base AsyncProcessor - Cambiar el nombre del parámetro de la CLI
### Parte 3: Migrar la gestión de colecciones al servicio de configuración
#### Resumen
Migrar las colecciones del espacio de claves de Cassandra librarian al almacenamiento del servicio de configuración. Esto elimina los temas de gestión de almacenamiento codificados de forma rígida y simplifica la arquitectura utilizando el mecanismo de envío de configuración existente para la distribución.
#### Arquitectura actual
```
API Request → Gateway → Librarian Service
↓
CollectionManager
↓
Cassandra Collections Table (librarian keyspace)
↓
Broadcast to 4 Storage Management Topics (hardcoded)
5.**Eliminar la infraestructura de administración de almacenamiento:**
Eliminar la configuración y el inicio de `self.storage_request_consumer`
Eliminar la configuración de `self.storage_response_producer`
Eliminar el método de despachador de `on_storage_management`
Eliminar las métricas para la administración de almacenamiento
Eliminar las importaciones: `StorageManagementRequest`, `StorageManagementResponse`
**Consideraciones específicas del backend:**
**Almacenes de vectores (Milvus, Pinecone, Qdrant):** Realizar un seguimiento de `(user, collection)` lógico en `known_collections`, pero puede crear múltiples colecciones de backend por dimensión. Continuar con el patrón de creación perezosa. Las operaciones de eliminación deben eliminar todas las variantes de dimensión.
**Objetos Cassandra:** Las colecciones son propiedades de fila, no estructuras. Realizar un seguimiento de la información a nivel de keyspace.
**Almacenes de grafos (Neo4j, Memgraph, FalkorDB):** Consultar nodos `CollectionMetadata` al inicio. Crear/eliminar nodos de metadatos durante la sincronización.
**Triples de Cassandra:** Utilizar la API `KnowledgeGraph` para las operaciones de colección.
**Puntos clave de diseño:**
**Consistencia eventual:** No hay mecanismo de solicitud/respuesta, el empuje de configuración se transmite.
**Idempotencia:** Todas las operaciones de creación/eliminación deben ser seguras para reintentar.
**Manejo de errores:** Registrar los errores, pero no bloquear las actualizaciones de configuración.
**Autocuración:** Las operaciones fallidas se volverán a intentar en el siguiente empuje de configuración.
**Formato de clave de colección:** `"user:collection"` en `config["collections"]`
#### Cambio 11: Actualizar el esquema de la colección: eliminar las marcas de tiempo
tables/library.py (eliminación de la tabla de colecciones)
schema/services/collection.py (eliminación de la marca de tiempo)
**Cambios Completados (Cambio 10):** ✅
Todos los servicios de almacenamiento (11 en total) - migrados a la configuración push para las actualizaciones de colecciones a través de `CollectionConfigHandler`
Esquema de gestión de almacenamiento eliminado de `storage.py`
## Consideraciones Futuras
### Modelo de Espacio de Claves por Usuario
Algunos servicios utilizan **espacios de claves por usuario** dinámicamente, donde cada usuario obtiene su propio espacio de claves de Cassandra:
**Servicios con espacios de claves por usuario:**
1.**Servicio de Consulta de Triples** (`trustgraph-flow/trustgraph/query/triples/cassandra/service.py:65`)
Utiliza `keyspace=query.user`
2.**Servicio de Consulta de Objetos** (`trustgraph-flow/trustgraph/query/objects/cassandra/service.py:479`)
Utiliza `keyspace=self.sanitize_name(user)`
3.**Acceso Directo al Gráfico de Conocimiento** (`trustgraph-flow/trustgraph/direct/cassandra_kg.py:18`)
Parámetro predeterminado `keyspace="trustgraph"`
**Estado:** Estos **no se modifican** en esta especificación.
**Revisión Futura Requerida:**
Evaluar si el modelo de espacio de claves por usuario crea problemas de aislamiento de inquilinos
Considerar si las implementaciones multi-inquilino necesitan patrones de prefijos de espacio de claves (por ejemplo, `tenant_a_user1`)
Revisar posibles colisiones de ID de usuario entre inquilinos
Evaluar si un espacio de claves compartido único por inquilino con aislamiento de filas basado en el usuario es preferible
**Nota:** Esto no bloquea la implementación multi-inquilino actual, pero debe revisarse antes de las implementaciones multi-inquilino de producción.
## Fases de Implementación
### Fase 1: Correcciones de Parámetros (Cambios 1-6)
Corregir el nombre del parámetro `--config-push-queue`
Agregar soporte para el parámetro `--cassandra-keyspace`
**Resultado:** Configuración de cola y espacio de claves multi-inquilino habilitada
### Fase 2: Migración de la Gestión de Colecciones (Cambios 7-9, 11)
Migrar el almacenamiento de colecciones al servicio de configuración
Eliminar la tabla de colecciones de librarian
Actualizar el esquema de colecciones (eliminar marcas de tiempo)
**Resultado:** Elimina la gestión de almacenamiento codificada, simplifica librarian
### Fase 3: Actualizaciones del Servicio de Almacenamiento (Cambio 10) ✅ COMPLETADO
Se actualizaron todos los servicios de almacenamiento para usar la configuración push para las colecciones a través de `CollectionConfigHandler`
Se eliminó la infraestructura de solicitud/respuesta de gestión de almacenamiento
Se eliminaron las definiciones de esquema heredadas
**Resultado:** Se logró una gestión de colecciones basada en configuración completa
## Referencias
Problema de GitHub: https://github.com/trustgraph-ai/trustgraph/issues/582