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
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).
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.
Suche
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 aktuell. 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 zuzuweisen.
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.
