Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Vector Nexus
Vector Nexus provides a unified trait (VectorStore
) and schema definition (IndexSchema
) for interacting with various vector databases in Rust. It aims to abstract the specific implementation details of different vector stores, allowing you to switch between them more easily in your applications (like RAG engines).
Auto-Schema Generation for Vector Databases
A key feature facilitated by the VectorStore
trait is Auto-Schema Generation. This addresses the challenge of keeping the application's understanding of the database structure synchronized with the actual database.
The Problem:
RAG (Retrieval-Augmented Generation) applications often need to know the structure of the underlying vector database – specifically, the names of different data collections (like "profile", "experience", "documents") and the relevant fields within each collection (like "name", "company_name", "content", "tags"). Manually defining this structure in a configuration file (IndexSchema
) can be tedious and error-prone, especially if the database schema evolves.
The Solution: generate_schema
The VectorStore
trait includes an optional but highly recommended method:
async ;
Core Concepts
-
VectorStore
Trait: This is the central piece of the library. It defines a common interface for operations you'd typically perform on a vector database, such as:- Searching for similar vectors (e.g.,
search
,search_hybrid
). - Counting documents within a specific index/topic.
- Generating an
IndexSchema
by inspecting the database. - (Potentially others like adding, updating, deleting documents - add these if your trait defines them). You implement this trait for each specific vector database you want to support (e.g., SurrealDB, Qdrant, Redis, etc.).
- Searching for similar vectors (e.g.,
-
IndexSchema
Struct: Defines the structure of your data within a specific index or table. It typically includes:name
: The name of the index/table/collection (e.g., "profile", "documents").prefix
: A string prefix often used for namespacing keys (e.g.,surreal:profile
).fields
: A list of field names within the index that are relevant for searching or filtering (excludingid
andvector
).
Integration with db2vec
Vector Nexus is designed to work seamlessly with data prepared and exported using tools like db2vec
.
- Export Data: Use
db2vec
to export data from your source database (e.g., PostgreSQL, MySQL) into a suitable format (like JSON Lines), potentially including pre-computed vector embeddings for relevant text fields. - Load Data: Load the exported data from
db2vec
into your chosen vector database (e.g., SurrealDB, Qdrant, Redis with vector search module). Ensure the table/collection names and field names match your intended structure. - Generate Schema: After loading the data, use the
generate_schema
method provided by the specificVectorStore
implementation invector-nexus
(e.g.,SurrealVectorStore::generate_schema
). This will inspect the loaded data in the vector database and create anIndexSchema
JSON file that accurately reflects the structure (table names and fields) of your loaded data. - Use
VectorStore
: Initialize yourVectorStore
implementation (e.g.,SurrealVectorStore
) and load the generatedIndexSchema
. Your application can now use theVectorStore
trait methods (search_hybrid
,count_documents
, etc.) to interact with the data originally exported bydb2vec
.
Essentially, db2vec
prepares the data, you load it into the vector DB, and vector-nexus
provides the unified Rust interface to query that data via its VectorStore
trait and the generated IndexSchema
.
How to Implement VectorStore
To add support for a new vector database, you create a struct representing the connection/client for that database and implement the VectorStore
trait for it.
// Example for a hypothetical "MyVectorDB"
use async_trait;
use Value;
use ; // Assuming these are in the root
use Error;
// Represents connection to your specific DB
How to Use VectorStore
Once you have one or more implementations of VectorStore
, you can use them generically in your application code. This is often done by storing the specific implementation behind an Arc<dyn VectorStore>
.
use ;
use Value;
use Arc;
use Error;
// Assume MyVectorDbClient implements VectorStore
// use crate::my_vector_db::MyVectorDbClient;
async
// Example Usage (in your main or setup function)
// #[tokio::main]
// async fn main() -> Result<(), Box<dyn Error + Send + Sync>> {
// // 1. Create your specific vector store client
// let my_db_client = MyVectorDbClient::new(/* ... */)?;
//
// // 2. Put it behind an Arc<dyn VectorStore>
// let store: Arc<dyn VectorStore> = Arc::new(my_db_client);
//
// // 3. Load or generate your schemas
// let schemas: Vec<IndexSchema> = vec![/* ... load from file or generate ... */];
//
// // 4. Pass the generic store and schemas to your application logic
// run_rag(store, &schemas).await?;
//
// Ok(())
// }
This setup allows your core application logic (run_rag
in this example) to work with any vector database that has a VectorStore
implementation, simply by changing which concrete type you instantiate and wrap in the Arc
at the beginning.