私が持っていたアイデアについての意見が必要です。SQLite と低予算のハイエンド ソリューションに興味がある/経験がある場合 (今のところ Win のみ ;))、これはあなたのためのものです。この質問を具体化している間、私はこのアイデアにかなり興奮しているので、我慢してください. 以下にTL;DRがあります
SQLite を使用して VB.NET (3.5) デスクトップ アプリケーションを開発しました。柔軟性が必要なため、データは EAV モデルで構造化されています (データのセマンティック構造は XML ファイルに個別に格納されます)。実際、このアプリケーションは、目前のシナリオでは大規模なデータベース (メイン ファイルで約 120MB) を使用しても、私の期待をはるかに上回るパフォーマンスを発揮します。
予想どおり、SQLite ファイルがネットワーク フォルダーにある場合、パフォーマンスは最悪です。それは耐えられますが、私にはより高い目標があります。予想されるシナリオ (今のところ) は最大です。ローカル Windows ネットワーク内で同時にデータベースにアクセスする必要がある 10 人のユーザー。大量の読み取りアクセスには 98% の同時実行が必要であり、挿入と更新はまばらで小規模です。
このソフトウェアは、予算が少なく、技術インフラストラクチャ (サポートとハードウェア) がさらに低い環境でほぼ独占的に使用されるため、私の目標はデータベース サーバーの使用を避けることです。また、データベースを独立したネットワークドライブに常駐できるようにしたいので、独自のSQLite「サーバー」をSQLiteningとして実装したくありません（つまり、アプリケーションの1つのインスタンスにネットワーク内のデータベースを自動的に「共有」するように指示します）。 .
クエリを最適化しても状況を修正できないことに気付いた後の私の最初の衝動は、実装するのにほとんど苦労しない「遅延同期」アプローチでした。データベースは (ほぼ) 挿入のみの「wiki 風」であるため、(多くの) 競合の問題はまったくありません。個別にロールバックします。エントリは「削除済みとしてマーク」され、「クリーンアップ」アクションで破棄できます。ただし、セッション中に他のユーザーが変更または入力したデータを「ライブ」にすることはできません。また、ユーザーが「ラッシュアワー」にお互いをブロックする可能性があるため、同期プロセスに時間がかかる場合があります。最悪の場合、おそらく数分で話しています。
TL;DR: SQLite を使用して、サーバーレスでローカル ネットワーク共有のライブ データベースを実装する方法
- 多くのSELECT
- いくつかのINSERT
- DELETEなし
- ユーザーセッションごとの更新はほとんどありません。
さらに仮定しましょう
- 利用可能な十分なハードドライブ容量が常にあります
- アーカイブ メカニズム (およびデータ プライバシーの制約) により、データベースが 200 MB を超えることはありません
- データベースファイルが存在する「共有ディレクトリ」で、ファイルが変更されたかどうか、および誰によって変更されたかを効率的に知ることができます
- 共有ディレクトリからファイルを十分に高速にコピーできます
今私が念頭に置いていたのは、読み取りアクセスのためにローカルにキャッシュされる各セッションの差分ファイルを実装することでした。
クライアント セッションの開始時:
- 共有ディレクトリ内の大きなファイルとセッション固有の (以下を参照) ファイルをチェックして、最後のセッション以降の変更を確認します (共有ディレクトリ内の CRC+ログファイル)。
- 変更されているかキャッシュされていない場合は、各セッションの前に大きな (200MB) 現在のデータベース ファイルをローカル パスにコピーします。
変更されているかキャッシュされていない場合は、すべてのセッション固有のファイル (以下を参照) もコピーします。
セッション中のすべての INSERTは、共有ディレクトリ内の小さなセッション固有のファイルに書き込まれます
- これは、ファイルごとに 2MB などの適切なサイズに制限することも、さらに小さいサイズに制限することもできます。その後、新しいファイルが作成されます。
- その後、読み取りアクセス (SELECT) が順次実行されます
- メイン ファイルのローカル コピー内
- セッション ファイルのローカル コピー内
- 共有キャッシュ内のすべての現在の (つまり、新しい) セッション ファイル
- 新しいセッション ファイルが検出されると、セッション ファイルはローカル キャッシュに再度コピーされます。
- 最後に、セッション ファイルは定期的にビッグ ファイルにマージされます。
- これはすべてのセッションの最後に発生する可能性がありますが、私が間違っていなければ、いつでも発生する可能性があります。
これは
- すべての同時書き込みを排除
- 大きなファイルとすべてのローカル セッション ファイルの同時読み取りを排除する
- 小さなセッション ファイルの読み取りに必要な同時実行数を減らす
- ネットワークの使用を最小限に抑えて、最新のセッション ファイルにアクセスします (同時ユーザーあたり 2MB)。
- すべてのクライアントの現在のデータ状態のライブ ビューを保持する
これは私には素晴らしいとは言えません。
質問: この「プロトコル」の名前はありますか?
これは SQLite を使用した実行可能なアプローチだと思いますか?それとも、これは野生のガチョウの追跡ですか?明らかな欠点を見落としていますか?
参加している場合、セッション ファイルの適切なサイズ (n * page_size?) は?
ご意見ありがとうございます。
クリストフ