私は2つのコンポーネントを持つ小さなシステムを開発しています。1つはインターネットリソースからデータをポーリングし、それをSQLデータに変換してローカルに永続化します。 2つ目は、ローカルインスタンスからそのsqlデータを読み取り、jsonとRESTful APIを介して提供します。
私はもともとデータをpostgresqlで永続化することを計画していましたが、アプリケーションには格納するデータと提供するトラフィックが非常に少ないため、それはやりすぎだと思いました。 SQLiteは仕事に適していますか?私は小さなフットプリントのアイデアが好きで、この1つのタスクのためにさらに別のSQLサーバーを維持する必要はありませんが、並行性について心配しています。
先読みロギングを有効にすると、どちらかのプロセスをデータベースからロックアウトせずに、SQLiteデータベースの読み取りと書き込みを同時に行うことができるようです。
1つのSQLiteインスタンスが、1つの読み取りと他の書き込みだけの場合、それにアクセスする2つの同時プロセスを維持できますか?私はコードを書き始めましたが、これがSQLiteの誤用かどうか疑問に思いました。
File Locking And Concurrency のドキュメントを探しています。
SQLiteプロセスは一連のロックを使用して並行性を処理します。読み取るために、いくつかのプロセスがSHARED
ロックを取得できます。
書き込みを行うプロセスは、RESERVED
ロックを取得する必要があり、実際に変更をディスクにフラッシュする必要がある場合にのみ、PENDING
状態に移行します。次に、読み取りプロセスでファイルのロックを解除する必要があります。その後、書き込みプロセスは、実際のデータベースファイルに書き込むためにEXCLUSIVE
に移動できます。
ライタープロセスは、実際の書き込み(メモリフラッシュ、コミット)のためにデータベースファイルをロックするだけでよいので、リーダーが1つとライターが1つだけのセットアップでも十分に機能します。私はそれがすべての読み取りと書き込みを行う1つのプロセスだけのセットアップとして、それよりも良くないとしても、同じように実行されることを期待します。
複数のプロセスが同じデータベースに頻繁に書き込む場合、SQLiteはあまり適していません。変更をシリアル化するには、排他的なPENDING
ロックを取得する必要があるためです。
フォローアップして、実装が成功したことをみんなに知らせたかっただけです。 SQLiteでの作業は本当にうれしいことで、一度に1つのプロセスだけが書き込みを行っていたため、セカンダリプロセスからの同時読み取りが非常に高速であっても、ロックアップの問題は発生しませんでした。