semadb
v2.0.2
Nenhum banco de dados de vetor híbrido de múltiplos índices com confusão / mecanismo de pesquisa
O SEMADB é um banco de dados de vetor de múltiplos índices, multi-vetor, baseado em documentos / mecanismo de pesquisa. Ele foi projetado para oferecer uma API JSON RESTful clara e fácil de usar. Os componentes originais do SEMADB foram construídos para um projeto de gerenciamento de conhecimento na Semafind antes de ser desenvolvido em um projeto independente. O objetivo é fornecer um mecanismo de pesquisa simples, moderno e eficiente que possa ser usado em uma variedade de aplicações.
Procurando uma solução hospedada? O Beta do Semadb Cloud está disponível no Rapidapi.
Para começar da fonte, siga as instruções para instalar Go. Essa é a única dependência necessária para executar o semadb. Tentamos manter o Semadb o mais independente possível e atualizado com os lançamentos GO mais recentes.
O SEMADB lê toda a configuração de um arquivo YAML, existem alguns exemplos contidos na pasta config . Você pode executar um único servidor usando:
SEMADB_CONFIG=./config/singleServer.yaml go run ./Se você estiver usando o código VS como seu editor, já existem tarefas pré-fabricadas que fazem a mesma coisa, mas também iniciam um cluster localmente também no modo de depuração.
Depois de executar um servidor, você pode usar o arquivo de amostras para ver algumas solicitações de exemplo que podem ser feitas no servidor. Para aproveitar ao máximo, instale a extensão do cliente REST, que permitirá fazer solicitações diretamente no editor e mostre os resultados.
Você pode executar a versão mais recente do SEMADB usando a seguinte imagem de contêiner de repositório:
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 ghcr.io/semafind/semadb:main
# If using podman
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 ghcr.io/semafind/semadb:mainque executará o ramo principal. Também existem versões marcadas para versões específicas. Consulte o Registro de Contêineres do Repositório estável e versões prontas para a produção.
Você pode construir e executar localmente a imagem do contêiner usando:
docker build -t semadb ./
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 semadb
# If using podman
podman build -t semadb ./
# The :Z argument relabels to access: see https://github.com/containers/podman/issues/3683
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 semadb Persistência de dados: o SEMADB armazena dados em um diretório em disco especificado no arquivo de configuração como rootDir . Por padrão, o diretório de dados é ./data e o executável semadb está localizado em / devoluções /data como o ponto de montagem no contêiner.
Observe que, ao usar o Docker, o nome do host e a lista de permissões do IPS podem precisar ser ajustados, dependendo da configuração de rede do Docker. Deixando o nome do host como uma string em branco e configurando a lista de permissões para '*' abre semadb para todas as conexões, conforme feito na configuração singleServer.yaml .
As contribuições são bem -vindas! Leia o arquivo do guia contribuinte para obter mais informações. O guia contribuinte também contém informações sobre a arquitetura do SEMADB e como começar com o desenvolvimento.
O algoritmo de pesquisa vetorial principal do SEMADB é baseado nos seguintes trabalhos de pesquisa seguintes:
Outros índices, como string ou texto, seguem uma abordagem de índice invertido. O índice invertido é uma estrutura de dados que armazena um mapeamento do conteúdo, como palavras ou números, para seus locais em um arquivo de banco de dados ou em um documento ou em um conjunto de documentos. O objetivo de um índice invertido é permitir pesquisas rápidas em texto completo, pesquisas de prefixo de string, pesquisa de intervalo inteiro etc.
Semadb com valores de configuração padrão em um Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz A estação de trabalho de commodities com RAM de 16 GB atinge um bom recall em benchmarks padrão, semelhante aos resultados relatados:
| v1 | v2 | v2-pq | v2-bq | |||||
|---|---|---|---|---|---|---|---|---|
| Conjunto de dados | Lembrar | QPS | Lembrar | QPS | Lembrar | QPS | Lembrar | QPS |
| Glova-100-angular | 0,924 | 973.6 | 0,853 | 773.9 | 0,526 | 628.6 | ||
| dbpedia-openai-100k-angular | 0,990 | 519.9 | 0,920 | 240.8 | 0,766 | 978.6 | ||
| luva-25-angular | 0,999 | 1130.3 | 0,992 | 914.4 | 0,989 | 805.8 | ||
| MNIST-784-EUCLIDEAN | 0,999 | 1898.6 | 0,999 | 1267.4 | 0,928 | 571.6 | 0,667 | 2369.7 |
| NYTimes-256-angulares | 0,903 | 1020.6 | 0,891 | 786.7 | 0,438 | 983.6 | ||
| SIFT-128-EUCLIDEAN | 0,999 | 1537.7 | 0,991 | 1272.9 | 0,696 | 967.4 |
Os resultados são obtidos usando a Ann-Benchmarks. As consultas por segundo (QPs) usam o cache completo em memória com um único encadeamento semelhante a outros métodos, mas não é uma boa indicação de desempenho geral. O pipeline completo seria mais lento, devido à jornada de ponta a ponta de uma solicitação, tem a sobrecarga de manuseio, codificação, decodificação, consulta, análise, validação, roteamento de cluster, chamadas de procedimento remoto, carregando dados do disco etc. No entanto, o desempenho bruto do algoritmo de pesquisa em um único fragmento seria, em teoria, semelhante ao relatado nos trabalhos de pesquisa.
A versão 1 (v1) é a implementação original de pesquisa de vetor puro do SEMADB. A versão 2 (v2) é a implementação de pesquisa de palavras-chave, com várias índice, híbrida, de pesquisa-chave, que tem uma sobrecarga muito mais alta de decodificação, despacho dados em índices e usando quantizadores. Versão 2 com quantização do produto (V2-PQ) e quantização binária (V2-BQ) usam os respectivos métodos de quantização para reduzir o uso da memória. Esperamos que o recall seja menor porque os métodos de quantização são perdidos e a pesquisa é aproximada.
O disco frio inicia pode ser muito lento. Na parte inferior da cadeia, fica o disco onde todos os dados são armazenados. Existem dois caches em jogo: o cache na memória e o cache do arquivo do sistema operacional. O cache do sistema operacional não está sob nosso controle e é preenchido à medida que os arquivos são lidos ou gravados. Quando uma solicitação é feita, o gráfico do índice é percorrido e os pontos são carregados do disco para o cache do sistema operacional e decodificados para o conjunto de pontos na memória. A operação de pesquisa geralmente executa leituras aleatórias do disco, pois atravessa o gráfico de similaridade; Portanto, durante um começo frio, pode levar muito tempo (1 segundo, 10 segundos ou mais), dependendo do hardware. Os discos de estado sólido (SSDs) são fortemente recomendados por esse motivo, pois servem melhor leituras aleatórias. Para implantações de aplicativos únicos, isso não é uma grande preocupação, porque esperamos que uma parte dos dados / índice seja armazenada em cache na memória ou pelo sistema operacional durante a operação. Uma alternativa é usar um layout de armazenamento orientado para gráficos personalizado no disco para que os blocos / páginas estejam melhor alinhados com os vizinhos de nós no gráfico de similaridade.
Escala horizontal automática : o número de servidores no SEMADB pode ser ajustado, mas apenas sincroniza na inicialização. O hash de rendezvous usado moverá 1/n de dados para o novo servidor ou moverá os dados do servidor removido de volta para os restantes. Como isso só acontece na startup, é mais voltado para aumentar ou diminuir as implantações com antecedência do que sob carga viva. A escala automática ao vivo é complicada de executar com segurança enquanto o banco de dados está em operação devido às condições de corrida entre os servidores. Algumas armadilhas são: um servidor ficando para trás na configuração enviando dados para servidores antigos, enquanto a transferência de dados está acontecendo, as solicitações de usuário devem ser tratadas, quaisquer dados mal escalados devem, eventualmente, chegar ao servidor correto, o sistema deve se recuperar de um cenário de cérebro dividido se a rede for dividida. Muitos bancos de dados distribuídos incorporam máquinas adicionais que adicionam complexidade significativa para lidar com essas teclas de versão, relógios vetoriais etc. No momento, você pode ajustar os servidores e reiniciar o cluster para redistribuir os dados.
Sem graça alta disponibilidade : o semadb é otimizado para cargas de trabalho pesadas de pesquisa. Operações de coleta e gravação de pontos exigem todos os envolvidos (servidores que foram distribuídos dados) para participar. No caminho da pesquisa, as falhas podem ser toleradas porque é uma pesquisa estocástica e quedas ocasionais no desempenho devido a fragmentos indisponíveis podem ser aceitáveis. Nós descarregamos a manutenção de um sistema saudável nas falhas do servidor físico em uma ferramenta de orquestração de contêineres, como o Kubernetes. Assumimos que o estado configurado do Semadb será mantido ativamente e, como resultado, não contenha nenhum algoritmos de descoberta ou consenso no design. Essa escolha de design novamente simplifica a arquitetura do Semadb e ajuda com o rápido desenvolvimento. Os desenhos originais incluíam mecanismos de consenso, como a jangada, e um sistema distribuído totalmente independente com descoberta de pares, mas isso foi considerado exagero.
Existem muitos projetos de busca e mecanismo de pesquisa de vetores de código aberto. Pode ser útil comparar o semadb com alguns deles para ver se alguém se encaixa melhor no seu caso de uso:
