サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
hito4-t.hatenablog.com
embulk-output-oracleを使っている方から、テーブルがあるのにエラーになってしまう、という問い合わせがあった。 調べてみると、テーブル名は大文字なのに、設定ファイルは小文字で書いてある。 普通にOracleでSQLを書くと大文字/小文字は区別されないが、embulk-output-jdbcではテーブル名を引用符で囲んだSQLを構築する。 Oracleでは引用符で囲むと大文字/小文字が区別されてしまうのだ。 うーん、各DBMSで大文字/小文字が区別されるかどうか、まとめておいた方がよさそうだ。 Oracle データベース・オブジェクトのネーミング規則 9. 引用符のない識別子は、大/小文字が区別されません。 引用符のない識別子は大文字として解析されます。 引用識別子では、大文字と小文字が区別されます。 実際にやってみた。 SQL> CREATE TABLE TEST(ID C
背景 自分はSIerのエンジニアである。 いろいろなお客様の、いろいろな業務システムと格闘するのがお仕事である。 また、今はembulk-input-jdbcとかembulk-output-jdbcのコミッタもやっている。 業務システムとRDBとテキストファイル 業務システムでは、たいていRDBを使っている。 そして、サーバ間でデータを連携するために、RDBからテキストファイルにエクスポートしたり、テキストファイルをRDBにインポートしたりすることが結構ある。 そんなときどうするかと言うと、RDB付属のツールを使うことが多い。 例えば、OracleへのインポートであればSQL*Loader、MySQLへのインポートであればmysqlimport、というように。 RDB付属のツールの問題点 いろいろなお客様がいて、いろいろなシステムがあるので、RDBもいろいろである。 ちなみに、うちの会社で
Embulkでプラグインをインストールすると、実行ユーザのホームディレクトリの下に.embulkディレクトリができて、gemがインストールされる。 別の環境でも同じようにEmbulkを動かすには、Javaをインストールして、Embulkの実行ファイルをコピーして、ホームディレクトリもコピーするだけ。 なんだけど、アプリケーションはホームディレクトリではなくてアプリケーション用のディレクトリにまとめたい、ということもある。 そこで、その方法について調べてみた。 Embulkのホームディレクトリ ".embulk"でgrepしてみると、embulk_bundle.rbに以下のコードがあった。 user_home = java.lang.System.properties["user.home"] || ENV['HOME'] unless user_home raise "HOME envir
以前、Embulkのエラー処理について調べてみるというタイトルで記事を書いたが、あれからずいぶんとバージョンが上がっているので、再度確認してみることにした。 CSVの項目が多過ぎる場合 以下のような警告が出て、スキップされた。 2015-12-11 16:02:29.364 +0900 [WARN] (task-0000): Skipped line 2 (Too many columns): 1,123.40,test1,TEST1,2015-04-24,2015-04-24 01:02:03,2015-04-24 01:02:03.123,999 終了コードは0だった。 ドキュメントを見ると、allow_extra_columns: true を設定すると、余計な項目は無視されて正常な行としてと取り込まれるようだ。 逆に、stop_on_invalid_record: true を設定
embulk-output-redshiftを使えばテキストファイルを簡単にAmazon Redshiftにインポートできる。 だが、やはり気になるのはパフォーマンスだ。 という訳で、embulk-output-redshiftのパフォーマンスを計測してみた。 計測環境 AWSのリージョンはTokyoを使用した。 Redshiftのインスタンスはdc1.large。クライアントのインスタンスはm1.xlarge(4コア)だ。 インポート先のテーブルは、以下を用意した。 create table example ( id integer, num decimal(12,0), value1 varchar(60), value2 varchar(60), value3 varchar(60), value4 varchar(60), value5 varchar(60), value6 va
embulk-output-jdbcではいろいろな型が出てくる。 ややこしいので、現在の実装に基づいてまとめてみた。 embulk-output-jdbcに出てくる型の種類 入力の型 column_optionsのvalue_type column_optionsのtype 出力先テーブルの列の型 入力の型 embulk内部の型であり、boolean/long/double/string/timestampのいずれかである。timestampにはフォーマット指定もあり、日付のみや時刻のみといいう指定もできる。 入力の型は、例えばCSV入力の場合はymlファイルで定義する。 embulk-input-jdbcを使う場合は入力元テーブルの列の型により自動的に決まる。 テーブルの列の型(java.sql.Types)入力の型 BOOLEAN BIT boolean TINYINT SMALLIN
最近こればっかりだが…、現在embulk-output-oracleの高速化に励んでいる。 どうやったら大量データをOracleに高速に突っ込めるか?というのをいろいろ試してみた。 SQL*Loader Oracleが提供する、大量データロード用のツール。 その目的に作られているだけあって、さすがに速い。 JDBCからダイレクト・パス・ロード SQL*Loaderでは、普通のINSERTではなく、ダイレクト・パス・ロードという特別な方法で高速にデータをロードしている。 実はこれ、JDBC経由でも使える。 APPEND_VALUESヒントを付けるのだ。 INSERT /*+ APPEND_VALUES */ INTO <テーブル名> ... 普通のINSERTに比べるとだいぶ速い。 とは言え、SQL*Loaderにはまだまだ敵わない。 OCI(Oracle Call Interface)でダ
Cのポインタを保持したい 現在embulk-output-oracleを高速化するために、JNI(Java Native Interface)を使ってプログラミングしている。 その時ちょっと悩んだのが、Cのポインタをどうやって保持するか、だ。 フローとしては、 Java C 初期化処理 → 必要なメモリを確保 処理本体 → メモリを使っていろいろ処理 後処理 → メモリを解放 のような感じだ。 初期化時に確保したメモリのポインタを、後続の処理に引き継ぐ必要がある。 どうやってポインタを保持するか まず、C側でグローバル変数で持つ方法。 これだと並列処理に対応できないからだめだ。 Java側にポインタを返し、後続の処理で渡し直してもらう方法がいいだろう。 と思ったが、Javaにはポインタ型というのが無い。intとかlongにキャストすればいいのかな?とも思ったが、処理系依存になるし気持ち悪い
JDBCには便利な機能があって、テーブルや列のメタ情報を取得できる(java.sql.DatabaseMetaDataのgetTablesとかgetColumnsとか)。 で、これらのメソッドの引数にはカタログとかスキーマを渡す必要がある。 これって何なの?というのを調べてみたい。 ちなみに、スキーマはどのDBMSでもだいたいスキーマだけど、カタログの方はDBMSによって違う。何なのかはDatabaseMetaData#getCatalogTermsにより調べられる。 手元にはOracle(12c)、SQL Server(2012)、MySQL(5.6)があるので、こいつらについて調べてみる。 Oracleのカタログとスキーマ catelog term (なし) 現在のカタログの取得 (なし) 現在のカタログの変更 (なし) 現在のスキーマの取得 Connection#getSchema
Embulkの並列処理 Embulkは、処理を複数のタスクに分割して並列に実行する仕組みを備えている。 しかし、標準のファイル入力プラグインでは、単純に1つのファイルを入力すると1タスクにしかならないようだ(こちら参照)。 ソースを読んでみると、複数ファイルを読むと複数タスクになるようだ。 試しにこんな感じに4ファイルを用意して、 /test └in ├in1.csv ├in2.csv ├in3.csv └in4.csv こんなymlファイルを用意して実行したら、 in: type: file path_prefix: '/test/in' parser: type: csv columns: - {name: id, type: string} - {name: name, type: string} out: type: file path_prefix: '/test/out' fi
Embulkを使えば、いろいろなデータを簡単にDBに突っ込めるはず。 でも、パフォーマンスが気になるよね。 という訳で、Embulkのパフォーマンスを測ってみることにした。 環境の準備 自分のマシンでパフォーマンステストをすると他のことができなくなってしまうので、AWSを使うことにした。 インスタンスタイプはどうしようか? マルチスレッドを試したいので4CPU欲しい。DB入れるのでメモリもある程度必要だ。ディスクはSSDだとちょっと速過ぎる気がするし、EBSだと遅い気がするし…、とかいろいろ考えて、結局旧世代のm1.xlargeにしてしまった。 OSは自分のマシンに合わせてWindows。JavaとかMySQLもインストールする。 MySQLのチューニングとかは特にしていない(あまり詳しくないので…)。 Embulkもダウンロードした。このときの最新は0.5.0。 embulk-outpu
embulk.batで起動する 前回は、Embulkを java -jar embulk.jar <command> ... で起動していたが、実はこれは正式な起動方法ではない。 embulk.jarをembulk.batにリネームし、 embulk <command> ... で、すっきりと起動できるのだ! 但し、0.4.8まではembulk.bat <command> ...でないと起動できなかった(詳細はこちら)。 どうして起動できるのか? embulk.bat(元はembulk.jar)の中身をテキストエディタで開くと、先頭に以下のようなコマンドが埋め込まれている。 java -jar %~f0 %* これは、 java -jar <embulk.batのフルパス> <コマンドライン引数> に展開されるので、embulk.batがJARファイルとして実行される。 ビルドスクリプトb
このページを最初にブックマークしてみませんか?
『hito4-t.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く