元データ分析の会社で働いていた人の四方山話スマートフォン用の表示で見る元データ分析の会社で働いていた人の四方山話この広告は、90日以上更新していないブログに表示しています。2010-07-01今週はまっていることDB相変わらずDB移行の部分です。db.dumpとかやったのが悲劇の始まりでした。0って具合にINSERTが行われ続けている...まあいいやと思って取り敢えず、停止。調べていて、ようやく原因が分かってきたような気がしてきたのでまとめてみる。-dと-Dオプションがいらない?http://www.postgresql.jp/document/pg803doc/html/app-pg-dumpall.htmldinsertsデータを(COPYではなく)INSERTコマンドとしてダンプします。これを行うとリストアが非常に遅くなります。これは主にPostgreSQL以外のデータベースにロードできるダンプを作成する時に役に立ちます。列の順序を変更した場合はリストアが失敗するかもしれないことに注意してください。VALUES...)としてダンプします。これによりリストアは非常に遅くなります。これは主に、PostgreSQL以外のデータベースにロードできるダンプを作成する時に役に立ちます。これを読む限り、バージョンが同じPostgres間のダンプ・リストアには必要無さそうなオプションでこいつが低速化させていたっぽい。copyとinsertの違いがまだよく分かっていないんだけど、この当たりに改善のポイントはありそう。標準出力への結果をdev/nullに捨てればよかった?データ挿入結果が一々画面に出力されるのが終わらなかった原因っぽいかなぁと。学生時代の研究でも、とりあえず標準出力を全てdev/nullに捨てるようにしただけで、某オープンソースのソフトウェアを利用した時の結果が出るまでの時間が大幅に改善されるなどした経験があるので、感覚的に大量の処理を行うときに標準出力がボトルネックなイメージがある。/dev/nullとすればいいのでは、という考えちなみにデータ挿入の途中でC-cで作業をやめたわけですが、データベースとしての機能は果たしてくれます。(データはたりてないけど)んでもって、一部のクエリに対して異常にレスポンスが遅くてなんでかなぁ、と考えていたんだけど、解決した。自分の場合は、データを流し込んでいる途中でやめたので、データベースとして必要最低限のテーブルと部分的なデータ、という状態になっていたと思われます。レスポンスの遅さの原因がインデックスが作られていなかったことかなぁ、と考えていて、実際、ダンプファイルの最後に記述されていたインデックスの部分をテーブルに流し込んだら、見事に高速に応答が帰ってくるようになりました。MongoDB最近、割と大きめなデータをRで扱う際に、どのようなソリューシ...2011-04-09地に身を潜め続けていた昨年と違い、今年はガンガン外に出ていきたいと思います。第一弾として、最近興味...地に身を潜め続けていた昨年と違い、今年はガンガン外に出てい...2011-04-06RでMySQLを操作してみる。Entriesはてなブログをはじめよう!rindai87さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。