データベースへの保存が遅すぎる (1 分あたり 10,000 レコード)<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />270,000 レコードと 72 列を持つ JMP テーブルがあります。
ODBC 経由でデータベースに保存しようとしていますが、プロセスが非常に遅く、1 分あたり約 10,000 レコードになります (はい、1 分あたり、これはタイプミスではありません)。
Microsoft SQL Server 2014 サーバーと PostgreSQL 9.3 サーバーの両方にエクスポートしようとしましたが、速度 (または速度の欠如) はどちらの場合も同じでした。 また、両方のサーバーは、JMP を実行しているワークステーションと同じ建物内にあります。 2 つのサーバーにアクセスできるユーザーは私だけなので、彼らが他のことで忙しくないことはわかっています。
速度が遅いのは、JMP がテキスト フィールドの長さを把握しようとしていることが原因である可能性があると考えたので、すべてのテキスト列を削除して数値フィールドのみを残しましたが、速度は同じです。
ODBC 経由でどちらかのデータベースから同様のサイズのテーブルを取得する場合、所要時間は 20 秒もかかりません。
ETL ツールは、ODBC または JDBC 経由で 2 つのデータベースに書き込む方がはるかに高速です。
データベースへの書き込みを高速化する方法について何か考えはありますか? 現時点では、この機能は非常に遅いため、実際には使用できません。
ありがとう。
Re: データベースへの保存が遅すぎる (1 分あたり 10,000 レコード)JMP 13 では、データベースの対話に関してかなりの改善が行われています。その 1 つは、[データベース] > [テーブルの保存] オプションです。
JMP 13 では、それをサポートするデータベース (ほとんどのデータベース) に対して複数の行が挿入 (一括挿入) されるようになりました。JMP 13 データベース対話の改善には、列名と大文字小文字の保持 (可能な場合)、および TIMESTAMP 情報の保持も含まれます。
Re: データベースへの保存が遅すぎる (1 分あたり 10,000 レコード)[データベース] > [テーブルの保存] オプションを使用したことはありません。実際、私はこの投稿を読むまでその存在を知らなかったので、一般的なタスクの関数を独自に書きました。私はそれらが遅いように感じますが、少なくともこのスレッドのどの速度よりも優れた速度を誇ることができます。
これが私のBulkInsert関数です。
//テーブルをデータベースに挿入..テーブル --ncols が一致すると仮定します
一括挿入=関数({データベース、 dbテーブル、 dt } 、 {デフォルトのローカル} 、
//db - データベース接続
//dbTable = データベーステーブル
//dt - JMP データテーブル
列数= Nコル( dt ） ;
行数= N行( dt ) ;
のために(私= 1 、私<=行数、私++、
値リスト= {} ;
のために( j = 1 、 j <=列数、 j ++、
もし(日付です(カラム( dt 、 j )) 、
に挿入する(値リスト、文字(フォーマット(カラム( dt 、 j )[私】 、 「ddMonyyyy h:m:s」 )))
、
に挿入する(値リスト、カラム( dt 、 j )[私])
） ;
） ;
値テキスト=代わりの(文字(値リスト） 、 「{」 、 "(" 、 "}" 、 ")" 、 「\!」 、 「」 ） ;
に代入(値テキスト、 「。、」 、 "ヌル、" ） ;
SQL_string = 「に挿入します」 || dbテーブル|| 「\!N」 ||
「価値観」 ||値テキスト;
SQLの実行(データベース、 SQL_string ） ;
） ;
） ;
ここにある、私が書いた isDate 関数が必要になります。列が日付/時刻であるかどうかを確認する簡単な方法はありますか?
日付/時刻列がない場合は、コードのその部分をコメント アウトすることもできます。
Re: データベースへの保存が遅すぎる (1 分あたり 10,000 レコード)現在は 2016 年であり、それからいくつかのバージョンがリリースされています。 遅いことは確認できますが、私の場合は 1 分あたり 200 レコードを取得します。 16.064.704 レコードがあるため、データベースに送信するまでに 2 か月かかります。 「キャンセル」ボタンは機能せず、唯一の方法はプロセスを強制終了することです。
何とかしてください。改善の余地はたくさんあるので、それほど難しいことではありません。
Re: データベースへの保存が遅すぎる (1 分あたり 10,000 レコード)
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
これは事実上、数千レコードを超えるテーブルに対しては「データベースに保存」オプションがまったく役に立たないことを意味します。 この高価なソフトウェアの仕様がもっと明確であれば...
Re: データベースへの保存が遅すぎる (1 分あたり 10,000 レコード)JMP 開発では、データを製品に取り込むことに重点が置かれてきました。Open Table で機能する「ブロック」フェッチ メカニズムを取得するのにかなりの時間を費やしましたが、Save Table には同様のメカニズムがありません。これを実施するためのオープンリクエストはありますが、特定の実装日を確約することはできません。
ブライアン・コーコラン
Re: データベースへの保存が遅すぎる (1 分あたり 10,000 レコード)
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.
ありがとう。 実は私も似たようなことを試したことがありました。 ただし、現時点では遅すぎて使用できないため、「データベースへの保存」を高速化する方法、つまり実現可能な方法があるかどうかを知りたいと思っています。
これは ODBC 設定/ドライバーに関係があるのでしょうか (ただし、JMP はデータベースからデータを取得するのが速いです)、それとも JMP の仕様なのでしょうか?
Re: データベースへの保存が遅すぎる (1 分あたり 10,000 レコード)JMP データセットを CSV ファイルにエクスポートしてから、SQL Server を使用できます。一括挿入機能性。少し面倒ですが、はるかに高速になるはずです。
