Interbase

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

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.

Und geht bitte nicht davon aus, das es Support nur bei IBPhoenix gibt, zum Glück gibt
es im Firebird Umfeld weit mehr Anbieter als nur IBPhoenix, irgendwelche Pauschalpreise,
die irgendwas abdecken, kommen eh im Open Source Umfeld nicht gut an.

Unser größtes Multimaster Replikationsprojekt bei einer sehr stark wachsenden Gastronomie
Kette, die einige sicherlich auch von persönlichen Besuchen kennen und deren Business
Software mit Delphi entwickelt wird, verbindet im Moment 140 Standorte in Deutschland mit
einer Datenbankserverhardware von uns. Da haben wir jeden Tag ca 1.5 Millionen
neue Datensätze zu verteilen, mit allen Zielen ergeben sich da ca 15 Millionen
Replikationsvorgänge innerhalb von 24 Stunden, da nicht jeder alle Daten bekommt.

Das Projekt ist real existierend und pro Standort zahlt der Kunden inkl Hardware, Software
und DB mit Replikation nicht mal 1000 € einmalig und zzgl ca 80 € Wartung pro Jahr.

Wir haben sämtliche Datenänderungen der letzten 3 Jahre im Log und können bei
Bedarf Techniken aus anderen Projekten ergänzen, mit denen beliebige Transaktionen
aus dem Log auch Jahre später noch rückgängig gemacht werden können (versehentlich
gelöschte Datensätze o.ä.). Das was wir da machen ist beim besten Willen eine ganz
andere Baustelle, als das was man sich mit IBReplicator zusammenklickt und auch die
Features von Interbase zum Thema Replikation würden an den Anforderungen garantiert
gnadenlos scheitern. Wenn ein Server offline ist (internet weg), kann der trotzdem
an dem Standort weiterarbeiten und synchronisiert sich automatisch sobald wieder
online ohne admin Eingriff.

Wenn übrigens schon Preise in den Raum geworfen werden und sich jemand die Mühe macht, das
englische Original in deutsche zu übersetzen, dann bitte auch die deutschen Preise einsetzen
Laut dieser Webseite https://www.embarcadero.com/de/app-d...tore/interbase
kostet Interbase Unlimited € 9621,15 und nicht nicht 7030 US$. Und im Grundpreis sind
nur 8 cores freigeschaltet. Weitere 8 Cores kosten je noch mal 1480 €.

Bei den Preisen seit Ihr da fast auf MSSQL Server Niveau, der bietet aber noch mal deutlich mehr
als interbase.

Um die o.a. Architektur abzubilden hätten wir mindestens 12 Interbase unlimited
kaufen müssen und weiter über hundert weitere it mindestens 5-10 Usern.

Und ja, ich weiss, da gibt es das VAR Programm, mit dem das alles viel preiswerter gehen könnte
usw.

Ich für meinen Teil schau mir aber auf jeden Fall mal deinen Test genauer an und würde
mich durchaus drauf freuen, wenn wir uns da zB auf den Forentagen auseinandersetzen
können, auch wenn wir dann das anschliessende Bierchen getrennt zu uns nehmen müssen

[Uwe Raabe]

Zitat von IBExpert:

Laut dieser Webseite https://www.embarcadero.com/de/app-d...tore/interbase
kostet Interbase Unlimited € 9621,15 und nicht nicht 7030 US$.

Um präzise zu sein: Da wir den privaten Nutzer hier getrost außen vor lassen können ist der effektive Preis 8.085,00 € - die Mehrwertsteuer ist hier eher nicht relevant.

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