|
AW: Wie bekomme ich einen performanten Firebird?
Hier mal die wichtigsten Eckdaten:
Zitat:
|
AW: Wie bekomme ich einen performanten Firebird?
Moin,
das mit den Buffers hast du ja schon gefunden, in der Statistik stand ja vorher 0 als Page Buffers und das bedeutet, das dein Superclassic pro connection sage und schreibe 75 Pages cacht. Da deine DB dann auch noch nur 4k Pagesize hat und nicht wie durchaus empfehlenswert 16k, ist daher dein cache beim insert 75*4k, also sage und schreibe 300 Kbyte. Das reicht nicht mal um die Systemtabellen zu cachen, geschweige denn Index pages, data pages usw. Dieser durchaus von Firebird bei der Classic/Superclassic Variante gewählte default wert von 75 ist sicherlich zu klein, aber aufgrund der Historie von Firebird bzw Interbase schon in der Steinzeit benutzbar gewesen, als Datenbankserver sich noch über 1MB Ram mehr gefreut haben. Weiterhin gehe ich aber davon aus, das dein Server trotz guter CPU mit Firebird leider eine ziemlich lahme Gurke ist, denn die fehlende CPU Last ist ganz einfach damit zu erklären, das die CPU nur auf den Datenträger=Festplatte oder Raid wartet. Und ich würde wetten, das der Datenträger eine gute alte drehende Festplatte ist, was im Zeitalter von robusten Enterprise SSDs für Datenbank so ähnlich ist wie heute noch einen Röhrenbildschirm auf dem Schreibtisch zu haben. Und ganz wichtig: RAID ist nicht immer vorteilhaft, dazu später mehr. Also erster Tip: Wenn Classic oder Superclassic, dann zunächst mal in firebird.conf den Eintrag #DefaultDbCachePages = 2048 durch DefaultDbCachePages = 1024 ersetzen (ohne # davor, weil das das Kommentarzeichen ist). Dann gilt ab sofort dieser Wert als Default, auch wenn in der DB nicht mit gfix angepasst wurde. Ab ca. 500 Pages wird firebird mit normalen Festplatten überhaupt erst sinnvoll benutzbar. Es gilt dabei immer der Wert mit gfix oder in ibexpert-services-database properties eingestellte wert überschreibt den Wert aus der Firebird.conf. Wenn im Statistikheader Page buffers 0 steht, gilt der Wert der Firebird.conf. Wenn der nicht gesetzt ist, dann gilt der Default Wert der Firebird Version, bei Superserver also 2048 und bei classic oder superclassic 75. Wenn du nun also mit einem Backup/Restore die Pagesize auf 16k verändert hast, dann gilt für 1000 Pages beim Superclassic ein Cache pro Userconnection von 16MB, da passt deutlich mehr rein als in 300k. Dieser Wert muss aber pro Userconnection auch auf dem Datenbankserver physikalisch frei sein und nicht in einer ausgelagerten Pagefile simuliert werden. Wenn du das mit zum Beispiel maximal 10 Userconnections auf der DB arbeitest, dann braucht der Cache gerade mal 160 MB, das sollte man schon frei haben. Dreh den Wert aber nicht zu hoch, es gibt nachher nicht nur Vorteile. Nächster Punkt: Deine Inserts kannst du am besten einfach mit execute block zusammenfassen, d.h. bei Masseninserts gar nicht parametrisieren, sondern nimm dir aus der SQL Datei wenn es geht jeweils 50 Zeilen (darf nicht mehr als 32 kb pro block sein) und schreibe
Code:
davor und
execute block as begin
Code:
dahinter. Jede insert Zeile muss am Ende ein Semikolon haben. Den Text packst du nun ganz normal in die sql.text eigenschaft deiner TxxQuery und führst das mit execsql aus. Auf dem Weg schickst du 50 Sqls in einem TCP/IP Datenpaket an den Server und nicht 2000 wie bei parametrisierten SQLs. Ob du dann nach jeweils 100*50 zeilen ein commit machst ist dann gar nicht mehr so wild.
end
So erzeugte SQLs Dateien kannst du auch mit IBExpert im Script executive, mit ibescript.exe oder mit jedem anderen einigermaßen brauchbaren SQL Tool für Firebird direkt ausführen. Manche Delphi Komponenten sind leider zu blöd dafür, mit den meisten klappt das aber. Zu guter Letzt dann noch folgender Hinweis zur Hardware: Wir haben mal bei einem Kunden, mit dessen Software und Hardware alle MTV Europe Fernsehstationen (MTV, viva und wie der Kram nicht alles heisst) ihr Programm ausstrahlen, einen Test von einigen Dell Servern als Stichprobe gemacht. Insgesamt setzt MTV über 100 Firebird Server ein, jeweils einer pro Kanal und Land, je Kanal auch eigene Hardware ohne Virtualisierung. Das komplette MTV Programm kommt aus Firebird Servern, genau so wie länderspzifische Klingeltonwerbung usw. Das spannende dabei war, das die Stichprobe mit 10 Server auf 7 Servern ok war und auf 3 angeblich baugleichen unglaublich langsam war. In allen Rechnern waren DELL Raid Controller mit 3 SAS HDDs eingebaut, auf den schnellen Rechner dauerte der in der IBExpert Vollversion eingebaute Benchmark insgesamt ca. 2 Minuten, auf den langsamen jedoch 17 Minuten. Theoretisch war alles identisch praktisch aber scheinbar nicht. Der Dell Support selbst hat auch nicht weitergeholfen, sondern auf der Kiste nur eine 500MB Datei in ca 2-3 Sekunden von einen Pfad in den anderen kopiert und gesagt, der Rechner ist ok. Aus der Sicht des Hardwareherstellers auch verständlich, für den Kunden aber trotzdem inakzeptabel. Egal ob du nun classic oder superclassic nimmst, im Multiuserbetrieb mit 10 User verursacht diese Version gegenüber dem Superserver die 10fache I/O Last auf dem Datenträger und die CPU wartet meistens nur darauf, das der Datenträger endlich mal wieder die eine oder andere angeforderte Page von der Platte nachlädt. Daher siehst du keine CPU Last. Wenn dann noch für jede Page der Schreiblesekopf bewegt werden muss, dann ist die mittlere Zugriffszeit des Datenträgers viel wichtiger als der CPU Speed, weil die eh nur wartet. Bei recht guten 10ms durchschnittliche Zugriffszeit wären dann also für 10*10 Kopfbewegungen schon die erste Sekunde Wartezeit zusammen. Wenn nun noch die Cachebuffers zu klein sind, dann sind das eher 10*100 Kopfbewegungen, also zusammen 10 Sekunden. SSDs habe da erhebliche Vorteile, im Zusammenspiel mit ausreichend Arbeitsspeicher geht dann noch mal richtig die Post ab, wenn man das sinnvoll einstellt. Deine CPUs können aber auch 100 Kerne haben, bei ienem zu lahmen Datenträger heizen die nur das Gehäuse während die warten. Das siehst du ja auch auf deinem Taskmanager: gähnende Langeweile in der CPU .... Ganz wichtiger Zusatzhinweis: pro userconnection benutzt Firebird in allen Versionen immer nur einen CPU Kern. Wenn du beim Import der einzige User bist, wirst du mit diesem einem Import auch nur einen CPU Kern auslasten. Wenn dein Import sauber multithreaded programmiert ist, könnte es ein Vorteil sein, das jeder Thread beim classic oder superclassic auf einem anderen Kern laufen kann, aber wenn der Datenträger lahm ist, dann erzeugt das mehr Last als es vorteile bringt. Mit den bei mtv auf den schnellen Servern gemessenen 120 Sekunden erreichst du im IBExpert Benchmark eine Wert von ca. 35% (die Referenz 100% ist der gleiche Benchmark auf einem von uns als Hardware für 1200 € angebotenen IFS Server, der ca. 40 Sekunden für den Benchmark mit dem Superserver braucht, d.h. das sind die 100% (beim superclassic erreicht der etwa 60%) Eine heute von mir ausgelieferter IFS Server, der schon ein paar Euro mehr gekostet hat, schafft mit verschiedenen Techniken mit dem Superserver als auch mit dem superclassic server im IBExpert Benchmark ca. 170 %, braucht als knapp über 20 Sekunden. Eine Benchmark auf einem Kundenserver, wo Schweinchen Schlau Systemadministrator wieder alles besser wusste, hat letzte Woche sämtliche mir bekannten Negativ Rekorde gebrochen, der brauchte für den gleichen Test sage und schreibe ca. 2 Stunden! Keine Ahnung was der da eingebaut, sah aber irgendwie nach iscsi schnittstelle an externer storage aus order irgendwas ähnliches, was für Datenbankserver der absolute Oberschwachfug ist, weil dann zu den mittleren Zugriffszeiten der HDD auch noch die Latenzzeit auf dem Netzwerkkabel kommt und bei viel Traffic auch noch die Kollosionen. Im Benchmark wurde dieser Server als erster mit 0% gemessen, weil die Referenzzeit unseres 100% Systems geteilt durch diese Zeit gerundet weniger als 1 ergab. Und die Anwender der Firebird basierenden Software können nicht vernünftig arbeiten, weil Schweinchen Schlau Systemadministrator meint, alles besser zu wissen als der Softwarehersteller, von dem wir den Auftrag zur Rechnerprüfung hatten. Der Softwarehersteller selbst hat schon einen von ihm konfgurierten Firebird Server zum Kunden mitgenommen hatte, auf dem das vernünftig lief. Kunde wollte aber lieber seine Schrottkonfiguration behalten, egal wie lahm die ist, warum auch immer ... Im Rahmen unsere Hotline schalten wir uns auch gerne auf die Server unserer Kunden und nutze dann eine IBExpert Tageslizenz für den Benchmark (ist halt nur in der Vollversion drin). Es ist immer wieder lustig, wenn dann jemand einen frisch gekauften teuren Rechner als komplett ungeeignet erkennt und dann doch auf einmal jemanden fragt, der sich damit auskennt, wie man den denn doch noch einigermaßen schnell bekommt. Je teurer die Storage und je virtualisierter das ganze ist, um so mieser sind die Werte im Vergleich zu einem echten dedizierten Datenbankserver. Als einfach Vorabtest auch ohne unseren Benchmark: Nicht eine Datei mit 500 MB von einen Pfad in den anderen auf dem gleichen Laufwerk kopieren, das ist langweilig und sagt nichts über Datenbankoperationen aus. Dafür lieber einfach mal 100000 oder 1mio Dateien mit je 1k von einem Pfad in einen anderen Pfad auf dem gleichen Laufwerk kopieren (wichtig: kopieren, nicht verschieben). Da rödelt sich die Platte einen ähnlichen Wolf wie bei Datenbankoperationen. Damit habt ihr schon mal ganz grob einen Vergleichswert mit einem Referenzsystem eurer Wahl. Die CPU Geschwindigkeit ist vergleichweise egal, der heute ausgelieferte Server, der die 170% erreicht hat, hatte 2,5 Ghz, das aber mit insgesamt 10 Kernen (Xeon E5) und einem guten Servermainboard, auf dem der eingebaute Intel C220/600 RAID Controler mit RAID1 super Leistung bringt. Aber auch da setzen wir diverse Tricks ein, damit eine 5,5GB große Datenbank mit ca. 50mio Datensätzen und reichlich Indizes beim backup/restore innerhalb von 13 Minuten durch ist (4 Minuten backup/9 Minuten Restore, jeweils mit gbak). Könnt Ihr ja mal mit euren Werten vergleichen So, das reicht aber auch nun, keine Ahnung ob so lange Post überhaupt von den meisten bis zum Ende gelesen werden :-) Ein schönes Wochenende wünsche ich |
AW: Wie bekomme ich einen performanten Firebird?
Zitat:
|
AW: Wie bekomme ich einen performanten Firebird?
Zitat:
Interessanter Post, btw. :-D LG |
AW: Wie bekomme ich einen performanten Firebird?
Super Post, ich habe jede Zeile genossen. Mein Datenimport ist nun durch, 8364632 records in 11:09:16.531. Bei der Einrichtung des Servers mussten wir wegen des Raids ganz schön tricksen weil Windows Server standardmäßig meint den Cache ausschalten zu müssen. Ich erzeuge gerade mal 1 Mio Testfiles.
|
AW: Wie bekomme ich einen performanten Firebird?
Noch eines zur Stripset Größe 64 KB
das Stripeset ist die Verwaltungseinheit eines RAID , d.h. jede Lese oder Schreibanforderung liest/schreibt diese Datenmenge von den Platten also bei Firebird Pagesize 4KB und Stripset 64KB laufen 60 KB nutzlos über die Platten also rund 93 % nutzlose Daten Bei dem vom HK vorgeschlagenen 16 KB sind das immer noch 75% Nutzlose Daten die von den Platten geholt werden also Stripset Größe auf 16KB (oder das kleinst mögliche ) - Wieso der Performance Einbruch nach ca 300000 Inserts , Antwort der Ram Cache des Diskcontrollers (488MB) ist vollgelaufen und jetzt schlägt der Treibanker RAID voll zu mfg Hannes |
AW: Wie bekomme ich einen performanten Firebird?
Ein RAID5 mit 3 Platten ist sicher(er) aber sicher nicht schnell.
Meine Erfahrung mit RAID5 hat mich gelehrt, dass man ab ca. 6 Platten in einem Verbund einen schnelleren Zugriff bekommt. Für Datenbanken ist allerdings ein RAID10 fast schon Pflicht. Windows Server und Cache abschalten: Das ist doch hoffentlich kein Domain-Controller, oder? Ein Domain-Controller schaltet den Cache auf der System-Platte (die Platte, wo die System-Partition liegt) ab, damit das Active-Directory keinen Schaden nehmen kann. Das sollte man auch tunlichst unterlassen, den Cache da wieder einzuschalten :!: Ein Server, der Domain-Controller werden soll bekommt für das System einen eigenen Plattenverbund spendiert (RAID1,5,10 je nach Geldbeutel und Gusto) und für die restlichen Daten weitere Platten-Verbünde, je nach Anforderung (RAID10 für DB, RAID5 für den anderen Kram). Für ein performantes, sicheres und schnell wiederherzustellendes Netzwerk packe ich auf 2 (hardware) getrennte VMs den Domain-Controller und Backup-Domain-Controller. Und diese sind ausschließlich Domain-Controller und haben sonst keine weiteren Aufgaben. Alle anderen Server werden nur Mitglieder der Domäne. |
AW: Wie bekomme ich einen performanten Firebird?
Zitat:
und einem ausgeklügelten Sicherungskonzept. Vorteile Raid 1: Jede der beiden Platten ist ohne Einschränkung in einem anderen Rechner sofort einsetzbar, zum Beispiel ist damit ein Backupserver mit gleichen Hot Plug Einschüben sofort einsetzbar. Im RAID 10 sind Einzelplatten gar nicht benutzbar und so manch ein Controller reagiert seltsam, wenn er zwei asynchrone Raid 0 Parts hochfahren soll. Der Geschwindigkeitsgewinn durch Raid0 hält sich je nach Stripe Größe auch sehr im Rahmen oder sorgt sogar für negative Auswirkungen. Auf dem Raid Laufwerk ist dann aber nur die Datenbank. Das OS kann dann auf einer normalen Platte sein, ob die dann mit Raid Technik abgesichert ist, ist dann dem eigene Geschmack und Budget überlassen. |
AW: Wie bekomme ich einen performanten Firebird?
Hallo,
es war sehr viel Text, habe es aber auch mit Freuden bis zum Ende gelesen :-D Übrigens, das System, das bei einem Kunden die Performance Problem bei schreiben hatte, war auch ein Dell, Zufall???? Auch hier konnte nicht festgestellt werden, absolut rätselhaft. Man konnte den Effekt sogar beim kopieren von grossen Dateien nachstellen, also mal 5 GB kopiert, so ab 500 MB ging die Geschwindigkeit teilweise auf 200 kB / Sek runter. Und wie gesagt, nirgendwo irgendeine Fehlermeldung. |
AW: Wie bekomme ich einen performanten Firebird?
Zitat:
Auf jeden Fall sind ein paar technische Fragen bei mir hochgekommen, wie man es verbessern kann - aber das ERP wird nächsten Monat durch ein ein anderes ersetzt...:| Trotzdem: Danke Holger, hat mir tiefe Einblicke gegeben und wird mir bei meinem zukünftigen Weg weiterhelfen. Mikhal |
AW: Wie bekomme ich einen performanten Firebird?
Zwischenbericht
Dank der Hilfe von Euch Allen und besonders Holger Klemt konnte ich das Problem jetzt lokalisieren. Es lag an der Write-Cache-Policy des Controllers. Diese war sehr konservativ eingestellt. Der in IBExpert eingebaute Benchmark meldete nach dem Aktivieren einer mehr auf Performance setzende Policy 120-fach höhere Performance! Der Import der Buchungstabelle war nach 5:53 abgeschlossen, also ca. doppelt so schnell wie vorher. Ich habe nun den nächsten Importlauf gestartet, diesmal mit deaktivierten Indizes. Es sieht auf den ersten Blick so aus als wäre das nochmals ca. 5-10 Mal schneller. Als nächsten Test werde ich einmal das ISql direkt auf dem Server starten und sehen ob durch den Wegfall der TCP-Übertragung noch etwas herauskommt. Im letzten Schritt werde ich durch mein Export-Tool mal ein Script erzeugen lassen, das die EXTERNAL TABLE Definitionen für die zu importierende Tabelle erzeugt und eine Importdatendatei mit festen Feldlängen passend dazu. Ich weiss nur noch nicht was ich mit evtl. vorhandenen Memos machen soll. @Sir Rufo: Ja, der Server ist leider auch ein DC. Der Cache wird schon ab Windows Server 2003 immer dann ausgeschaltet, wenn Windows auf der betreffenden Disk das AD hat und auf dem Controller keine BBU erkennen kann. Was dann passiert hängt in der Tat von der Qualität des Treibers ab. Ich habe daher beim Bootvorgang dskcache eingebunden um die Laufwerk-Richtlininen zu ändern. Wenn die Cache-Befehle nicht durchgereicht werden (dann gibt auch dskcache einen Fehler aus), der Treiber also eigentlich schlecht programmiert ist, dann ist alles in Ordnung. |
AW: Wie bekomme ich einen performanten Firebird?
Da merkt man ja, das mein Text durchaus einige Male gelesen wurde.
Lasst euch von den Hardwareheinis keinen vom Pferd erzählen, Ihr könnt tausende Euros für Pseudosicherheit ausgeben, die bei Datenbanksystemen so viele negative Einflüsse haben, das man das gar nicht glaubt. Meistens ist weniger mehr. Falls Ihr schon mit Firebird arbeitet, dann gibt es noch einen anderen sehr einfach Test. Erzeugt mit dem Befehl
Code:
mal ein Shadow der Datenbank und messt die Zeit, die der dafür braucht. Das Shadow sollte auf der selben Platte liegern wie die DB. Nachdem das Shadow erzeugt wurde, könnt ihr mit
"CREATE SHADOW 1 ''C:\db\db.shd'"
Code:
das shadow wieder löschen. Achtung: das Shadow ist fast genau so groß wie die Orginal Datenbankdatei.
"DROP SHADOW 1"
Gestern beim Kunden auf dem neuen Server aktuell gemessener Bestwert waren ca. 6 Sekunden pro GB, die 5,5GB große Datei wurde von Firebird 2.5 dabei page für page innerhalb von ca. 30 Sekunden kopiert. Mit einem Trick konnten wir den Wert sogar noch auf 20 Sekunden herunterbringen und das Shadow haben wir dann als automatisierte Datensicherung genommen, die ab sofort alle 30 oder 15 Minuten ausgeführt wird, obwohl beim Erstellen des Shadow aktive Verbindungen auf der Datenbank auch schreiben können, während das Shadow erstellt wird. Falls euer Server also beim Shadow erzeugen die auf Festplatten und RAIDs üblichen 3-5MB pro Sekunde schafft, dann sollte Ihr die Eignung als Datenbakserver einfach mal hinterfragen. Meistens braucht man ja nur messbare Argmente, damit die Hardwareheinis mal aufhören mit deren Klugscheißereien und den  Schweigefuchs zu machen: Öhrchen auf und Schnäuzchen zu. |
AW: Wie bekomme ich einen performanten Firebird?
Zitat:
|
AW: Wie bekomme ich einen performanten Firebird?
Unabhängig davon ob es jetzt die "richtige" Maschine oder Server ist: Mir ging es darum FireBird genauso schnell oder schneller zu sehen als das bisher eingesetzte DB-System bei gleicher Hardware. Das ist gelungen.
8,364,632 records
Den Test mit dem external file spare ich mir:
Vielen, vielen Dank nochmals an alle Helfer! |
AW: Wie bekomme ich einen performanten Firebird?
Spannende Infos von IBExpert!
Auch wenn ich auf einem Laptop mit einem kommerziellen Standard DB System auf ähnliche oder bessere Werte komme (jenachdem wie man's macht) als hier genannt (4 Mio records ca 6 Minuten oder 11 Minuten): Zitat:
Mich wundert immer wieder mal, wie egal das vielen hier scheinbar meist ist. Mich würde für einen genaueren Vergleich noch der originale Tabellenaufbau interessieren und ob dort ein Primärschlüssel definiert ist. Oder ist "Index deaktiviert" gleich "nicht mal Primärschlüssel"? |
AW: Wie bekomme ich einen performanten Firebird?
Untenstehend die DDL für die betreffende Tabelle. Die Indizes waren beim letzten Import komplett deaktiviert mit ALTER INDEX <name> INACTIVE. In der usprünglichen DB gibt es keine PK und keine RI. Grosse Integer werden durch DOUBLE dargestellt, da die ursprünglich verwendeten DB keine BIGINT bzw. INT64 unterstützen - nicht lachen, das System ist in den Ursprüngen knapp 30 Jahre alt.
Code:
CREATE TABLE BUCHUNG
( "ID" DOUBLE PRECISION, "VORG_NR" DOUBLE PRECISION, "LFD_BNR" DOUBLE PRECISION, "MAND_ID" DOUBLE PRECISION, "ART_ID" DOUBLE PRECISION, "PAL_NR" CHAR ( 10 ), "ZUG_NR" CHAR ( 20 ), "ZUG_POS" INTEGER, "ABG_NR" CHAR ( 20 ), "ABG_POS" INTEGER, "LIEFER_ID" DOUBLE PRECISION, "KD_ID" DOUBLE PRECISION, "BELEG_ID" DOUBLE PRECISION, "BUCH_DAT" DATE, "ZUG_DAT" TIMESTAMP, "MENGE" DOUBLE PRECISION, "PLATZ_ID" DOUBLE PRECISION, "DATUM" DATE, "ZEIT" CHAR ( 8 ), "VORGANG" CHAR ( 3 ), "AUTO_VORG" CHAR ( 3 ), "ART" CHAR ( 4 ), "USER" CHAR ( 8 ), "STATUS" CHAR ( 4 ) ); CREATE INDEX "BUCHUNG_ID" ON BUCHUNG (ID); CREATE INDEX "BUCHUNG_MAND_ID" ON BUCHUNG (MAND_ID, ART_ID, DATUM, ZEIT); CREATE INDEX "BUCHUNG_ART_ID" ON BUCHUNG (ART_ID, MAND_ID, DATUM, ZEIT); CREATE INDEX "BUCHUNG_ZUG_NR" ON BUCHUNG (ZUG_NR, MAND_ID, ART_ID); CREATE INDEX "VORG_NR" ON BUCHUNG (VORG_NR); CREATE INDEX "BUCHUNG_PLATZ_ID" ON BUCHUNG (PLATZ_ID); CREATE INDEX "VORGANG" ON BUCHUNG (VORGANG); CREATE INDEX "BUCHUNG_STATUS" ON BUCHUNG (STATUS); |
AW: Wie bekomme ich einen performanten Firebird?
Abschliessend im Thread nur noch mal als Hinweis an alle, die viel
importieren und exportieren: Der Weg über external files bringt bei Firebird erheblich mehr speed als man denkt. Die folgende Tabelle mit 20 Feldern, PK und 3 weiteren Indizes und 1.000.000 Datensätze braucht für die Übertragung von drinnen nach draußen oder von draußen nach drinnen jeweils ca. 1 Minute (der server hatte bei dem Test nur eine normale Festplatte eingebaut). Ganz wichtig: External files definieren geht immer, aber benutzen könnt Ihr die erst, wenn Ihr in der Firebird.conf den Parameter ExternalFileAccess angepasst habt und den Firebird Server noch mal neu startet.
Code:
Bei diesem Beispiel könnt ihr dann im pfad c:\export dateien einlesen oder
ExternalFileAccess = Restrict C:\export
auch von firebird erstellen lassen. Das Feld crlf ist im external file nur definiert, damit man im Texteditor auch zeilenvorschübe sehen würde, wenn man die denn dort öffnet. Bei allen weiteren Typen am besten wegen Lesbarkeit auf char(m) umwandeln. Die Datei sieht dann so aus (Die Boardsoftware schummelt da weitere crlf rein, ist aber pro datensatz immer eine Zeile).
Code:
Es rechnet zeitlich sich sehr oft, wenn man Daten für einen Import bekommt, die mit
1 JENNIFER WOMMACK MARTIN LUTHER KING JR AVE - PITTSFIELD MO 14960 USA 3 JENNIFER.WOMMACK@yahoo.com 1(435)703-9855 4 1389 4408 4192 3925 6/2016 JENNIFER.WOMMACK1000001 567373 36 45000 F
2 MARIA DOHERTY NE NEFF ROAD - ROCKVILLE CT 67979 USA 5 MARIA.DOHERTY@yahoo.com 1(924)920-6861 1 7739 7739 5985 5952 12/2019 MARIA.DOHERTY1000002 726542 31 79000 F 3 RICKEY HUFFMASTER FIRST AVENUE EAST - BERKELEY HEIGHTS MN 12931 USA 11 RICKEY.HUFFMASTER@yahoo.com 1(659)169-7730 2 4666 5413 7709 9617 3/2016 RICKEY.HUFFMASTER1000003 709595 31 41000 M .... einem kleinen Delphi oder Lazarus Hilfsprogramm in ein passendes Fixed format zu konvertieren und danach den Import in die Datenbank auf diesem Weg zu machen. Beim Export kann man auf einfach csv Dateien erzeugen, in dem man die Daten einfach als varchars trimt und mit trenner in einen char(255) einträgt. Das füllt Firebird dann zwar bis zum Ende mit Leerzeichen auf, ist aber für jedes csv Import normalerweise unkritisch (char(2) für crlf nixht vergessen) Direkter csv Import ohne externe Tools via external file ginge zwar auch, ist aber relativ umständlich, in dem man das als Stored Procedure auseinanderfrickelt. Hier der Befehl, um Daten aus der internen Tabelle in die externe zu kopieren [CODE] insert into customer_ext_c (ID, FIRSTNAME, LASTNAME, ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY, REGION, EMAIL, PHONE, CREDITCARDTYPE, CREDITCARD, CREDITCARDEXPIRATION, USERNAME, PASSWD, AGE, INCOME, GENDER,crlf) select ID, FIRSTNAME, LASTNAME, ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY, REGION, EMAIL, PHONE, CREDITCARDTYPE, CREDITCARD, CREDITCARDEXPIRATION, USERNAME, PASSWD, AGE, INCOME, GENDER,' ' from CUSTOMER [CODE] Hier der Befehl, um Daten aus der externen Tabelle in die interne zu kopieren
Code:
Metadaten
insert into customer (ID, FIRSTNAME, LASTNAME, ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY, REGION, EMAIL, PHONE,
CREDITCARDTYPE, CREDITCARD, CREDITCARDEXPIRATION, USERNAME, PASSWD, AGE, INCOME, GENDER) select ID, FIRSTNAME, LASTNAME, ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY, REGION, EMAIL, PHONE, CREDITCARDTYPE, CREDITCARD, CREDITCARDEXPIRATION, USERNAME, PASSWD, AGE, INCOME, GENDER from customer_ext_c
Code:
/******************************************************************************/
/**** Generated by IBExpert 27.04.2014 20:58:34 ****/ /******************************************************************************/ /******************************************************************************/ /**** Tables ****/ /******************************************************************************/ CREATE TABLE CUSTOMER ( ID NUMERIC(18,0) NOT NULL, FIRSTNAME VARCHAR(50) NOT NULL, LASTNAME VARCHAR(50) NOT NULL, ADDRESS1 VARCHAR(50) NOT NULL, ADDRESS2 VARCHAR(50), CITY VARCHAR(50) NOT NULL, STATE VARCHAR(50), ZIP INTEGER, COUNTRY VARCHAR(50) NOT NULL, REGION SMALLINT NOT NULL, EMAIL VARCHAR(50), PHONE VARCHAR(50), CREDITCARDTYPE SMALLINT NOT NULL, CREDITCARD VARCHAR(50) NOT NULL, CREDITCARDEXPIRATION VARCHAR(50) NOT NULL, USERNAME VARCHAR(50) NOT NULL, PASSWD VARCHAR(50) NOT NULL, AGE SMALLINT, INCOME NUMERIC(18,0), GENDER VARCHAR(1) ); CREATE TABLE CUSTOMER_EXT_C EXTERNAL 'C:\EXPORT\CUSTOMER.DAT' ( ID CHAR(18), FIRSTNAME CHAR(50), LASTNAME CHAR(50), ADDRESS1 CHAR(50), ADDRESS2 CHAR(50), CITY CHAR(50), STATE CHAR(50), ZIP CHAR(18), COUNTRY CHAR(50), REGION CHAR(18), EMAIL CHAR(50), PHONE CHAR(50), CREDITCARDTYPE CHAR(18), CREDITCARD CHAR(50), CREDITCARDEXPIRATION CHAR(50), USERNAME CHAR(50), PASSWD CHAR(50), AGE CHAR(18), INCOME CHAR(18), GENDER CHAR(1), CRLF CHAR(2) ); /******************************************************************************/ /**** Primary Keys ****/ /******************************************************************************/ ALTER TABLE CUSTOMER ADD CONSTRAINT PK_CUSTOMER PRIMARY KEY (ID); /******************************************************************************/ /**** Indices ****/ /******************************************************************************/ CREATE INDEX CUSTOMER_IDX1 ON CUSTOMER (FIRSTNAME); CREATE DESCENDING INDEX CUSTOMER_IDX3 ON CUSTOMER (ID); CREATE UNIQUE INDEX IX_CUSTOMER_USERNAME ON CUSTOMER (USERNAME); |
AW: Wie bekomme ich einen performanten Firebird?
Acuh wieder sehr informativ, danke. Leider habe ich damit zwwei bereits geschilderte Probleme, nämlich NULL und BLOB SUB_TYPE TEXT korrekt importiert zu bekommen.
|
AW: Wie bekomme ich einen performanten Firebird?
naja, nullwerte werde mit coalesce umgewandelt in Leerstrings. Falls im Ziel dann auch wieder nullwerte gebraucht werden, können die dort ja via trigger auch wieder von einem Spezialstring, z.B. 'NULL' wieder in einen Nullwert umgewandelt werden.
Blobs sind eine eigene Baustelle, da würde ich wenn es geht die blobdaten in einen varchar packen (geht ja bis 32765 Zeichen Länge, macht dann aber das external file sehr groß), dann mit substring(feldname from 1 for 32765) noch begrenzen. Oder noch besser, aus dem original Import entfernen und später gesondert einspielen. Entweder baust du dir dafür ein eigenes Tools oder benutzt so was wie in IBExpert eingebaut http://ibexpert.net/ibe/index.php?n=...sIntoADatabase |
AW: Wie bekomme ich einen performanten Firebird?
Tolle Ansätze auf aktuellem Stand... ist zwar noch nicht auf dem Level was Anwendungen in meinem Gebiet brauchen, aber als "gute" Referenzwerte zur Argumentation bei hyperschlauen Admins/IT-Beratern super zu verwenden.
1Mio Datensätze pro Minute ist für SQL schon nicht schlecht... Da ich pro Tabelle "sehr sehr viele" kleine Buchungsdatensätze(100..300Mio Records) in Simulationen schneller 1..2Mio Datensätze pro Sekunde incl. (Zeit)Index streamen/kopieren muss(das ist nochmal Faktor 100+ schneller!), geht das wohl weiter nur mit eigenen auf LowLevel programmierten binären File-Strukturen. Wenn es einen "realistischen"/"bezahlbaren" SQL-Datenbankserver mit einer Transferleistung von 1Mio Records/Sekunde(oder besser;) gäbe, würde mich das interessieren... wäre für jegliche Vorschläge offen, egal ob hier oder als PM. |
AW: Wie bekomme ich einen performanten Firebird?
Microsoft SQL-Server mit den
einschlägigen Optimierungen sowie diversen Tricks, die man sonst noch im Internet findet (meist Hardware) ist per bulk load schon sehr schnell. Mich würde es wundern, wenn es ein RDBMS gibt, das diese Performance ohne bulk load hinbekommt.Mit einem einfachen Key-Value Store (vor Jahren mal geschrieben) habe ich vor längerer Zeit ohne Optimierungen ca. 0.5 Mio Datensätze im regulären Betrieb hinbekommen (Datensätze ist übertrieben. 32 Byte-Chunks waren das und embedded war das Teil auch noch). Ich kann mir gut vorstellen, das gängige IMDB oder ausgewachsene KVS die Performance hinbekommen, die Du wünschst. Aber bezahlbar ist das dann irgendwann nicht mehr, weil der Server dann ziemlich teuer wird (und persistent ist das dann ja sowieso nicht). Allerdings hat mein KVS das auch auf Pladde geschrieben. Bei den aktuellen (z.B. Redis) scheint das auch der Fall zu sein. Insofern sollte ich die nicht in einem Atemzug mit IMDB nennen. |
AW: Wie bekomme ich einen performanten Firebird?
Zitat:
|
AW: Wie bekomme ich einen performanten Firebird?
Zitat:
|
AW: Wie bekomme ich einen performanten Firebird?
Aber dann bewegen wir uns ja auch eher im Bereich von Big Data denn in relationalen DBMS.
|
AW: Wie bekomme ich einen performanten Firebird?
BigData ist das noch nicht, ist nur eine kleine Lösung für DataMining und etwas Statistik im Bankenumfeld für elektronische Finanztransaktionen bis in den Millisekundenbereich.
Über 10Jahre kommen dann pro Tabelle schon mal locker hunderte Millionen von Datensätzen zusammen. BigData wird es erst, wenn von vor hat solche Daten von sagen wir allen weltweit gehandelten Werten (Aktien,Optionen,Futures,Forex) auf einem System zusammen zu führen und dann möglichst in Echtzeit was darin zu suchen... dann hätte ich gerne eine Transferleistung von 100..200Mio Records/Sekunde... 8-) |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 15:10 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