アカウント名:
パスワード:
T/O
*BSDで10億程度のファイルを上記の基準で処理したら、どうなるの？
マジレスすると、そんなことをしなければいけないサーバを構築をしたニンゲンの首が吹き飛ぶ処理できる様にしろと客から光の速度でクレームがくる
お前の設計で会社がマジやばい
>マジレスすると、そんなことをしなければいけないサーバを構築をしたニンゲンの首が吹き飛ぶ
以前、あるシステムを見てくれといわれて...あのぉ、lsが返ってこないんですけど...で、ディレクトリを一個あがって、ls -lしてみたらそのディレクトリのサイズが異常。リンクの数も、7桁。
「なんかいっぱいファイルが入っているみたいですけど、分割できませんか？」「それをしようとして、出来ないので困ってる」...
なんでも、社員情報を、社員番号.name.txt 社員番号.address.txt 社員番号.phone.txt社員番号.緊急連絡先.address.txt 社員番号.緊急連絡先.phone.txt 社員番号......１０万人(正社員／契約社員／外注出向者等)分程度を、ひとりについて20ファイルくらいにわけて、一カ所に入れて、簡易DBかわりに使っていたらしい。
なんでも、「下手にDB使うより簡単だし、検索もシェルでやるから簡単なんだ」とのことでした。もちろん、全部、平文なわけで、「どうしてこーゆーの作ったの？」と聞いたら、「前任者が、社員を一度に検索できるシステムを安く作れという命令で作った」そうだ。
各部署ではマル秘扱いの社員データを、毎日ダウンロードしてはマッチングして更新かけていたのが、どうも遅いし、終わった気配がないので心配で聞いてきたらしい。
ある日再起動時にfsckが起動されて、丸1日かかったが何とかfsckを終えた。月末恒例の処理しようとしたら、何かエラーがでる。と。原因を調べたらファイルが存在しておらず、/lost+foundにファイルの残骸が。バックアップのtarファイルから復元しようとしたが、tarでバックアップを取っていた時点では既にメタデータがおかしかったらしくファイルとして存在していなかった。
※ 作り話ですが、ふつうにありそうですよね。
>バックアップのtarファイルから復元しようとしたが、tarでバックアップを取っていた時点では既にメタデータがおかしかったらしくファイルとして存在していなかった。
当時のtarにはたしか、8GB上限があってtarでは取れなかった。部分だけバックアップしようとして、tar cvf /dev/rmt0 10*.*.txtで取っていたらしいのだが、ある日「too many arguments」で落ちたらしい。その時は、もっと細分化してバックアップをとるとかで逃げたらしいけど、逃げ方が場当たりで、「1*は、100,101,102...で分けて、2番台は二桁で...9番台はそのまま」みたいなことやっていたね。
> ※ 作り話ですが、ふつうにありそうですよね。
本当にあった怖い話の一種かもね。
従業員10万人て、超大企業じゃないですか。#開発費けちりすぎ。
「既存のDB技術と一線を画し」 [srad.jp]した技術ですね!
これほど、データベースを使った方が簡単な事例も少なそうですよね…。本当にご苦労様です。
WinFSが陽の目を見ていれば採用されそうな事例ですね
性能やセキュリティが要件に入っていなかったのなら正しいかも。性能はともかくちゃんと動いていたわけだし、いろんな部署の人が使っていたわけだし。設計者もDBの方がいいことは知っていて（あるいは安く作れる方は破綻することを知っていて）、敢えてこういう実装にしたのではないかと深読みしてみました。
モデしてしまったのでAC
>その程度なら社員番号の100番ごとにディレクトリ分けるだけで大幅にスピードアップできそうなものだが。
検索や洗い替えの処理とか、結構な数があって。それらが全て同じディレクトリにあることを前提に作られていたりする。なもんで、データコピーの時間もさることながら、そういったスクリプトとかを洗い出すのが大変だったな。結局、「まともなDBにしないと、今後も同じ様なことになる」ってなことで、要件定義から差し戻しにした。
NEWS-OSがまだBSD系だったころのお話。
シェルスクリプトか、何かスクリプト言語使って社員番号.name.txt > 別のディレクトリ/社員番号.data.txt社員番号.address.txt >> 別のディレクトリ/社員番号.data.txt社員番号.phone.txt >> 別のディレクトリ/社員番号.data.txt…した後nameaddressphone…ファイルとjoinして、その処理を社員番号でFor構文か何かで繰り返し処理すれば良いんじゃないの？とりあえずファイル数が20分の一になるよ。検索にはGrep使えばいいんだし。adressに改行が入っていると面倒そうだけど。どうしてもファイルを一つにまとめられなければ個人毎にディレクトリを作
>ファイルとjoinして、その処理を社員番号でFor構文か何かで繰り返し処理すれば良いんじゃないの？
前述したけど、検索するのが「色々できる」ってことで、各利用者が勝手に検索系のスクリプトを組んでいて、それがデータ形式依存たっぷりなわけでね。まずは「どういった使い方してるの？」を聞いたら、皆さん「rshで自分が書いたshellスクリプトでやっている」...で、そのデータをPC側で色々と料理していた。
セキュリティもへったくもありゃしないの。
でもって、データの容量的にも、当時のWSに付けるHDDの最大級をフルフル使っていて、サイズと処理速度が追いつかなかった。
>作業の実際が分からないけど、役職ごとの処理が多ければ役職毎、部署毎の処理が多ければ部署毎にディレクトリを作れば検索速度が上がるんじゃないか？
部署／役職のリストもあって、そこには社員番号だけを使っていたらしい。なんでも、信頼できる最新のデータが、そのディレクトリにあるデータだってことで、部署／役職／勤務地等のデータには、社員のデータも一応色々と入っていたけど「あ、それメンテしてないから使わないことにしたんだ」...
さらに酷いことが発覚したというか、別の部署でもそのデータを使っていて、勝手に変えられないんだ！とか...
極端を言えば、部署外からのアクセスも出来ちゃう便利データだったわけで、「これはさすがにまずいだろう」と忠告したんですけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
ここで*BSDの優位性をアピールっ！ (スコア:0)
T/O
Re: (スコア:0)
*BSDで10億程度のファイルを上記の基準で処理したら、どうなるの？
Re: (スコア:5, おもしろおかしい)
マジレスすると、そんなことをしなければいけないサーバを構築をしたニンゲンの首が吹き飛ぶ
処理できる様にしろと客から光の速度でクレームがくる
お前の設計で会社がマジやばい
Re:ここで*BSDの優位性をアピールっ！ (スコア:2, おもしろおかしい)
>マジレスすると、そんなことをしなければいけないサーバを構築をしたニンゲンの首が吹き飛ぶ
以前、あるシステムを見てくれといわれて...
あのぉ、lsが返ってこないんですけど...
で、ディレクトリを一個あがって、ls -lしてみたらそのディレクトリのサイズが異常。
リンクの数も、7桁。
「なんかいっぱいファイルが入っているみたいですけど、分割できませんか？」
「それをしようとして、出来ないので困ってる」...
なんでも、社員情報を、社員番号.name.txt 社員番号.address.txt 社員番号.phone.txt
社員番号.緊急連絡先.address.txt 社員番号.緊急連絡先.phone.txt 社員番号......
１０万人(正社員／契約社員／外注出向者等)分程度を、ひとりについて20ファイルくらい
にわけて、一カ所に入れて、簡易DBかわりに使っていたらしい。
なんでも、「下手にDB使うより簡単だし、検索もシェルでやるから簡単なんだ」とのことでした。
もちろん、全部、平文なわけで、「どうしてこーゆーの作ったの？」と聞いたら、「前任者が、
社員を一度に検索できるシステムを安く作れという命令で作った」そうだ。
各部署ではマル秘扱いの社員データを、毎日ダウンロードしてはマッチングして更新かけて
いたのが、どうも遅いし、終わった気配がないので心配で聞いてきたらしい。
Re:ここで*BSDの優位性をアピールっ！ (スコア:2)
ある日再起動時にfsckが起動されて、丸1日かかったが何とかfsckを終えた。
月末恒例の処理しようとしたら、何かエラーがでる。と。
原因を調べたらファイルが存在しておらず、/lost+foundにファイルの残骸が。
バックアップのtarファイルから復元しようとしたが、tarでバックアップを取っていた時点では既にメタデータがおかしかったらしくファイルとして存在していなかった。
※ 作り話ですが、ふつうにありそうですよね。
Re:ここで*BSDの優位性をアピールっ！ (スコア:1)
>バックアップのtarファイルから復元しようとしたが、tarでバックアップを取っていた時点では既にメタデータがおかしかったらしくファイルとして存在していなかった。
当時のtarにはたしか、8GB上限があってtarでは取れなかった。
部分だけバックアップしようとして、tar cvf /dev/rmt0 10*.*.txtで取っていたらしいのだが、ある日「too many arguments」で落ちたらしい。
その時は、もっと細分化してバックアップをとるとかで逃げたらしいけど、逃げ方が場当たりで、「1*は、100,101,102...で分けて、2番台は二桁で...9番台はそのまま」みたいなことやっていたね。
> ※ 作り話ですが、ふつうにありそうですよね。
本当にあった怖い話の一種かもね。
Re:ここで*BSDの優位性をアピールっ！ (スコア:2, すばらしい洞察)
従業員10万人て、超大企業じゃないですか。
#開発費けちりすぎ。
Re:ここで*BSDの優位性をアピールっ！ (スコア:1)
「既存のDB技術と一線を画し」 [srad.jp]した技術ですね!
Re:ここで*BSDの優位性をアピールっ！ (スコア:1)
これほど、データベースを使った方が簡単な事例も少なそうですよね…。
本当にご苦労様です。
Re: (スコア:0)
WinFSが陽の目を見ていれば採用されそうな事例ですね
Re:ここで*BSDの優位性をアピールっ！ (スコア:1, 興味深い)
なんでも、「下手にDB使うより簡単だし、検索もシェルでやるから簡単なんだ」とのことでした。
もちろん、全部、平文なわけで、「どうしてこーゆーの作ったの？」と聞いたら、「前任者が、
社員を一度に検索できるシステムを安く作れという命令で作った」そうだ。
性能やセキュリティが要件に入っていなかったのなら正しいかも。
性能はともかくちゃんと動いていたわけだし、いろんな部署の人が使っていたわけだし。
設計者もDBの方がいいことは知っていて（あるいは安く作れる方は破綻することを知っていて）、敢えてこういう実装にしたのではないかと深読みしてみました。
モデしてしまったのでAC
Re: (スコア:0)
Re:ここで*BSDの優位性をアピールっ！ (スコア:1)
>その程度なら社員番号の100番ごとにディレクトリ分けるだけで大幅にスピードアップできそうなものだが。
検索や洗い替えの処理とか、結構な数があって。それらが全て同じディレクトリにあることを前提に作られていたりする。
なもんで、データコピーの時間もさることながら、そういったスクリプトとかを洗い出すのが大変だったな。
結局、「まともなDBにしないと、今後も同じ様なことになる」ってなことで、要件定義から差し戻しにした。
NEWS-OSがまだBSD系だったころのお話。
Re: (スコア:0)
Re: (スコア:0)
シェルスクリプトか、何かスクリプト言語使って
社員番号.name.txt > 別のディレクトリ/社員番号.data.txt
社員番号.address.txt >> 別のディレクトリ/社員番号.data.txt
社員番号.phone.txt >> 別のディレクトリ/社員番号.data.txt
…
した後
name
address
phone
…
ファイルとjoinして、その処理を社員番号でFor構文か何かで繰り返し処理すれば良いんじゃないの？
とりあえずファイル数が20分の一になるよ。
検索にはGrep使えばいいんだし。
adressに改行が入っていると面倒そうだけど。
どうしてもファイルを一つにまとめられなければ個人毎にディレクトリを作
Re:ここで*BSDの優位性をアピールっ！ (スコア:1)
>ファイルとjoinして、その処理を社員番号でFor構文か何かで繰り返し処理すれば良いんじゃないの？
前述したけど、検索するのが「色々できる」ってことで、各利用者が勝手に検索系のスクリプトを組んでいて、それがデータ形式依存たっぷりなわけでね。
まずは「どういった使い方してるの？」を聞いたら、皆さん「rshで自分が書いたshellスクリプトでやっている」...で、そのデータをPC側で色々と料理していた。
セキュリティもへったくもありゃしないの。
でもって、データの容量的にも、当時のWSに付けるHDDの最大級をフルフル使っていて、サイズと処理速度が追いつかなかった。
>作業の実際が分からないけど、役職ごとの処理が多ければ役職毎、部署毎の処理が多ければ部署毎にディレクトリを作れば検索速度が上がるんじゃないか？
部署／役職のリストもあって、そこには社員番号だけを使っていたらしい。
なんでも、信頼できる最新のデータが、そのディレクトリにあるデータだってことで、部署／役職／勤務地等のデータには、社員のデータも一応色々と入っていたけど「あ、それメンテしてないから使わないことにしたんだ」...
さらに酷いことが発覚したというか、別の部署でもそのデータを使っていて、勝手に変えられないんだ！とか...
極端を言えば、部署外からのアクセスも出来ちゃう便利データだったわけで、「これはさすがにまずいだろう」と忠告したんですけどね。