Speichern des Suchergebnisses zum Blättern und Sortieren

8

Ich habe MS Search Server 2010 implementiert und bisher ist es wirklich gut. Ich mache die Suchanfragen über ihren Web-Service, aber wegen der inkonsistenten Ergebnisse , ich denke darüber nach, das Ergebnis zwischenzuspeichern.

Die Seite ist ein kleines Intranet (500 Angestellte), also sollte es keine Probleme geben, aber ich bin neugierig, welchen Ansatz Sie wählen würden, wenn es eine größere Seite wäre.

Ich habe abit gegoogelt, aber ich bin nicht wirklich über etwas Bestimmtes gekommen. Also, ein paar Fragen:

  • Welche anderen Ansätze gibt es? Und warum sind sie besser?
  • Wie viel kostet es, eine Datenansicht von 400 bis 500 Zeilen zu speichern? Welche Größen sind möglich?
  • Andere Punkte, die Sie beachten sollten.

Jede Eingabe ist willkommen:)

    
Mattias 15.02.2010, 18:47
quelle

4 Antworten

2

Sie müssen viele Techniken anwenden, um dies erfolgreich durchzuziehen.

Zuerst benötigen Sie eine Art Persistenz-Layer. Wenn Sie eine einfache alte Website verwenden, ist die Sitzung des Benutzers die logischste zu verwendende Ebene. Wenn Sie Web-Services (also session-less) verwenden und nur über einen Client telefonieren, dann brauchen Sie noch eine Art Anwendungsebene (eine Art gemeinsame Sitzung) für Ihre Dienste. Warum? Auf dieser Ebene befindet sich der Datenbankergebniscache.

Second , Sie müssen Ihre Ergebnisse in einem beliebigen Container zwischenspeichern (Sitzung oder Anwendungsebene von Webdiensten). Sie können dies auf verschiedene Arten tun ... Wenn die Abfrage von einem Benutzer ausgeführt werden kann, funktioniert ein einfacher Hash der Abfrage, und Sie können dieses gespeicherte Ergebnis für andere Benutzer freigeben. Wahrscheinlich möchten Sie immer noch eine Art GUID für das Ergebnis, so dass Sie dies in Ihrer Clientanwendung weitergeben können, aber ein Hash-Lookup von den Abfragen zu den Ergebnissen ist hilfreich. Wenn diese Abfragen eindeutig sind, können Sie einfach die eindeutige GUID für das Abfrageergebnis verwenden und diese an die Clientanwendung weitergeben. Dies ist der Fall, damit Sie Ihre Caching-Funktion ausführen können ...

Der Caching-Mechanismus kann eine Art Puffer oder Warteschlange fester Länge enthalten, so dass alte Ergebnisse automatisch gelöscht / entfernt werden, wenn neue hinzugefügt werden. Wenn eine Abfrage eintrifft, bei der es sich um einen Cache-Fehltreffer handelt, wird sie normal ausgeführt und dem Cache hinzugefügt.

Third , Sie werden eine Möglichkeit haben, Ihr Ergebnisobjekt zu pagen ... das Iterator-Muster funktioniert hier gut, obwohl wahrscheinlich etwas einfacheres funktionieren könnte ... wie fetch X Anzahl der Ergebnisse ab Punkt Y . Allerdings wäre das Iterator-Muster besser, da Sie dann später Ihren Caching-Mechanismus entfernen und direkt aus der Datenbank blättern könnten, falls Sie dies wünschen.

Vierte , Sie benötigen eine Art Pre-Fetch-Mechanismus (wie von anderen vorgeschlagen). Sie sollten einen Thread starten, der die vollständige Suche durchführt, und in Ihrem Hauptthread einfach eine schnelle Suche mit der obersten X Anzahl von Elementen durchführen. Hoffentlich wird der zweite Thread beendet, wenn der Benutzer versucht, einen Paging-Vorgang auszuführen. Das vollständige Ergebnis wird nun im Cache gespeichert. Wenn das Ergebnis nicht bereit ist, können Sie einfach eine einfache Ladebildschirmlogik einbauen.

Das sollte Ihnen einen Weg geben ... lassen Sie es mich wissen, wenn Sie etwas Klärung / mehr Details zu einem bestimmten Teil wünschen.

Ich werde dir noch ein paar Tipps geben ...

  1. Sie möchten nicht das gesamte Ergebnis an die Client-App senden (wenn Sie Ajax oder eine ähnliche IPhone-App verwenden). Warum? Nun, weil das eine riesige Verschwendung ist. Der Benutzer wird wahrscheinlich nicht alle Ergebnisse durchblättern ... jetzt haben Sie nur mehr als 2 MB Ergebnisfelder für nichts gesendet.

  2. Javascript ist eine großartige Sprache, aber denken Sie daran, dass es sich immer noch um eine clientseitige Skriptsprache handelt ... Sie möchten die Benutzererfahrung nicht zu sehr verlangsamen, indem Sie riesige Datenmengen an Ihren Ajax-Client senden . Senden Sie einfach das vorab abgerufene Ergebnis Ihrer Client- und zusätzlichen Seitenergebnisse als Benutzerseiten.

  3. Abstraktion Abstraktion Abstraktion ... Sie wollen den Cache, die Abfrage, das Paging, das Prefetching ... so weit wie möglich abstrahieren. Warum? Nehmen wir an, Sie wollen Datenbanken wechseln oder direkt aus der Datenbank blättern, anstatt ein Ergebnisobjekt im Cache zu verwenden ... nun, wenn Sie es richtig machen, ist es viel einfacher, es später zu ändern. Wenn Sie Webdienste verwenden, können viele andere Anwendungen diese Logik später auch verwenden.

