2010-09-09(木) 23:46(UTC +0900) p Tweet
「超多数ファイル」一括処理の勘所
元ネタはクラウド関連となっていますが、実際にはローカルシステム側でのお作法の問題ですのでチョイと解説。
先ずは元ネタとそれに反応しての呟きを。
clip IT!
from 日経トレンディネット
「人気のDropbox、100GB買って分かった“落とし穴”」
75GB分の転送に時間が掛かりまくる、と云うオハナシ。先ず空のフォルダを共有設定して、そこに少しずつコピーし共有させた方が早い。 『 人気のDropbox、100GB買って分かった“落とし穴” – デジタル – 日経トレンディネット http://j.mp/aikyfR 』
対策としては上記の通り。
元ネタの様に「マイドキュメント」をまるまる同期させたいなら、一旦マイドキュメントの中身を別フォルダに移動し、空になったマイドキュメントを共有対象として設定してからおもむろに移動してた分をマイドキュメントにコピーし戻す、と。
あ、ココで間違っても「ファイルをコピー/移動先のフォルダに貼り付け」はしないように! 右ドラッグでのコピーや Fire File Copy などのツールでいきましょう。
このとき、トレイアイコンなどを見ながら、同期中のくるくるマークが消えたのを確認しながら、次のコピーを開始するのがミソです。
このとき、コピーする数をある程度少なくするのがポイント。
例えば、フォルダ内のファイル数が子/孫フォルダまで含めて100とか200とかその程度なら、親フォルダごと一発でコピーしても平気でしょう。
逆に、フォルダ内に1,000だの5,000だのという大量のファイルがあるなら、小分けに拾ってコピーを繰り返すなどした方が良いでしょう。
もしも「ファイル数は大量だけど総容量は少ない」のであれば、思い切って zip 圧縮し、 zip フォルダとして運用する手もアリでしょう。
また、ドデカイファイル(数GB単位)がゴロゴロしているなどの場合も、ファイルを一つずつ拾ってコピーするのが無難でしょう。
ちなみに、「後からコピー」するこのやり方は、作業ついでのバックアップも兼ねるやり方になりますね。もし、マイドキュメント自体を変更する手筈を心得ているなら、そのやり方と併用しても良いでしょう。
なぜそんなに遅くなるのか?
コレはウィルススキャンなどと同様、「大量のファイルが一度に登録されるので、更新確認しながらの最初の完全同期は大変なコストになる」というハナシです。
Dropbox や SugarSync での「ファイルを共有する」動作とは、「対象フォルダ内をリアルタイム更新チェックし、更新されたファイルを差分変更する」てコトです。
つまり、一度に大量のファイルが増えたなら、先ずそのファイル全てを覚えようと更新確認し、当然新ファイルは全て更新対象なのでファイルをクラウドに投げ、その感も更新確認を止めず、引き続きファイルのアップロードを継続する、と。
更に、ネットに出て行くファイルですので当然ウィルスチェッカーもイチイチ監査を入れてきます(笑)
コレでは、そりゃー時間が掛かるッてモノですね。
では、なぜ空にしてから始めた方が良いのか?
実は、フォルダ空にすると云うよりは、少ないファイル数から初めるコトが大事なんです。
つまり、初回の更新確認はサクッと終わらせ、以降、同期完了のペースに併せてファイルを手動で追加するコトで、更新確認処理とファイル同期(アップロード)処理の負荷を軽減/分散する、と。
もし「手動でやるのでは意味がない」と云うコトなら、 wait を効かせたバッチファイルでゆっくりコピーさせるとか、どうでしょ?
関連するかも知れない?
cat: Tips(ティップス), 電脳系
tag: Dropbox, web-apps, クラウドコンピューティング
0 Trackback
2010-09-01(水) 18:27(UTC +0900) p Tweet
ご家庭内にも「デジタル」防災を
今日は防災の日、てコトで、ご家庭でも必要となってきている各種情報機器に関する防災ネタを。
先ずは、なんと云っても電源確保、つまりは UPS (無停電電源装置) を入れましょう。
最近「パソコン」と云えばほとんどがノートパソコンとなり、更に自宅でもケータイをメインに使う方も多いので、端末自体に内蔵バッテリを持っているから『別に UPS なんか要らない』と思っているコトでしょう。
であるが故に、急な停電が起きた場合の影響範囲を見積もることもせず、意外な見落としで大ダメージを被ってしまう恐れがあるワケですね。
ウチの場合、データ保管用の NAS やテレビ録画用の HDD レコーダー、それらや端末を連絡するハブやルーターは UPS に繋ぐ必要があります。
一般のご家庭なら、複合機(プリンタ/スキャナ)や USB 接続の外付け HDD 、更にそれらの経路となる USB ハブ自体も、保護する必要があるかもしれませんね。
次に、真に残すべきは機材ではなくデータであるコトに着目し、保管場所としての NAS を導入しましょう。
過去から蓄積しているメール、家族を写した写真やビデオ、がんばって作り込んだイラストやモデルデータ、諸々の住所録や家計簿など、他に誰も作っていない、『コレが消えたら最初からやり直し』となるデータは、実は『ご家庭の中』にこそ存在するのです。
業務に関するモノなら誰かが写しを残しているかもしれませんし、関係先のデータを寄せることで自社データの再現も可能かもしれませんが、個人がもつ私用のデータというモノは、当人が自ら行う以外にバックアップはされないワケですね。
もちろん、前出の通り普通の外付け HDD でも大丈夫ですが、可能であれば RAID 構成を組めるアプライアンスタイプの NAS がオススメです。
特に iTunes を利用していたり、家族がそれぞれ自分用の端末を持っていたりする場合、大容量の NAS をネットワークの向こう側に置くと楽できますし、 Wi-Fi で宅内モバイルする場合にも、外付け HDD を持ち歩くなどの危険もなくなりますね。
更に、モノによっては「定期的に NAS → NAS の自動バックアップを行う」機能もありますので「バックアップのバックアップ」も可能です(笑)
最後に、データを預ける金庫として、使い勝手が良くなり費用的にも手を出しやすくなった クラウドサービス の活用も検討しましょう。
例えば、先に示した「残すべきデータ」の内【メール】【写真やビデオ】については、そのものズバリ、ウェブメールサービスや写真/ビデオ共有サービスに投げてしまえます。
具体的には、 Gmail/Picasa/YouTube (Google) や Yahoo!メール/Flickr (Yahoo!) や Live Hotmail/Live SkyDrive (Microsoft) と云った、各社のサービスです。
更に、【住所録】については iPhone なら MobileMe に預ける、表計算による【住所録や家計簿】なら Google Docs に転写して移行する、なども可能ですし、【イラストやモデルデータ】についても Dropbox や インターネットディスク のようなオンラインストレージに(容量次第ですが)ファイルそのものを預けるのもアリです。
特にクラウドの活用は、データのバックアップにもなりますが、重要なのはむしろ端末への依存度を下げる効果にあります。
単純に、「場所を問わずに利用(アクセス)出来る」という面もありますが、データをクラウドに預けているので「端末を買い換えるなどしてもデータの移し替えが不要」という効能もあります。
クラウドに投げておくのが無理なくらいの大きなファイルであっても、 NAS や外付け HDD に入れておけば同様にデータの移し替えは不要になりますね。
まだまだ暑い日が続きます。
ブレーカーが落ちたり停電したり、色々な障害に遭遇することもあるでしょう。
台風もこれからが本番ですので、風水害でバックアップを残さなかったことを後悔するかもしれません。
冬の乾燥する時期ともなれば、火事で焼け出されて飯の種となるデータを丸ごと喪う可能性もあります。
防災・減災という視点で、個人持ちのデータの保管について、改めて考えてみて下さい。
関連するかも知れない?
cat: Tips(ティップス), 電脳系
tag: NAS, UPS, クラウドコンピューティング, 台風, 減災, 災害, 防災
0 Trackback
2010-07-28(水) 16:33(UTC +0900) p Tweet
Google Apps for Gov 2.0
正式には Google Apps for Government ですが、目指すところは Gov 2.0 なんだよな、てコトでこのタイトルで。
私も、自前のドメインで無償版を活用しておりますが、いよいよ行政レベルで対応するようですね。以下に気になった記事のリンクをば。
clip IT!
from TechCrunch Japan
「Google Appsのロサンゼルス市への売り込み–遅れが克服されて年内完全稼働へ」
- 米ロサンゼルス市のGoogle Apps移行計画、技術的困難で大幅遅延へ マイコミジャーナル
- Google、米連邦政府向けの「Google Apps」を発表 Impress INTERNET Watch
- 政府向けGoogle Apps登場 マイコミジャーナル
- グーグル、米国政府機関向けの「Google Apps for Government」をリリース : Googleウォッチ Computerworld.jp
- Google、米連邦政府機関仕様の『Google Apps』を発表 japan.internet.com
- Google、米政府機関専用クラウドサービスを発表 ITmedia News
これで、組織がクラウドを拒絶できる理由が「国境」だけとなりますね。みんなもっとクラウドに投げればイイヨ! 『 Google、米連邦政府向けの「Google Apps」を発表 -INTERNET Watch http://j.mp/ap2yaz 』
既に呟いてますけど、政府の機関であってもその全データを丸抱えする必要がないというコトの表れであり、況んや私企業をや、と云う感じですね。
確かに Los Angeles 市では導入が遅れたのかも知れませんけど、あんな、下手すればその辺の中小企業よりよほど巨大な組織が全面導入するという意味は、とても大きいです。
働く職員数はもちろん、そこで取り扱われる情報や関わる人数の多さからして、国際的な大企業にも匹敵し、且つ、扱われる情報の重篤さも尋常ではない警察組織も含まれるなど、コレは決定的な変換点になりますね。
そこまで含めても、多少の遅れがあっても導入できそうと云うコトは、もうどんな組織でも、ほとんどの場合は導入可能であることを示していると思います。
もちろん、「私企業」ならばこそ絶対に外部に預けたくない情報というモノもあるとは思いますが、それはつまり「情報は資産である」と云うコトに繋がります。
しかし、多くの私企業が極普通に、同じ私企業である銀行に自らの「金融資産を預けている」この資本主義の世において、他の私企業に「情報資産を預ける」ことが本当に不可能なのでしょうか?
金融資産であれば、預けている先が潰れたらその資産も目減りするでしょうが、情報資産なら必要に応じて手元に複製を残しておけるワケです。
情報資産を「預け先から盗まれる」危険性と、中の人が盗んだり、中の人の不手際で盗まれたりする危険性と、どちらの可能性が高いでしょう。(※参考資料)
ぶっちゃけ、メールなんてモノは全てを暗号化していたとしても、「誰から誰へ」という一番肝心な情報はモロバレしているし、それを避けたいなら Skype などの独立網で更に暗号化されているコミュニケーションツールを利用するべきです。
さて、最後に出てくる【言い訳】は多分、『グーグルは米国の企業じゃないか』だと思います。
ご安心ください。
先ず、今あなたが利用している「コンピュータ」の OS は、そもそも国外の製品であると云うコトを思い出してください。
つまり、国境や国籍は言い訳としては弱いと云うコトです。
それでも、と云うなら、既にクラウドなサービス自体は国内企業からも提供が始まってますし、『系列』内の情報サービス会社がグループ会社全体に対してクラウド提供する『プライベート・クラウド』という方法もあります。
コレなら物理的にも国内に置くことが可能ですよね。
ともかく、最早『sendmailがうんたらとか言ってる』場合じゃないですよ、と。
…えー、まあ、ぶっちゃけると、我が勤め先にこそお願いしたいのですが(爆)
関連するかも知れない?
cat: 意見書, 電脳系
tag: Google, Google Apps, Google Docs, web-apps, クラウドコンピューティング
0 Trackback
2008-12-09(火) 19:51(UTC +0900) p Tweet
Dropbox 利用開始と運用上の小ネタ
最早説明不要なほどに有名になってますが、今更ながら Dropbox を利用開始しました。
先日までは WebDAV でデータの同期をとっていましたが、回線状況によってあまりにもレスポンスが悪くなったり、そもそも回線を繋げない場所では利用できないとか、ネット上の資源に直接アクセスする「完全にオンライン前提」の仕組みはちょっとムリがあったようです orz
(将来的に「ネットワーク接続が完全に見えなくなる」まではおあずけ、ですかね)
対して、各端末のローカルに特定のフォルダを用意し、ファイルの読み書きはローカルのストレージに対して行い、その中にあるファイルで更新されたモノだけを自動的に同期するというやり方は、現状では最適解ですね。
実際に数日試して、改めてその人気の理由を実感したところですが、二カ所だけ「イラッ☆」とするコトがありました。
つまり「指定フォルダの場所と名前」です。
Dropbox は単なる同期ツールではなく、一部については公開フォルダとしたり写真フォルダとしたりッて構造である為、指定フォルダの下に「Public」「Photos」というフォルダを作ります。
が、私はそれらと同レベルにファイルをバラバラ置くのはイヤなので、指定フォルダの下にもう一個フォルダ(例えば share など)を作ってその中にファイルやフォルダを置くことにしてます。
以前はその指定フォルダを置く場所すらも決め打ちであったらしいですが、今は My Doduments などの外に置けるよう多少は改善したのかな? それでもやはりデフォルトで作られるフォルダが邪魔くさいな、と。
更に、「指定フォルダ」に付けられる名前は「My Dropbox」となってますが、オールドタイプ的にはフォルダ名やファイル名にブランクが入るのは気持ち悪いワケで。
そこで、「指定フォルダをドライブとしてマップする」コトにしました。
やり方は簡単。
適当なバッチファイルを作って、その中に
subst W: “C:\My Dropbox\share”
と云ったコマンドを一行入れてやるだけです。あとは、そのバッチファイル(或いはショートカット)をスタートアップにでも放り込んでおきましょう
ここで、「W:」はマップ先ドライブの指定、「”C:\My Dropbox\share”」は Dropbox の指定フォルダと自分で作り込んだ共有用のフォルダです。
ちなみに、今回はこのやり方で先に WebDAV をマップしていたドライブに繋ぎ換えることにしました。
こうすると、それまで使っていたショートカットや諸々の設定を変更せずに済むのでオススメです。
関連するかも知れない?
オススメ(殿堂)
オススメ(amazon)
オススメ(ニコ動)
オススメ(link)
検索
タグクラウド
最近のエントリ
カレンダー
日 | 月 | 火 | 水 | 木 | 金 | 土 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
分類別
保管庫
- 2020年1月
- 2019年6月
- 2016年8月
- 2014年9月
- 2014年6月
- 2013年9月
- 2013年8月
- 2013年4月
- 2013年1月
- 2012年10月
- 2011年12月
- 2011年11月
- 2011年10月
- 2011年9月
- 2011年8月
- 2011年7月
- 2011年6月
- 2011年5月
- 2011年4月
- 2011年3月
- 2011年2月
- 2011年1月
- 2010年12月
- 2010年11月
- 2010年10月
- 2010年9月
- 2010年8月
- 2010年7月
- 2010年6月
- 2010年5月
- 2010年4月
- 2010年3月
- 2010年2月
- 2010年1月
- 2009年12月
- 2009年11月
- 2009年10月
- 2009年9月
- 2009年8月
- 2009年7月
- 2009年6月
- 2009年5月
- 2009年4月
- 2009年3月
- 2009年2月
- 2009年1月
- 2008年12月
- 2008年11月
- 2008年10月
- 2008年9月
- 2008年8月
- 2008年7月
- 2008年6月
- 2008年5月
- 2008年4月
- 2008年3月
- 2008年2月
- 2008年1月
- 2007年12月
- 2007年11月
- 2007年10月
- 2007年9月
- 2007年8月
- 2007年7月
- 2007年6月
- 2007年5月
- 2007年4月
- 2007年3月
- 2007年2月
- 2007年1月
- 2006年12月
- 2006年11月
- 2006年10月
- 2006年9月
- 2006年8月
- 2006年7月
- 2006年6月
- 2006年5月
- 2006年4月
- 2006年3月
- 2006年2月
- 2006年1月
- 2005年12月
- 2005年11月
- 2005年10月
- 2005年9月
- 2005年8月
- 2005年7月
- 2005年6月
- 2005年5月
- 2005年4月
- 2005年3月
- 2005年2月
- 2004年12月
- 2004年11月
- 2004年10月
- 2004年9月
- 2004年8月
- 2004年7月
- 2004年6月
- 2004年5月
- 2003年10月
- 2003年7月
- 2003年4月
- 2003年3月
- 2003年2月
- 2003年1月
- 2002年12月
- 2002年11月
- 2002年10月
- 2002年9月
- 2002年8月
- 2002年7月
- 2002年6月
- 2002年5月
- 2002年4月
- 2002年3月
- 2002年2月
- 2002年1月
- 2001年12月
- 2001年11月
- 2001年10月
- 2001年9月