nicht angemeldet
Bietet Perl genug Performance für eine Datenbank ?
Hallo Leute,
Das Problem:
Eine Datenbank mit bis zu 2000 Einträgen, als Texttabellen, Ein Datenfeld enthält auch längere Texte. Eine Abfrage soll bestimmte Datensätze selektieren, HTML-Seiten erstellen, und über CGI an den Client zurückgeben.
Das ganze in Perl (kein Fast -Cgi) oder eventuell in C++ realisiert.
Reicht für so ein Vorhaben die Geschwindigkeit von Perl ? denn es muss ja:
1. Das Script initialisiert werden.
2. Die Textdateien geöffnet und eingelesen werden.
3. Die Selektion erfolgen.
4. Die Htmlseiten erstellt und zurückgegeben werden.
Und das alles in ordentlicher Geschwindigkeit, und auch bei ordentlichem Verkehr.
eventuell wäre auch noch eine Volltextsuche über die Datenbank sinnvoll.
Bin für alle Meinungen zu dem Thema dankbar.
Gruß
Marko
-
Hallo Marko,
Klick mal auf den folgenden Verweis:
http://www.teamone.de/cgi-local/sfasuch.pl?DatenbankWaehrend du auf das Ergebnis wartest, wird ein ganz normales Perl-Script gestartet, dass eine ganz normale Textdatei durchsucht, die zum Zeitpunkt dieses Postings eine Groesse von ca. 14 MB hat (pro Woche waechst sie um ca. 300 KB).
Wenn dir das reicht, voilà!
viele Gruesse
Stefan Muenz-
hi!
Es stimmt schon - TextDB können eine sehr einfache und schnelle Lösung bieten, vorausgesetzt die Datei braucht nur ein mal von vorne bis hinten durchlaufen zu werden.
Allemein rate ich jedoch von der Verwendung von textDB's ab! Sie sind schwierig in der Wartung (Bsp.: Übertrag in Archiv, Datensätze mit bestimmten Kriterien sollen abgeändert werden, Datensätze sollen sortiert ausgegeben werden, Bestimmte Datensätze sollen gelöscht werden ...)
In solchen Fällen ist man mit einer DB und SQL immer besser d'ran. (Man braucht nur die Länge eines SQL-Befehles mit der Länge des Perl-Codes vergleichen, der für eines der oben genannten Bsp. von nöten ist)
Grüße
Manfredps. an Stefan: Das war jetzt lediglich meine Meinung (als jemand der in der Praxis beides ausprobiert hat), und KEINESFALLS ein persönlicher Angriff - SelfAktuell funktioniert ja sehr gut mit TEXT-DBs!
-
Hallo Fredy
Das war jetzt lediglich meine Meinung (als jemand der in der Praxis beides ausprobiert hat), und KEINESFALLS ein persönlicher Angriff - SelfAktuell funktioniert ja sehr gut mit TEXT-DBs!
Hab ich auch nicht so verstanden und stimme dir voll zu! Sobald man Datenbanken nicht nur durch "Anhaengen" aktualisiert und ansonsten nur ausliest, sind "richtige" Datenbanken die bessere Loesung.
Sag mal, ist es wirklich so schlimm, dass man sich im voraus entschuldigen muss, wenn man eine andere Meinung zu haben glaubt als ich? ;-(
viele Gruesse
Stefan Muenz-
Hallo ihr zwei!
Das war jetzt lediglich meine Meinung (als jemand der in der Praxis beides ausprobiert hat), und KEINESFALLS ein persönlicher Angriff - SelfAktuell funktioniert ja sehr gut mit TEXT-DBs!
Hab ich auch nicht so verstanden und stimme dir voll zu! Sobald man Datenbanken nicht nur durch "Anhaengen" aktualisiert und ansonsten nur ausliest, sind "richtige" Datenbanken die bessere Loesung.
Wenn man schon im voraus das Gefühl hat, daß die Datenmengen einen irgendwie dazu nötigen von Textdateien Abstand zu nehmen, kann man sich ja von Anfang an auf ein Modul wie DBI einschießen. Das hat zum einen den Vorteil, daß man die SQL-Mächtigkeit ausnutzen kann, auf die Freddy angespielt hat. Weiterhin kann man hier unterschiedlichste Datenbanktreiber einsetzen (DBDs), die einem von der "wriklichen" Datenbank abstrahieren lassen. So kann man dann (besonders anfänglich) auch Treiber für "Textdatei-Datenbanken" einsetzen. Man muß also gar keine Datenbank (Oracle, MySQL o.ä) installiert haben, wenn man das Skript entwickelt. Wenn einem dann später die Performance sorgen bereitet, kann reletiv einfach die Datenbank und den entsprechenden Treiber wechseln.
Jörk
PS: ähnliches gilt auch, wenn man auf einem Windows-PC arbeitet und ODBC nutzt (welches auch über DBI gehändelt werden kann)
-
Hallo und vielen Dank,
also das war es was ich wollte, einen allgemeinen Überblick, der die Entscheidung erleichtert. Die von Jörk vorgeschlagene Möglichkeit klingt sehr interessant, nur die Frage was ist DBI ? Und wo bekomme ich die entsprechenden Module ?
Und dann, funktioniert das alles, wenn ich einen normalen billig-Webspace mit FTP-Zugang und eigenem CGI-Verzeichniss (UNIX) habe, also kein Telnet o.ä. ? Datenbankserver ist leider etwas zu teuer.Gruss
Marko
Wenn man schon im voraus das Gefühl hat, daß die Datenmengen einen irgendwie dazu nötigen von Textdateien Abstand zu nehmen, kann man sich ja von Anfang an auf ein Modul wie DBI einschießen. Das hat zum einen den Vorteil, daß man die SQL-Mächtigkeit ausnutzen kann, auf die Freddy angespielt hat. Weiterhin kann man hier unterschiedlichste Datenbanktreiber einsetzen (DBDs), die einem von der "wriklichen" Datenbank abstrahieren lassen. So kann man dann (besonders anfänglich) auch Treiber für "Textdatei-Datenbanken" einsetzen. Man muß also gar keine Datenbank (Oracle, MySQL o.ä) installiert haben, wenn man das Skript entwickelt. Wenn einem dann später die Performance sorgen bereitet, kann reletiv einfach die Datenbank und den entsprechenden Treiber wechseln.
Jörk
PS: ähnliches gilt auch, wenn man auf einem Windows-PC arbeitet und ODBC nutzt (welches auch über DBI gehändelt werden kann)
-
Hi!
also das war es was ich wollte, einen allgemeinen Überblick, der die Entscheidung erleichtert. Die von Jörk vorgeschlagene Möglichkeit klingt sehr interessant, nur die Frage was ist DBI ? Und wo bekomme ich die entsprechenden Module ?
Und dann, funktioniert das alles, wenn ich einen normalen billig-Webspace mit FTP-Zugang und eigenem CGI-Verzeichniss (UNIX) habe, also kein Telnet o.ä. ? Datenbankserver ist leider etwas zu teuer.DBI steht für DataBase Interface. Die Module und weitere Informationen findet man unter anderem auf http://www.symbolstone.org/technology/perl/DBI/index.html
Ich bin mir nicht ganz sicher, ob die Installation des Modules zu einem Problem für Dich werden kann ... Möglicherweise sind dort systemabhängige Komponenten drin.
Jörk
-
-
-
Hi,
Sag mal, ist es wirklich so schlimm, dass man sich >> im voraus entschuldigen muss, wenn man eine andere >> Meinung zu haben glaubt als ich? ;-(
Das nicht, aber ich wollte nicht den Eintruck erwecken, daß ich, als jemand der dieses Forum intensiv nutzte, die Art kritisiere, wie es gamacht worden ist...
Grüße
fredy
-
-
-
-
Bin für alle Meinungen zu dem Thema dankbar.
Naja,
ich hatte auch mal so meine Bedenken... ein PERL/CGI-Script sollte 15 verschiedene Verzeichnisse dynamisch browsen, dass heisst, je nach Übergabeparameter sollte das Script in einer (von 15) bestimmten Directory alle HTML-Files mit dem "TITLE und Erstellungsdatum als Link" auflisten.
Das Scrpit sah am Ende so aus:
Alle ".htm"-Files in der als Parameter übergebenen Dir werden samt Pfadangabe auf ein Array gelesen.In einer FOR-Schleife ruft dann jedes Element des Arrays die Funktion (liestitel) auf, die die jeweilige HTML-Datei öffnet, den TITLEtag rausliest und wieder schließt. Eine weitere Funktion (liesdat) ermittelt das Erstellungsdatum. Print schickt dann den in dieser FOR-Schleife zusammengesetzten String "a href=..." zum Browser.
Als ich dieses Script das erste Mal auf meinem HOME-PC testete zerlegte sich meine Stirn in Falten <g>...
... aber als das Teil dann auf dem richtigen Server lief - waow, da ging die Post ab!
Will damit nur sagen, dass bei CGIs, die ja auf dem Server ablaufen - die Performanze in erster Linie von den Hardwarekonditionen (sprich CPU, RAM ... ) des Servers bestimmt wird. Die hat mit PERL (= Scripte die zur Laufzeit interpretiert werden) eigenlich weniger zu tun: auch EXE-Files können langsam sein --- ist das vielleicht der Hintergrund Deiner Frage?
RadlerWadeln grüßen ;-) Rolf