|
Datenbank: Interbase • Version: XE7 • Zugriff über: FireDac
Interbase
Setzt hier jemand Interbase bei Kunden ein?
Wenn ja, wo seht Ihr die Vorteile gegenüber Firebird? (vom Preis mal abgesehen) Habe hier eine Anfrage ein altes Projekt in einem Fertigungsbetrieb zu übernehmen und zu erweitern. Interbase ist da noch auf Version 5.x. Ich spiele eigentlich mit dem Gedanken alles auf Firebird umzustellen (Bleibt vom Budget mehr bei mir hängen ;-) |
AW: Interbase
Die Anzahl der Antworten sollte dir schon eine Antwort geben, mein Tip: Der Umstieg auf FB lohnt sich nicht nur wegen
der Einsparungen der Lizenzkosten. Hier und da bekommen wir noch seltene Anfragen von Interbase Anwendern, um das was zu ergänzen oder oben drauf zu programmieren und es ist aus meiner Sicht die Höchststrafe, was bei Interbase alles nicht verfügbar ist. Die Liste aufzuzählen spar ich mir mal, insbesondere aber ist ein Umstieg von einer älteren Interbase Version auf eine neuere nicht wirklich von Vorteil gegenüber einem Umstieg von einer älteren IB Version auf FB 25 oder auch gleich auf FB302 |
AW: Interbase
Aha.
Wenn nach 6 Stunden keine Antwort kommt, dann lässt das "natürlich" Rückschlüsse auf die Verbreitung zu?!?! InterBase hat definitiv Vorteile, wenn es um die Skalierung über mehrere Cores/CPUs geht... auch oder insbesondere ggü einem Firebird 3.0x. Über Datenbank/Tabellen/Spalten-Verschlüsselung wollen wir gar nicht reden... Von daher: Leben und leben lassen |
AW: Interbase
Die Auswahl einer Datenbank sollte nicht vorrangig nach der Beliebtheit vorgenommen werden.
Entscheidend ist eher die erforderliche Leistung dann die Kosten. Auch sollte man die Kosten eine Umstellung eines Projektes auf eine andere DB nicht unterschätzen. |
AW: Interbase
@Fritzew: Vereinfacht gesagt sind InterBase und Firebird komplett unterschiedliche Produkte (mit gemeinsamen Wurzeln) geworden. Beide Produkte/Projekte haben den Fokus auf unterschiedliche Themen gelegt.
Embarcadero (natürlich Pro InterBase) bietet zB folgenden Vergleich mit Schwerpunkten wie Security, Betrieb, Performance an:  https://www.embarcadero.com/products...rbase_firebirdder ganze Performance-Vergleich mit InterBase ASYNC writes vs. Firebird SYNC writes hinkt womöglich ein bißchen ... Ziemlich neu von IBSurgeon halt in Richtung SQL-Sprachkonstrukte/Konformität (das ist das was Holger gemeint hat, dass hier Firebird aus SQL-User Sicht mehr bietet) etc. http://ib-aid.com/en/articles/differ...and-interbase/Dh. beide Produkte haben sich mit unterschiedlichen Schwerpunkten weiterentwickelt. Hier muss sich jeder mit (Last) Tests selbst eine Meinung bilden. Keine Ahnung was der "Fertigungsbetrieb" tatsächlich an Last auf die DB verursacht. Umstellung ist natürlich mit Zeit und daher Kosten verbundenm, obwohl sich der Aufwand von einer alten InterBase Version <= 6.0 auf Firebird vermutlich in Grenzen hält, da InterBase 6.0 der gemeinsame Nenner ist :-), dh hier keine InterBase spezifischen Sachen in Verwendung sind, die man in Firebird anders lösen müßte. Ich kenne viele User/Kunden aus beiden Lagern, die mit dem zufrieden sind, was sie gerade am Laufen haben. :-D |
AW: Interbase
Danke an alle,
Ich werde da mal ein paar Last-Tests mit Firebird und Interbase fahren. |
AW: Interbase
Zitat:
gerne machen, aber sei dir gewiss, das Interbase in Sachen Performance nicht nur gegen FB3 ziemlich schlechte Karten hat. Wir haben dafür in IBExpert einen Datenbankbenchmark eingebaut, der multithreaded läuft und mit minimalen Änderungen auch noch mit Interbase einsetzbar ist. Benchmark Ergebnisse will ich hier nicht posten, aber auch Datenbankverschlüsselung kann Firebird und zwar sowohl schnell als auch sicher (Ein Benchmark auf einer verschlüsselten Interbase DB fiel da deutlich mehr zurück). Bei FB braucht es ein Zusatzmodul, das bieten aber neben uns auch mehrere andere an. Es ist aber nun mal ziemlich sicher eine deutliche Tendenz im Markt erkennbar, das gewisse lizenzpflichtige Produkte langfristig keine Chance gegen gleich- oder höherwertige Open Source Produkte haben. Vor 10-15 Jahren gab es deutlich mehr kommerzielle Anbieter von Datenbanksystemen. Wenn du Lust auf eine gemeinsame Session mal irgendwo auf einer Konferenz hast steh ich gerne bereit, jeder sucht sich 50% der Beispiele aus und der jeweils andere versucht das nachzumachen. Könnte bestimmt lustig werden (und ich bin gerne für Überraschungen offen, falls Interbase da irgendwo deutlich überlegen wäre). |
AW: Interbase
Also, wir setzen beides ein. Beide haben ihre Vor- und Nachteile letztendlich hängt es aus meiner Sicht davon ab, was benötigt wird.
Wir haben die Erfahrung gemacht, dass bei einer sehr hohen Auslastung (viele gleichzeitige Zugriffe) und bei speziellen Anforderungen bzgl. Ausfallsicherheit Interbase die Nase vorn hat. Hier das Stichwort gemeinsamer Cache oder Dumps ... Sicherlich geht FB da mit der 3er den richtigen Weg. Allerdings werden wir die 4er Version abwarten müssen, damit FB einen deutlichen Abstand zu IB gewinnt. Wenn es sich um eine kleinere DB mit relativ geringer Anzahl an Usern handelt, dann ist FB sicherlich die bessere Alternative. Falls es sich um eine große DB mit sehr vielen Benutzern handelt und das Thema Disaster Recovery über ein tägliches Backup der DB hinaus geht, dann würde ich mir die aktuelle Version von IB anschauen. Gruß Knuut21 |
AW: Interbase
Zitat:
[Verschlüsselung] Zitat:
Zitat:
|
AW: Interbase
Hallo,
Zitat:
wenn also mehrdeutige joins verwendet werden. Tabelle1: id,Name Tabelle2: id,Name Select Name From Tabelle1 Join Tabelle2 On Tabelle1.Id=Tabelle2.Id Welches Name wird genommen? Unter Interbase wurde (meist) Name aus der From-Tabelle benutzt. Firebird informiert immerhin, dass man bitte den Tabellenname oder -alias voranstellen soll. Das hatte mich damals viel Mühe gemacht, bei der Umstellung von IB6 auf FB1.01 und FB1.05. |
AW: Interbase
Zitat:
Ich hätte ein ungutes Gefühl wenn Meine DB so etwas problemlos schluckt. Gruß K-H |
AW: Interbase
Hallo,
IB6 hatte damit kein Problem ... |
AW: Interbase
Das ist ja das Problem, wenn eine DB mit sowas kein Problem hat.
Denn es ist schlicht nicht eindeutig. Den Vogel schießt da ja mysql ab. Zum Glück gibt es hier seit einigen Versionen die Strict Einstellungen für den ganzen Schrott, den mysql sich in jungen Jahren da geleistet hat. Damit hat man dann die Chance, sein System wasserdicht zu machen. Natürlich ist es im Nachhinein eine Menge Arbeit und Spaß macht es auch keinen. Aber noch weniger Spaß macht sicher die Suche nach Fehlern, die dadurch entstehen. Unstimmigkeiten in Reports, mal so mal so Ergebnisse, mir graut. Nach wie vor ein Grund für mich, mysql nur zum Spielen anzufassen. |
AW: Interbase
Nun denn, dann einfach mal für jeden reproduzierbare Resultate (erst mal single
threaded, aber schon markant): In jeder IBExpert Version (auch in der Personal Edition) ist im Demo DB Pfad ein Script, das so auch mit Interbase funktioniert. Ob man das über IBExpert oder isql oder sonstwie ausführt, macht keinen Unterschied. Beide Datenbanken werden mit 16k pagesize angelegt (8k machte bei beiden keinen Vorteil). Wenn die DB fertig ist, dann wird über IBExpert - Services - Database Properties oder gfix der cache buffer auf 5000 gesetzt, so das der Cache ausreichend groß sein sollte (was die geringen Zahlen als Ergebnisse von reads und writes auch so bestätigen). Anschliessend disconnect und reconnect damit die buffers gesetzt sind. In beiden Datenbanken wird der jeweilige Client für 32 Bit eingesetzt (fbclient aus firebird 3.0.2 und gds32.dll aus dem installierten Paket). Der Test lief mit IBExpert, lässt sich aber auch mit der jeweiligen isql Version ausführen Beide DB Server sind 64 Bit Version auf identischer Hardware/Windows 10 Version (firebird Version 3.0.2 bzw. Interbase 2017 Developer Edition 13.0.0.129) Damit der Test einfach reproduzierbar ist, wird nun zunächst einfach mal jeweils 3 mal die SP initall gestartet mit dem parameter 10000 und danach jeweils disconnect/connect gemacht (weil beim ersten durchlauf noch keine Daten gelöscht werden müssen). Wenn das durch ist, dann startet man nun initall mit 10000 auf beiden Datenbanken, später dann noch mal 3 mal zum Auwärmen mit 100000 10000 erzeugt ca. 910000 individuelle insert/update/delete/select statements 100000 erzeugt ca. 9,1 Mio individuelle insert/update/delete/select statements Ergebnisse Interbase 10000 9,36 Sekunden Firebird 10000 4,11 Sekunden Interbase 100000 160,33 Sekunden Firebird 100000 57,63 Sekunden (ohne Statistik, aber mit 1 mio als param wird die db ca 1.3 GB groß) Interbase 1000000 37 Minuten Firebird 1000000 12 Minuten Unter ".. kann da FB noch mithalten" versteh ich da was völlig anderes .... Interbase braucht bei den meisten mir bekannten mehr oder weniger komplexeren Operationen 2-10 mal länger als Firebird (und ich rede da auch multithreaded nicht von der begrenzt vorteilhaften classic/superclassic version auf lahmen Festplatten und wir haben Firebird verschiedensten Hardware- und Userzahlkonfigurationen da im Einsatz ). ich würde mich freuen, wenn du das mit reproduzierbaren Beispielen widerlegen könntest, die nicht nur auf Inkompatibilitäten basieren. Zeig mir irgendwas, das Interbase schneller kann. Ich glaub auch keineswegs, das das irgendwie an der Developer Edition liegen sollte, falls das das Argument wäre, weil gleichartige Ergebnisse auch bei Kunden mit lizensierten Interbase Versionen mit reichlich cores identische Verhältnisse ergab. Query Statistiken aus IBExpert (die leichten Abweichungen der Operation liegen an der Random Funktion)
Code:
Anfang Interbase 2017 10000 35169 record(s) was(were) updated in INVENTORY 10000 record(s) was(were) updated in ORDERS 10000 record(s) was(were) deleted from CUSTOMER 10000 record(s) was(were) deleted from INVENTORY 10000 record(s) was(were) deleted from ORDERS 10000 record(s) was(were) deleted from PRODUCT 34993 record(s) was(were) deleted from ORDERLINE 10000 record(s) was(were) inserted into CUSTOMER 10000 record(s) was(were) inserted into INVENTORY 10000 record(s) was(were) inserted into ORDERS 10000 record(s) was(were) inserted into PRODUCT 35169 record(s) was(were) inserted into ORDERLINE ------ Performance info ------ Prepare time = 0ms Execute time = 9s 359ms Current memory = 32.743.344 Max memory = 35.797.280 Memory buffers = 1.783 Reads from disk to cache = 790 Writes from cache to disk = 51 Fetches from cache = 4.851.962 100000 349393 record(s) was(were) updated in INVENTORY 100000 record(s) was(were) updated in ORDERS 100000 record(s) was(were) deleted from CUSTOMER 100000 record(s) was(were) deleted from INVENTORY 100000 record(s) was(were) deleted from ORDERS 100000 record(s) was(were) deleted from PRODUCT 350371 record(s) was(were) deleted from ORDERLINE 100000 record(s) was(were) inserted into CUSTOMER 100000 record(s) was(were) inserted into INVENTORY 100000 record(s) was(were) inserted into ORDERS 100000 record(s) was(were) inserted into PRODUCT 349393 record(s) was(were) inserted into ORDERLINE ------ Performance info ------ Prepare time = 0ms Execute time = 2m 40s 328ms Current memory = 89.204.944 Max memory = 89.225.424 Memory buffers = 5.000 Reads from disk to cache = 40.517 Writes from cache to disk = 3.947 Fetches from cache = 49.142.098 Ende Interbase 2017 Anfang Firebird 3.0.2 10000 34953 record(s) was(were) updated in INVENTORY 10000 record(s) was(were) updated in ORDERS 10000 record(s) was(were) deleted from CUSTOMER 10000 record(s) was(were) deleted from INVENTORY 35007 record(s) was(were) deleted from ORDERLINE 10000 record(s) was(were) deleted from ORDERS 10000 record(s) was(were) deleted from PRODUCT 10000 record(s) was(were) inserted into CUSTOMER 10000 record(s) was(were) inserted into INVENTORY 34953 record(s) was(were) inserted into ORDERLINE 10000 record(s) was(were) inserted into ORDERS 10000 record(s) was(were) inserted into PRODUCT ------ Performance info ------ Prepare time = 0ms Execute time = 4s 109ms Current memory = 88.583.408 Max memory = 89.313.520 Memory buffers = 5.000 Reads from disk to cache = 1.071 Writes from cache to disk = 18 Fetches from cache = 3.917.798 100000 350293 record(s) was(were) updated in INVENTORY 100000 record(s) was(were) updated in ORDERS 100000 record(s) was(were) deleted from CUSTOMER 100000 record(s) was(were) deleted from INVENTORY 349696 record(s) was(were) deleted from ORDERLINE 100000 record(s) was(were) deleted from ORDERS 100000 record(s) was(were) deleted from PRODUCT 100000 record(s) was(were) inserted into CUSTOMER 100000 record(s) was(were) inserted into INVENTORY 350293 record(s) was(were) inserted into ORDERLINE 100000 record(s) was(were) inserted into ORDERS 100000 record(s) was(were) inserted into PRODUCT ------ Performance info ------ Prepare time = 0ms Execute time = 57s 625ms Current memory = 89.840.264 Max memory = 92.460.528 Memory buffers = 5.000 Reads from disk to cache = 26.224 Writes from cache to disk = 19.499 Fetches from cache = 52.106.099 Ende Firebird 3.0.2 |
AW: Interbase
Firebird installiert (3.0.2), IBExpert installiert.
DB erzeugt..... INITALL aufgerufen:
Code:
(Hat der Editor von IBExperts noch nichtmal eine Zeilennummerierung?!?!?)
validation error for column "CUSTOMER"."FIRSTNAME", value "*** null ***".
At procedure 'INITALL' line: 106, col: 5. |
AW: Interbase
Zitat:
wie wäre es mit (Hat der Formulardesigner von Delphi nicht nicht einmal ein Undo?!?!?!?) Ist auch nicht besser oder? Von mir aus kann der Thread geschlossen werden, bevor das hier noch ausartet. Habe mich für Firebird entschieden, es geht um ca 70 Clients und es werden ziemlich sicher noch mehr. Das wird für den Einsatzzweck zu teuer. Das ist aber eine Entscheidung für diesen speziellen Fall und sollte nicht als allgemeine Aussage gewertet werden! Danke an alle die geantwortet haben. Zitat:
|
AW: Interbase
Zitat:
selber entscheiden ob man das haben möchte oder nicht. http://ibexpert.net/ibe/index.php?n=...#EditorOptionsDer Null fehler deutet darauf hin, das du keinen Parameter an die SP übergeben hast, dann weiss die nicht, wie groß die db werden soll. Nimm zB 10000 als Anfang Und zur Zeilennummer: Im Default arbeitet der SP Editor im Lazy mode und zeigt nur Zeilennummern im Body an, daher würde die von FB generierte Fehlernummer woanders hinzeigen. Um die übereinstimmen zu lassen, setze hier statt lazy den Standard mode http://ibexpert.net/ibe/index.php?n=...2900#ProcEdOptUnd es ist ja nun keineswegs so das Delphi schon immer Zeilennummern konnte, zumindest bis inkl V7 war das gar nicht möglich, das nur so am Rande ;-) Während der Forentage bin ich leider im Amerika, würde aber wenn Daniel es technisch ermöglichen kann, gerne die Session mit Matthias auch remote machen. Ich hab da wo ich an dem Samstag bin, sehr gutes Internet und über pcvisit können wir problemlos auf auf den Bildschirmen zwischen Hamburg und USA für alle sichtbar umschalten. |
AW: Interbase
Das fände ich super!!!!
|
AW: Interbase
Zitat:
Gruß K-H |
AW: Interbase
Zitat:
Das ein Editor (ich weiß um die Problematik der BLRs) eine Zeilennummerierung haben sollte (was er ja wohl auch hat), ist kein ungewöhnlicher Anspruch.... |
AW: Interbase
Liste der Anhänge anzeigen (Anzahl: 1)
Da ich das Beispiel mit Firebird und "IBExpert" nicht zum laufen bekommen habe, hier mal TPC Ergebnisse mit 4 DWHs. Dies ist ein durchaus anerkannter Benchmark für Datenbanken.....
(Intel i7, 4 CPUs/Cores, i7-4960HQ, 2.6 GHz, Windows 10, 64 Bit, 4 GB RAM): InterBase 2017: TPC-C Throughput: 14002.95 tpmC Firebird 3.0.2 TPC-C Throughput: 9934.92 tpmC Die Messungen habe ich gerade selbst durchgeführt..... bei mehr DWH sieht es ja noch schlechter für Firebird aus: https://www.embarcadero.com/de/produ...rbase_firebirdGenauer(r Ergebnisse im Anhang): Interbase:
Code:
Firebird:
Transaction Mix, in percent of total transactions
Transaction Count Percent new order 168034 43.48 payment 168033 43.48 order status 16805 4.35 delivery 16804 4.35 stock level 16803 4.35 Response Times, in seconds Transaction 90th %ile Minimum Average Maximum new order 0.250 0.000 0.009 3.031 payment 0.250 0.000 0.003 3.017 order status 0.250 0.000 0.022 0.079 delivery 0.250 0.000 0.031 3.047 stock level 0.250 0.000 0.005 0.047
Code:
Transaction Mix, in percent of total transactions
Transaction Count Percent new order 119217 43.48 payment 119211 43.48 order status 11922 4.35 delivery 11924 4.35 stock level 11924 4.35 Response Times, in seconds Transaction 90th %ile Minimum Average Maximum new order 0.250 0.000 0.005 0.062 payment 0.250 0.000 0.002 0.032 order status 0.750 0.015 0.126 0.453 delivery 0.250 0.000 0.003 0.032 stock level 0.250 0.000 0.046 0.172 |
AW: Interbase
Liste der Anhänge anzeigen (Anzahl: 2)
Habe noch mal einige Folgetests gemacht (immer 4 Warehouses):
(Jeweils neuer PREPARE und LOAD) InterBase 2017: TPC-C Throughput: 13879.43 tpmC TPC-C Throughput: 13403.73 tpmC (Ohne Journaling zum Vergleich: TPC-C Throughput: 12827.94 tpmC) Firebird 3.0.2: TPC-C Throughput: 9943.16 tpmC TPC-C Throughput: 9347.40 tpmC (Man sah bei Firebird auch gut, daß die CPUs nicht gleichförmig ausgelastet werden) Anhang 47486 Vergleichsweise InterBase 2017 dazu: Anhang 47490 Auffällig auch der hohe RAM Bedarf von Firebird ggü InterBase: 900 MByte / 630 MByte |
AW: Interbase
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/interbasekostet 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 |
AW: Interbase
Zitat:
Bei Interbase macht der nichts auf der Platte (async oder forced writes off) und bei Firebird ist die Platte an der Lastgrenze (sync oder forced writes on). Wenn da nun der Server viele Transaktion im Journal nur im Speicher hält ist das im fehlerfall keineswegs gleichwertig mit forced writes on. |
AW: Interbase
Zitat:
|
AW: Interbase
Zitat:
TPC ist nun nicht irgendein Benchmark eines x-beliebigen Tools..... Zitat:
"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... |
AW: Interbase
Zitat:
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. |
AW: Interbase
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 |
AW: Interbase
daher ist das ja schwierig, das zu vergleichen, die von dir zitierte Webseite
https://www.embarcadero.com/de/produ...rbase_firebirdzeigt 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 :-) |
AW: Interbase
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) |
AW: Interbase
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. |
AW: Interbase
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. |
AW: Interbase
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ärzWenn 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 AmazonCloudservices sind von Hochverfuegbarkeit weit entfernt |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 15:41 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz