AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Firebird und Geschwindigkeit mit SSD
Thema durchsuchen
Ansicht
Themen-Optionen

Firebird und Geschwindigkeit mit SSD

Ein Thema von Dumpfbacke · begonnen am 23. Feb 2011 · letzter Beitrag vom 7. Apr 2011
Antwort Antwort
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#1

AW: Firebird und Geschwindigkeit mit SSD

  Alt 23. Feb 2011, 19:34
Wie bekomme ich denn die Daten von Excel in einem Abwasch in Firebird ?
Hat er doch geschrieben :

Wenn deine Exceldaten dann ggf noch in das Firebird external file format übertragen wird (einfaches Textformat mit fester Satzbreite), dann sind auch schnell mal bis zu 100000 Datensätze pro Sekunde in die Datenbank übertragen.
Die Excel-Tabellen müssen zuerst in geeignetem Format exportiert werden (eben am besten feste Feldlängen, statt "CSV" zu wörtlich zu nehmen). Das wäre erst mal Excel.

Wie das auf der FB Seite aussieht steht hier :

http://www.firebirdsql.org/index.php...eful&id=netzka
Gruß
Hansa
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
696 Beiträge
 
FreePascal / Lazarus
 
#2

AW: Firebird und Geschwindigkeit mit SSD

  Alt 23. Feb 2011, 19:54
bei aktuellen Excel Versionen geht "speichern unter ...., typ formatierter Text Leerzeichen getrennt", das könnte man dann ggf von Firebird als externe Tabelle benutzen.
ggf ist das aber mit Makroprogrammierung auch schnell erledigt, ich mach mit excel nur das was man nicht vermeiden kann Manchmal schreibt excel dabei nämlich die dateien nicht so wie man die braucht, auch wenn das laut format theoretisch richtig wäre.

Ggf macht es sinn, einfach die Tabelle mittels einer geeigneten Excel Komponente in einem Delphiprogramm verwursten und in ein passendes Format schreiben, das lässt sich ggf besser automatisieren. Würde ich jedefalls bei vielen Dateien und großen Datenmengen so machen. Wenn das relativ wenig Daten sind kannst du auch über ODBC an die Tabelleinhalte ran, das geht unter anderem mit der ibeblock Sprache in IBExpert oder mit Tools-ODBC Viewer. Bei großen Menge ist das über ODBC aber zu lahm.

FIREBIRD_LCK ist einfach eine Umgebungsvariable für deinen Computer, geb einfach in Windows "Start - Suchen" Umgebungsvariable ein, dann unten als neue Systemvariable ergänzen und den Pfad, wo das hin soll, eintragen.
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
Firebird 5 Update und Know-how Workshop – 28.8.-29.08.2025 64546 Mörfelden - Walldorf
  Mit Zitat antworten Zitat
tsteinmaurer

Registriert seit: 8. Sep 2008
Ort: Linz, Österreich
530 Beiträge
 
#3

AW: Firebird und Geschwindigkeit mit SSD

  Alt 24. Feb 2011, 07:08
Wenn bzgl. Datentransfer etwas Out-Of-The Box nicht geht, dann würde ich zu einem professionellen ETL Tool wie z.B. Pentaho Data Integration (formals Kettle) greifen. Damit kannst du eine Fülle an Datenquellen anzapfen, verwursten (bereinigen, transformieren ...) etc. und dann wieder irgendwo einfügen. Im Falle von Firebird einfach mit dem JDBC-Treiber.

Für so ein ETL-Tool braucht man zwar etwas Einarbeitungszeit, aber wenn man mal den Dreh heraus hat, dann ist so etwas immer sehr hilfreich.

Thomas
  Mit Zitat antworten Zitat
Blup

Registriert seit: 7. Aug 2008
Ort: Brandenburg
1.493 Beiträge
 
Delphi 12 Athens
 
#4

AW: Firebird und Geschwindigkeit mit SSD

  Alt 24. Feb 2011, 09:16
Um einen einzelnen Datensatz tatsächlich physisch zu speichern muss die SSD einen komplette Page lesen, die Änderung vornehmen und diese Page wieder speichern. Ich habe die Erfahrung gemacht, das SSD mit "forced writes" beim Schreiben extrem langsamer sind als normale HDD. Sobald man "forced writes" deaktiviert sind SSD wieder schneller.

