Upsize und ISAM-Emulation

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Benutzeravatar
steffen.pirsig
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 24
Registriert: Fr, 04. Nov 2011 12:09
Wohnort: Eschborn, Deutschland
Danksagung erhalten: 6 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von steffen.pirsig »

Hallo Andreas,

erlaube mir bitte zu deinen nachfolgenden Feststellungen/Äußerungen ein paar Korrekturen/Klarstellungen :)
andreas hat geschrieben: Mo, 05. Aug 2019 10:25 Ich habe einiges gelesen, an Vorträgen gehört und selbst Tests unter C# mit Parallelausführung auf mehreren CPUs (keine Threads) ausprobiert.
Die Job-Verteilung auf mehrere CPUs kostet viel Zeit! Das ist von vielen Experten bewiesen!
Deswegen raten diese, vor der Anwendung der Parallelausführung auf mehreren CPUs jeden einzelnen Fall zu bewerten!
Ich habe Beispiele in C# nachgebaut, die das gleiche mit unterschiedlicher Menge der Operationen/Daten ausführen.
Die Ergebnisse: die Ausführung auf mehrere CPUs löhnt sich nur bei sehr großen Operations-/Datenmenge aber auch nicht immer!
Bei kleinen Mengen ist die Parallelität viel langsamer! Und ob es bei den Größeren Mengen und kleinen ms-Unterschieden es sich lohnt, ist auch die Frage, die jeder für sich selbst und je Projekt beantworten muss.

Im folgenden Bild habe ich Screenshot von dem C#-Programm angehängt. Die Schleifen machen nur mathematische Operationen. Bei dem Beispiel mit den Namen werden diese auf Bildschirm ausgegeben. Die Ergebnisse müssten für alle Programmiersprachen gelten! Die Verteilung der Aufgaben auf Threads würde hier bestimmt noch das ganze etwas beschleunigen, würde aber von der eigener Programmierung und richtiger Aufgabenverteilung abhängen!
1. Die Parallele Variante wird nicht besser je mehr Daten verarbeitet werden, sondern weil das Verhältniss Parallelisierungskosten zu Anzahl der ausgeführten Operation die Parallelisierbar sind sich verändert.
2. Ich kenne deinen Testcode nicht, muss aber aus deiner Aussage "nur mathematische Operationen" sowie deinen Messdaten vermuten das du keine Komplexen Operation durchführst (File I/O, sorts in memory, scan von byte-arrays, Windows API Calls, UI calls), auch muss ich bei deinen Messdaten davon ausgehen das du keine Daten auf die gleichzeitig Zugegriffen werden muss zwischen den Threads synchronisierst. Beides würde deine Parallelisierungskosten weiter erhöhen und damit das ganz noch mehr zu ungunsten der Parallelisierung verschieben.

Wenn mann 1+2 verstanden hat und berücksichtigt dann ist es leider so, das nur wenige Szenarien von Multithreading über CPU Kerne hinweg im Sinne einer Skalierung der Verarbeitungsgeschwindigkeit profitieren. Photoshop Filter sind ein gutes Beispiel, das Bild wird in Partitionen unterteilt und dann wird auf jedem Thread einer anderen CPU der Filter auf die Bilddaten angewandt. Funktioniert aber auch nur wirklich schneller wenn bis auf Assembler Ebene alles optimiert ist - und die haben bei Adobe dafür tatsächlich ein eigenes Team das sich mit diesem Aspekt auseinandersetzt.

Nochmals, Multihreading war niemals dafür gedacht über mehrer Kerne hinweg eine Skalierung zu erreichen. Die besten Skalierung erreicht man heute indem über Prozesse auf unterschiedlichen Kernen die Aufgaben verteilt werden. Dazu wird am besten die CPU für den Prozess zufällig aus den Verfügbaren CPUs ausgewählt - also ungefähr: SetLogicalProcessor( RandomInt(GetLogicalProcessorCount()) )

Multithreading ist dafür gemacht mehrere Ausführungspfade innerhalb eines Prozesses ohne yielding zu erhalten oder in der Praxis ganz einfach dafür Sorge zu tragen das ein Anwender nicht darauf warten muss das der Druckjob fertig ist, oder der Auswertungslauf fertig ist. Er kann trotzdem in der multithreaded Anwendung weiterarbeiten und zum Beispiel einen Kunden editieren.

