Interbase

[IBExpert]

die tpcc binaries hab ich mittlerweile, daher brauch ich von deiner seite eigentlich nur die
parameter bz batches, die du benutzt hast.

Meine ersten Ergebnisse zeigen interbase bei forced writes on ca. 0.5 % vorn und bei forced
writes off ca 2 % langsamer auf meinem Laptop, jeweils im 4wh setup.

hab da aber noch nicht alles zu ende konfigurert, zB nutzt fb3 by default over the wire encryption
und wenn ich richtig informiert bin (und das im protokoll auf tcpip ebene anschaue) macht Interbase
das nicht.

[danielmagin]

Jungs was gebt ihr euch da ein Battle. Ich schlage einfach vor ihr solltet die Test wie es sich für einen ordentlichen Test als Script in das Internet legen. So ist das alles transparent und man erspart sich das lästige Fingerpointing.

Eigentlich ist die Welt gross genug damit alle DB existieren können.

Auch sollte man sich überlegen wofür man welche DB benutzen will. Bei wirklich grossen mega Banchmarktest kommt man eigentlich nur auf die Gewinner MSSQL, Oracle und DB2. Dies sind die einzigen DB die wirkliches Clustering, Balancing und Replikation aus der Engine heraus können. Weder IB und FB kann das aus Haus aus nur mit "waghalsigen" Konfigurationen. Auch sind beide nicht wirklich auch Cloudfähig und somit auslagerbar.

Ob jemand dem Support aus dem freiwilligen OpenSource Bereich oder lieber von einer Firma gestützt haben will muss jeder selbst entscheiden und sich eine Meinung bilden.

Ja ich persönlich bevorzuge IB aber das ist meine persönliche Sympathie und bin damit nie schlecht gefahren. Aber das können auch andere von FB sagen.

Also legt die Scripts oder Tests (wenn dann bitte mit Sourcen, am besten Delphi) in Netz oder lasst es. Ach ja und schreibt die Tests so das man auch die Database Zugriffs Komponenten austauschen kann, diese beeinflussen auch sehr die Ergebnisse.

[IBExpert]

Ich für meinen Teil bevorzuge ja nun wie bekannt FB und habe auch schon eine ziemlich ähnliche Umgebung mit IB und FB getestet, aber
bin zu völlig anderen Ergebnissen und stehe weiterhin zu meiner Aussage.

Und ich will weder hier noch sonstwo Ergebnisse aus einem nicht fair dokumentierten Test auf Basis eine ähnlichen tpc Umgebung
veröffentlichen, sondern werde das erst machen, wenn es sauber dokumentiert ist udn wenn dabei IB bei einigen Test schneller
sein sollte, werde ich auch das dokumentieren.

Den Hinweis von Matthias, das er die Konfiguration und Daten aus seinem Test nicht veröffentlichen darf
("Testkit kann ich nicht zur Verfügung stellen.... siehe TPC.ORG")
kapier ich nicht so ganz, weil es nur um die Konfigurationsfiles bzw Aufrufparameter ging und nicht um die Binaries.

TPC C basiert auf Binaries, die mit Kommandozeilenparameter aufgerufen werden. Wenn man die Parameter nicht kennt, braucht man sich
über das Ergebnis auch keine Vergleiche anstellen. Jeder kann die Parameter so lange drehen, bis die Ihm selber passen.

TPC C ist meiner Meinung nach auch zu wenig auf Schreiblast ausgelegt, aber das ist nur mein Eindruck.

Jeder, der mit der Interbase Funktionalität, Stabilität, Performance und der Lizensierung klar kommt, hat erst mal keinerlei Grund,
das in Frage zu stellen und zu wechseln.

Ob aber das was man mit diesen Datenbanken machen kann, "waghalsige" Konfigurationen sind, hängt immer mit der eigenen Perspektive
zusammen. Meine Perspektive ist da eine deutlich andere und bei 160+x Standorten mit async Multimasterreplikation sind die
Lizensierungsbudgets bei den genannten Kandidaten schon deutlich im 7 stelligen Eurobereich und diverse Gründe sprechen
dafür, dieses Projekt nicht in die Cloud zu verlagern.

Telekom Störung im März

Wenn du mal eben an 50 % der Standorte (so viel waren an dem Tag zwischen 10 und 15 Stunden offline) alle Kunden nach Hause
schicken kannst, dann wird jede Einsparung durch Cloud Lösungen sich ganz schnell in Luft auflösen, aber ein schönes
Geschäftsmodell für Kundenerpressbarkeit.

Tppfehler bei Amazon
Cloudservices sind von Hochverfuegbarkeit weit entfernt