Ein Algorithmusoptimierungsproblem für das Agentenverteilungssystem
Zum Beispiel sind die Agentenstufen in drei Stufen unterteilt: Gold, Silber und Bronze. Ich bin jetzt Goldagent A. Gleichzeitig habe ich Silberagenten B, C und D entwickelt. Silberagent B hat Bronze entwickelt Agenten E und F, wie in der Abbildung gezeigt:
As untergeordnete Proxy-Liste
╦═══════
║
╠═ b
║ ╠══ e
║ ╠══ f
╠═ c
╠═ d
Die Methode, die ich verwende, um das obige Beispielbild zu erstellen, ist: (PHP+MYSQL)
Suchen Sie zuerst nach allen Agenten, deren überlegener Agent ist A.
Zum Beispiel habe ich Agent B gefunden und dann nach allen Agenten gesucht, deren überlegener Agent B ist. Diese Suche ist abgeschlossen.
Erneut nach Agent C suchen…………
Und so weiter.
Frage:
Es gibt jetzt 300.000 Datensätze in der Agentendatenbank. Befolgen Sie die oben beschriebene Methode:
Jede Suche dauert lange 1.000 untergeordnete Agenten werden überhaupt nicht angezeigt.
Die Lösung, die ich gefunden habe, besteht darin, ein Array zum Speichern aller Benutzerbeziehungen zu verwenden und dieses Array dann als Datei zu speichern. Jedes Mal, wenn ein Benutzer hinzugefügt oder gelöscht wird, wird das Array gleichzeitig aktualisiert Die gewünschten Daten werden aus dem Array übertragen und dann direkt zur Datenbank weitergeleitet, um eine Auswahl auszuführen. . Ist dieser Ansatz machbar? Gibt es andere Lösungen?
Traverse
Wenn Sie die unteren Mitglieder der oberen Ebene finden möchten, verwenden Sie die Durchquerung visueller Ebenen. Dieser Algorithmus fragt die Datenbank mehrmals visuell ab. . . Es verbraucht zu viele Ressourcen. Gibt es Alternativen? Cache? Redis?
Antwortinhalt:
Ein Algorithmusoptimierungsproblem für das Agentenverteilungssystem
Zum Beispiel sind die Agentenstufen in drei Stufen unterteilt: Gold, Silber und Bronze. Ich bin jetzt Goldagent A. Gleichzeitig habe ich Silberagenten B, C und D entwickelt. Silberagent B hat Bronze entwickelt Agenten E und F, wie in der Abbildung gezeigt:
As untergeordnete Proxy-Liste
╦═══════
║
╠═ b
║ ╠══ e
║ ╠══ f
╠═ c
╠═ d
Die Methode, die ich verwende, um das obige Beispielbild zu erstellen, ist: (PHP+MYSQL)
Suchen Sie zuerst nach allen Agenten, deren überlegener Agent ist A.
Zum Beispiel habe ich Agent B gefunden und dann nach allen Agenten gesucht, deren überlegener Agent B ist. Diese Suche ist abgeschlossen.
Erneut nach Agent C suchen…………
Und so weiter.
Frage:
Es gibt jetzt 300.000 Datensätze in der Agentendatenbank. Befolgen Sie die oben beschriebene Methode:
Jede Suche dauert lange 1.000 untergeordnete Agenten werden überhaupt nicht angezeigt.
Die Lösung, die ich gefunden habe, besteht darin, ein Array zum Speichern aller Benutzerbeziehungen zu verwenden und dieses Array dann als Datei zu speichern. Jedes Mal, wenn ein Benutzer hinzugefügt oder gelöscht wird, wird das Array gleichzeitig aktualisiert Die gewünschten Daten werden aus dem Array übertragen und dann direkt zur Datenbank weitergeleitet, um eine Auswahl auszuführen. . Ist dieser Ansatz machbar? Gibt es andere Lösungen?
Traverse
Wenn Sie die unteren Mitglieder der oberen Ebene finden möchten, verwenden Sie die Durchquerung visueller Ebenen. Dieser Algorithmus fragt die Datenbank mehrmals visuell ab. . . Es verbraucht zu viele Ressourcen. Gibt es Alternativen? Cache? redis?
Es wird empfohlen, hierarchisch abzufragen und Daten bei Bedarf abzufragen. Das gleichzeitige Anzeigen eines Beziehungsbaums erfordert viele Abfragen und verbraucht Ressourcen.
Eine solche Implementierung kann unendlich viele Klassifizierungsebenen anzeigen. und durchqueren Sie die Baumstruktur der Reihe nach. Die Klassifizierung von Einkaufszentren basiert auf denselben Prinzipien
Überprüfen Sie zunächst, ob der Index auf Proxy-Ebene erstellt wurde.
Es ist nicht sinnvoll, den gesamten Baum auf einer Seite anzuzeigen. Es kann eine On-Demand-Abfrage erfolgen.
Der Gold-Agent öffnet die Seite, um alle Silber-Agenten der Untergebenen anzuzeigen. Klicken Sie auf den Silber-Agenten-Benutzer, um die Bronze-Agenten seiner Untergebenen anzuzeigen.
Vielen Dank für die Einladung, lassen Sie mich einige meiner Ideen mit Ihnen teilen:
Wenn die Aktualisierungen nicht sehr häufig sind, verwenden Sie 缓存 (das Datenvolumen beträgt 300.000 und es wird geschätzt, dass nur die Ebenen 1 bis 2 zwischengespeichert werden können), anstatt jedes Mal eine SQL-Abfrage zu verwenden.
wird mehrmals geladen. Wie oben erwähnt, laden Sie zuerst N级 und dann Ajax, um N+1级 anzufordern.
Baumstruktur-Infinitus-Klassifizierung
Suchen Sie selbst nach der konkreten Antwort. Es ist sehr schwierig, dies im Detail zu erklären. Ich gebe Ihnen das allgemeine Prinzip.
Wie können Sie so schnell wie möglich wissen, wer Ihre Untergebenen sind? Wenn sich alle anstellen, müssen Sie nur zwei Bedingungen erfüllen: 1. Sie wissen, wer der Erste ist. 2. Stellen Sie sicher, dass Sie der Letzte sind. (Natürlich können Sie auch wissen, wer der Letzte ist, und sicherstellen, dass Sie der Erste sind.)
Weisen Sie basierend auf dieser Schlussfolgerung jedem Knoten eine geeignete Seriennummer zu, um eine schnelle Suche zu erreichen, z. B. „select * from tree where indexNumber >= search.node.min && indexNumber <“.
Die endgültige Tabellenstruktur ähnelt
id, parent_id (übergeordneter Knoten), top_id (Wurzelknoten, wenn mehrere Bäume vorhanden sind), indexNumber (Indexnummer im Baum, top_id+indexNumber ist eindeutig), min ( Ich bin der Maßstab, der der Erste unter diesem Zweig ist), Ebene (Baumhöhe)
Für Ihr Beispiel sollte es ähnlich sein (die erste Zahl in Klammern ist die Indexzahl, die zweite ist min, die dritte ist die Baumhöhe)
<code> a(6,1,0)
b(3,1,1) c(4,4,1) d(5,5,1)
e(1,1,2) f(2,2,2)</code>Nach dem Login kopieren
Diese Struktur ist beim Betrieb von Knoten komplizierter (wenn Sie beispielsweise ein g nach f hinzufügen oder f löschen, muss abcd die Sequenznummer neu berechnen), aber die Suche ist im Allgemeinen sehr schnell in einer Suche La.
