Sponsored Links |
|
||||
MySQL funktioniert genau so zuverlässig wie andere DBMS.
Wir setzen unter anderem auch MySQL ein, die aktuell verwendeten Versionen sind etwas älter, laufen aber absolut stabil. Ich wüsste keinen Grund, der dagegen spricht. |
Sponsored Links |
|
||||
Merci Inta,
mein Problem: Ich bin mit einer damals neuen Version von dBASE IV mal recht derb auf die Nase gefallen und habe mir vorgenommen, mich nie mehr auf fertige Pakete zu verlassen. Das zu bauende System wird >10 Jahre in Betrieb sein und ich muß einfach vorher wissen was mich erwartet. Mache ich Fehler kann ich sie beheben... Wenn ich mir da eine Gurke einfange habe ich ein echtes Problem. |
|
||||
Nuja, da kann ich dir auch viel erzählen wie stabil die 4er bei uns auch unter viel Last läuft, garantieren kann ich dir natürlich nichts. Wenn du Sicherheit/Support brauchst, dann kannst du auf die Enterprise Varianten zurückgreifen, die kosten dann halt entsprechend - dürften aber von der Stabilität der freien Variante entsprechen.
Hast du MySQL einfach mal installiert und damit getestet? |
|
||||
Ich habe mySQL noch nicht ausprobiert.
Wenn da Probleme auftauchen sollten, dann vermutlich erst wenn ich nicht mehr wechseln kann - das ist genau das Problem. Schreibe ich die DB selbst habe ich wenigstens die Chance den Fehler zu finden und auszumerzen. Bei einem fertgien Produkt (egal ob OSS) nicht. Die Probleme auf die ich auflaufen werde sind die Klassiker: Record-Locking. Wie setze ich den timeout ? Die eigentliche Datenbank ist eindimensional. Alle anderen sind eher Konfigurationsfiles. Ich muß auch etwas auf die Performance schauen. Von den kommerziellen Produkten war bisher Btrieve mit Abstand das schnellste. Meine ideale Datenbank würde fest im Speicher liegen (so in etwa wie eine RAM-Disk oder ähnliche Mechanismen) und die Abfragen bearbeiten ohne etwas nachladen zu müssen. Bei Novell hatte so etwas mal probiert. Beim Apache fehlt mir da noch der Einstieg. Ich habe für jeden Kunden min. einen Server zur freien Verfügung, zumindest das wäre kein Problem. |
|
||||
hm, ich würd' mich an Deiner Stelle erstmal ein wenig da einlesen und ein paar Tests fahren.
Wenn Du Dich so lange binden musst, dann dürfte ein wenig Zeit zum Testen ja drin sein. Klar, dass man nicht alles Testen kann, aber zumindest bekommt man ein Gefühl dafür. |
|
||||
Kurz mal der grundlegende Aufbau:
* Organisiert ist alles nach Jahren (zB 2008, 2007, ...) und Dokumententyp (zB Lieferscheine, Rechnungen ...) (einfacher mit Backups und Löschen nach der Aufbewahrungsfrist) * Innerhalb eines Typs und Jahres habe ich das nach Bestandsdaten (PDF, TIFF, Text etc) und Indexrohdaten organisiert (Vorteil: Backups, Dateigrößen unter 4 GB). Aus den täglichen Indexrohdaten erstelle ich die Suchindices, es sind im Prinzip nach dem Suchbegriff sortierte Tabellen, bei einigen zusätzlich noch Hashtabellen. Pro Jahr und Dokumententyp sind es im Moment mehr als 120 GB. Eine einzelne Indexdatei liegt bei ca 700 MB. Funktionieren tut das prima, das System hat sehr kurze Responsezeiten und läuft zuverlässig. Jetzt will das halt einer als Workflowsystem, also muß ich die komplette Indizierung änderbar machen dh, diesen durch eine Datenbank ersetzen. Jetzt wird's halt eklig: Es laufen täglich Daten rein, es muß also auch täglich indiziert werden. Momentan läuft der komplette Vorgang (Dateimport und Indizierung) ca. 3 h, das geht noch, die restlichen 21h ist das Archiv verfügbar. Ich hatte das vor Jahren schon mal probiert, also einen Lauf mit Btrieve Import und einem mit meinem System. Letzteres war ca 20 mal schneller. 3h mal 20 wird eng |
|
||||
Zitat:
Wenn du Test- oder Originaldaten hast, dann würde ich wie schon vorgeschlagen wurde ein paar Testcases basteln. |
Sponsored Links |
|
||||
*ächz* 10 Jahre dumpen und neu Einlesen ... Never ...
Was dabei so ewig dauert ist das Aktualisieren der Indices nach jeder Änderung. So mache ich das einmal zum Schluß. Wenn ich 100 Mio Sätze einlese gibt das einen sehr deutlichen Unterschied. Die Indizierung ist auch geteilt, ich habe keinen binären Baum sondern nur eine einfache Tabelle mit den sortieren Suchbegriffen/Indexdaten. Der Rest läuft dann bei der Suche. Bei den dicken Dingern habe ich den ersten Treffer bzw eine Aussage ob's überhaupt da ist nach max 15 Vergleichen. Während der suche müssennoch die Benutzerrechte festgestellt und gewertet werden, natürlich mit Gruppenrechten, IP-Adressen und anderem Krempel. Die Trefferliste wird dann im Browser angezeigt und per Klick ist dann das PDF da. Das Teil ist recht komplex, dazu kommen noch jede Menge Im- und Exportmöglichkeiten, bis zur autonom laufenden CD mit zertifizierten Dokumenten (und einem kleinen PDF-Interpreter ). Ich denke, das gibt PHP nicht mehr her, dafür ist es auch nicht gemacht. Ich muß das mal ausprobieren bin aber etwas skeptisch (deshalb frage ich ja hier mal). Im Normalöfall sind ans Web geklemmte Datenbanken, glaube ich, etwas kleiner Edit: Noch ein gravierendes Problem: Migration. Wenn's dumm läuft habe ich alle Jahre eine neue Datenbankversion und kann die Datenbanken migrieren. Dann gute Nacht. |
Sponsored Links |
Stichwörter |
datenbank, mysql, volltextsuche |
|
|