mirror of
https://github.com/trustgraph-ai/trustgraph.git
synced 2026-04-26 08:56:21 +02:00
Structure the tech specs directory (#836)
Tech spec some subdirectories for different languages
This commit is contained in:
cybermaggedon
GitHub
parent
48da6c5f8b
commit
e7efb673ef
423 changed files with 0 additions and 0 deletions
410
docs/tech-specs/pt/collection-management.pt.md
Normal file
410
docs/tech-specs/pt/collection-management.pt.md
Normal file
|
|
@ -0,0 +1,410 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Especificação Técnica de Gerenciamento de Coleções"
|
||||
parent: "Portuguese (Beta)"
|
||||
---
|
||||
|
||||
# Especificação Técnica de Gerenciamento de Coleções
|
||||
|
||||
> **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.
|
||||
|
||||
## Visão Geral
|
||||
|
||||
Esta especificação descreve as capacidades de gerenciamento de coleções para o TrustGraph, exigindo a criação explícita de coleções e fornecendo controle direto sobre o ciclo de vida da coleção. As coleções devem ser criadas explicitamente antes de serem usadas, garantindo a sincronização adequada entre os metadados do bibliotecário e todos os backends de armazenamento. O recurso suporta quatro casos de uso primários:
|
||||
|
||||
1. **Criação de Coleção**: Crie explicitamente coleções antes de armazenar dados
|
||||
2. **Listagem de Coleções**: Visualize todas as coleções existentes no sistema
|
||||
3. **Gerenciamento de Metadados da Coleção**: Atualize nomes, descrições e tags de coleções
|
||||
4. **Exclusão de Coleções**: Remova coleções e seus dados associados em todos os tipos de armazenamento
|
||||
|
||||
## Objetivos
|
||||
|
||||
**Criação Explícita de Coleção**: Exigir que as coleções sejam criadas antes que os dados possam ser armazenados
|
||||
**Sincronização de Armazenamento**: Garantir que as coleções existam em todos os backends de armazenamento (vetores, objetos, triplas)
|
||||
**Visibilidade da Coleção**: Permitir que os usuários listem e inspecionem todas as coleções em seu ambiente
|
||||
**Limpeza de Coleções**: Permitir a exclusão de coleções que não são mais necessárias
|
||||
**Organização de Coleções**: Suportar rótulos e tags para melhor rastreamento e descoberta de coleções
|
||||
**Gerenciamento de Metadados**: Associar metadados significativos às coleções para clareza operacional
|
||||
**Descoberta de Coleções**: Facilitar a localização de coleções específicas por meio de filtragem e pesquisa
|
||||
**Transparência Operacional**: Fornecer visibilidade clara do ciclo de vida e do uso da coleção
|
||||
**Gerenciamento de Recursos**: Permitir a limpeza de coleções não utilizadas para otimizar a utilização de recursos
|
||||
**Integridade de Dados**: Impedir a criação de coleções órfãs no armazenamento sem rastreamento de metadados
|
||||
|
||||
## Contexto
|
||||
|
||||
Anteriormente, as coleções no TrustGraph eram criadas implicitamente durante as operações de carregamento de dados, levando a problemas de sincronização em que as coleções poderiam existir em backends de armazenamento sem metadados correspondentes no bibliotecário. Isso criava desafios de gerenciamento e dados órfãos.
|
||||
|
||||
O modelo de criação explícita de coleções aborda esses problemas:
|
||||
Exigindo que as coleções sejam criadas antes de serem usadas via `tg-set-collection`
|
||||
Transmitindo a criação da coleção para todos os backends de armazenamento
|
||||
Mantendo um estado sincronizado entre os metadados do bibliotecário e o armazenamento
|
||||
Impedindo a gravação em coleções inexistentes
|
||||
Fornecendo gerenciamento claro do ciclo de vida da coleção
|
||||
|
||||
Esta especificação define o modelo de gerenciamento explícito de coleções. Ao exigir a criação explícita de coleções, o TrustGraph garante:
|
||||
Que as coleções sejam rastreadas nos metadados do bibliotecário desde a criação
|
||||
Que todos os backends de armazenamento estejam cientes das coleções antes de receber dados
|
||||
Que não existam coleções órfãs no armazenamento
|
||||
Visibilidade e controle operacionais claros sobre o ciclo de vida da coleção
|
||||
Tratamento de erros consistente quando as operações referenciam coleções inexistentes
|
||||
|
||||
## Design Técnico
|
||||
|
||||
### Arquitetura
|
||||
|
||||
O sistema de gerenciamento de coleções será implementado dentro da infraestrutura existente do TrustGraph:
|
||||
|
||||
1. **Integração do Serviço do Bibliotecário**
|
||||
As operações de gerenciamento de coleções serão adicionadas ao serviço do bibliotecário existente
|
||||
Nenhum novo serviço é necessário - aproveita os padrões de autenticação e acesso existentes
|
||||
Lida com a listagem, exclusão e gerenciamento de metadados de coleções
|
||||
|
||||
Módulo: trustgraph-librarian
|
||||
|
||||
2. **Tabela de Metadados de Coleção do Cassandra**
|
||||
Nova tabela no keyspace existente do bibliotecário
|
||||
Armazena metadados da coleção com acesso específico ao usuário
|
||||
Chave primária: (user_id, collection_id) para multilocação adequada
|
||||
|
||||
Módulo: trustgraph-librarian
|
||||
|
||||
3. **CLI de Gerenciamento de Coleções**
|
||||
Interface de linha de comando para operações de coleção
|
||||
Fornece comandos de listagem, exclusão, rotulagem e gerenciamento de tags
|
||||
Integra-se com o framework de CLI existente
|
||||
|
||||
Módulo: trustgraph-cli
|
||||
|
||||
### Modelos de Dados
|
||||
|
||||
#### Tabela de Metadados de Coleção do Cassandra
|
||||
|
||||
Os metadados da coleção serão armazenados em uma tabela estruturada do Cassandra no keyspace do bibliotecário:
|
||||
|
||||
```sql
|
||||
CREATE TABLE collections (
|
||||
user text,
|
||||
collection text,
|
||||
name text,
|
||||
description text,
|
||||
tags set<text>,
|
||||
created_at timestamp,
|
||||
updated_at timestamp,
|
||||
PRIMARY KEY (user, collection)
|
||||
);
|
||||
```
|
||||
|
||||
Estrutura da tabela:
|
||||
**user** + **collection**: Chave primária composta que garante o isolamento do usuário
|
||||
**name**: Nome da coleção legível por humanos
|
||||
**description**: Descrição detalhada do propósito da coleção
|
||||
**tags**: Conjunto de tags para categorização e filtragem
|
||||
**created_at**: Timestamp de criação da coleção
|
||||
**updated_at**: Timestamp da última modificação
|
||||
|
||||
Esta abordagem permite:
|
||||
Gerenciamento de coleções multi-tenant com isolamento de usuário
|
||||
Consulta eficiente por usuário e coleção
|
||||
Sistema de tags flexível para organização
|
||||
Rastreamento do ciclo de vida para insights operacionais
|
||||
|
||||
#### Ciclo de Vida da Coleção
|
||||
|
||||
As coleções são explicitamente criadas no gerenciador antes que as operações de dados possam prosseguir:
|
||||
|
||||
1. **Criação da Coleção** (Dois Caminhos):
|
||||
|
||||
**Caminho A: Criação Iniciada pelo Usuário** via `tg-set-collection`:
|
||||
O usuário fornece o ID da coleção, nome, descrição e tags
|
||||
O gerenciador cria um registro de metadados na tabela `collections`
|
||||
O gerenciador transmite "create-collection" para todos os backends de armazenamento
|
||||
Todos os processadores de armazenamento criam a coleção e confirmam o sucesso
|
||||
A coleção está agora pronta para operações de dados
|
||||
|
||||
**Caminho B: Criação Automática na Submissão de Documento**:
|
||||
O usuário submete um documento especificando um ID de coleção
|
||||
O gerenciador verifica se a coleção existe na tabela de metadados
|
||||
Se não existir: O gerenciador cria metadados com valores padrão (nome=collection_id, descrição/tags vazias)
|
||||
O gerenciador transmite "create-collection" para todos os backends de armazenamento
|
||||
Todos os processadores de armazenamento criam a coleção e confirmam o sucesso
|
||||
O processamento do documento prossegue com a coleção agora estabelecida
|
||||
|
||||
Ambos os caminhos garantem que a coleção exista nos metadados do gerenciador E em todos os backends de armazenamento antes de permitir operações de dados.
|
||||
|
||||
2. **Validação de Armazenamento**: As operações de escrita validam se a coleção existe:
|
||||
Os processadores de armazenamento verificam o estado da coleção antes de aceitar escritas
|
||||
As escritas em coleções inexistentes retornam um erro
|
||||
Isso impede que as escritas contornem a lógica de criação de coleção do gerenciador
|
||||
|
||||
3. **Comportamento da Consulta**: As operações de consulta lidam com coleções inexistentes de forma elegante:
|
||||
As consultas em coleções inexistentes retornam resultados vazios
|
||||
Nenhum erro é lançado para operações de consulta
|
||||
Permite a exploração sem exigir que a coleção exista
|
||||
|
||||
4. **Atualizações de Metadados**: Os usuários podem atualizar os metadados da coleção após a criação:
|
||||
Atualize o nome, a descrição e as tags via `tg-set-collection`
|
||||
As atualizações se aplicam apenas aos metadados do gerenciador
|
||||
Os backends de armazenamento mantêm a coleção, mas as atualizações de metadados não são propagadas
|
||||
|
||||
5. **Exclusão Explícita**: Os usuários excluem coleções via `tg-delete-collection`:
|
||||
O gerenciador transmite "delete-collection" para todos os backends de armazenamento
|
||||
Aguarda a confirmação de todos os processadores de armazenamento
|
||||
Exclui o registro de metadados do gerenciador somente após a limpeza do armazenamento estar completa
|
||||
Garante que nenhum dado órfão permaneça no armazenamento
|
||||
|
||||
**Princípio Chave**: O gerenciador é o ponto de controle único para a criação de coleções. Seja iniciada por um comando do usuário ou pela submissão de um documento, o gerenciador garante o rastreamento adequado de metadados e a sincronização do backend de armazenamento antes de permitir operações de dados.
|
||||
|
||||
Operações necessárias:
|
||||
**Criar Coleção**: Operação do usuário via `tg-set-collection` OU automática na submissão de documento
|
||||
**Atualizar Metadados da Coleção**: Operação do usuário para modificar o nome, a descrição e as tags
|
||||
**Excluir Coleção**: Operação do usuário para remover a coleção e seus dados em todos os armazenamentos
|
||||
**Listar Coleções**: Operação do usuário para visualizar coleções com filtragem por tags
|
||||
|
||||
#### Gerenciamento de Coleções em Múltiplos Armazenamentos
|
||||
|
||||
As coleções existem em vários backends de armazenamento no TrustGraph:
|
||||
**Vector Stores** (Qdrant, Milvus, Pinecone): Armazena embeddings e dados vetoriais
|
||||
**Object Stores** (Cassandra): Armazena documentos e dados de arquivos
|
||||
**Triple Stores** (Cassandra, Neo4j, Memgraph, FalkorDB): Armazena dados de grafo/RDF
|
||||
|
||||
Cada tipo de armazenamento implementa:
|
||||
**Rastreamento do Estado da Coleção**: Manter o conhecimento de quais coleções existem
|
||||
**Criação de Coleção**: Aceitar e processar operações de "criar-coleção"
|
||||
**Validação de Coleção**: Verificar se a coleção existe antes de aceitar gravações
|
||||
**Exclusão de Coleção**: Remover todos os dados para a coleção especificada
|
||||
|
||||
O serviço de bibliotecário coordena as operações de coleção em todos os tipos de armazenamento, garantindo:
|
||||
Que as coleções sejam criadas em todos os backends antes de serem usadas
|
||||
Que todos os backends confirmem a criação antes de retornar o sucesso
|
||||
Ciclo de vida da coleção sincronizado em todos os tipos de armazenamento
|
||||
Tratamento de erros consistente quando as coleções não existem
|
||||
|
||||
#### Rastreamento do Estado da Coleção por Tipo de Armazenamento
|
||||
|
||||
Cada backend de armazenamento rastreia o estado da coleção de forma diferente, com base em suas capacidades:
|
||||
|
||||
**Cassandra Triple Store:**
|
||||
Usa a tabela `triples_collection` existente
|
||||
Cria um triple de marcador do sistema quando a coleção é criada
|
||||
Consulta: `SELECT collection FROM triples_collection WHERE collection = ? LIMIT 1`
|
||||
Verificação de existência de coleção eficiente de partição única
|
||||
|
||||
**Qdrant/Milvus/Pinecone Vector Stores:**
|
||||
As APIs nativas de coleção fornecem verificação de existência
|
||||
Coleções criadas com configuração de vetor adequada
|
||||
O método `collection_exists()` usa a API de armazenamento
|
||||
A criação da coleção valida os requisitos de dimensão
|
||||
|
||||
**Neo4j/Memgraph/FalkorDB Graph Stores:**
|
||||
Usa nós `:CollectionMetadata` para rastrear coleções
|
||||
Propriedades do nó: `{user, collection, created_at}`
|
||||
Consulta: `MATCH (c:CollectionMetadata {user: $user, collection: $collection})`
|
||||
Separado de nós de dados para uma separação limpa
|
||||
Permite listagem e validação eficientes de coleções
|
||||
|
||||
**Cassandra Object Store:**
|
||||
Usa a tabela de metadados da coleção ou linhas de marcador
|
||||
Padrão semelhante ao triple store
|
||||
Valida a coleção antes das gravações de documentos
|
||||
|
||||
### APIs
|
||||
|
||||
APIs de Gerenciamento de Coleção (Bibliotecário):
|
||||
**Criar/Atualizar Coleção**: Criar uma nova coleção ou atualizar metadados existentes via `tg-set-collection`
|
||||
**Listar Coleções**: Recuperar coleções para um usuário com filtragem opcional por tag
|
||||
**Excluir Coleção**: Remover a coleção e os dados associados, propagando para todos os tipos de armazenamento
|
||||
|
||||
APIs de Gerenciamento de Armazenamento (Todos os Processadores de Armazenamento):
|
||||
**Criar Coleção**: Lidar com a operação de "criar-coleção", estabelecer a coleção no armazenamento
|
||||
**Excluir Coleção**: Lidar com a operação de "excluir-coleção", remover todos os dados da coleção
|
||||
**Verificação de Existência da Coleção**: Validação interna antes de aceitar operações de gravação
|
||||
|
||||
APIs de Operação de Dados (Comportamento Modificado):
|
||||
**APIs de Gravação**: Validar se a coleção existe antes de aceitar dados, retornar um erro se não existir
|
||||
**APIs de Consulta**: Retornar resultados vazios para coleções inexistentes sem erro
|
||||
|
||||
### Detalhes de Implementação
|
||||
|
||||
A implementação seguirá os padrões existentes do TrustGraph para integração de serviços e estrutura de comandos de linha de comando.
|
||||
|
||||
#### Exclusão em Cadeia de Coleção
|
||||
|
||||
Quando um usuário inicia a exclusão de uma coleção por meio do serviço de bibliotecário:
|
||||
|
||||
1. **Validação de Metadados**: Verificar se a coleção existe e se o usuário tem permissão para excluí-la
|
||||
2. **Propagação para o Armazenamento**: O bibliotecário coordena a exclusão em todos os escritores de armazenamento:
|
||||
Escritor de armazenamento vetorial: Remover incorporações e índices de vetor para o usuário e a coleção
|
||||
Escritor de armazenamento de objetos: Remover documentos e arquivos para o usuário e a coleção
|
||||
Escritor de triple store: Remover dados de grafo e triples para o usuário e a coleção
|
||||
3. **Limpeza de Metadados**: Remover o registro de metadados da coleção do Cassandra
|
||||
4. **Tratamento de Erros**: Se alguma exclusão de armazenamento falhar, manter a consistência por meio de mecanismos de reversão ou repetição
|
||||
|
||||
#### Interface de Gerenciamento de Coleção
|
||||
|
||||
**⚠️ ABORDAGEM ANTIGA - SUBSTITUÍDA POR PADRÃO BASEADO EM CONFIGURAÇÃO**
|
||||
|
||||
A arquitetura baseada em fila descrita abaixo foi substituída por uma abordagem baseada em configuração usando `CollectionConfigHandler`. Todos os backends de armazenamento agora recebem atualizações de coleção por meio de mensagens de configuração em vez de filas de gerenciamento dedicadas.
|
||||
|
||||
~~Todos os escritores de armazenamento implementam uma interface de gerenciamento de coleção padronizada com um esquema comum:~~
|
||||
|
||||
~~**Esquema de Mensagem (`StorageManagementRequest`):**~~
|
||||
```json
|
||||
{
|
||||
"operation": "create-collection" | "delete-collection",
|
||||
"user": "user123",
|
||||
"collection": "documents-2024"
|
||||
}
|
||||
```
|
||||
|
||||
~~**Arquitetura de Filas:**~~
|
||||
~~**Fila de Gerenciamento de Vetores** (`vector-storage-management`): Armazenamentos de vetores/embeddings~~
|
||||
~~**Fila de Gerenciamento de Objetos** (`object-storage-management`): Armazenamentos de objetos/documentos~~
|
||||
~~**Fila de Gerenciamento de Triplas** (`triples-storage-management`): Armazenamentos de grafos/RDF~~
|
||||
~~**Fila de Resposta de Armazenamento** (`storage-management-response`): Todas as respostas são enviadas aqui~~
|
||||
|
||||
**Implementação Atual:**
|
||||
|
||||
Todos os backends de armazenamento agora usam `CollectionConfigHandler`:
|
||||
**Integração de Configuração Push**: Os serviços de armazenamento se registram para notificações de configuração push
|
||||
**Sincronização Automática**: Coleções criadas/excluídas com base em alterações de configuração
|
||||
**Modelo Declarativo**: Coleções definidas no serviço de configuração, os backends sincronizam para corresponder
|
||||
**Sem Requisição/Resposta**: Elimina a sobrecarga de coordenação e o rastreamento de respostas
|
||||
**Rastreamento do Estado da Coleção**: Mantido via cache `known_collections`
|
||||
**Operações Idempotentes**: É seguro processar a mesma configuração várias vezes
|
||||
|
||||
Cada backend de armazenamento implementa:
|
||||
`create_collection(user: str, collection: str, metadata: dict)` - Criar estruturas de coleção
|
||||
`delete_collection(user: str, collection: str)` - Remover todos os dados da coleção
|
||||
`collection_exists(user: str, collection: str) -> bool` - Validar antes de gravar
|
||||
|
||||
#### Refatoração do Armazenamento de Triplas Cassandra
|
||||
|
||||
Como parte desta implementação, o armazenamento de triplas Cassandra será refatorado de um modelo de tabela por coleção para um modelo de tabela unificada:
|
||||
|
||||
**Arquitetura Atual:**
|
||||
Keyspace por usuário, tabela separada por coleção
|
||||
Esquema: `(s, p, o)` com `PRIMARY KEY (s, p, o)`
|
||||
Nomes de tabela: coleções de usuários se tornam tabelas Cassandra separadas
|
||||
|
||||
**Nova Arquitetura:**
|
||||
Keyspace por usuário, tabela única "triples" para todas as coleções
|
||||
Esquema: `(collection, s, p, o)` com `PRIMARY KEY (collection, s, p, o)`
|
||||
Isolamento de coleção por meio de particionamento de coleção
|
||||
|
||||
**Alterações Necessárias:**
|
||||
|
||||
1. **Refatoração da Classe TrustGraph** (`trustgraph/direct/cassandra.py`):
|
||||
Remover o parâmetro `table` do construtor, usar a tabela "triples" fixa
|
||||
Adicionar o parâmetro `collection` a todos os métodos
|
||||
Atualizar o esquema para incluir a coleção como a primeira coluna
|
||||
**Atualizações de Índice**: Novos índices serão criados para suportar todos os 8 padrões de consulta:
|
||||
Índice em `(s)` para consultas baseadas em sujeito
|
||||
Índice em `(p)` para consultas baseadas em predicado
|
||||
Índice em `(o)` para consultas baseadas em objeto
|
||||
Observação: O Cassandra não suporta índices secundários multi-coluna, portanto, estes são índices de coluna única
|
||||
|
||||
**Desempenho do Padrão de Consulta:**
|
||||
✅ `get_all()` - varredura de partição em `collection`
|
||||
✅ `get_s(s)` - usa a chave primária de forma eficiente (`collection, s`)
|
||||
✅ `get_p(p)` - usa `idx_p` com filtragem `collection`
|
||||
✅ `get_o(o)` - usa `idx_o` com filtragem `collection`
|
||||
✅ `get_sp(s, p)` - usa a chave primária de forma eficiente (`collection, s, p`)
|
||||
⚠️ `get_po(p, o)` - requer `ALLOW FILTERING` (usa `idx_p` ou `idx_o` mais filtragem)
|
||||
✅ `get_os(o, s)` - usa `idx_o` com filtragem adicional em `s`
|
||||
✅ `get_spo(s, p, o)` - usa toda a chave primária de forma eficiente
|
||||
|
||||
**Observação sobre ALLOW FILTERING**: O padrão de consulta `get_po` requer `ALLOW FILTERING`, pois precisa tanto de restrições de predicado quanto de objeto sem um índice composto adequado. Isso é aceitável, pois este padrão de consulta é menos comum do que as consultas baseadas em sujeito no uso típico de armazenamentos de triplas.
|
||||
|
||||
2. **Atualizações do Gravador de Armazenamento** (`trustgraph/storage/triples/cassandra/write.py`):
|
||||
Manter uma única conexão TrustGraph por usuário em vez de por (usuário, coleção)
|
||||
Passar a coleção para as operações de inserção
|
||||
Melhor utilização de recursos com menos conexões
|
||||
|
||||
3. **Atualizações do Serviço de Consulta** (`trustgraph/query/triples/cassandra/service.py`):
|
||||
Uma única conexão TrustGraph por usuário
|
||||
Passar a coleção para todas as operações de consulta
|
||||
Manter a mesma lógica de consulta com o parâmetro de coleção
|
||||
|
||||
**Benefícios:**
|
||||
**Exclusão Simplificada de Coleções**: Excluir usando a chave de partição `collection` em todas as 4 tabelas
|
||||
**Eficiência de Recursos**: Menos conexões de banco de dados e objetos de tabela
|
||||
**Operações entre Coleções**: Mais fácil de implementar operações que abrangem várias coleções
|
||||
**Arquitetura Consistente**: Alinha-se com a abordagem unificada de metadados de coleção
|
||||
**Validação de Coleção**: Fácil de verificar a existência da coleção via tabela `triples_collection`
|
||||
|
||||
As operações de coleção serão atômicas sempre que possível e fornecerão tratamento de erros e validação apropriados.
|
||||
|
||||
## Considerações de Segurança
|
||||
|
||||
As operações de gerenciamento de coleção requerem autorização apropriada para evitar acesso ou exclusão não autorizados de coleções. O controle de acesso estará alinhado com os modelos de segurança TrustGraph existentes.
|
||||
|
||||
## Considerações de Desempenho
|
||||
|
||||
As operações de listagem de coleções podem precisar de paginação para ambientes com um grande número de coleções. As consultas de metadados devem ser otimizadas para padrões de filtragem comuns.
|
||||
|
||||
## Estratégia de Testes
|
||||
|
||||
Os testes abrangentes cobrirão:
|
||||
Fluxo de trabalho de criação de coleção de ponta a ponta
|
||||
Sincronização do armazenamento de back-end
|
||||
Validação de gravação para coleções inexistentes
|
||||
Tratamento de consultas para coleções inexistentes
|
||||
Exclusão de coleção em cascata em todos os armazenamentos
|
||||
Cenários de tratamento de erros e recuperação
|
||||
Testes unitários para cada armazenamento de back-end
|
||||
Testes de integração para operações entre armazenamentos
|
||||
|
||||
## Status da Implementação
|
||||
|
||||
### ✅ Componentes Concluídos
|
||||
|
||||
1. **Serviço de Gerenciamento de Coleção Librarian** (`trustgraph-flow/trustgraph/librarian/collection_manager.py`)
|
||||
Operações CRUD de metadados de coleção (listagem, atualização, exclusão)
|
||||
Integração da tabela de metadados de coleção do Cassandra via `LibraryTableStore`
|
||||
Coordenação da exclusão de coleção em cascata em todos os tipos de armazenamento
|
||||
Tratamento de solicitações/respostas assíncronas com gerenciamento de erros adequado
|
||||
|
||||
2. **Esquema de Metadados de Coleção** (`trustgraph-base/trustgraph/schema/services/collection.py`)
|
||||
Esquemas `CollectionManagementRequest` e `CollectionManagementResponse`
|
||||
Esquema `CollectionMetadata` para registros de coleção
|
||||
Definições de tópicos de fila de solicitações/respostas de coleção
|
||||
|
||||
3. **Esquema de Gerenciamento de Armazenamento** (`trustgraph-base/trustgraph/schema/services/storage.py`)
|
||||
Esquemas `StorageManagementRequest` e `StorageManagementResponse`
|
||||
Tópicos de fila de gerenciamento de armazenamento definidos
|
||||
Formato de mensagem para operações de coleção no nível do armazenamento
|
||||
|
||||
4. **Esquema de 4 Tabelas do Cassandra** (`trustgraph-flow/trustgraph/direct/cassandra_kg.py`)
|
||||
Chaves de partição compostas para desempenho da consulta
|
||||
Tabela `triples_collection` para consultas SPO e rastreamento de exclusão
|
||||
Exclusão de coleção implementada com o padrão de leitura e exclusão
|
||||
|
||||
### ✅ Migração para Padrão Baseado em Configuração - CONCLUÍDO
|
||||
|
||||
**Todos os armazenamentos de back-end foram migrados do padrão baseado em fila para o padrão baseado em configuração `CollectionConfigHandler`.**
|
||||
|
||||
Migrações concluídas:
|
||||
✅ `trustgraph-flow/trustgraph/storage/triples/cassandra/write.py`
|
||||
✅ `trustgraph-flow/trustgraph/storage/triples/neo4j/write.py`
|
||||
✅ `trustgraph-flow/trustgraph/storage/triples/memgraph/write.py`
|
||||
✅ `trustgraph-flow/trustgraph/storage/triples/falkordb/write.py`
|
||||
✅ `trustgraph-flow/trustgraph/storage/doc_embeddings/qdrant/write.py`
|
||||
✅ `trustgraph-flow/trustgraph/storage/graph_embeddings/qdrant/write.py`
|
||||
✅ `trustgraph-flow/trustgraph/storage/doc_embeddings/milvus/write.py`
|
||||
✅ `trustgraph-flow/trustgraph/storage/graph_embeddings/milvus/write.py`
|
||||
✅ `trustgraph-flow/trustgraph/storage/doc_embeddings/pinecone/write.py`
|
||||
✅ `trustgraph-flow/trustgraph/storage/graph_embeddings/pinecone/write.py`
|
||||
✅ `trustgraph-flow/trustgraph/storage/objects/cassandra/write.py`
|
||||
|
||||
Todos os backends agora:
|
||||
Herdam de `CollectionConfigHandler`
|
||||
Registram-se para notificações de push de configuração via `self.register_config_handler(self.on_collection_config)`
|
||||
Implementam `create_collection(user, collection, metadata)` e `delete_collection(user, collection)`
|
||||
Usam `collection_exists(user, collection)` para validar antes de gravar
|
||||
Sincronizam automaticamente com as alterações do serviço de configuração
|
||||
|
||||
Infraestrutura baseada em fila herdada removida:
|
||||
✅ Esquemas `StorageManagementRequest` e `StorageManagementResponse` removidos
|
||||
✅ Definições de tópicos de fila de gerenciamento de armazenamento removidas
|
||||
✅ Consumidor/produtor de gerenciamento de armazenamento removido de todos os backends
|
||||
✅ Manipuladores `on_storage_management` removidos de todos os backends
|
||||
Loading…
Add table
Add a link
Reference in a new issue