Hallo, ich brauche mal ein paar Tipps von Datenbankexperten. Mal angenommen man hat einen Roman (500 Seiten mit 2500 Zeichen / Seite) welcher in eine Datenbank gespeichert werden soll. Über ein Webformular soll man die Möglichkeit haben nach Textabschnitten zu suchen. Bei einem Suchergebnis wird die Seitenzahl ausgegeben. Frage: 1) Welche Datenbank würde man hierfür typischerweise benutzen? (Diese sollte auch eine performante Suche ermöglichen und unter Linux / Debian laufen). SQL, Mongo DB, Coach DB,...? 2) Mal angenommen man verwendet eine SQL DB. Wie soll der Text/Daten getrennt werden? Soll jeder Satz in ein eigenes Feld gespeichert werden oder soll jede Seite in ein eigenes Feld? 3) Mal angenommen man müßte später eine gesamte Bibliothek in der DB speichern, welche Möglichkeiten zur Optimierung der Suchperformance bzw zur effizienteren Datenspeicherung würden sich anbieten?
:
Bearbeitet durch User
Der Hein schrieb: > Mal angenommen man hat einen Roman (500 Seiten mit 2500 Zeichen / Seite) > welcher in eine Datenbank gespeichert werden soll. Über ein Webformular > soll man die Möglichkeit haben nach Textabschnitten zu suchen. Bei einem > Suchergebnis wird die Seitenzahl ausgegeben. > > Frage: > > 1) Welche Datenbank würde man hierfür typischerweise benutzen? Womöglich gar keine? Ich sehe bei dem hier beschriebenen Anwendungsfall erstmal so noch nichts, wofür man zwingend eine Datenbank bräuchte. Einen Roman kann man zum Beispiel auch als PDF-Datei auf einem Webserver ablegen. Für das Durchsuchen eines PDFs gibt es entsprechende Tools/APIs in verschiedenen Programmiersprachen wie zum Beispiel: C++: Xpdf http://www.foolabs.com/xpdf/about.html Python: pdfminer https://pypi.python.org/pypi/pdfminer/ PdfSearch http://sourceforge.net/projects/pdfsearch/ Für weitere siehe: List of PDF software http://en.wikipedia.org/wiki/List_of_PDF_software Eine weitere Möglichkeit wäre ein Ablegen als HTML-Datei, bzw. in mehreren HTML-Dateien. Auch die kann man ganz normal auf einen Server kopieren. Den Inhalt der Dateien kann man mit jeder Programmiersprache durchsuchen, die File I/O beherrscht. Das dürften so ziemlich alle sein. Naja man wird es vielleicht nicht gerade in Assembler machen wollen :-) Nicht alle Daten kommen in die Datenbank. Insbesondere bei statischen Daten, die sich sowieso nicht ändern, ist das eher witzlos. Der Sinn und Zweck von Datenbankanwendungen ist es ja gerade, Änderungen an den Daten vornehmen und speichern zu können.
:
Bearbeitet durch User
Neuere Versionen von MySQL bzw. MariaDB (und sicher auch andere) beherrschen von Hause aus eine Volltextsuche ... gut verpackt in hochoptimierten Algorithmen. Ich würde also die Originaldokumente als PDF/A oder EPUB speichern, versehen mit Absatzmarken und den ASCII-Text in der DB. Bei einem Match erfolgt der Link auf den entsprechenden Absatz nebst zusätzlichen Infos zu Autor, Werk, Kapitel, Seite usw.
Mark Brandis schrieb: > Nicht alle Daten kommen in die Datenbank. Sehe ich auch so. Aber wenn es eine Datenbank machen soll, dann MySQL. Viele Sachen im Internet laufen darüber.
Für eine Bibliothek würde ich auf jeden Fall entsprechende Indices verwenden (z.B. alle Wörter im Text). Ob das MySQL derzeit für Textfelder anbietet weiß ich nicht. Überlegenswert wäre auf jeden Fall auch ein Bigram Index, oder sowas in der Art, damit man auch trotz Tippfehler die richtigen Textpassagen findert. Aber da müsste man vermutlich wirklich die Experten auf dem Gebiet fragen. Ich weiß das bei größeren Projekten in diesem Feld Oracle verwendet wir da bestimmte Funktionen bei MySQL derzeit einfach noch nicht existieren (hab mal von einem Kollegen gehört die bei Linguistischen Datenbanken z.B. stored procedures anwenden) Bei aktuellen und sinnvollen Metadaten in der Datenbank könnte es, ja nach Anforderung, sogar reichen nur das PDF als Volltextversion abzulegen. Lg, Sepp
Hallo, dein Problem ist ein Thema für NoSQL Datenbanken wie MongoDB oder Redis. Die einen nicht-relationalen Ansatz verfolgen. Auszug aus Wikipedia: "Relationale Datenbanken leiden üblicherweise unter Leistungsproblemen bei datenintensiven Applikationen wie Indexierung von großen Dokumentmengen..." Es ist ja nicht so das du gerade das erste Bibliotheksprogramm erfindest :-) Damit haben sich schon Leute beschäftigt. Grüße aus Berlin
Ich würde das Problem etwas mehr strukturieren. Zum einen brauchst du ja eine (effiziente) Suche. Hierfür brauchst du eine Komponente, die dir die Fundstellen zu einen Begriff zurückliefert. Je nachdem wie man suchen möchte wäre ein Index evtl. von Vorteil. Vielleicht reicht auch eine einfache Textsuche. Wenn du einen Index verwenden willst und dabei auch einen erweiterten Suchausdruck umsetzen willst würde ich z.B. mal Apache Lucene oder auch den Volltext-Index von Mysql anschauen. Zum anderen brauchst du eine Ablage der Dokumente, damit man schnell darauf zugreifen kann. Von meiner Begriffsauslegung her brauchst du dafür eine Datenbank (=System zur elektronischen Datenverwaltung) und zwar egal ob du ein Standard SQL-DBMS, NoSQL oder auch eine eigene Datenbank damit meinst, die die Dokumente als Dateien ablegt. Ich würde die Wahl aber eher von Suche abhängig machen. Schliesslich soll die DB deinen Anwendungszweck unterstützen und nicht als Selbstzweck benutzt werden. Irgendwie musst du dir ja auch noch Gedanken machen wie die Seitenzahl eines Buches erhalten bleiben soll. Eine reine Textdatei ist sicher gut für die Suche und effizient zum speichern, aber lässt eine beliebige Interpretation der Ausgabe und damit der Seitenzuordnung zu. Vielleicht wäre hier eine Art Markup, z.B. XML von Vorteil. Dann könnte man über Lucene und dessen Meta-Daten einfach auf ein XML-Path verweisen und man bräuchte nicht mal ein ausgewachsene DBMS dafür.
Mag mir jemand nebenbei erklären, wozu eine Volltextsuche(!) in Büchern einer Stadtbibliothek nötig sein soll?
Rufus Τ. Firefly schrieb: > Mag mir jemand nebenbei erklären, wozu eine Volltextsuche(!) in Büchern > einer Stadtbibliothek nötig sein soll? Ich war zwar schon länger nicht mehr in einer physikalischen Bibliothek, aber die Google Büchersuche war mir schon oft eine Hilfe, wenn ich nach bestimmten Begriffen gesucht habe. So findet man dort auch Bücher die einen Begriff wie z.B. "neonicotinoids" nicht im Titel haben. Ich halte das für sinnvoll.
Das ist für die Hausaufgaben :-) Du musst 'Die Leiden des jungen Werthers' nicht lesen, kannst aber auf Knopfdruck die Seitenzahl nennen auf der ein bestimmtes Zitat steht.
zu 1 Alle "ausgewachsenen" Datenbanksysteme können das. PostgreSQL hat ebenfalls Funktionen für die Suche in Texten drin. zu 2 Einen Text in Sätze aufzuteilen ist keine triviale Aufgabe. Ob es dir gelingt, aus einem Textdokument Informationen über die Position auf bestimmten Seiten zu gewinnen ... das ist sehr vom Dateityp bzw. vom Erstellungsystem abhängig. Glücklicherweise sind die existierenden Volltextsuchsysteme nicht wirklich darauf angewiesen. zu 3 Bei SQL-Datenbanken kann man Partitionierung nutzen. Aber ... Die bessere Technik für die Suche in Texten bietet Lucene bzw. Solr. http://lucene.apache.org/ http://lucene.apache.org/solr/ http://de.wikipedia.org/wiki/Apache_Lucene Durch die bei Lucene verwendeten Techniken ist das System gut skalierbar hinsichtlich Größe des Dokumentenbestands und Suchperformanz. Es gibt auch einige Firmen, die Unterstützung bei der Einführung oder spezielle Erweiterungen anbieten.
Der Hein schrieb: > 1) Welche Datenbank würde man hierfür typischerweise benutzen? Du willst dasselbe wie Google. Und Nein, da ist kein SQL dahinter. Sondern ein inverted tree. Und die Auswertung und Suche erfolgt mehrstufig und verteilt auf mehrere Prozessoren. In der Praxis würdest du Google deine Bibliothek indizieren lassen und nur noch das Ergebnis der weitergeleiteten Suchanfrage bearbeiten
Rufus Τ. Firefly schrieb: > Mag mir jemand nebenbei erklären, wozu eine Volltextsuche(!) in Büchern > einer Stadtbibliothek nötig sein soll? Nach gedruckten Büchern kannst du nach heutigem Stand - inhaltsbezogen - fast garnicht suchen. Außer den bibliographischen Angaben steht bestenfalls ein Kurztext zur Verfügung, oft der (gekürzte) Klappentext, der mehr auf Verkaufsförderung als auf den Inhalt ausgerichtet ist. An ein Abstract eines technischen oder wissenschaftlichen Papers kommt das nicht ran. Prinzipiell finde ich Volltextsuche (zumindest als Fallback) eine gute Sache. Ich suche oft genug in der Wikipedia und finde nur in den Ergebnissen der Volltextsuche passende Treffer. Gut, bei Unterhaltungsliteratur müsste ich mir auch erstmal Suchanfragen überlegen. (In welchen Simmel trifft ein Erich auf einen Elch, der anschließend von einem Ferrari angefahren wird, sowas in der Art ;-) Man darf aber nicht davon ausgehen, dass eine Volltextsuche den vollständigen Text kennt. Da gibt es z.B. bei PDF-Dokumenten durchaus einige Lücken, noch schlimmer eingescannte, OCR-behandelte Dokumente.
For Volltextsuche in einer Menge Büchern wird man keine normale SQL-Datenbank verwenden. Auch wenn die inzwischen Volltextsuche ganz gut können ist eine optimierte Lösung wie Solr oder Elasticsearch da besser geeignet. Spätestens wenn man so Sachen wie Stemming (Suche nach Wortstamm) und ähnliches sauber implementiert haben will.
Konrad S. schrieb: > Ich suche oft genug in der Wikipedia und finde nur in den Ergebnissen > der Volltextsuche passende Treffer. Ich benutze Wikipedia nur über google, d.h. ich suche nach "Suchbegriff wiki". Liefert bessere Ergebnisse :-) Für mc.net gilt ähnliches.
le x. schrieb: > Ich benutze Wikipedia nur über google, d.h. ich suche nach "Suchbegriff > wiki". Ich meide die großen Datensammler. Leider geht es nicht ganz ohne sie. :-( > Liefert bessere Ergebnisse :-) Ja. Braucht schon ein "gewisses" Engagement um bessere Treffer als Google zu liefern.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.