Interbase

[MEissing]

Zitat von IBExpert:

Das ist doch schon mal ein Ansatz. Wenn ich mal Zeit hab schau ich mir das auch noch an,
aber auf den ersten Blick IB journaling+async writes gegen Firebird sync writes ist ja
schon mal nicht so ganz zu ignorieren. Ich werde mal bei Gelegenheit bei Varianten
auf Ausfallsicherheit und vergleichbaren Einstellungen testen. Traue keiner Statistik,
die du nicht selber gefälscht hast ....

Sehr gerne..... Deine Aussage "Zeig mir irgendwas, das Interbase schneller kann." kann damit als abgehakt gelten?!?

TPC ist nun nicht irgendein Benchmark eines x-beliebigen Tools.....

Zitat von IBExpert:

Wie Ihr auf die 10000, 20000 oder 50000 US$ Support in dem Dokument kommt, erschliesst sich mir
auch nicht wirklich, außer man will explizit einen teuren Mitbewerber als Vergleichsmaßstab.

Auf die Preise will und werde ich nicht näher eingehen..... mit ging es (und geht es) ausschliesslich um deine Aussage
"Zeig mir irgendwas, das Interbase schneller kann."

Nur soviel: MS SQL Server ist noch deutlich teurer... Siehe dir Core-Licensing (min 4) und rechne das mal auf 8 Cores hoch...

[IBExpert]

Zitat von MEissing:

Sehr gerne..... Deine Aussage "Zeig mir irgendwas, das Interbase schneller kann." kann damit als abgehakt gelten?!?

Ja und Nein, bisher sehe ich ein Testergebnis, das für Interbase eine höhere Zahl anzeigt, wobei ich aber die Rahmenbedingungen nicht kenne und die sehr unterschiedliche Auslastung der HDD ist schon ein deutlicher Hinweis darauf, das da nicht mit gleichen Einstellungen gearbeitet wurde.

Was wäre denn das Interbase Ergebnis ohne Journaling und mit Forced Writes? Über die Vorteile von Forced Writes unter Windows brauchen wir uns nicht streiten, journaling hin oder her ....

Sobald ein Windows Prozess Dateien im Filesystem ablegen will und das Betriebssystem die Dateien nicht sofort in korrekter Reihenfolge schreibt, fängt Windows an, beim Schreiben selber die Reihenfolge innerhalb der Dateien zu optimieren und das setzt das Prinzip außer Kraft, das über Jahre hinweg Interbase und Firebird als kaum kaputtbare Datenbank etabliert hat.

Durch minimale Änderungen in der Konfiguration kann ich bei Firebird mit forced writes off arbeiten und mit MaxUnflushedWrites und MaxUnflushedWriteTime in der config das Datenverlustrisiko minimieren. Es kommt also im Vergleich immer drauf an, was man im Vergleich bei der Gegenseite optimiert. Aufgrund aktueller Hardware und schneller verfügbarer SSDs ist die Notwendigkeit solcher Workarounds immer unwichtiger, es sei denn man setzt Interbase oder Firebird auf Schrotthardware ein, was leider häufiger vorkommt als man denkt und was keineswegs durch einen hohen Anschaffungspreis der Hardware ausgeschlossen ist.

Für das Journal empfiehlt der Hersteller Embarcadero ein eigenes Laufwerk (http://docwiki.embarcadero.com/Inter...urnaling_Works
"For best performance, place the journal files on a dedicated hard drive"). Jedes Drive kann damit für sich für den Totalausfall der DB sorgen, DB ohne Journal ist unbrauchbar und Journal ohne DB auch.

Ich werd mir auf jeden Fall mal bei Gelegenheit anschauen, was Interbase bei aktiviertem Journal auf nur einer Platte so macht, ein Tool wie der process monitor von sysinternals.com ist das ausgesprochen hilfreich. Es geht mir aber nicht darum, das Interbase da nicht wirklich gut sein darf, sondern darum, das ich für mich und ggf auch für Leser hier wissen will, was die Rahmenbedingungen sind und welche Leistungen damit erreicht werden.


Kannst du mir das von dir verwendete Testkit zur Verfügung stellen? Wäre blöd wenn wir da immer mit unterschiedlichen Versionsständen oder ganz anderen Ausschnitten
aus den großen tpc benchmark sets testen.

[MEissing]

Ergebnis ohne Journaling hatte ich angegeben....

(Da ich wusste, daß du das anzweifelst.... Und Journaling ist nicht ASYNC )

Testkit kann ich nicht zur Verfügung stellen.... siehe TPC.ORG

[IBExpert]

daher ist das ja schwierig, das zu vergleichen, die von dir zitierte Webseite
https://www.embarcadero.com/de/produ...rbase_firebird
zeigt in der Grafik eindeutig interbase async gegen firebird sync

ich werde mir mal eine langweilige Zugfahrt oder Wartezeit am flughafen vornehmen,
und das mal zu vergleichen, auch wenn andere das vielleicht für Haarspalterei
halten, ich finde das gut und hab spaß dran

[MEissing]

Journalling ist *nicht* ASYNC..... es ist das beste aus beiden Welten: ASYNC zur Datenbankdatei, aber SYNC zum Journal.

(Ja... Spaß macht mir das auch... solange es ergebnisoffen ist)

[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.