アカウント名:
パスワード:
リードオンリーではなく「更新頻度が低いデータ」を「BD-RW」でストレージ化するという話では。書いたら終了のBDそのものやBD-Rでは、更新する度にDiskは増殖して手に負えなくなるでしょう。
Facebookにある動画や写真やメッセージのデータは、増えることはあっても減ることはほとんどなく、データが断片化しがちなＲＷにする必要は薄いのではないでしょうか。もし削除や名前変更があったら、インデックスやアクセス権の部分だけ別データベースで管理して、見えなくするなり検索できなくするなりすればよいのでは。
実体データを残したままだと、万が一流出したら怖いな。去年の三鷹ストーカー事件のJKはFBで男漁ってたとかで、本人及び関係者がきわどいデータを残してたりして。#Face Bookは使ってないので無問題
× Face Book○ Facebook
該当データのとこだけゼロフィルした別ディスクにコピーして、元ディスクは破棄かな。そういう問題が起きる頻度が少なければ、これでもペイするはず。
ソニーの奴は放送局用で、映像アーカイブ用途のようだから、間違って消したりできないってのはむしろ利点かも。
Facebookがディスクに落とせるくらい古いデータを消す必要があるのはユーザーか公的機関から要請があったときだけだから、そういう運用でも全然問題ないんじゃないかな。
該当データのところだけ焼ききれば、別ディスクは不要ですね。
ハードディスク記録の場合でも、削除要請されたとき、０で埋めてランダムバイトで埋めて、また０で埋めて…を１６回繰り返して復元不能にして、それをバックアップ側にまで…と手間をかけてやっているでしょうか？実は削除したと言ってもブロックが参照できないだけで復元可能だったり、バックアップは保存期限まで放置だったりがほとんどなのでは。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
部門名 (スコア:0)
リードオンリーではなく「更新頻度が低いデータ」を「BD-RW」でストレージ化するという話では。
書いたら終了のBDそのものやBD-Rでは、更新する度にDiskは増殖して手に負えなくなるでしょう。
Re:部門名 (スコア:0)
Facebookにある動画や写真やメッセージのデータは、増えることはあっても減ることはほとんどなく、データが断片化しがちなＲＷにする必要は薄いのではないでしょうか。もし削除や名前変更があったら、インデックスやアクセス権の部分だけ別データベースで管理して、見えなくするなり検索できなくするなりすればよいのでは。
Re: (スコア:0)
実際、データ削除が何らかの理由で求められたらどうするつもりでしょうか。テーブルから削除するだけ？
Re: (スコア:0)
実体データを残したままだと、万が一流出したら怖いな。
去年の三鷹ストーカー事件のJKはFBで男漁ってたとかで、本人及び関係者がきわどいデータを残してたりして。
#Face Bookは使ってないので無問題
Re: (スコア:0)
× Face Book
○ Facebook
Re: (スコア:0)
該当データのとこだけゼロフィルした別ディスクにコピーして、
元ディスクは破棄かな。
そういう問題が起きる頻度が少なければ、これでもペイするはず。
ソニーの奴は放送局用で、映像アーカイブ用途のようだから、
間違って消したりできないってのはむしろ利点かも。
Re: (スコア:0)
Facebookがディスクに落とせるくらい古いデータを消す必要があるのはユーザーか公的機関から要請があったときだけだから、そういう運用でも全然問題ないんじゃないかな。
Re: (スコア:0)
該当データのところだけ焼ききれば、別ディスクは不要ですね。
Re: (スコア:0)
ハードディスク記録の場合でも、削除要請されたとき、０で埋めてランダムバイトで埋めて、また０で埋めて…を１６回繰り返して復元不能にして、それをバックアップ側にまで…と手間をかけてやっているでしょうか？実は削除したと言ってもブロックが参照できないだけで復元可能だったり、バックアップは保存期限まで放置だったりがほとんどなのでは。