Trefferlimit bei Suche

  • Moin moin.


    Die Anzahl der Suchergebnisse ist bei mir auf 1000 Treffer beschränkt.
    Das führt häufiger bei den Benutzern zu irritierenden Ergebnissen, weil die Suche wohl bei dem kleinsten Index / ältesten Beiträgen beginnt.


    Frage:
    Gibt es eine Einstellung, mit der die Anzahl der Suchergebnisse limitiert wird? - Wenn ja, wo ist diese zu finden?

    Wenn nein, ist das nur bei mir so, dass die Anzahl der Suchergebnisse auf dieses Trefferlimit beschränkt ist?
    Wenn nein, gibt es eine Stelle wo man das ändern kann?


    Vielen Dank für Eure Aufmerksamkeit und Hilfe.

  • Es gibt keine Einstellung, um das zu ändern.

    Die Beschränkung gilt für alle.

    Ändern kannst Du es nur durch einen direkten Eingriff in eine Datei (nicht unbedingt empfehlenswert).


    Gruß norse

    Zugang zu meinen Arbeiten und dem dazugehörigen Support bekommt Ihr bei Interesse hier und hier.

    • Offizieller Beitrag

    Damit sich dort das Limit bemerkbar macht, müsste es schon ein sehr allgemeiner Begriff sein. Grundsätzlich wäre es interessant, wie sich die Suche bei der Erhöhung des Limits verhält; Mit 4.1 haben wir einen nicht unerheblichen Teil der Suche überarbeitet, ein Teil dieser Änderung dürfte nun auch ein höheres Limit zulassen.

  • Damit sich dort das Limit bemerkbar macht, müsste es schon ein sehr allgemeiner Begriff sein.

    Das passiert schon häufiger. In Sourcecode-Zitaten wiederholen sich gewisse Begriffe häufig. Und wenn Beiträge mit Sourcecode wiederum zitiert werden, wiederholen sich diese Begriffe sehr sehr oft.

    Jüngstes Beispiel beim meinen Usern war UIImage und NSObject. Da endet die Suche bei 2012 und 2010.


    Zum Testen haben ich NSArray und NSString verwendet. Da sollen laut dem Suchergebnis die jüngsten Ergebnisse dann aus 2008 bzw. 2006 stammen. :|

    Grundsätzlich wäre es interessant, wie sich die Suche bei der Erhöhung des Limits verhält; Mit 4.1 haben wir einen nicht unerheblichen Teil der Suche überarbeitet, ein Teil dieser Änderung dürfte nun auch ein höheres Limit zulassen.

    Das klingt verheißungsvoll. :)


    P.S.: Möchtest Du es selbst evtl. mal versuchen?

    P.S.P.S.: Das Forum ist unter Homepage hinterlegt. Versuche die Suche mal mit "string", "array" oder auch "hallo".

    5 Mal editiert, zuletzt von iosxdevs (31. März 2015 um 15:28)

    • Offizieller Beitrag

    Das Problem ist eher, dass MySQL bei sehr vielen Treffer immer ineffizienter wird.

    Für den Test habe ich einen Teil eines älteren Backups dieses Forums hier genommen, im Suchindex befinden sich 78.792 Datensätze. Diese enthalten den Begriff woltlab insgesamt 14.465 mal.

    Test-System: MySQL 5.6.15-log, Intel Core i7-4820K (4x 3,7 GHz), 32 GB DDR3-1600, 512 GB SSD

    Der entscheidende Punkt hierbei ist, dass dies nur die innere Abfrage des Suchindex darstellt, außen kommt noch der Abgleich mit der Beitrags/Themen-Tabelle zwecks Filterung von gelöschten bzw. deaktivieren Beiträgen/Themen sowie der Abgleich mit den zugänglichen Foren. Davon ab offenbaren die Werte oben den Sinn unserer Strategie des reinen Limits ohne einer Sortierung nach Zeit, denn sobald sortiert wird steigt der Zeitbedarf astronomisch an und liegt jenseits jeglicher Nutzbarkeit. Dazu kommt noch, dass diese Werte auf einer sehr leistungsstarken Maschine mit einem extrem kleinen Suchindex ermittelt wurden.

  • Wie schaut denn ne vergleichbare Suche mit elasticsearch aus ?
    Auf das Plugin Warte ich ja schon die ganze zeit und wäre doch mal interesannt zu vergleichen wie viel das ausmacht^^

  • Das Problem ist eher, dass MySQL bei sehr vielen Treffer immer ineffizienter wird.

    Ja. Das ist richtig.

    Der entscheidende Punkt hierbei ist, dass dies nur die innere Abfrage des Suchindex darstellt, außen kommt noch der Abgleich mit der Beitrags/Themen-Tabelle zwecks Filterung von gelöschten bzw. deaktivieren Beiträgen/Themen sowie der Abgleich mit den zugänglichen Foren. Davon ab offenbaren die Werte oben den Sinn unserer Strategie des reinen Limits ohne einer Sortierung nach Zeit, denn sobald sortiert wird steigt der Zeitbedarf astronomisch an und liegt jenseits jeglicher Nutzbarkeit. Dazu kommt noch, dass diese Werte auf einer sehr leistungsstarken Maschine mit einem extrem kleinen Suchindex ermittelt wurden.

    Klar. Und das hast sehr anschaulich dargestellt. Der springende Punkt auf der Anwenderseite ist jedoch, die Performance der Suche hilft wenig, wenn der Benutzer kein brauchbares oder sinnvolles Ergebnis erhält. Der User wundert und ärgert sich nur darüber. Und das trotz guter Performance!

    In dem konkreten Fall würde z.B. eine Erhöhung des Limit auf 2000 reichen um die meisten Fälle abzudecken. Im Allgemeinen könnte es sicher helfen, wenn nicht die ersten (ältesten) 1000 Ergebnisse, sondern die letzten (jüngsten) 1000 Ergebnisse angezeigt würden.

    • Offizieller Beitrag

    sondern die letzten (jüngsten) 1000 Ergebnisse angezeigt würden.

    Das ist vollkommen klar und das hat auch keiner bestritten, aber wie in meinem obigen Beispiel erläutert, geht die Performance bei der Sortierung sofort in den Keller. Was nützt einem eine Suche die gute Ergebnisse liefert, dafür aber eine halbe Minute braucht? Von der extremen Last die das für den Server bedeutet ganz abgesehen, das kommt nämlich noch on top dazu.

    Unser Problem hierbei ist, dass wir eine Lösung brauchen die möglichst alle Fälle abdeckt. Eine Suche die bei 50.000 Datensätzen funktioniert ist schön, wenn diese aber bei 500.000 die Datenbank in die Knie zwingt, ist das schlicht inakzeptabel. Die Zeit die MySQL braucht steigt leider nicht linear sondern eher exponentiell.

    Mit elasticsearch haben wir eine Lösung für sehr große Foren, da ab einem gewissen Punkt selbst eine reine Volltext-Suche ohne Sortierung bereits extrem langsam wird. Bei 5 Millionen Datensätzen auf eine "beefy machine" waren es 8 Sekunden und trotzdem waren die Ergebnisse alles andere als relevant.


    Dennoch streben wir eine Verbesserung der aktuellen Suche an, seit der Aufteilung des Suchindex auf die einzelnen Objekt-Typen mit WCF 2.1 haben wir sehr viel mehr Möglichkeiten. Bisher war u.a. eines der Probleme bei der Sortierung, dass MySQL nur eine begrenzte Anzahl an Indizes nutzt und zu dem man kaum Kontrolle darüber hat, welche verwendet werden. Mehr kann ich dazu erst sagen, wenn unsere Tests abgeschlossen sind, bis dahin kann ich leider nicht viel anderes hierzu beitragen.

  • Das ist vollkommen klar und das hat auch keiner bestritten, aber wie in meinem obigen Beispiel erläutert, geht die Performance bei der Sortierung sofort in den Keller. Was nützt einem eine Suche die gute Ergebnisse liefert, dafür aber eine halbe Minute braucht? Von der extremen Last die das für den Server bedeutet ganz abgesehen, das kommt nämlich noch on top dazu.

    Unser Problem hierbei ist, dass wir eine Lösung brauchen die möglichst alle Fälle abdeckt. Eine Suche die bei 50.000 Datensätzen funktioniert ist schön, wenn diese aber bei 500.000 die Datenbank in die Knie zwingt, ist das schlicht inakzeptabel. Die Zeit die MySQL braucht steigt leider nicht linear sondern eher exponentiell.

    Mir ist der Zielkonflikt absolut bewusst. - Nur derzeit, hat man ja im Problemfall nicht mal die Möglichkeit diese Abwägung selbst zu treffen.

    Optimal wäre eine sinnvolle Voreinstellung (Limit von 1000), welche die Mehrheit aller Cases abdeckt. Aber einem dennoch die Möglichkeit lässt, diese an die gewachsenen Gegebenheiten anzupassen.

    Mit elasticsearch haben wir eine Lösung für sehr große Foren, da ab einem gewissen Punkt selbst eine reine Volltext-Suche ohne Sortierung bereits extrem langsam wird. Bei 5 Millionen Datensätzen auf eine "beefy machine" waren es 8 Sekunden und trotzdem waren die Ergebnisse alles andere als relevant.

    Erstaunlich. Das macht mich neugierig.

    Dennoch streben wir eine Verbesserung der aktuellen Suche an, seit der Aufteilung des Suchindex auf die einzelnen Objekt-Typen mit WCF 2.1 haben wir sehr viel mehr Möglichkeiten. Bisher war u.a. eines der Probleme bei der Sortierung, dass MySQL nur eine begrenzte Anzahl an Indizes nutzt und zu dem man kaum Kontrolle darüber hat, welche verwendet werden.

    Das wollte ich als Anregung gerade mal in den Raum werfen. Insofern schön zu hören, dass sich da was tut.

    Mehr kann ich dazu erst sagen, wenn unsere Tests abgeschlossen sind, bis dahin kann ich leider nicht viel anderes hierzu beitragen.

    Danke für die Zeit und Mühe die Du aufgebracht hast.

    Einmal editiert, zuletzt von iosxdevs (31. März 2015 um 17:52)

    • Offizieller Beitrag

    Optimal wäre eine sinnvolle Voreinstellung (Limit von 1000)

    Das ist es doch bereits, das Limit liegt bei 1000. Das Problem ist nur, dass nicht sortiert wird, weil dann die Performance komplett einbricht.

    Erstaunlich. Das macht mich neugierig.

    Das wäre mit Kanonen auf Spatzen geschossen, elasticsearch wird eigentlich erst dann interessant, wenn die MySQL-Suche endgültig den Geist aufgibt. Das ist i.d.R. nur im Bereich von Millionen von Beiträgen der Fall, zu dem ist elasticsearch ein separater Dienst der auf einem Server betrieben wird, auf einem Webspace steht so etwas per sé nicht zur Verfügung.

  • Das ist es doch bereits, das Limit liegt bei 1000. Das Problem ist nur, dass nicht sortiert wird, weil dann die Performance komplett einbricht.

    Ja klar. Aber Du weisst, daß das Zitat dem Kern der Aussage entrissen ist. Das war die Einleitung.

    Hier noch mal vollständig und die entscheidende Stelle hervorgehoben.

    Optimal wäre eine sinnvolle Voreinstellung (Limit von 1000), welche die Mehrheit aller Cases abdeckt. Aber einem dennoch die Möglichkeit lässt, diese an die gewachsenen Gegebenheiten anzupassen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!