Ich habe einen Index von ungefähr 100k Dokumenten, die eine Filmeinheit darstellen.
Benutzer können Filme auf verschiedene Listen (wie Favoriten usw.) setzen.
Diese Listen sind in einer MySQL-Datenbank gespeichert und werden nicht in solr. indiziert.
Ich könnte die Benutzer-IDs in mehrwertigen Feldern speichern, die eine Liste darstellen, aber das ist ziemlich schlecht, weil die Felder sehr, sehr lang werden würden und die Indizierung ebenfalls problematisch wäre.
Also mache ich momentan folgendes (Pseudocode):
%Vor%Das funktioniert großartig und schnell, aber die Anzahl der Elemente in Filterabfragen ist auf 1024 beschränkt (das habe ich versucht). auch Filterabfragen summieren sich. Wenn ich also eine Filterabfrage mit 500 Werten zum Filtern habe, kann ich andere Werte zu 524 Filtern auf einem anderen Feld haben.
Es ist okay für jetzt, weil ich die Einträge pro Liste auf 1024 beschränkt habe, und das ist ziemlich viel, aber ich denke, dass dieser Ansatz sehr ungeschickt ist und viel Overhead produziert.
Gibt es keine bessere Lösung? Wie schreibt man ein Solr-Modul, das direkt mit der Datenbank verbunden ist oder so? Ich würde es gerne in PHP machen.
Wenn es keinen anderen Weg gibt, kann ich irgendwie das 1024 Limit erhöhen? weil es jetzt sehr schnell geht! Ich denke mit guter Hardware wäre mehr kein Problem.
Bearbeiten: Wie in den Kommentaren gefragt, poste ich hier mein ursprüngliches Schema und eine funktionierende Beispielabfrage.
%Vor%Das sind meine Ergänzungen zu der Standard-schema.xml
Ein Beispiel-Suchergebnis kann hier angesehen werden.
Eine Beispielabfrage wäre:
%Vor%Hier würde der Benutzer nach Filmen suchen, die sind:
Die Liste enthält die Filme (Dokumente) mit den IDs 1185616 1054606 88763 361748 78748 und sind in der mysql-Datenbank gespeichert.
ps: Ich weiß nicht, ob ich die Frage gut formuliert habe, ich hoffe es ist verständlich. Wenn nicht, bitte bearbeiten Sie!
Schritt eins ist, sicherzustellen, dass Sie wirklich Solr verwenden möchten. Wenn Sie Ihr Schema betrachten, gibt es eine Menge, die anfällig für ein normales RDBMS mit einfacher Textindizierung ist. Nehmen Sie sich eine halbe Stunde Zeit und schauen Sie sich PostgreSQL an, es sei denn, Sie haben bereits festgestellt, dass ein normales, gut altmodisches RDBMS mit einigen zusätzlichen Glocken und Pfiffen einfach nicht für Sie geeignet ist.
Es gibt ein großes Interesse an diesem Problem in der Solr-Gemeinschaft, aber es gibt keine echte Lösung.
Der offensichtliche Ansatz besteht darin, ein "favorisiertes" Dokument jedes Mal neu zu indizieren, wenn jemand es mit seinem Benutzernamen in einem mehrwertigen Feld bevorzugt. Das ist natürlich hirntot, aber das bedeutet nicht, dass es nicht funktionieren wird, je nachdem wie oft einer deiner Nutzer mit seiner / ihrer Favoritenliste rumhängt. Wenn Ihre Dokumente klein sind (ich nehme an, sie sind nur ein paar K) und Sie haben genug Hardware, um den gesamten Index im Speicher zu halten (wahrscheinlich, weil Sie nur 100K Dokumente haben), könnte dies der Ansatz sein . Sie können es testen, indem Sie einen Index einer Größe erstellen, die tatsächlich in den verfügbaren Speicher passt und die Strategie implementieren. Schau, ob es schnell genug ist.
Sie können diese Vorgänge auch "ablaufen lassen", wenn die Leute nicht in einem Schritt eine Vielzahl von Favoriten hinzufügen:
Dies kann für Sie funktionieren, wenn die Leute eine angemessene Anzahl von Favoriten pro Tag hinzufügen und Sie nachts nicht viel Verkehr haben.