対象環境
情報源
要点
自動翻訳したのを斜め読みしてポイントを抜き出した。
問題
単一ファイルであるがゆえの問題がある。
スレッドセーフでない(同時書込不可)
読取だけなら同時アクセス可。だが書込は同時にできない。
整合性を保ったまま同時に書込むことができない。
ミューテックスなど排他制御機構を使い、ファイルロックして同時アクセスさせないようにすることで整合性を保つ。アプリ側ではロック解除されるまで待機するなりタイムアウトさせることになりそう。
解決策はないか。そもそも問題はファイルシステムが同時アクセスを考慮していないことにある。ならばlibfuseを使って自動的にファイルに対して排他制御をするファイルシステムを作れば運用が楽になりそう。書込するときはミューテックスでファイルロックする。同時に書込が発生したらタイムアウト時間やエラー時の処理を設定したとおりにするような機構があれば使いやすそう。もっとも、FUSEはLinuxカーネルの機能らしいのでOS限定だが。
容量
たとえばファイルシステムによる上限がある。FAT16なら2GB、FAT32なら4GBまで。Linuxのext4は16TiBまで。
ファイルシステム | 上限 |
---|---|
FAT16 | 2GiB 2^31 |
FAT32 | 4GiB 2^32 |
exFAT | 16EiB 2^64 |
ext4 | 16TiB 2^44 |
SQLite3 | 140TiB 2^47 |
16TiBは2の何乗か
まずはSI接頭辞について確認。たとえば以下。
1KB
:10^3
1KiB
:2^10
では以下は?
1TB
:10^12
1TiB
:2^?
B
とiB
ではiB
のほうが少し大きい。でもiB
の計算がよくわからないので、大体同じだと考えてB
で計算してみる。
式 | 解 |
---|---|
16TiB≒16TB=16*1012 | 1.6e+13 |
log2 1.6e+13 | 43.8631371386 |
iB
でなくB
で計算したため、もう少し大きいはず。43.8631371386
より大きい直近の整数は44
である。つまり、16TiB
は2^44
と思われる。
USBメモリや外付HDDなどはFAT32であることがある。それらを使ってファイルを移動させようとすると上限にひっかかってしまうこともありうる。ファイル分割ツールなどを使えば解決できるかもしれないが未調査。
ハードウェア容量の制約もある。HDDサイズは1TB以上になってきた。DBに使える分は最大でもせいぜい数百GB。それだけあれば趣味で使うくらいなら困らないと思うが。
SQLite固有の制約についてはこちらを参照。大抵はOS,BIOS,ファイルシステムの上限のほうが先にひっかかる。
所感
SQLite3はライセンス的にも、環境構築的にも、非常に使いやすいRDBMS。
ただしサーバ型の一般的なRDBMSと比べると同時書込不可などの問題もある。
ソースコードはGitHubで管理していないようだ。非公式ならこちらのリポジトリがあったが。