Welche Hard- und Software ist für einen prof. Firebirdserver notwendig?

[Bernhard Geyer]

Zitat von Chemiker:

Er soll mit ca. 20 Usern verbunden werden.

Arbeiten die immer gleichzeitig?
Wieviel Inserts pro Tag/Stunde/Minute werden anstehen?
Wiviele Abfragen pro Tag/Stunde/Minute?
Wie groß wird die Datenbank werden? MB/GB/TB-Bereich?

[Bummi]

@haentschman
Eine "intelligente" Datenbank, bzw. auch ein Middeltier sind IMHO bezüglich der Datenintegrität und der durchgängigen Durchsetzung von Anforderungen, auch beim Zugriff durch gegf. später hinzukommende fremde Clientanwendungen bei größeren Projekten unabdingbar. Hier halte ich Trigger/Rechte und Prozeduren/Function(s)/Tables für die am einfachsten zu implementierenden Regelwerke. (Normale Anforderungen wie Normalisierung/ForeinKeys etc. betrachte ich hierbei als selbstverständlich).

[Furtbichler]

Eine VM ist imho keine gute Idee, denn die Netzwerklast wird hier ein Problem werden.

Für eine genaue Abschätzung benötigt man jedoch die von Bernhard angefragten Informationen.

[Bummi]

@Furtbichler

ich war auch erst (entsetzt) skeptisch als einige unserer Großkunden auf virtuelle Datenbankserver umgestellte haben. Musste meine Meinung aber mittlerweile revidieren, bei entsprechender Konfiguration sind die Teile doch recht leistungsfähig (und schnell an neue Anforderungen angepasst).

[haentschman]

Zitat:

Hier halte ich Trigger/Rechte und Prozeduren/Function(s)/Tables für die am einfachsten zu implementierenden Regelwerke. (Normale Anforderungen wie Normalisierung/ForeinKeys etc. betrachte ich hierbei als selbstverständlich).

... da sind wir uns einig, daß das normale Härte ist. (Datenintegrität) Ich meinte, daß die Datenbank nicht unbedingt für das Aufarbeiten von riesigen Datenmengen (Berechnungen etc.) herangezogen wird. Wenn das dann 20 Clients gleichzeitig machen ist schnell Schluß. Die 20 Berechnungen auf den jeweiligen Clienten fallen da nicht so ins Gewicht.

[Bummi]

hängt von der betroffenen Datenmenge ab, vor ich hier GB's über Netz ziehe wird in Prozeduren berechnet und die (kleine) Ergebnismenge geliefert. (rein persönliche Äußerung)
(hinzufügen muss ich dass ich mit Firebird so gut wie keine Erfahrung habe)

[Chemiker]

Hallo,

@haentschman: Das Netz sollte kein Problem sein ist erst vor 2 Jahren erneuert worden.

@p80286: XP-Prof. läuft zurzeit, aber es können nicht mehr als 10 Usern gleichzeitig arbeiten.

@Bernhard Geyer:

Zitat:

Arbeiten die immer gleichzeitig?

Über 10 wollen immer gleichzeitig arbeiten.

Zitat:

Wieviel Inserts pro Tag/Stunde/Minute werden anstehen?

100 Inserts pro Minute; können mit der Zeit noch mehr werden.

Zitat:

Wiviele Abfragen pro Tag/Stunde/Minute?

Alle 3 Minuten 1 Abfrage möglich, dass ist der max. Wert wird eher weniger sein.

Zitat:

Wie groß wird die Datenbank werden? MB/GB/TB-Bereich?

Zurzeit ist sie ca. 12 GB groß.
Das ist das was schon vorhanden ist, es soll aber noch 2 weitere Anwendungen (die noch in der Entwicklung sind) auch das Grundlage den FB-Server haben.
@Furtbichler: Die VM ist von unseren Admin vorgeschlagen worden.
@Bummi:

Zitat:

ich war auch erst (entsetzt) skeptisch als einige unserer Großkunden auf virtuelle Datenbankserver umgestellte haben. Musste meine Meinung aber mittlerweile revidieren, bei entsprechender Konfiguration sind die Teile doch recht leistungsfähig (und schnell an neue Anforderungen angepasst).

Welche Software habt ihr dafür verwendet?

Bis bald Chemiker

[Furtbichler]

Also eine VM (um das Thema nochmals aufzugreifen) hat bei einem Kunden zum kompletten Zusammenbruch der DB geführt, einfach weil tierisch viele Daten übers Netz in die DB geblasen werden und die VM-Umsetzung des Netzwerks nun einmal Overhead kostet.

Bei der prognostizierten Performance von knapp 2 Operationen pro Sekunde wird dieses Limit jedoch aller Vorausicht nach nicht erreicht werden.

Ich würde grundsätzlich einem DB-Server so viel CPU-Power und RAM wie irgend möglich spendieren, natürlich in Abwägung der zu erwartenden Arbeiten. So eine DB ist ein Numbercruncher, nur eben nicht mit FP, sondern mit Integerwerten (Das Aggregieren von FP-Feldern mal ausgenommen, aber das fällt nicht ins Gewicht).

Mit handelsüblicher Mittelklasseserverhardware fährt man i.A. sehr gut. Wir merken bei Neukunden sehr schnell, das es mit einer DB-Anwendung nicht getan ist, und dann ist es praktisch, beim DB-Server nicht gespart zu haben.

[Sir Rufo]

Also für eine VM spricht auf jeden Fall schon mal die Möglichkeit der einfachen Skalierung, 24/7 Betrieb bei einer sehr hohen Verfügbarkeit, nahezu hardware-unabhängig (Portierung auf neue Hardware), etc.

ABER, das gilt natürlich nur, wenn man darunter auch die richtige Hardware laufen hat, die dafür auch gedacht ist. Gerade beim Thema Festplattenzugriffe oder Netzwerk (wie ja schon angesprochen wurde) wird es schnell sehr teuer, wenn dort die Performance für mehr als eine VM hoch sein muss/soll und/oder Redundanz gefordert ist.

Somit kann es wesentlich kostengünstiger sein, dafür einen eigenständigen Rechner zu nehmen.
Im Falle eines Hardwaredefekts ist man allerdings mit der Wiederherstellung idR langsamer als mit einer (vernünftigen) VM Umgebung.

Es kommt wie immer auf den Geldbeutel und den Einsatzzweck an.

[p80286]

Zitat von haentschman:

Ich meinte, daß die Datenbank nicht unbedingt für das Aufarbeiten von riesigen Datenmengen (Berechnungen etc.) herangezogen wird.
...
Die 20 Berechnungen auf den jeweiligen Clienten fallen da nicht so ins Gewicht.

"Riesig"? Wenn Du ein normales Count oder ein paar Sum's auf dem Client ausführen willst, mußt Du erst die Daten über die Leitung quälen, da ist dann ganz schnell Schluß mit lustig.

Meiner Meinung nach ist der DB-Server genau dafür zuständig.

Gruß
K-H