Ich untersuche Indexierungs-Engines, insbesondere Apache Lucene Solr. Wir sind bereit, es für unsere Suchen zu verwenden, aber eines der Probleme, die durch unsere Frameworks-Suche gelöst werden, ist der Zugriff auf Zeilenebene.
Solr bietet keinen Datensatzzugriff von Anfang an:
& lt; ... & gt; Solr beschäftigt sich nicht mit Sicherheit, weder auf Dokumentebene noch auf Kommunikationsebene.
Und im Abschnitt über die Sicherheit auf Dokumentebene: Ссылка
Es gibt einige Vorschläge - entweder Manifold CF (das ist sehr undokumentiert und scheint in einem sehr Pre-Beta-Stadium) oder schreiben Sie Ihre eigene Anfrage Handler / Search-Komponente (dieser Teil ist als Stub markiert) - ich denke, dass der spätere man hätte größere Auswirkungen auf die Leistung.
Ich nehme also an, dass auf diesem Gebiet nicht viel getan wird.
In der kürzlich veröffentlichten Version 4.0 von Solr haben sie die Verbindung zweier indizierter Entitäten eingeführt. Joining scheint eine gute Idee zu sein, da unser Framework auch einen Join durchführt, um zu wissen, ob der Datensatz für den Benutzer zugänglich ist. Das Problem hier ist, dass wir manchmal einen inneren Join machen, und manchmal auch einen äußeren (abhängig von dem Optimistischen (alles was nicht verboten ist) oder pessimistischen (alles ist nur verboten, was explizit erlaubt ist) Sicherheitseinstellung im Scope).
Um besser zu verstehen, wie unsere Struktur aussieht:
Dokumente
%Vor%DocumentRecordAccess
%Vor%So wäre zum Beispiel die generierte Abfrage für die Einstellung Dokumente in pessimistischer Sicherheit:
%Vor%Dies würde nur das foo zurückgeben, aber nicht die Leiste. Und in optimistischer Einstellung:
%Vor%Zurückkommen beide - das Foo und die Bar.
Zurück zu meiner Frage - vielleicht hat jemand das schon getan und kann seine Einsichten und Erfahrungen teilen?
Ich fürchte, hier gibt es keine einfache Lösung. Sie müssen etwas opfern, damit ACLs mit der Suche zusammenarbeiten.
Wenn Ihre Korpusgröße klein ist (ich würde sagen, bis zu 10K Dokumente), könnten Sie einen Cache-Satz von verbotenen (oder erlaubten, weniger ausführlichen) Dokumenten erstellen und die relevante Filterabfrage (+*:* -DocumentNr:1 ... -DocumentNr:X) senden. Unnötig zu sagen, das skaliert nicht. Das Senden von großen Abfragen wird die Suche etwas langsamer machen, aber dies ist (bis zu einem gewissen Punkt) überschaubar. Abfrageanalyse ist billig .
Wenn Sie diese Dokumente irgendwie gruppieren und ACLs auf Dokumentengruppen anwenden können, würde dies eine Verkürzung der Abfragelänge ermöglichen, und der obige Ansatz würde perfekt passen. Das ist genau das, was wir verwenden - unsere Lösung implementiert Taxonomie und hat Taxonomie-Berechtigungen über fq query.
Wenn Sie die Gesamtzahl der Ergebnismengen nicht anzeigen müssen, können Sie Ihre Abfrage ausführen und die Ergebnismenge auf der Clientseite filtern. Nochmal, nicht perfekt.
Sie können auch Ihre Datenstrukturen denormalisieren und beide Tabellen in einem einzigen Dokument wie folgt ablegen:
DocumentNr: 1
Name: Foo
Allowed_users: u1, u2, u3 (oder Forbidden_users: ...)
Der Rest ist so einfach wie das Senden der Benutzer-ID mit Ihrer Anfrage.
Oben ist nur sinnvoll, wenn sich die ACLs selten ändern und Sie können es sich leisten, den gesamten Korpus neu zu indizieren, wenn sie dies tun.
Sie könnten einen benutzerdefinierten Abfragefilter schreiben, der BitSet s erlaubter oder verbotener Dokumente nach Benutzer (Gruppe?) aus der Datenbank gespeichert hat. Dies würde nicht nur das Bereitstellen eines DB-Zugriffs für Solr webapp erfordern, sondern auch das Erweitern / Neupacken des mit Solr gelieferten .war. Während dies relativ einfach ist, wäre der schwierigere Teil eine Cache-Invalidierung : Die Haupt-App sollte Solr-Apps irgendwie signalisieren, wenn ACL-Daten geändert werden .
Die Optionen 1 und 2 sind wahrscheinlich vernünftiger, wenn Sie Solr und Ihre App auf dieselbe JVM setzen und javabin verwenden können Fahrer.
Es ist schwierig, mehr zu beraten, ohne die Besonderheiten der Corpus / ACLs zu kennen.
Ich stimme mit mindas überein, was er vorgeschlagen hat (sol-4), ich habe meine Lösung auf die gleiche Weise implementiert, aber der Unterschied ist, dass ich nur wenige verschiedene Arten von ACLs habe. Auf Benutzergruppenebene, Benutzerebene und sogar Dokumentenebene (privater Zugriff).
Die Lösung funktioniert gut. Aber das Hauptproblem in meinem Fall ist, dass ACLs häufig geändert werden und das im Index aktualisiert werden muss, während die Suchleistung nicht beeinträchtigt wird.
Ich versuche, dies mit Load Balancing zu verwalten und fügen Sie dem Cluster einige weitere Knoten hinzu.
Mindas, Unicron können Sie bitte Ihre Gedanken dazu machen?