Gruss
Steffen F. Pirsig
Alaska Software Inc.
Benutzeravatar
steffen.pirsig
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 24
Registriert: Fr, 04. Nov 2011 12:09
Wohnort: Eschborn, Deutschland
Danksagung erhalten: 6 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von steffen.pirsig »

Hallo Jan,
Jan hat geschrieben: Mo, 05. Aug 2019 16:42 Es SCHEINT so als ob man die Auslastung der Kerne per WMI auslesen kann. Hab mich da aber noch nicht tief reinlesen können.

Jan
ja kann man. Das Problem ist aber in einer dynamischen Lastumgebung ist dieser Wert bereits zum Zeitpunkt der Rückgabe des Messergebnisses so veraltet das der Wert nicht mehr der Realität entspricht. Es gibt zwar viele coole und auch komplexe "Scheduling" Algorithmen aber in der Praxis war der Random immer noch der beste. Immer daran denken, ein Zufallszahlengenerator soll ja in einer unendlichen Zeit alle Zahlen seines Wertebereiches in exakt gleicher Anzahl ausgeben. Mit anderen Worten, die CPU Last wird durch die Verwendung eines Zufallszahlengenerator sehr gleichmäßig auf alle Kerne verteilt.

Gruss
Steffen F. Pirsig
Alaska Software Inc.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

Hallo Steffen,

ja, die Funktionen kannte ich schon. Hatte das mal irgendwo in einem Sample oder einem Eurer Papiere gelesen, glaube ich. Hab das aber irgendwie noch nie umgesetzt.

Warum ich auf das Auslesen der Prozessorlast je Kern kam: Wenn ich Pech hab schmeiß ich meinen Prozess auf einen Kern, der gerade in einer heftigen Auswertung rumwerkelt. Nicht nur für einen Sekundenbruchteil, sondern für Minuten. Könnte ja sogar ein eigenes Programm von mir sein. Und da wäre es vermutlich nett zu wissen, welchen Kern man da am Besten meidet.

Aber ich stimme Dir zu: Vermutlich werden die allermeisten Spitzen doch eher sehr temporär sein.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
steffen.pirsig
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 24
Registriert: Fr, 04. Nov 2011 12:09
Wohnort: Eschborn, Deutschland
Danksagung erhalten: 6 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von steffen.pirsig »

Jan,
Jan hat geschrieben: Mo, 05. Aug 2019 17:28 Warum ich auf das Auslesen der Prozessorlast je Kern kam: Wenn ich Pech hab schmeiß ich meinen Prozess auf einen Kern, der gerade in einer heftigen Auswertung rumwerkelt. Nicht nur für einen Sekundenbruchteil, sondern für Minuten. Könnte ja sogar ein eigenes Programm von mir sein. Und da wäre es vermutlich nett zu wissen, welchen Kern man da am Besten meidet.

Aber ich stimme Dir zu: Vermutlich werden die allermeisten Spitzen doch eher sehr temporär sein.

Jan
ich verstehe deinen Wunsch sehr gut. Wir hatten vor mehr als 10 Jahren die gleichen Wünsche aber mussten in vielen Experimenten und durch das Studium externer Arbeiten lernen. Das Problem "Welches ist die beste CPU für meinen Prozess" ist in Wirklichkeit signifikant komplexer als wir es hier diskutieren - ich nenne mal als weitere Entscheidungsparameter CPU Quotas, Thread Quantum sowie Adaptives-Scheduling des Betriebssystemes und das ist wiederum nur einen kleiner Teil dessen was berücksichtigt werden muss.

Wie gesagt, Random ist aktuell das effektivste Verfahren. Und was deine Auswertungsproblematik betrifft, dreh den Spieß einfach rum. Will sagen, reserviere CPU 1-2 für deine Auswertungsprozesse und setzten die anderen Prozesse oder Terminal-Sessions (RDP) dann per Random-Funktion auf die verbleibenden CPUs und du bist fein raus.

Steffen F. Pirsig
Alaska Software Inc.
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von andreas »

Hallo Steffen,

