[Armadillo:08595] Re: DB を使用したいので使われた事のある

山本様

通常のデータベースならレコード単位でもロックを掛けることが
できるのですが、SQLite3はDB単位になってしまいます。
スレッドセーフと言われても、DB単位のロックでは使いにくいですね。

私の開発したアプリの場合は、スレッドでなくクライアントとサーバに分かれおり、
データの追加、削除、更新についてはサーバ側で一括して行うようにしました。
それとパフォーマンスは落ちますが細かくcommitしています。
SDカードでcommitをするとすごく遅くなるので、
頻繁に更新されるようなテーブルなどは、RAMディスク上に配置する、あるいは
いっそのことアプリの配列で管理したほうが良いかもしれません。（データ量に
よりますが）

次のような使い分けをしてました。

1.大量データかつ更新が殆どない。→SDカード上のDB

2.少量だが、複数のテーブルでJOINしたり、更新も頻繁なもの。→RAMディスク上のDB
(バックアップはSQLテキスト形式でSDカードに保存：SD上でcommitするより速いです）

3.一時的なテーブル情報　→　DBテーブルを止めてアプリでリスト構造のデータで管理
。
（一連の処理が終わった時とPowerOFF時にDBに書き込む。)



----- Original Message -----
>Date: Thu, 31 Jan 2013 18:25:31 +0900
>From: Yamamoto <email@hidden>
>To: Armadillo general discussion list <email@hidden>
>Subject: [Armadillo:08586] Re:
> DB を使用したいので使われた事のある
>
>
>Yamamotoです。
>
>頂いた意見を参考に基本設計していたのですが、実質動作として単一のスレッドでし
か処
>理出来ないらしいということに今頃気づいてしまいました。
>
>SQLiteはマルチスレッドに対応はしているけど、実際は単一スレッドでしか使用でき
ない
>のですね？
>複数スレッドで使用すると最初にtransactionを使用したスレッド以外が使用しようと
す
>るとDBロックになるとか？
>transactionを使用しないと処理時間が大幅にかかるとかあるようですね？
>
>On Wed, 30 Jan 2013 00:58:12 +0900 (JST)
>email@hidden wrote:
>
>> 
>> 山本様
>> 
>> 以前簡単なテストした記憶があるのですが、手元に無いのではっきりとしたことは
>> ご返事できません。
>> 簡単にテストするには郵便番号データのCSVファイルをダウンロード
>> して、登録、検索すると良いと思います。
>> 
>> 以前開発したシステムでの話ですが、
>> 通常タッチパネルでの操作（登録者max2000名）では、検索による遅延は
>> 感じられないです。ただ利用者の操作履歴に関しては数十万件保存した場合
>> スペックに合わなくって、日別のテキストファイルにして、一部インデックス的な
>> データをRAMディスク上に作ってawkで処理した記憶があります。
>> （SQLite3 + SDカードで一件の履歴を書き込みしcommitするのに0.5秒近い数値が
>> 出たことがあります）
>> また、頻繁に更新がかかるテーブルについては、RAMディスク上に配置し
>> 定期的にSQLテキストでダンプしてSDにバックアップを取ってました。
>> 
>> DBをSD(以前はCF）に置いた場合、書き込み速度が問題となります。
>> インデックスを持ってる場合は特に。データの検索が主体のアプリならまだしも、
>> 頻繁にデータを更新する用途には充分な評価が必要だと思います。
>> 少量のデータや履歴のようにシーケンシャルなデータならテキスト
>> ファイルのほうが実用性があると思います。
>> 
>> それと電源はバッテリーバックアップとアプリあるいはシステムからの信号で
>> PowerOFFできるようなハード設計が必要ですね。
>> 
>> 
>> 
>> ----- Original Message -----
>> >Date: Tue, 29 Jan 2013 18:06:34 +0900
>> >From: Yamamoto <email@hidden>
>> >To: Armadillo general discussion list <email@hidden>
>> >Subject: [Armadillo:08563] Re:
>> > DB を使用したいので使われた事のある
>> >
>> >
>> >Yamamotoです。
>> >
>> >天晴さん、有難う御座います。
>> >
>> >ちなみに処理時間とか計測されたことはありますか？
>> >検索/登録/更新/削除等で最大及び最小とか平均が解れば助かりますが。
>> >(データとか構造、件数で一概には言えないと思いますが)
>> >
>> >On Tue, 29 Jan 2013 01:07:35 +0900 (JST)
>> >天晴 <email@hidden> wrote:
>> >
>> >> こんにちは、山本様
>> >> 
>> >> 天晴です。
>> >> 
>> >> Armadillo-500FXでの話しになりますが、その前にSH-3のLinuxでSQLiteを使って
た
>> >> 関係上、500FXに移植したときはそのままSQLite3にしました。
>> >> (SH3ではC言語でコールバックで面倒な処理をこなしてましたが、500FXではLaza
rus
>> の
>> >> SQLDBコンポーネントを利用したのでログ表示はDBからGUI直結表示にしました）
>> >> 
>> >> そのほかに、500FXでDebianをインストールしFirebirdも少し動作テストしてい
ます
>> 。
>> >> 
>> >> SQlite3は使い方によって何らかのタイミングでVaccumしないと、ファイルサイ
ズが
>> >> 肥大化してしまい、データベースのバックアップで時間がかかりすぎた記憶があ
り
>> ます
>> >> 。
>> >> 
>> >> 個人的には使いやすさ、保守のし易さからすればFirebirdなんですが、ARMにつ
いて
>> は
>> >> まだ実績が少ないので、しばらく様子見かなと思ってます（Firebirdはembedded
構
>> 成、
>> >> からC/S構成まで可能で、動作テストしたのはAradillo500FXをDBサーバにして、
>> >> PCからアクセスするような構成でした、取り合えず動くということを確認しただ
け
>> で
>> >> パフォーマンス、信頼性等は評価していません。）
>> >> 
>> >> 
>> >
>> >(^_^)v(^_^)/~(^_^)v(^_^)/~
>> >  　　　山本　伸夫
>> >   email@hidden
>> >(^_^)/~(^_^)v(^_^)/~(^_^)v
>> >
>> >_______________________________________________
>> >armadillo mailing list
>> >email@hidden
>> >http://lists.atmark-techno.com/cgi-bin/mailman/listinfo/armadillo
>> 
>> _______________________________________________
>> armadillo mailing list
>> email@hidden
>> http://lists.atmark-techno.com/cgi-bin/mailman/listinfo/armadillo
>
>(^_^)v(^_^)/~(^_^)v(^_^)/~
>  　　　山本　伸夫
>   email@hidden
>(^_^)/~(^_^)v(^_^)/~(^_^)v
>
>_______________________________________________
>armadillo mailing list
>email@hidden
>http://lists.atmark-techno.com/cgi-bin/mailman/listinfo/armadillo