Livello di coerenza

Come database vettoriale distribuito, Milvus offre diversi livelli di consistenza per garantire che ogni nodo o replica possa accedere agli stessi dati durante le operazioni di lettura e scrittura. Attualmente i livelli di consistenza supportati sono Strong, Bounded, Eventually e Session, con Bounded come livello di consistenza predefinito.

Panoramica

Milvus è un sistema che separa l'archiviazione dal calcolo. In questo sistema, i DataNode sono responsabili della persistenza dei dati e li memorizzano in uno storage distribuito di oggetti, come MinIO/S3. I QueryNode gestiscono attività di calcolo come la ricerca. Queste attività comportano l'elaborazione di dati batch e di dati in streaming. In parole povere, i dati batch possono essere intesi come dati che sono già stati memorizzati nello storage a oggetti, mentre i dati in streaming si riferiscono a dati che non sono ancora stati memorizzati nello storage a oggetti. A causa della latenza di rete, i QueryNode spesso non dispongono dei dati di streaming più recenti. Senza ulteriori salvaguardie, l'esecuzione della ricerca direttamente sui dati in streaming può comportare la perdita di molti punti di dati non impegnati, compromettendo l'accuratezza dei risultati della ricerca.

Milvus Commercial Edition è un sistema che separa l'archiviazione dal calcolo. In questo sistema, i DataNodes sono responsabili della persistenza dei dati e li memorizzano in uno storage a oggetti distribuito, come MinIO/S3. I QueryNode gestiscono attività di calcolo come la ricerca. Queste attività comportano l'elaborazione di dati batch e di dati in streaming. In parole povere, i dati batch possono essere intesi come dati che sono già stati memorizzati nello storage a oggetti, mentre i dati in streaming si riferiscono a dati che non sono ancora stati memorizzati nello storage a oggetti. A causa della latenza di rete, i QueryNode spesso non dispongono dei dati di streaming più recenti. Senza ulteriori salvaguardie, l'esecuzione della ricerca direttamente sui dati in streaming può comportare la perdita di molti punti di dati non impegnati, compromettendo l'accuratezza dei risultati della ricerca.

Dati batch e dati in streaming

Come mostrato nella figura precedente, i QueryNode possono ricevere contemporaneamente dati in streaming e dati batch dopo aver ricevuto una richiesta di ricerca. Tuttavia, a causa della latenza della rete, i dati in streaming ottenuti dai QueryNodes possono essere incompleti.

Per ovviare a questo problema, Milvus marca il tempo di ogni record nella coda di dati e inserisce continuamente i timestamp di sincronizzazione nella coda di dati. Ogni volta che viene ricevuto un timestamp di sincronizzazione (syncTs), QueryNodes lo imposta come ServiceTime, il che significa che QueryNodes può vedere tutti i dati precedenti a quel Service Time. Sulla base del ServiceTime, Milvus può fornire timestamp di garanzia (GuaranteeTs) per soddisfare le diverse esigenze degli utenti in termini di coerenza e disponibilità. Gli utenti possono informare i QueryNodes della necessità di includere nell'ambito di ricerca i dati precedenti a un determinato momento, specificando i GuaranteeT nelle loro richieste di ricerca.

ServiceTime e GuaranteeTs

Come mostrato nella figura precedente, se GuaranteeTs è inferiore a ServiceTime, significa che tutti i dati precedenti al momento specificato sono stati completamente scritti su disco, consentendo ai QueryNodes di eseguire immediatamente l'operazione di ricerca. Quando GuaranteeTs è maggiore di ServiceTime, i QueryNodes devono aspettare che ServiceTime superi GuaranteeTs prima di poter eseguire l'operazione di ricerca.

Gli utenti devono trovare un compromesso tra l'accuratezza della query e la sua latenza. Se gli utenti hanno requisiti di coerenza elevati e non sono sensibili alla latenza delle query, possono impostare GuaranteeTs su un valore il più grande possibile; se gli utenti desiderano ricevere rapidamente i risultati della ricerca e sono più tolleranti nei confronti dell'accuratezza delle query, allora GuaranteeTs può essere impostato su un valore inferiore.

Livelli di coerenza illustrati

Milvus offre quattro tipi di livelli di consistenza con diverse GaranzieT.

• Forte

  L'ultimo timestamp viene utilizzato come GuaranteeTs e i QueryNode devono attendere che il ServiceTime soddisfi il GuaranteeTs prima di eseguire le richieste di ricerca.

• Eventuale

  Il GuaranteeTs è impostato su un valore estremamente basso, ad esempio 1, per evitare i controlli di coerenza, in modo che i QueryNode possano eseguire immediatamente le richieste di ricerca su tutti i dati del batch.

