milvus-logo
LFAI
Home
  • Konzepte

In-Memory-Replikation

In diesem Thema wird der Mechanismus der In-Memory-Replikation (Replikation) in Milvus vorgestellt, der mehrere Segmentreplikationen im Arbeitsspeicher ermöglicht, um die Leistung und Verfügbarkeit zu verbessern.

Informationen zur Konfiguration von In-Memory-Replikaten finden Sie unter Abfrageknotenbezogene Konfigurationen.

Übersicht

Replica_Availiability Replica_Availiability

Mit In-Memory-Replikaten kann Milvus das gleiche Segment auf mehrere Abfrageknoten laden. Wenn ein Abfrageknoten ausgefallen ist oder mit einer aktuellen Suchanfrage beschäftigt ist, kann das System neue Anfragen an einen inaktiven Abfrageknoten senden, der eine Replikation desselben Segments besitzt.

Leistung

Mit In-Memory-Replikationen können Sie zusätzliche CPU- und Speicherressourcen nutzen. Dies ist sehr nützlich, wenn Sie einen relativ kleinen Datensatz haben, aber den Lesedurchsatz mit zusätzlichen Hardwareressourcen erhöhen möchten. Die Gesamt-QPS (Abfrage pro Sekunde) und der Durchsatz können erheblich verbessert werden.

Verfügbarkeit

In-Memory-Replikate helfen Milvus, sich schneller zu erholen, wenn ein Abfrageknoten ausfällt. Wenn ein Abfrageknoten ausfällt, muss das Segment nicht auf einem anderen Abfrageknoten neu geladen werden. Stattdessen kann die Suchanfrage sofort an einen neuen Abfrageknoten weitergeleitet werden, ohne dass die Daten erneut geladen werden müssen. Da mehrere Segmentreplikationen gleichzeitig verwaltet werden, ist das System bei einem Failover widerstandsfähiger.

Wichtige Konzepte

In-Memory-Replikate sind als Replikatgruppen organisiert. Jede Replikatgruppe enthält Shard-Replikate. Jedes Shard-Replikat hat ein Streaming-Replikat und ein historisches Replikat, die den wachsenden und versiegelten Segmenten im Shard entsprechen (d. h. DML-Kanal).

An illustration of how in-memory replica works Ein Beispiel für die Funktionsweise der In-Memory-Replikation

Replikatgruppe

Eine Replikatgruppe besteht aus mehreren Abfrageknoten, die für die Verarbeitung historischer Daten und Replikate zuständig sind.

Shard-Replikat

Ein Shard-Replikat besteht aus einem Streaming-Replikat und einem historischen Replikat, die beide zu demselben Shard gehören. Die Anzahl der Shard-Replikate in einer Replikatgruppe wird durch die Anzahl der Shards in einer bestimmten Sammlung bestimmt.

Streaming-Replikat

Ein Streaming-Replikat enthält alle wachsenden Segmente desselben DML-Kanals. Technisch gesehen sollte ein Streaming-Replikat nur von einem Abfrageknoten in einem Replikat bedient werden.

Historisches Replikat

Ein historisches Replikat enthält alle versiegelten Segmente aus demselben DML-Kanal. Die versiegelten Segmente eines historischen Replikats können auf mehrere Abfrageknoten innerhalb derselben Replikatgruppe verteilt werden.

Shard-Leader

Ein Shard-Leader ist der Abfrageknoten, der das Streaming-Replikat in einem Shard-Replikat bedient.

Entwurfsdetails

Balance

Ein neues Segment, das geladen werden muss, wird auf mehrere verschiedene Abfrageknoten verteilt. Eine Suchanfrage kann bearbeitet werden, sobald mindestens ein Replikat erfolgreich geladen wurde.

Cache

Der Proxy unterhält einen Cache, der die Segmente den Abfrageknoten zuordnet, und aktualisiert ihn in regelmäßigen Abständen. Wenn der Proxy eine Anfrage erhält, holt Milvus alle versiegelten Segmente, die durchsucht werden müssen, aus dem Cache und versucht, sie gleichmäßig den Abfrageknoten zuzuordnen.

Für wachsende Segmente unterhält der Proxy auch einen Channel-to-Query-Node-Cache und sendet Anfragen an die entsprechenden Query-Nodes.

Ausfallsicherung

Die Caches des Proxys sind nicht immer auf dem neuesten Stand. Einige Segmente oder Kanäle können zu anderen Abfrageknoten verschoben worden sein, wenn eine Anfrage eingeht. In diesem Fall erhält der Proxy eine Fehlerantwort, aktualisiert den Cache und versucht, sie einem anderen Abfrageknoten zuzuordnen.

Ein Segment wird ignoriert, wenn der Proxy es auch nach der Aktualisierung des Caches nicht finden kann. Dies kann der Fall sein, wenn das Segment verdichtet wurde.

Wenn der Cache nicht genau ist, kann der Proxy einige Segmente übersehen. Abfrageknoten mit DML-Kanälen (wachsende Segmente) geben Suchantworten zusammen mit einer Liste zuverlässiger Segmente zurück, mit denen der Proxy vergleichen und den Cache aktualisieren kann.

Erweiterung

Der Proxy kann Suchanfragen nicht vollständig gleichmäßig auf die Abfrageknoten verteilen, und die Abfrageknoten verfügen möglicherweise über unterschiedliche Ressourcen zur Bedienung von Suchanfragen. Um eine langschwänzige Verteilung der Ressourcen zu vermeiden, weist der Proxy aktive Segmente auf anderen Abfrageknoten einem untätigen Abfrageknoten zu, der ebenfalls über diese Segmente verfügt.

Übersetzt vonDeepLogo

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started
Feedback

War diese Seite hilfreich?