Beitrag von till (1103 Beiträge) am Sonntag, 2.Januar.2005, 19:24.
größere db - fragen dazu
hallo,
ich plane eine größere adress-db mit rund 40.000 einträgen in der endfassung. es werden 12-13 felder pro datensatz werden.
meine fragen (sorry: ich bin bei neuen (lizenz-)versionen NICHT auf dem stand der dinge):
a) lizenversion
muss ich bei einer lizenzversion auf einem virtuellen (premium)server bei domainfactory mit performance problemen bei einer db dieser größe rechnen ?
gibt es probleme, wenn IM NACHHINEIN z.b. schreibfehler bei feldnamen berichtigt werden müssen ?
werden verküpfte suchen (z.b. nach PLZ + 2 oder 3 felder) bei einer db dieser größe in venünftiger zeit erfolgen oder muss "gestückelt" werden ?
ist es möglich komplette backups der db mit bp bordmitteln zu ziehen ohne "krücken" benutzen zu müssen ?
b)
wie sieht das alles bei einer mietversion bei bp/netdirekt aus ?
zusätzlich:
wieviele user werden dort auf einen server (und was für einen ?) gelegt ?
till
Antworten
Beitrag von Friesecke (245 Beiträge) am Montag, 3.Januar.2005, 16:08.
Re: größere db - fragen dazu
Hallo Till,
bei einer großen db spielt die Anzahl der Felder (12, 13) zunächst mal keine Rolle. Wichtig ist dagegen die Anzahl der Felder, die sortiert
werden sollen. Denn die Sortierung kostet Zeit.
Es ist also weniger problematisch, eine db mit 40.000 Sätzen und einem Sortierfeld zu haben als eine db mit 30.000 Sätzen und 10 Sortierfeldern.
Verknüpfte Suchen sind in bp grundsätzlich problematisch, da bp keine Verknüpfung im Index ermöglicht. Du kannst ja pro Feld nur entscheiden, ob nach Text oder Zahl sortiert werden soll. Und Relationen kannst Du vergessen bzw. mußt Du selbst programmieren. Deshalb brauchst Du trotzdem nicht zu stückeln. Du kannst Dir den gewünschten Index selbst programmieren.
Dann passiert auch der Zugriff blitzschnell. Aber Du mußt auch unterscheiden, ob die Daten durch den Anwender angelegt werden oder über eine csv.Datei importiert werden. Das mußt Du unterschiedlich berücksichtigen.
Bei kompletten backups kann ich Dir keine aktuelle Information geben, weil ich das schon seit langem lasse. (Man kann den Tag auch anders verbringen.)
Aber auch hier gibt es Möglichkeiten, das selbst zu programmieren.
Zu Zeitproblemen insgesamt : Zeit kostet immer die Suche und Auswertung, nie das Anlegen eines Datensatzes. Daher ist entscheidend, daß Du Maßnahmen ergreifst, bei der Erfassung (!!!) Daten so zu prüfen und dann richtig abzulegen, daß Du bei der Auswertung schnell bist. Wenn Du die Datenanordnung so gestaltest (mit Unterstützung von Prüf- und Korrekturmaßnahmen bei der Erfassung), daß Du sie garantiert richtig und gut sortiert ablegst, dann brauchst Du bei der Auswertung keine Prüfungen.
Anderes Problem ist, wenn Du eine große Datenbank verknüpfen willst, evtl. mit einer weiteren recht großen. Da gibt es sicher Probleme.
Fazit : Gute Datenbankkenntnisse helfen enorm und können nicht durch noch so komplizierte perl-Befehle ersetzt werden. Probleme sind zu erwarten, müssen aber nicht sein.
Bei weiteren oder konkreten Fragen, melde Dich über meine mail, die Du ja kennst. Ich bin nur sehr selten hier im Forum.
Gruß
Antworten
Beitrag von till (1103 Beiträge) am Montag, 3.Januar.2005, 16:54.
danke erstmal .. CB sagst du bitte noch was dazu ?
christoph, könntest du bitte noch etwas konkret zu den angesprochenen punkten sagen ?
falls die datensicherung nicht möglich ist ohne (wie friesecke meint) einen tag einzuplanen, muß ich alternativen suchen.
ebenso bei performanceproblemen, egal wodruch verursacht.
ich bitte um auskunft.
till
Antworten
Beitrag von hempelr (1976 Beiträge) am Montag, 3.Januar.2005, 21:29.
Re: danke erstmal .. CB sagst du bitte noch was dazu ?
sorry, dass ich mich einklinke - aber ein paar Erfahrungen kann ich vielleicht beisteuern...
Punkt Datensicherung: Nur (oder am besten?) per FTP - bei vielen grossen DBs nur per DSL sinnvoll, ansonsten mit Provider klären, ggf. gegen Aufpreis Backup möglich, denkbar und m.E. am sinnvollsten wäre auch ein eigener Root-Server und ein zweiter für die Backups (gibt da ab und an u.a. auch bei netdirekt günstig welche)
Punkt Geschwindigkeit: Ist eh gröstenteils von deinem Programmierstil abhängig. Alles was du im get sinnvoll mit Sortierfeldern und Filterbedingungen erschlagen kannst, läuft sehr schnell.
Wichtig immer bei grossen DBs mit Range arbeiten, möglichst keine redundanten und/oder mehrfachen kompletten DB-Durchläufe mit get_while_get_next oder gar loop (bspw. um mehrfache Werte einzeln in Optionfelder aufzunehmen - dann lieber mehrere kleine DBs für solche Sachen nehmen und Relationen per Hand proggen - das ist eh die beste Variante)
Allerdings ist bei sehr komplexen Datenstrukturen mit diversen Relationen BP nicht mehr die geeignete Plattform - es sei denn, du nutzt das flache DB-Modell mit wenigen Sortier- bzw. Index-Feldern, die dann als Relationsfelder genutzt werden. (bspw. anstatt nach PLZ, Ort, Ortsteil jeweils getrennt zu sortieren ein zusätzliches Feld, das die Werte für PLZ, Ort und Ortsteil durch einen bestimmten String getrennt enthält als Sortierfeld definiert und die Eingabe dafür manuell im Template zusammengebaut, das Ausgeben dann danach sortiert macht das ganze erheblich schneller).
Punkt Virtueller Server: Generell Finger weg, die sind produktiv nicht sinnvoll einsetzbar, sind eher was für Script-Kiddis, die ihre ersten Schritte in Webserververwaltung gehen. (und wenn so ein Kiddi was testet, was den Server in die Knie zwingt, dann siehts erst richtig schlecht aus, ausserdem weisst man nie genau, wiviele VServer auf einem physikalischen am laufen sind.
Wenn man bp auf nem virtuellen Server laufen lässt und halbwegs ein paar Hits pro Stunde auf die Templates hat, dann wirste eh vom Provider schnell abgemahnt, dass zuviel Rechenzeit verbraten wird bzw. erhalten die Scripte je nach Provider nur so kleine Zeitscheibenanteile vom Gesamt-Server, dass die Laufzeiten inakzeptabel werden.
Für HTML und PHP ohne DB-Anbindung mags grad so schleichen, aber für mehr ist ein VServer rausgeschmissenes Geld, da biste mit nem normalen Multi-Domain-Account mit Perl/CGI mitunter noch besser bedient.
Punkt Datensicherheit bp-Intern: Da hat sich wirklich sehr viel getan, die DBs sind so ziemlich "unerschütterlich" geworden, hab schon ewige Zeiten keine Datenbank zum Abschmieren gebracht. Trotzdem (aus leidvoller Erfahrung aus frührern Zeiten) mach ich in jedem Fall vor ner Strukturänderung (und dazu gehört nunmal auch das Umbenennen von vorhandenen Feldern) eine Sicherheistkopie, das ist ja eh schnell gemacht.
Aber Friesecke hat wohl schon das wichtigste gesagt, das Datenbank-Design vor Beginn geplant erspart jede Menge Arbeit und Mehrarbeit. Bei komplexeren Programmen ist ein Umbenennen eines Feldnamens mit erheblichem Änderungsaufwand verbunden und birgt dann immense Fehlerquellen im Script.
Ich denke aber im grossen und ganzen sind 40.000 Datensätze mit ca. 15 Feldern eher "lustig" für BP - ich denke nur an die DB englisch-deutsch oder auch Geodaten, das zuckt ja überhaupt nicht...
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Dienstag, 4.Januar.2005, 14:37.
Re: danke erstmal .. CB sagst du bitte noch was dazu ?
Die Frage kann man nicht per se beantworten, denn Grösse hat nicht direkt was mit Geschwindigkeit zu tun. Es hängt viel mehr davon ab, was Du machst und wie. Wenn Du die 40.000 Datensätze alle auf einmal holen und damit womöglich noch wilde Berechungen anstellen willst, dann wird das entsprechend dauern und u.U. das Programm von nötigen Laufzeit/Speichersperren auf einem shared webhosting Server abgebrochen. Über virtual Server kann ich nichts sagen, nie benutzt, es gibt doch für ein paar Euro mehr bereits einen eigenen Server...
Verknüpfungen, auch mehrere, sind kein Problem. Hier spasseshalber mal mehrere Verknüpfungen bei > 100.000 Datensätzen:
http://baseportal.de/cgi-bin/baseportal.pl?htx=/baseportal/dict_de_en&q=a&Deutsch~=ab&Deutsch~=abe&Deutsch~=aber
Das sind 4 Verknüpfungen (wird zwar immer dasselbe Feld abgefragt, das macht aber keinen Unterschied), dauert 0.07-0.11 Sekunden... Kannst selber noch mehr anhängen und rumprobieren...
Richtig lange dauert "sort" mit mehreren Feldern (also z.b. "sort=Feld1,Feld2,Feld3"). Also sort bei grossen DBs unbedingt vermeiden.
Nur den Feldnamen zu ändern, sollte eigentlich keine Probleme geben, weil dort nichts an der DB-Struktur geändert wird. Felder einfügen oder löschen ist das was Zeit kostet und u.U. vom Provider abgebrochen wird. Die aktuelle baseportal-Version bietet aber hier die Möglichkeit durch (je nach Bedarf wiederholtes) Neuladen der Seite die Reorganisation an der abgebrochenen Stelle fortzusetzen, bis alles fertig ist.
Wo ist bei Backups mittels Archiven oder per FTP ein Problem?
Antworten
Beitrag von till (1103 Beiträge) am Dienstag, 4.Januar.2005, 19:28.
Re: danke erstmal .. CB sagst du bitte noch was dazu ?
hallo christoph und danke zuerst mal.
wild werden die abfragen nicht werden, aber schon so etwas wie
plz&fachrichtung&schwerpunkt&ort
wird es schon werden. wild berechnet werden wird da nichts weiter.
till
Antworten