du hast in beiden Punkten (1 und 2) wie auch mit dem Rest Recht! Ich kenne es genauso, wie du es beschreibst und die Testbedingungen sind genauso, wie du erklärst. Die Parallel-For-Schleife teilt automatisch die Durchläufe auf die CPUs auf und verarbeitet die zugewiesene Menge. Diese Funktionen haben auch einige Begrenzungen, die ich hier nicht eingehen werde. Ich wollte nur Zeigen, wie es in anderen Sprachen mit den Zeiten aussieht und dass es nicht wirklich viel ausmacht und in vielen Fällen von dem Programmierer abhängt, ob das Programm dadurch evtl. schneller oder langsamer wird!
Im Bezug auf Threads und Upsize würde es dann auch keine große Rolle spielen.
Wenn ich dich richtig verstanden habe, laufen die Threads auf einer CPU aber evtl. auf die Kerne verteilt?! Wenn es so ist, dann wäre ja das ganze Problem damit eigentlich erledigt! Man sollte dann nur auf die größere Anzahl der Kerne je CPU bei Hardwarekauf achten.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

Tom hat geschrieben:Schreibt jemand, der mit einer zehn Jahre alten Compilerversion arbeitet -
wie sich beim letzten Forum Treffen herausstellte hat 50% der Teilnehmer mit v1.9.355 gearbeitet.
wir ALLE die mit der "Stable" Version arbeiten werden durch solche Aussagen diskriminieren :!:

