Databaseへの書き込み・削除の繰り返しについて

[Kyash]

Kyashと申します．よろしくお願いいたします．

表題の通り，SQLiteDatabaseへの書き込みと削除の繰り返しについて悩んでいます．

端末の電源が落ちたときの場合に備えて，一時的にデータベースに書き込んでおき，
必要な処理が終わったことを確認後に処理が完了したデータを消すことを考えています．

これだとどうしても書いたり消したり（＋読んだり）を繰り返してしまうため，
もし常にSDカード上の同じ場所にデータが保存された場合，
比較的短時間でSDカードが寿命を迎えてしまうのではないかということを心配しています．

やはり，このような一時保存はしない方がよいのでしょうか？
期待としてはSQLiteDatabaseがデータの保存先を「散らせてくれる」ということが
あったりしないかな，と思うのですが，
（当然？）そのような情報はネットで検索しても出てきません．

「しても大丈夫」とか「しない方がよい」など，情報をご存知の方，教えていただけないでしょうか？

以上です，よろしくお願いします．

[天然パーマ]

天然パーマと申します

私なら。。。

書き換え回数が異常な数値にならない限り気にしません。

機械は必ず壊れるものですから

SDカード以前に端末が２・３年ぐらいで寿命を迎えると考えていますので

（バッテリー寿命や他の故障などで）

それでもSDカードの寿命が気になる・バックアップに要する書き込み回数が多いのでしたら

バックアップ処理の変更を行うのも手かもしれません。

・通常時のバックアップ

１．バックアップ用テーブルのレコード数を調べる

２．レコード数がｎ以上なら全て削除

３．バックアップをinsertする

・復帰時

１．最終行のデータを使用してリストアする

２．全て削除

みたいな感じですかね。

こうすれば同じエリアに書き込まれない気がします

実用的な実装ではもっと工夫する必要があると思いますが

公式？メーカ等のソースではないので信用性はどうかとおもいますが

”昨今のSDカードはセルに書き込み回数の寿命があるため、

できるだけ同じエリアに連続的に書き込まないような工夫が

なされています。”

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1286968197

sqliteのデータは１つのファイルなので同一エリアに書き込まれる気がしますが。。。

以上、まとまりが悪いですね。。

2014年8月7日木曜日 17時13分08秒 UTC+9 Kyash:

[Yoshiaki Ito]

伊藤です。

ソフトウェア開発者としては、DBへの書き込み回数によるハードウェアの劣化より、
DBへの書き込み回数(バックグラウンド処理)によるバッテリへの負荷を気にする方がいいのかなと思います。
どちらにしても必要な処理であればやるべきだと思います。

私は基本ソフト専門ではないのでメーカ情報まではわかりませんが、SSDへの処理はOSレベルの処理かと思います。
WindowsではいつだかSSDが広まった頃XPではSSDに最適化されていなかったとか云云かんぬんで、7からはSSDではデフラグが無くなる等対応したなんて話があった気がします。(Vistaは知りません。。。)
どの道Javaではアクセス先まで指定出来ませんし、書き込み容量だけで言えばDBのデータより動画とかの方が強烈です。
ネットに出ていないのは書き込み先まで気に出来ない(関与出来ない)からではないかと思います。

つまるところアプリエンジニアとしては、頻発する書き込み処理によるSSDの劣化よりUXを気にされた方がよいかなという印象です。言われなくてもかもしれませんが、それだけの書き込みをUIスレッド等で行っていたら操作がロックされたように見えるのでスレッド化する等して気をつけて下さい。

> --
> このメールは Google グループのグループ「日本Androidの会」に登録しているユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには android-group-j...@googlegroups.com にメールを送信してください。
> このグループに投稿するには android-g...@googlegroups.com にメールを送信してください。
> http://groups.google.com/group/android-group-japan からこのグループにアクセスしてください。
> その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。

[竹内 学]

竹内です。

基本的に SD カードを始めとするフラッシュメモリは、

同一ブロックに書き込みが集中しない様に SD カードのコントローラが制御しています。

これは OS では特に気にしなくて良い様になっていまして、

OS レベルでは同じブロックに書込みしても、

物理ブロックは別のブロックに書かれる様になっています。

初期の SSD でプチフリ現象が話題になっていましたが、

あれも、書込み時のブロック  ローテーション時に発生していまして、

使用中のブロックの情報を別の領域に待避したりして、

万遍なくブロックを使い切ろうと言う機構 (ウェアレベリング) がプチフリとして悪影響を出していました。

SD カードの場合も高機能なコントローラ搭載タイプはウェアレベリングを行っています。

そうで無いのなら、未使用ブロックのみを使い回すタイプですので、

空き容量が少ない場合、同じブロックを使い回す率が高くなりますので、

それだけ故障が早くなります。

そういう事を踏まえますと

出来るだけ容量が大きく、

ウェアレベリング搭載の高機能タイプの SD カードを使う限り、

気にする事は無い。

と思います。

2014年8月8日 15:32 Yoshiaki Ito <aidem...@gmail.com>:

このメールは Google グループのグループ「日本Androidの会」の登録者に送られています。

[Kyash]

Kyashです．

天然パーマさま，伊藤さま，竹内さま，情報やご意見，アイデアなどありがとうございました．
お返事が遅くなりまして，申し訳ありません．

SDカードのコントローラが寿命を延ばすようにいろいろやってくれているということで，少し安心しました．

ただ，竹内さまの情報から，SDカード容量が少なくなってくると故障が早くなるとのことなので，
ちょっと考えないといけないかなと思っています．

また，天然パーマさまがおっしゃられているように，
データベースが作られてしまうと（SQLiteOpenHelperのonCreateが呼ばれてしまうと），
SDカード上の最初のレコードの書き込み場所は決まってしまう気がして，
ちょっと心配も残っています．

ということで，急なシャットダウンなど不測の事態で多少のデータが失われる可能性が高まるとしても，
・とりあえずデータベースには保存せずに処理→処理がうまくいかなかったときだけデータベースに保存
・一応，シャットダウンのブロードキャストを捕捉して，これがきたら処理中のデータがあればデータベースに保存
のような処理で対応してみようかな，と思います．
（この方法だと，プログラムのバグ等でシステムにアプリが強制終了させられる場合には
データが消失しますので，気をつけねば...です）

伊藤さま，UXへの影響に関するご指摘，ありがとうございました．
たまたま，今回はデータの保存や処理自体がワーカースレッド上で行われていましたので，
UXへの影響に関しては失念していても問題ありませんでしたが，
上記のような改造を行っている最中に，うっかりメインスレッド上で処理をさせないように
気をつけたいと思います．

以上です，ありがとうございました．