• Stallo limitato

  GuranteeTs è impostato su un punto precedente all'ultimo timestamp per far sì che i QueryNodes eseguano ricerche con una certa tolleranza di perdita di dati.

• Sessione

  L'ultimo momento in cui il client inserisce i dati viene utilizzato come GuaranteeTs in modo che i QueryNodes possano eseguire ricerche su tutti i dati inseriti dal client.

Milvus utilizza Bounded Staleness come livello di consistenza predefinito. Se il livello di garanzia non è specificato, viene utilizzato come livello di garanzia l'ultimo ServiceTime.

Impostazione del livello di consistenza

È possibile impostare diversi livelli di consistenza quando si crea una raccolta e quando si eseguono ricerche e query.

Impostazione del livello di consistenza alla creazione di una raccolta

Quando si crea una raccolta, è possibile impostare il livello di consistenza per le ricerche e le query all'interno della raccolta. L'esempio di codice seguente imposta il livello di coerenza su Strong.

client.create_collection(
    collection_name="my_collection",
    schema=schema,
    # highlight-next
    consistency_level="Strong",
)

CreateCollectionReq createCollectionReq = CreateCollectionReq.builder()
        .collectionName("my_collection")
        .collectionSchema(schema)
        // highlight-next
        .consistencyLevel(ConsistencyLevel.STRONG)
        .build();
client.createCollection(createCollectionReq);

export schema='{
        "autoId": true,
        "enabledDynamicField": false,
        "fields": [
            {
                "fieldName": "my_id",
                "dataType": "Int64",
                "isPrimary": true
            },
            {
                "fieldName": "my_vector",
                "dataType": "FloatVector",
                "elementTypeParams": {
                    "dim": "5"
                }
            },
            {
                "fieldName": "my_varchar",
                "dataType": "VarChar",
                "isClusteringKey": true,
                "elementTypeParams": {
                    "max_length": 512
                }
            }
        ]
    }'

export params='{
    "consistencyLevel": "Strong"
}'

curl --request POST \
--url "${CLUSTER_ENDPOINT}/v2/vectordb/collections/create" \
--header "Authorization: Bearer ${TOKEN}" \
--header "Content-Type: application/json" \
-d "{
    \"collectionName\": \"my_collection\",
    \"schema\": $schema,
    \"params\": $params
}"

I valori possibili per il parametro consistency_level sono Strong, Bounded, Eventually e Session.

Impostare il livello di consistenza nella ricerca

È sempre possibile modificare il livello di coerenza per una ricerca specifica. L'esempio di codice seguente riporta il livello di consistenza a Bounded. La modifica si applica solo alla richiesta di ricerca corrente.

res = client.search(
    collection_name="my_collection",
    data=[query_vector],
    limit=3,
    search_params={"metric_type": "IP"}，
    # highlight-start
    consistency_level="Bounded",
    # highlight-next
)

SearchReq searchReq = SearchReq.builder()
        .collectionName("my_collection")
        .data(Collections.singletonList(queryVector))
        .topK(3)
        .searchParams(params)
        .consistencyLevel(ConsistencyLevel.BOUNDED)
        .build();

SearchResp searchResp = client.search(searchReq);

curl --request POST \
--url "${CLUSTER_ENDPOINT}/v2/vectordb/entities/search" \
--header "Authorization: Bearer ${TOKEN}" \
--header "Content-Type: application/json" \
-d '{
    "collectionName": "my_collection",
    "data": [
        [0.3580376395471989, -0.6023495712049978, 0.18414012509913835, -0.26286205330961354, 0.9029438446296592]
    ],
    "limit": 3,
    "consistencyLevel": "Bounded"
}'

Questo parametro è disponibile anche nelle ricerche ibride e nell'iteratore di ricerca. I valori possibili per il parametro consistency_level sono Strong, Bounded, Eventually e Session.

Impostare il livello di consistenza nella query

È sempre possibile modificare il livello di coerenza per una ricerca specifica. Il seguente esempio di codice imposta il livello di coerenza su Eventualmente. L'impostazione si applica solo alla richiesta di query corrente.

res = client.query(
    collection_name="my_collection",
    filter="color like \"red%\"",
    output_fields=["vector", "color"],
    limit=3，
    # highlight-start
    consistency_level="Eventually",
    # highlight-next
)

QueryReq queryReq = QueryReq.builder()
        .collectionName("my_collection")
        .filter("color like \"red%\"")
        .outputFields(Arrays.asList("vector", "color"))
        .limit(3)
        .consistencyLevel(ConsistencyLevel.EVENTUALLY)
        .build();
        
 QueryResp getResp = client.query(queryReq);

Questo parametro è disponibile anche nell'iteratore della query. I valori possibili per il parametro consistency_level sono Strong, Bounded, Eventually e Session.