klar wer das "neue" Modell fährt "lästert" über das "alte" aber meine Frage was den NICHT unter Windows 10 funktionieren würde kann keiner beantworten [-X
wenn das wirklich der Fall wäre wurden sicherlich ALLE v1.9x User unstellen "müssen" auf eine neuere Version.
Hubert hat geschrieben:Wenn 4 PCs mehr inserts schaffen, als 4 PC mit 4 Threads, würde ich mal auf die Netzwerkkarte tippen, viel langsamer als eine CPU.
4 x Xbase++ Apps auf 4 PC wo Satzweise das zusammenstellen eines SQL Statment laufen erzeugen eben KEINE Last für die Netzwerkkarte :!:
die Netzwerk Belastung auf dem Server wurde mit < 50% angezeigt und stieg bei einer CPU und 4 Threads auf 80%. bei 40 Apps x Xbase++ sähe es anders aus.
Andreas hat geschrieben:Wenn ich dich richtig verstanden habe, laufen die Threads auf einer CPU aber evtl. auf die Kerne verteilt?!
Wenn es so ist, dann wäre ja das ganze Problem damit eigentlich erledigt!
Man sollte dann nur auf die größere Anzahl der Kerne je CPU bei Hardwarekauf achten.
wenn Xbase++ es auf mehrere Kerne verteilen würde wäre wie du sagst das Problem erledigt ... tut es ja nicht, oder :?:

---

richtig ist das ich wohl von einen "Schnell Boot" spreche wärend hier ein "Dampfer" fährt.

mit SQL als Back-End stehe ich in Konkurenz zu anderen Sprachen ("Schnell Boot") wo Xbase++ (egal ob v1.9x oder v2.x) wie ein alter "Dampfer" aussieht.
die Kunden sind "schlauer" geworden was "Versprechungen" angeht und deshalb wird oft eine Demo "nach Vorgabe" verlangt.

erst wenn man sich der Direkten Konkurrenz stellt merkt man wie krass die Unterschiede sein können.

---

Multithreading von Alaska ist "anderes" als von harbour oder anderen Sprachen.
darüber gab es etliche Diskussionen wo sich auch Steffen beteiligt hat. wer will kann das ja nachlesen.

Xbase++ biete dem User ein Menge Vorteil indem es die User in einen "goldenen Käfig" sperrt.
Windows Nachrichten werden "zensiert" und nur das durchgelassen was Alaska für notwendig erachtet.
ein CG sorgt für das "aufräumen" und das jeder Thread seine eigene Workarea besitzt hat ja auch (vermeindliche) Vorteile für den User.

wenn ein Xbase++ User nun aus seinem "goldenen Käfig" ausbricht und in die Windows Welt sieht dann "merkt" man erst welche Möglichkeiten einem vorenthalten wurden. Steffen als "hoher" Priestern muss natürlich seinen "goldenen Käfig" verteidigen aber die Zeiten ändern sich.

---

M$ hat gute Erfahrungen mit Github mit "Usern" gemacht. es wird darüber gemunkelt das M$ "alten Code", der nicht mehr Supportet wird, auszulagern.
was wäre wenn M$ den Source von "FoxPro" bei Github einstellen würde ...
gruss by OHR
Jimmy
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von andreas »

Normalerweise, wenn mir ein Produkt nicht gefällt, schmeiße ich dieses weg und benutze ein besseres. Dabei konzentriere ich mich weiterhin auf dessen Benutzung. Falls ich doch bei dem alten Produkt bleibe, nehme ich seine alle Nachteile an und meckere nicht darüber. Es gibt genug alternativen und es ist meine Entscheidung. Ich kann nur noch in einer höflichen Form dem Hersteller die Verbesserungsvorschläge machen. Das gilt bestimmt für jeden hier.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von brandelh »

Die "nicht sehr genaue" Netzwerklastanzeige ... schöner Balken, zeigt an welcher Anteil an der verfügbaren Datenbandbreite genutzt wird,
wenn man eine riesige Datei mit dem Explorer herunterkopiert, kann man hier eine Auslastung sehen.

Was ich meinte war die Antwortzeit, auch bei kleinen Paketen, die bei einem Gigabit Netz 0 % auslasten, sind dennoch Wartezeiten (im Sekundenbereich ... aber wehe wenn die Gegenseite nicht antwortet, dann kann es auch länger sein).

Das sind die Zeiten die ich meine ...
Das Verteilen von Aufgaben auf mehrere CPUs, kann nur von Vorteil sein, wenn diese völlig unabhängig voneinander sind, sonst müssen sie sich gegenseitig sperren und der Cache ist ja - soweit ich mich erinnere - auch je CPU !
Das dauernde Umschalten von einer CPU auf eine andere kostet wertvolle Zeit und zwingt jedes System in die Knie. Ähnlich der Situation wenn man früher auf den Drucker warten musste und alles in einem Thread ablief.

Zur Xbase++ Version, in der aktuellen 2.00 wurden viele offene PDR der 1.90 gefixed !
Warum du meinst dass die 10 Jahre alte Version "stable" sei, kann ich nicht beurteilen, den Begriff habe ich bei Alaska noch nie gesehen (oder vergessen).
Sicher ist aber, dass die 2.00 die du noch hast und auch schon Jahre alt ist, längst überholt ist.

Keine Version eines Programmes ist fehlerfrei !

Die aktuelle 2.00 ist sicher stabiler als die alte und kann auch mehr.
Ich muss Tom 100 % Recht geben, dein ewiges herum gehacke auf den "Problemen" von Xbase++ nervt mich auch.

Wenn ich C/C++ Programmieren wollte und mich um alle Nachrichten kümmern wollte, dann würde ich das machen und nicht versuchen einer Hochsprache anzulasten, dass Sie dem normalen Anwendungsentwickler Arbeit abnimmt.
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

Steffen stellt es so dar als wenn es nicht an dem Produkt Xbase++ läge sondern an Usern die nicht wissen wie man damit umgeht und einen PG-Server nicht ordentlich konfigurieren können :roll:
wenn er das hier im Forum sagt reagiere ich natürlich darauf das es durchaus einige User gibt die sich schon seit einigen Jahren damit beschäftigen und wir User nicht so doof sind um einen PG-Server ordentlich zu konfigurieren [-X

das Steffen dann noch im Thread "4 GB Patch" was schreibt hat mich doch sehr erstaunt :shock:
sicherlich hat Steffen schon etliche Apps für "Delaunay Triangulation" geschrieben und hat dabei Wissenschaftliche Unterstützung gehabt :badgrin:

solang Steffen hier im Forum etwas schreibt was den User nicht als gleichwertig ansieht werde ich weiterhin Beiträge schreiben.
:boxing:

---
andreas hat geschrieben: Di, 06. Aug 2019 8:24 Normalerweise, wenn mir ein Produkt nicht gefällt, schmeiße ich dieses weg und benutze ein besseres.
wenn ich einen alten VW (kein Diesel) fahre muss ich den nicht weg schmeissen ...
aber ein neues Auto von VW werde ich mir wohl nicht kaufen ... es sei denn ein E-mobil :!:
gruss by OHR
Jimmy
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von andreas »

AUGE_OHR hat geschrieben: Mi, 07. Aug 2019 2:54
andreas hat geschrieben: Di, 06. Aug 2019 8:24 Normalerweise, wenn mir ein Produkt nicht gefällt, schmeiße ich dieses weg und benutze ein besseres.
wenn ich einen alten VW (kein Diesel) fahre muss ich den nicht weg schmeissen ...
aber ein neues Auto von VW werde ich mir wohl nicht kaufen ... es sei denn ein E-mobil :!:
Jimmy,

du verhältst dich hier schlimmer als kleines Kind, nimmst nur Stücke aus dem Text und greifst die Leute persönlich an! :(

Ich habe in meinem Text betont: wenn mir ein Produkt nicht gefällt!
Wenn dir dein alter VW gefällt, dann spricht nichts dagegen, dass du ihn behältst!
Viele schätzen dich hier für dein Ehrgeiz und was du hier an informativen Beiträgen zur Programmierung lieferst!
Die Persönliche Angriffe und auch noch in der Öffentlichkeit sind aber was anderes!
Dann wunderst du dich, dass die Leute sich genervt fühlen und nichts mehr von dir in der Sache hören wollen!
Irgendwann wird es nach hinten gehen! Hör bitte damit auf!
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: Upsize und ISAM-Emulation

Beitrag von HaPe »

Irgendwann wird es nach hinten gehen! Hör bitte damit auf!
Full ACK 8)
--
Hans-Peter
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

hi,

hier im Forum ist Steffen für mich nur ein User und nicht ein Hersteller.
im Forum duzen sich die User und auf diesem Level sprechen wir hier gewöhnlich im Forum.

nur weil Steffen im Forum anwesend ist bedeutet das nicht das sich irgendwas geändert hat [-X
lediglich der Ton hat sich gewandelt seit Steffen dabei ist ...
gruss by OHR
Jimmy
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

AUGE_OHR hat geschrieben: Do, 08. Aug 2019 1:25lediglich der Ton hat sich gewandelt seit Steffen dabei ist ...
Stimmt. Dadurch, das tiefergehende Infos von ihm gepostet werden sind manche DIskusisonen wesentlich sachlicher geworden.

Jan
Zuletzt geändert von Jan am Do, 08. Aug 2019 7:21, insgesamt 1-mal geändert.
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Stimmt,

der Ton hat sich gewandelt. Ob es wesentlich sachlicher geworden ist eine gute Frage. Aus meiner Sicht empfinde ich es eher negativ.
Valar Morghulis

Gruss Carlo
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Hallo

wir haben nun doch noch einen Weg gefunden Datensätze (ohne das Upsize-Tool) sehr schnell in eine PG-Datenbank abzufüllen.
Dies ohne die Serverkonfiguration zu ändern.
Es ist möglich so ca. 80'000 Datensätze/Sek. in die Datenbank zu füllen.
pgin.jpg
pgin.jpg (17.55 KiB) 10530 mal betrachtet
Mein Upsize resp. Umstieg von DBF zu PG ist damit erfolgreich verlaufen und das Projekt abgeschlossen.
(mit PG meine ich allerdings NICHT die DBF Emulation)
Valar Morghulis

Gruss Carlo
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

hi Carlo,
ramses hat geschrieben: Sa, 21. Dez 2019 20:21 wir haben nun doch noch einen Weg gefunden Datensätze (ohne das Upsize-Tool) sehr schnell in eine PG-Datenbank abzufüllen.
Dies ohne die Serverkonfiguration zu ändern.
Es ist möglich so ca. 80'000 Datensätze/Sek. in die Datenbank zu füllen.
das hört sich doch gut an =D>

hast du schon gemerkt das es "keinen interessiert" wie man auf solche Geschwindigkeiten kommt ... das wäre ja "Arbeit" ...
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Hallo Jimmy
AUGE_OHR hat geschrieben: So, 22. Dez 2019 0:19 hast du schon gemerkt das es "keinen interessiert" wie man auf solche Geschwindigkeiten kommt ... das wäre ja "Arbeit" ...
Ja. Sicher habe ich das auch bemerkt. Das kann aber auch daran liegen dass das Interesse an echtem PostgreSQL fehlt oder niemand richtig grosse Datenbestände hat wo es dann auf Geschwindigkeit ankommt und ohne diese gar nicht geht. Stell dir vor meine grösste Datenbank hat über 500Mio. Datensätze da geht nichts ohne Geschwindigkeit. Und ja es ist "Arbeit" .....
Valar Morghulis

Gruss Carlo
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von brandelh »

Ähm,

vor einigen Jahren hatte ich dazu schon mal was geschrieben (Umsetzen großer Datenbestände von DBF auf MySQL und PostGreSQL mit SQLexpress) ... also von meinen Experimenten berichtet.
Meine Erfahrung hat mich gelehrt eine ANSI Datei mit der Syntax einer Datensicherung in meiner Anwendung zu erzeugen und in der Server-Verwaltung diese einzuspielen.

Allerdings habe ich es nie praktisch gebraucht ;-)
Gruß
Hubert
Antworten