Laden...

Indexierungsframework gesucht

Erstellt von popel vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.977 Views
P
popel Themenstarter:in
13 Beiträge seit 2010
vor 13 Jahren
Indexierungsframework gesucht

Hallo,

ich bin auf der Suche nach einem Framework, mit dem man Dateien indexieren / indizieren kann. Also im Prinzip etwas ähnliches wie Lucene. Allerdings soll es einige Dinge können.
Dazu zählen z.B. *Indexspeicherung auf einer Datenbank *es sollten möglichst viele Dateitypen unterstützt werden *verwendete Programmiersprache: C# *es wäre cool, wenn das System die Dokumente nach erstmaliger Indexierung "überwacht" *es sollte Dokumente in deutscher Sprache aufbereiten können

Kennt jemand so etwas?
Wäre wirklich nett, wenn mit jemand einen Tipp oder eine Empfehlung geben kann.

... sind wir nicht alle ein bisschen popel 8o

185 Beiträge seit 2005
vor 13 Jahren

hallo,

Indexspeicherung auf einer Datenbank

Die meisten DBMS unterstützen die Indizierung von DB Spalten, in welchen Text gespeichert ist - ist das eine Lösung für dich?

es sollten möglichst viele Dateitypen unterstützt werden

Das hat nichts mit der Indizierung an sich zu tun. Um aus einer Datei mit einem bestimmten Typ (z.B. .doc) einen Klartext extrahieren zu können, musst du über die "IFilter" Schnittstelle gehen (z.B. http://www.codeproject.com/KB/cs/IFilter.aspx) und den Text extrahieren - dieser kann dann durch die Indizierung weiterverarbeitet werden?

es wäre cool, wenn das System die Dokumente nach erstmaliger Indexierung "überwacht" siehe: FileSystemWatcher-Klasse

es sollte Dokumente in deutscher Sprache aufbereiten können Für Lucene.net und auch z.,B. Sql Server (sicher auch andere, aber von denen weiß ich es), gibt es Tokenizer, die das können.

fg
hannes

P
popel Themenstarter:in
13 Beiträge seit 2010
vor 13 Jahren

Die meisten DBMS unterstützen die Indizierung von DB Spalten, in welchen Text gespeichert ist - ist das eine Lösung für dich?

Leider nein.
Ich möchte den erstellten Index auf einer Datenbank speichern. Das was du meinst scheint eine Indizierung einer DB zu sein. Oder habe ich das jetzt falsch verstanden?

Das hat nichts mit der Indizierung an sich zu tun. Um aus einer Datei mit einem bestimmten Typ (z.B. .doc) einen Klartext extrahieren zu können, musst du über die "IFilter" Schnittstelle gehen (z.B.
>
) und den Text extrahieren - dieser kann dann durch die Indizierung weiterverarbeitet werden?

Prinzipiell gebe ich dir recht, aber z.B. Terrier kümmert sich gleich mit um den Dateizugriff.

es wäre cool, wenn das System die Dokumente nach erstmaliger Indexierung "überwacht"
siehe:
>

Das ist genial, genau so etwas meinte ich. Tausend thx

es sollte Dokumente in deutscher Sprache aufbereiten können
Für Lucene.net und auch z.,B. Sql Server (sicher auch andere, aber von denen weiß ich es), gibt es Tokenizer, die das können.

wollte ich auch nur der Vollständigkeit halber mit erwähnen.

Achja und zum Thema SQL Server:
Leider muss das System so weit wie möglich unabhängig vom konkreten DB-System sein.

... sind wir nicht alle ein bisschen popel 8o

185 Beiträge seit 2005
vor 13 Jahren

Leider nein.
Ich möchte den erstellten Index auf einer Datenbank speichern. Das was du meinst scheint eine Indizierung einer DB zu sein. Oder habe ich das jetzt falsch verstanden?

Nein, hab damit eh die Indizierung der DB gemeint.
Warum möchtest du den Index in einer DB speichern bzw. was ist das Problem, wenn der Index wie bei Lucene am Dateisystem liegt?

Achja und zum Thema SQL Server:
Leider muss das System so weit wie möglich unabhängig vom konkreten DB-System sein.

Das war auch der Grund, warum ich Lucene.net einsetze.
Hat halt alles Vor- und Nachteile. Lucene.net ist einfach verwendbar, schnell + bietet Möglichkeiten, die eine DB integrierte Volltextsuche (meines Wissens nach) dzt. nicht kann z.B. Direkten Zugriff auf den VolltextIndexkatalog.
Großer Vorteil des Volltextindexes in der DB ist imho., dass man Abfragen auf diesen dann in ein SQL Statement gemeinsam mit anderen Kriterien kombinieren kann. (Select ... from ... where Fulltext(...) and ...)

fg
hannes

P
popel Themenstarter:in
13 Beiträge seit 2010
vor 13 Jahren

Genau der von dir angesprochene Vorteil ist es, der die Verwendung einer Datenbank erforderlich macht.
Es müssen Zugriffe aus verschiedenen Anwendungen auf den erstellten Index möglich sein. Mit Datenbanken ist man auch wesentlich flexibler. So kann man die Indexierungsroutine jederzeit ändern und doch das DB-Schema beibehalten.

... sind wir nicht alle ein bisschen popel 8o

185 Beiträge seit 2005
vor 13 Jahren

hallo,

der von mir angesprochene Vorteil (Volltextindizierung der DB verwenden), kommt aber nur zum tragen, wenn man die Volltextfunktion der DB verwendet!
Dann bist du aber nicht mehr DB unabhängig.

Wenn du Lucene.net verwendest, kannst du Volltextabfragen nicht mit SQL Statements kombinieren, auch nicht, wenn der Index in der DB liegt - zumindest nicht, wenn es ein Überbau ist, der anstelle eines Dateisystems die DB als Ablage verwendet.

Lucene.net weiß ja nichts von SQL Abfragen und die DB nichts von einem Volltext in Lucene - eine Kombination innerhalb eines einzigen Select Statements in der Form "Select * from ... where Fulltext("abc")" ist daher so nicht möglich.

So kann man die Indexierungsroutine jederzeit ändern und doch das DB-Schema beibehalten.

Weiß nicht, was du damit meinst.
Auch wenn du den Index am Dateisystem hast, ist er unabhängig von einem DB Schema.

fg
hannes

P
popel Themenstarter:in
13 Beiträge seit 2010
vor 13 Jahren

Ich meine das ganze so:
Auf einer DB werden alle Informationen zu den Dokumenten gespeichert. Also alle Indexeinträge.
Jetzt kann jederzeit der eigentliche Indexierungsvorgang bzw. die Plattform und alles drum und dran geändert werden. Die DB bleibt trotzdem die gleiche.
Dadurch, dass man die DB recht neutral hält kann man sogar problemlos das konkrete Datenbankmanagementsystem austauschen.
Die zur Abfrage der Informationen verwendeten Clients müssen nicht geändert werden. Weder bei einer Änderung der DBMS (außer evtl. die Connection-Routine) noch bei Änderungen der Indexierungsroutine (wenn die Daten die gleichen bleiben).

Diesen unschlagbaren Vorteil hätte man bei Lucene nicht. Da ist man immer an Lucene selbst gebunden. Man könnte dies dann zwar selber umbauen o.ä. aber es wäre wesentlich aufwändiger als beispielsweise ein anderes Framework zu verwenden, weil es z.B. effektivere Zugriffsverfahren verwendet.

Jetzt verständlich?

... sind wir nicht alle ein bisschen popel 8o

185 Beiträge seit 2005
vor 13 Jahren

hallo,

ja, jetzt ist mir verständlich, was du meinst.

Wir verwenden es dzt. (produktiv + erfolgreich) in der Form, dass es einen eigenen "Server" gibt, welcher Webservice Anfragen entgegennimmt. Dieser verwendet intern Lucene.net, um einen Index am Dateisystem abzulegen.

Die Komponente, welche Volltextsuchen durchführt, weiß nichts von Lucene.net - für diese ist es ein Webservice Aufruf.

fg
hannes

P
popel Themenstarter:in
13 Beiträge seit 2010
vor 13 Jahren

Ein Webservice erzeugt in meinen Augen zu viel Overhead.
Außerdem besteht nunmal der Wunsch nach einer Datenbank.

Gibt es denn keine anständigen .NET-Alternativen zu Lucene?

... sind wir nicht alle ein bisschen popel 8o

1.820 Beiträge seit 2005
vor 13 Jahren

Hallo!

@popel:
Ich gehe mal davon aus, dass die von dir genannten Punkte die wichtigsten sind:*Indexspeicherung auf einer Datenbank: Schreibe dir einen Wrapper, welcher die einfachsten DB-Aktionen kapselt (INSERT, UPDATE, DELETE), dann kannst du später mit rel. wenig Aufwand die DB wechseln: Einfach einen neuen Adapter schreiben. Ich versuche gerade selbst, einen solchen zu entwickeln, evtl. kann ich dir da weiterhelfen. *es sollten möglichst viele Dateitypen unterstützt werden: Der CodeProject-Link von HannesB geht doch bereits in die Richtung. *verwendete Programmiersprache C#: Kein Problem, wenn du es selbst machst *es wäre cool, wenn das System die Dokumente nach erstmaliger Indexierung überwacht": Ist auch geklärt *es sollte Dokumente in deutscher Sprache aufbereiten können: Das wird denke ich mal kein auf dem Markt befindlicher Indexierer leisten, da es über diese Grundaufgabe hinausgeht. Aber wenn du dir einen eigenen schreibst, könntest du den Text der Dokumente analysieren, und ab einem Schwellwort von x Prozent dt. Wörter das Dokument an ein externes Programm oder eigene Erweiterungen weitergeben.

Insgesamt ist natürlich wichtig, wieviel Aufwand du betreiben möchtest, um möglichst nah an deine Zielvorstellungen zu gelangen. Mit ein paar 100,- Euro könntest du natürlich auch ohne eigenen Aufwand eine Lösung entwickeln lassen, oder viel bei Google suchen, um möglichst adaptive Teilsysteme zu finden, welche exakt so miteinander kombiniert werden können und wenig bis garnichts kosten.

Aber da ja für einige deiner Punkte auch im Falle einer Eigenentwicklung bereits Komponenten existieren, schätze ich den Aufwand für ein solches System nicht allzu hoch ein (vorausgesetzt es soll keine hochskalierbares, 100%ausfallsicheres redundantes System sein).

Nobody is perfect. I'm sad, i'm not nobody 🙁

P
popel Themenstarter:in
13 Beiträge seit 2010
vor 13 Jahren

Hy,

danke erstmal für eure Antworten.
Ich finde es sehr schade, wenn es so etwas wirklich noch nicht geben sollte. Dann wird mir wohl nix anderes übrig bleiben als mir das alles selbst zusammen zu schustern.
Meine Befürchtungen sind nur die Performance und vor allem die Tatsache, dass die Dokumente ja nebenbei verwendet werden müssen.

Naja, ich werde mir das alles mal anschauen.

Für weitere Tipps und Vorschläge bin ich offen und würde mich darüber freuen.

... sind wir nicht alle ein bisschen popel 8o