Wenn das in diesem Beispiel nicht so ist, vermute ich, das der Treiber oder die Firmware der SSD trotz aktivem "forced writes" weiterhin Schreibzugriffe verzögert ausführt.
  Mit Zitat antworten Zitat
borwin

Registriert seit: 14. Sep 2006
Ort: Rostock
72 Beiträge
 
Delphi 2007 Enterprise
 
#5

AW: Firebird und Geschwindigkeit mit SSD

  Alt 24. Feb 2011, 09:27
Zitat:
Wenn du bei dem Script die DB auf unterschiedliche Datenträger legst, dann wirst du die Unterschiede sehen. Gewinner bei mir war eine RAM Disk, danach kam dann die SSD, danach dann eine normale Festplatte. Wenn du aber ausreichend Speicher hast und die cache buffers groß genug sind und du am besten auch noch die 64 Bit Firebird Version nimmst, dann kann auch eine 10GB DB komplett im RAM betrieben werden (http://www.firebirdsql.org/rlsnotesh...gine-cachesize). Das ist aber kein Limit, wenn du 100GB physikalisch hast dann kannst du auch das komplett mit FB25x64 für Firebird benutzen.
Da habe ich doch eine Frage. Wenn die Daten im RAM liegen und es zu einem Stromausfall kommt sind die Daten doch weg?
Ist zwar aus meiner Sicht schnell aber auch ein erhöhtest Risiko.
Oder habe ich da was übersehen?

Gruß BORWIN
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.555 Beiträge
 
Delphi 12 Athens
 
#6

AW: Firebird und Geschwindigkeit mit SSD

  Alt 24. Feb 2011, 09:33
Ja, was im RAM liegt ist dann weg ... genauso natürlich auch eine RAMDisk.

Darum wird ein ordentlicher Server ja auch mit Notstrom versorgt und hatt dann genügend Zeit um den Stromausfall zu überbrücken oder um in Ruhe alles zu sichern (ordentlich Runterfahren oder Ruhezustand).
Ein Therapeut entspricht 1024 Gigapeut.

Geändert von himitsu (24. Feb 2011 um 09:35 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
696 Beiträge
 
FreePascal / Lazarus
 
#7

AW: Firebird und Geschwindigkeit mit SSD

  Alt 24. Feb 2011, 10:21
Firebird bietet dir da noch eine ergänzende Alternative, das Shadow.
Du kannst nämlich zum Beispiel eine DB auf einer Ramdisk betreiben und das
zugehörige Shadow auf einer physikalischen Platte.

Der Vorteil ist dabei dass in der DB auf der Ramdisk alle Lese und Schreibvorgänge
stattfinden, auf dem Shadow aber nur die Schreibvorgänge, die dadurch zwar ein
wenig an Performance verlieren. Außerdem musst du beim hochfahren des Servers
erst mal vom Shadow die neue DB in die Ramdisk kopieren, um dann von dort das
Shadow neu zu erzeugen.

Leseintensive Anwendungen können dadurch schon einiges gewinnen, aber wenn die
komplette db eh im Cache ist bringt das keine Vorteile. Daher am besten fb25x64
mit ordentlich RAM und einen schnellen Datenträger, ob schnelle SSD oder lieber
schnelle HDD ist dann Geschmackssache und persönliche Risikoeinschätzung.

Wichtig bei forced writes ist in erster Linie die Schreibreihenfolge, weil nur
dabei immer eine als Datenbank benutzbare konsistente Datei auf dem Datenträger
bleibt. Bei forced writes off schreibt windows selbst in der Reihenfolge wie es das
für sinnvoll hält und das hinterlässt im Fehlerfall durchaus mal Müll auf der Platte.

USV hilft ja auch nur in Ausnahmefällen, beim Bluescreen bleibt der halt noch länger
sichtbar, aber ob der Speicherinhalt es noch auf die Festplatte schafft, hängt von
vielen Faktoren ab.

Ich finde zwar auch das Hardware mittlerweile recht stabil ist, aber im Worst Case
hilft einem das auch nicht weiter.
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
Firebird 5 Update und Know-how Workshop – 28.8.-29.08.2025 64546 Mörfelden - Walldorf
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:58 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz