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

[Shin-ya Koga]

サムシングプレシャスの古賀です。

Yamamotoさん（[Armadillo:08588]）：
>微妙ですが、c)になるのかな？
>
>処理的には
>①複数のテーブルを対応するスレッドだけが基本的にinsertでデータの追加だけします。
>これらのスレッドは待たされると処理上困る。
>
>②定期的に不要に成ったデータを削除するスレッドが1ついて、これが削除対象のレコー
>ドを各テーブル毎に順次selectしてupdate or delete処理します。
>このスレッドは待たされても問題なし。
> 
>③不定期に各テーブルからデータ確認用のselectが実施される。
>これも待たされても問題なし。
>
>
>大まかなところでこんな事をしたいのですが、いずれにしろ②、③処理中に①を行おうと
>すると②、③が終わるまで待たされることになりますよね。

ということであれば、microSD カードからのブートで Debian を動かして、
PostgreSQL を使う、というのが解かも知れませんね：
　http://www.postgresql.org/docs/8.2/static/supported-platforms.html

もしくは、"Tokyo Cabinet" や QDBM などの低レベル DB ライブラリを
駆使して、お望みの semantics を持つ DB を実装する必要があるように
思います。

あるいは、SQLite3 を使いつつ、(1) の用途では、insert を実行する
専用のスレッドを動かして、insert 要求を発行するスレッドが block
されないようにする（insert 文のリクエストを、insert 要求発行
スレッドがキューイングして順次実行する仕組みにする）、という
方策も考えられますよね。

# その場合、(3) のスレッドが、(1) でｓ insert されたレコードが
# 「見える」ようになるまで待つ「同期処理」も必要になりそうです
# けれど。


・・・いずれにせよ、実績があって枯れた既存の DBMS を使おうが、
自分でスクラッチから実装して車輪を再発明しようが、全体としての
処理は変わらないと思うので、再利用と自前実装・評価にまつわる
コストの間のトレードオフ次第で、採用すべき戦略が自ずと決まって
くるんだと思います。

--
古賀信哉 （株）サムシングプレシャス