Das Speichern in der Datenbank ist zu langsam (10.000 Datensätze pro Minute).<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />Ich habe eine JMP-Tabelle mit 270.000 Datensätzen und 72 Spalten.
Ich versuche, es über ODBC in einer Datenbank zu speichern, aber der Vorgang ist äußerst langsam: Es sind etwa 10.000 Datensätze pro Minute (ja, pro Minute, das ist kein Tippfehler).
Ich habe versucht, sowohl auf einen Microsoft SQL Server 2014- als auch auf einen PostgreSQL 9.3-Server zu exportieren: Die Geschwindigkeit (oder das Fehlen derselben ...) ist in beiden Fällen gleich. Außerdem befinden sich beide Server im selben Gebäude wie die Workstation, von der aus ich JMP ausführe. Ich bin der einzige Benutzer, der Zugriff auf die beiden Server hat, daher weiß ich, dass sie mit nichts anderem beschäftigt sind.
Ich dachte, die langsame Geschwindigkeit könnte darauf zurückzuführen sein, dass JMP versucht, die Länge der Textfelder herauszufinden, also habe ich alle Textspalten entfernt und nur numerische Felder übrig gelassen, aber die Geschwindigkeit ist gleich.
Wenn ich über ODBC eine Tabelle ähnlicher Größe aus einer der beiden Datenbanken abrufe, dauert das weniger als 20 Sekunden.
ETL-Tools, die über ODBC oder JDBC in die beiden Datenbanken schreiben, sind viel schneller.
Irgendwelche Ideen, wie ich das Schreiben in die Datenbanken beschleunigen könnte? Derzeit ist die Funktion so langsam, dass sie praktisch unbrauchbar ist.
Danke schön.
Betreff: Speichern in der Datenbank ist zu langsam (10.000 Datensätze pro Minute)In JMP 13 gab es einige Verbesserungen hinsichtlich der Datenbankinteraktion.Eine davon ist die Option Datenbank>Tabelle speichern.
In JMP 13 werden jetzt mehrere Zeilen eingefügt (Masseneinfügung) für Datenbanken, die dies unterstützen (und das sind die meisten davon).Zu den Verbesserungen der JMP 13-Datenbankinteraktion gehört auch die Beibehaltung von Spaltennamen und Groß-/Kleinschreibung (sofern möglich) sowie die Beibehaltung von TIMESTAMP-Informationen.
Betreff: Speichern in der Datenbank ist zu langsam (10.000 Datensätze pro Minute)Ich habe die Option „Datenbank > Tabelle speichern“ nie verwendet.Eigentlich wusste ich bis zum Lesen dieses Beitrags nicht, dass es existiert, also habe ich eine Reihe meiner eigenen Funktionen für allgemeine Aufgaben geschrieben.Obwohl ich das Gefühl habe, dass sie langsam sind, können sie zumindest bessere Geschwindigkeiten vorweisen als alles andere in diesem Thread.
Hier ist meine BulkInsert-Funktion:
//Tabelle in Datenbank einfügen..Table – setzt Ncols-Übereinstimmungen voraus
BulkInsert = Funktion ({ db , dbTable , dt } , { Standardmäßig lokal } ,
//db – Datenbankverbindung
//dbTable = Datenbanktabelle
//dt – JMP-Datentabelle
numCols = NCols ( dt ) ;
numRows = NRows ( dt ) ;
für ( ich = 1 , ich <= numRows , ich ++,
Werteliste = {} ;
für ( J = 1 , J <= numCols , J ++,
Wenn ( isDate ( Spalte ( dt , J )) ,
einfügen in ( Werteliste , verkohlen ( Format ( Spalte ( dt , J )[ ich ] , „ddMonyyyy h:m:s“ )))
,
einfügen in ( Werteliste , Spalte ( dt , J )[ ich ])
) ;
) ;
WerteText = Ersatz ( verkohlen ( Werteliste ) , „{“ , "(" , „}“ , ")" , „\!““ , "'" ) ;
Ersetzen in ( WerteText , ".," , "NULL," ) ;
SQL_string = "Einfügen in " || dbTable || "\!N" ||
"Werte " || WerteText ;
SQL ausführen ( db , SQL_string ) ;
) ;
) ;
Sie benötigen die Funktion isDate, die ich geschrieben habe und die Sie hier finden: Gibt es eine einfache Möglichkeit herauszufinden, ob es sich bei einer Spalte um Datum/Uhrzeit handelt?
Alternativ können Sie diesen Teil des Codes auskommentieren, wenn Sie keine Datums-/Uhrzeitspalten haben.
Betreff: Speichern in der Datenbank ist zu langsam (10.000 Datensätze pro Minute)Es ist jetzt das Jahr 2016 und mehrere Versionen später. Und ich kann die Langsamkeit bestätigen, aber in meinem Fall schaffe ich 200 Datensätze pro Minute. Bei 16.064.704 Datensätzen wird es zwei Monate dauern, bis sie an die Datenbank übermittelt werden. Die Schaltfläche „Abbrechen“ funktioniert nicht und der einzige Ausweg besteht darin, den Vorgang abzubrechen.
Bitte tun Sie etwas dagegen – da es so viel Verbesserungspotenzial gibt, sollte es nicht so schwer sein!
Betreff: Speichern in der Datenbank ist zu langsam (10.000 Datensätze pro Minute)
BrianCorcoran wrote:
The emphasis in JMP development has been on getting data into the product. We have put considerable time into getting "block" fetching mechanisms working for Open Table, but we do not have a similar mechanism for Save Table. We have an open request to do this, but cannot commit to a specific implementation date.
Brian Corcoran
Das bedeutet im Endeffekt, dass die Option „In Datenbank speichern“ für Tabellen mit mehr als ein paar tausend Datensätzen völlig nutzlos ist. Wenn nur die Spezifikationen dieser teuren Software klarer wären ...
Betreff: Speichern in der Datenbank ist zu langsam (10.000 Datensätze pro Minute)Der Schwerpunkt bei der JMP-Entwicklung lag darauf, Daten in das Produkt zu integrieren.Wir haben viel Zeit darauf verwendet, die „Block“-Abrufmechanismen für „Open Table“ zum Laufen zu bringen, aber wir haben keinen ähnlichen Mechanismus für „Save Table“.Wir haben hierfür eine offene Anfrage, können uns jedoch nicht auf einen konkreten Umsetzungstermin festlegen.
Brian Corcoran
Betreff: Speichern in der Datenbank ist zu langsam (10.000 Datensätze pro Minute)
PMroz wrote:
You could export the JMP dataset to a csv file, and then use the SQL Server bulk insert functionality. A bit of a kluge but it should be much faster.
Danke schön. Ich hatte tatsächlich etwas Ähnliches versucht. Allerdings würde ich wirklich gerne wissen, ob es eine Möglichkeit gibt, das Speichern in der Datenbank schneller, also machbar, zu machen, da es im Moment so langsam ist, dass es unbrauchbar ist.
Hat es etwas mit den ODBC-Einstellungen/Treibern zu tun (aber JMP ruft Daten schnell aus den Datenbanken ab), oder ist JMP einfach so?
Betreff: Speichern in der Datenbank ist zu langsam (10.000 Datensätze pro Minute)Sie könnten den JMP-Datensatz in eine CSV-Datei exportieren und dann den SQL Server verwenden Masseneinlage Funktionalität.Ein bisschen klug, aber es sollte viel schneller sein.