Jetzt habe ich wahrscheinlich eine überentwickelte Lösung für das, was Sie brauchen, vorgeschlagen :). Aber wenn Sie dies mit den richtigen Techniken durchführen können, werden Sie eine Menge lernen und eine sehr gute Basis haben, falls Sie die Funktionalität erweitern oder diesen Code wiederverwenden möchten.

Lass es mich wissen, wenn du Fragen hast.

    
Polaris878 27.03.2010, 05:49
quelle
1

Es klingt, als ob der langsame Teil der Suche die Volltextsuche und nicht die Ergebnissuche ist. Wie wäre es, die resultierenden Ressourcen-IDs zwischenzuspeichern? Da es auch wahr sein kann, dass Suchanfragen häufig dupliziert werden, speichern Sie einen Hash der Suchabfrage, der Abfrage und der übereinstimmenden Ressourcen. Dann können Sie die nächste Seite der Ergebnisse nach ID abrufen. Funktioniert auch mit AJAX.

Da es sich um ein Intranet handelt und Sie die gesuchten Ressourcen kontrollieren können, könnten Sie sogar die Übereinstimmung einer neuen oder aktualisierten Ressource mit beliebten Abfragen während der Leerlaufzeit vorberechnen.

    
Jason Kleban 26.03.2010 23:17
quelle
0

Ich muss zugeben, dass ich mit MS Search Server nicht besonders vertraut bin, daher trifft dies möglicherweise nicht zu. Ich hatte oft Situationen, in denen eine Anwendung Hunderte von Millionen von Datensätzen nach Ergebnismengen durchsuchen musste, die in einem SQL Server sortiert, paginiert und untersucht werden mussten. Generell mache ich einen zweistufigen Ansatz. Zuerst greife ich die ersten "x" Ergebnisse an, die angezeigt werden müssen, und sende sie zur schnellen Anzeige an den Browser. Zweitens beende ich in einem anderen Thread die vollständige Abfrage und verschiebe die Ergebnisse in eine temporäre Tabelle, in der sie schneller gespeichert und abgerufen werden können. Jede gegebene Abfrage kann Tausende oder Zehntausende von Ergebnissen haben, aber im Vergleich zu den Hunderten von Millionen oder sogar Milliarden von Gesamtdatensätzen kann diese kleinere Teilmenge sehr leicht aus der Temp-Tabelle manipuliert werden. Es belastet auch die anderen Tabellen weniger, wenn Abfragen stattfinden. Wenn der Benutzer eine zweite Seite mit Datensätzen benötigt oder diese sortieren muss oder nur eine Teilmenge der ursprünglichen Abfrage benötigt, wird dies aus der temporären Tabelle abgerufen.

Logic muss dann eingefügt werden, um nach veralteten temporären Tabellen zu suchen und sie zu entfernen. Das ist einfach genug und ich lasse den SQL Server diese Funktionalität behandeln. Schließlich muss eine Logik implementiert werden, wenn sich die ursprüngliche Abfrage ändert (signifikante Änderungen des Umfangs), so dass ein neuer Datensatz abgerufen und zur weiteren Abfrage in eine neue temporäre Tabelle eingefügt werden kann. Das alles ist relativ einfach.

Benutzer sind so gewöhnt, zweite Rückgabezeiten von Orten wie Google zu teilen, und dieses Modell gibt mir genügend Flexibilität, um das tatsächlich zu erreichen, ohne die spezielle Software und Hardware zu benötigen, die sie verwenden.

Hoffe das hilft ein wenig.

    
Tim C 15.02.2010 19:54
quelle
0

Tims Antwort ist eine großartige Möglichkeit, Dinge zu handhaben, wenn Sie die erste Abfrage in einem zweiten Thread ausführen können und die Logik (Paging / Sortierung / Filterung), die auf die Ergebnisse angewendet wird, eine Aktion auf dem Server erfordert ... .. sonst ....

Wenn Sie AJAX verwenden können, kann ein Ergebnissatz mit 500 Zeilen auf der Seite aufgerufen und auf dem Client sortiert oder sortiert werden. Dies kann zu einigen wirklich interessanten Features führen. Schauen Sie sich die DataGrid-Lösungen von jQueryUI und Dojo zur Inspiration an!

Und für wirklich intensive Funktionen wie willkürliche Regex-Filter und Drag-and-Drop-Spaltenumordnung können Sie den Server vollständig freigeben.

Wenn Sie die Daten gleichzeitig in den Browser laden, können Sie auch unterstützende Daten (Seitenvorschauen usw.) aufrufen, wenn der Benutzer sie anfordert ....

Das Hauptproblem besteht darin, die Daten, die Sie pro Ergebnis zurückgeben, auf das zu beschränken, was Sie tatsächlich für Ihre Sortierungen und Filter verwenden.

Die Möglichkeiten sind endlos:)

    
Andrew Neelands 16.02.2010 20:01
quelle

Tags und Links