XmlまたはSqlite、データベースのXmlを削除するタイミング
データを保存するためにXmlが本当に好きですが、sqlite/databaseがより良いオプションになるのはいつですか？たとえば、xmlにxアイテムより多いか、yMBより大きい場合は？
私はrssリーダーをコーディングしていて、フィード項目のallのキャッシュを保存するためにsqliteデータベースではなくxmlを使用する際に間違った選択をしたと思います。 1か月後に〜1mbのxmlファイルを持つフィードもあれば、700を超えるアイテムがあるフィードもありますが、ほとんどのアイテムは〜30アイテムしかなく、severalの後にサイズが〜50kbですヶ月。
すべてを検索できるようにしたいので、現在は上限を実装する予定はありません。
だから、私の質問は：
- Sqlite/databasesのオーバーヘッドはいつxmlを使用して正当化されますか？
- 少数の大きなxmlファイルたくさんの小さなが存在する場合、データベースに十分な正当性がありますか？ （長い長い時間）
更新済み（詳細）
GUIでフィードが選択されるたびに、そのフィードxmlファイルからすべてのアイテムをリロードします。
また、XML内のすべてのノードをループしてアイテムを検索し、それを既読/未読に設定すると、読みにくいステータスを変更する必要があります。
私は基本的に Mitchel に同意します。これは、XML/sqliteで何をするかによって、非常に具体的になる可能性があるということです。あなたのケース（キャッシュ）については、sqlite（または他の埋め込みデータベース）を使用する方が理にかなっているように思えます。
最初に、sqliteはXMLよりも多くのオーバーヘッドを必要とするとは本当に思っていません。また、開発時間のオーバーヘッドとランタイムのオーバーヘッドの両方を意味します。唯一の問題は、sqliteライブラリに依存していることです。しかし、とにかくXMLのライブラリが必要になるので、それは問題ではありません（プロジェクトがC/C++であると想定しています）。
sqliteのxmlに対する利点：
- すべてを1つのファイルに
- キャッシュが大きくなるため、パフォーマンスの損失はXMLよりも低く、
- フィードメタデータをキャッシュ自体（他のテーブル）から分離しておくことができますが、同じ方法でアクセスできます。
- ほとんどの人にとって、SQLはXPathよりも扱いやすいでしょう。
sqliteの欠点：
- 同じデータベースにアクセスする複数のプロセスで問題が発生する可能性があります（おそらくあなたのケースではありません）。
- 少なくとも基本的なSQLを知っている必要があります。キャッシュに何十万ものアイテムが存在しない限り、あなたはそれをあまり最適化する必要はないと思います、
- おそらく何らかの方法で、セキュリティの観点からより危険になる可能性があります（SQLインジェクション）。一方、Webアプリをコーディングしていないため、これは発生しません。
他の事柄はおそらく両方のソリューションに対して同等です。
要約すると、それぞれの質問に対する答えは次のとおりです。
両方のバックエンドで特定のアプリケーションをテストしない限り、わかりません。それ以外の場合は常に推測です。両方のキャッシュの基本的なサポートは、コードの問題にはなりません。次に、ベンチマークと比較を行います。
XMLファイルの編成方法により、sqlite検索は常に高速である必要があります（非常に高速であるため、とにかく重要ではないいくつかのコーナーケースを除きます）。とにかく、XMLでの検索を高速化するには、インデックスデータベースが必要です。ただし、sqliteを使用すると、データベースの一部としてインデックスを作成できます。
私はこれで経験がありますか？最初はXMLを使用してすべてのデータを保存し、その後sqliteに移動したプロジェクトに取り組んでいます。各テクノロジーには多くの長所と短所がありますが、スイッチオーバーを引き起こしたのはパフォーマンスでした。これが私たちが観察したものです。
小さなデータベース（数メガ以下）の場合、XMLの方がはるかに高速で扱いが簡単でした。私たちのデータは自然にツリー形式でしたので、XMLがはるかに魅力的になり、XPATHを使用すると、祖先ツリーをたどる必要がなく、1行で多くのクエリを実行できました。
Win32環境でプログラミングしていて、標準のMicrosoft DOMライブラリーを使用しました。すべてのデータをメモリにロードし、それをdomツリーに解析して、メモリ内のコピーを検索、追加、変更します。定期的にデータを保存し、書き込み中にマシンがクラッシュした場合に備えてコピーをローテーションする必要がありました。
また、C++ツリーマップを使用して手動で「インデックス」を作成する必要もありました。もちろん、これはsqlで行うのは簡単です。
ファイルシステム上のデータのサイズは、「メモリ内」のDOMツリーよりも2〜4倍小さいことに注意してください。
データが10M〜100Mのサイズになるまでに、実際に問題が発生し始めました。興味深いことに、すべてのデータサイズで、XML処理はsqliteよりもはるかに高速でした（ハードドライブではなくメモリ内にあるため）。問題は実際には2つありました。最初に、ロード時間が長くなり始めました。データがメモリに格納され、マップが作成されるまで、1分ほど待つ必要があります。もちろん、一度ロードされたプログラムは非常に高速でした。 2番目の問題は、このメモリのすべてが常に拘束されていたことです。わずか数百メガのシステムでは、非常に高速で実行したとしても、他のアプリでは応答しなくなります。
実際に、ファイルシステムベースのxmlデータベースの使用を検討しています。いくつかのオープンソースバージョンのxmlデータベースがあります。私は商用のxmlデータベースを使用しようとしたことがないので、コメントすることはできません。残念ながら、XMLデータベースをまったく機能させることができませんでした。データベースに数百メガのxmlを設定する作業でさえ、何時間もかかりました...おそらく私たちはそれを誤って使用していました。もう1つの問題は、これらのデータベースがかなり重いということでした。彼らはJavaを必要とし、完全なクライアントサーバーアーキテクチャを持っていました。私たちはこの考えをあきらめました。
Sqliteを見つけました。問題は解決しましたが、代償が伴いました。最初にsqliteをプラグインしたとき、メモリとロード時間の問題はなくなりました。残念ながら、すべての処理がハードドライブで行われるようになったため、バックグラウンド処理の負荷が非常に高くなりました。以前は、CPUの負荷に気づくことさえありませんでしたが、現在、プロセッサの使用率はかなり高くなっています。コードを最適化する必要がありましたが、一部のデータをメモリに保持する必要もありました。多くの単純なXPATHクエリを複雑なマルチクエリアルゴリズムとして書き直す必要もありました。
これが私たちが学んだことの要約です。
ツリーデータの場合、XPATHを使用すると、XMLのクエリと変更がはるかに簡単になります。
小さなデータセット（1千万未満）の場合、XMLはSQLiteのパフォーマンスを飛躍的に向上させました。
大規模なデータセット（10M〜100Mを超える）の場合、一部のコンピューターが使用できなくなるほど、XMLの読み込み時間とメモリ使用量が大きな問題になりました。
大規模なデータセットに関連する問題を修正するためのオープンソースxmlデータベースを取得できませんでした。
SQLITEにはXML domのメモリの問題はありませんが、一般にデータの処理が遅くなります（メモリではなくハードドライブにあります）。 （sqliteテーブルはメモリに保存できますが、おそらくこれで高速になります。メモリからデータを取り出したいので、これを試みませんでした。）
テーブルへのツリーデータの保存とクエリは楽しいものではありません。ただし、トランザクションの管理とインデックス作成は部分的にそれを補います。
すぐに使える優れたデータベース、つまりファイルシステムがあることを忘れないでください。
適切なディレクトリファイル構造が次のとおりであることを多くのプログラマが忘れています：
- 地獄のように速い
- ポータブルです
- 実行時のフットプリントが小さい
XMLファイルを複数のXMLファイルに分割することについて人々が話している...私は、XMLを複数のディレクトリと複数のプレーンテキストファイルに分割することを検討します。
試してごらん。さわやかで速いです。
- アプリケーションが知っておくべきデータにXMLを使用します-構成、ロギング、その他。
- ユーザーが直接または間接的に操作するデータには、データベース（Oracle、SQLサーバーなど）を使用します-実際のデータ
- ユーザーデータがよりシリアライズされたコレクションである場合は、SQLiteを使用してください-ファイルとそのコンテンツの膨大なリストまたは電子メールアイテムのコレクションなど。SQLiteはそれが得意です。
データの種類とサイズによって異なります。
RSSアイテムの保存にXMLを使用しません。フィードリーダーは、データを受信すると常に更新を行います。
XMLを使用する場合は、最初にファイルからデータをロードし、解析してから、簡単に検索/取得/更新できるように保存する必要があります。データベースのように聞こえます...
また、アプリケーションがクラッシュした場合はどうなりますか？ XMLを使用する場合、XMLファイル内のデータとメモリ内のデータはどのような状態になります。少なくともSQLiteを使用するとアトミック性が得られるため、最後のデータベース書き込みが行われたときと同じ状態でアプリケーションが起動することが保証されます。
XMLは、アプリケーションから他の場所にデータを移動したり、アプリケーション間で情報を共有したりする必要がある場合に、交換フォーマットとして最適に使用されます。データベースは、ほとんどすべてのサイズのアプリケーションに適したストレージ方法です。
データベースの代わりにXMLをデータの永続化に使用する必要があるのはいつですか？ほとんどは決してない。 XMLはデータ転送言語です。解析に時間がかかり、クエリに不便です。 XMLを解析し（細断しないでください！）、結果のデータをドメインオブジェクトに変換します。次に、ドメインオブジェクトを永続化します。永続化のためのデータベースの主な利点はSQLです。これは、構造化されていないクエリ、および一般的なツールと最適化手法へのアクセスを意味します。
私はSQLiteへの切り替えを行い、データベースにあることをmuchよく知っています。
これには他にも多くの利点があります。
- 新しいアイテムの追加は本当に簡単です
- 複数の列による並べ替え
- 一意のインデックスで重複を削除する
私は2つのビューを作成しました。1つは未読アイテム用、もう1つはすべてのアイテム用です。これがビューの最適な用途であるかどうかはわかりませんが、実際に使用してみました。
StopWatchクラスを使用してxmlとsqliteのベンチマークも行いました。sqliteの方が高速ですxmlファイルを解析する私の方法が最速の方法ではなかった可能性もあります 。
- 小さい＃アイテムとサイズ（25アイテム、30kb）
- 〜1.5 ms SQLite
- 〜8.0 ms xml
- 大きなアイテム数（700アイテム、350kb）
- 〜20 ms SQLite
- 〜25 ms xml
- 大きなファイルサイズ（850アイテム、1024kb）
- 〜45 ms SQLite
- 〜60 ms xml
拡張する必要がある場合は、データベースを使用してください。
私にとってそれはあなたが彼らと何をしているのか、何人のユーザー/プロセスが同時にそれらにアクセスする必要があるかなどに本当に依存します。
私はいつも大きなXMLファイルを扱いますが、それらは単一のプロセスであり、スタイルアイテムをインポートするものであり、マルチユーザーやパフォーマンスは実際には必要ありません。
本当にそれはバランスです。
XMLは、完全に構造化されていないデータを格納するのに適しており、通常は別のアプリケーションと交換する必要があります。データにはSQLデータベースを使用することを好みます。データ自体のタイプミスや省略のために微妙なエラーが発生する可能性があるため、XMLはエラーが発生しやすくなっています。一部のオープンソースアプリケーションフレームワークは、構成、データなどに使用するxmlファイルが多すぎます。SQLで使用することを好みます。
経験則を求めているので、一度設定して、アクセスや検索をあまり行わない場合は、XMLベースのアプリケーションデータや設定などを使用すると思います。アクティブな検索と更新には、SQLを使用するのが最適です。
たとえば、WebサーバーはアプリケーションデータをXMLファイルに保存し、複雑な検索を実行したり、ファイルを更新したりする必要はありません。 Webサーバーが起動し、xmlファイルを読み取り、それを処理します。したがって、XMLはここで完璧です。 Strutsのようなフレームワークを使用するとします。アプリケーションを開発してデプロイした後は、XMLを使用する必要があり、アクション構成はあまり変化しません。したがって、XMLファイルは良い方法です。 Strutsで開発されたアプリケーションで広範な検索と更新、削除が許可されている場合、SQLが最適な方法です。
もちろん、XMLまたはSQLのみを唱え、XMLまたはSQLを唯一の方法として宣言する組織内の1人または2人の開発者に確実に会います。そのような人々に注意し、アプリケーションに適切な「感じ」を実行してください。 「テクノロジーの宗教」だけに従う必要はありません。
データの更新頻度、データの検索頻度などを考えてください。次に、何を使用するか（XMLまたはSQL）について回答します。
@Bradleyに同意します。
XMLは非常に遅く、ストレージ形式としては特に有用ではありません。なぜわざわざ？テキストエディタを使用して手動でデータを編集しますか？もしそうなら、XML stillはYAMLのようなものに比べてあまり便利な形式ではありません。 SQliteのようなものを使用すると、クエリを簡単に記述でき、データを出し入れするための明確に定義されたAPIがあります。
プログラム間でデータを送信する必要がある場合は、XMLで問題ありません。しかし、効率の名の下では、おそらく送信時にXMLを生成し、受信時にそれを「実際のデータ」に解析する必要があります。
上記のすべては、「データベースのオーバーヘッドが正当化されるとき」についてのあなたの質問は一種の議論の余地がないことを意味します。 XMLのオーバーヘッドは、SQliteよりもずっと高いです。 （MSSQLのような完全なデータベースは、特に管理オーバーヘッドが大きくなりますが、まったく別の問題です。）
XMLは、テキストおよびバイナリファイル形式で保存できます。
コンピュータがファイル形式を効率的に読み書きできるようにすることが主な目的である場合は、バイナリファイル形式で作業する必要があります。
データベースは、データを保存および維持するための使いやすい方法です。バイナリファイル形式のデータを保存するための最速の方法ではありません。
処理を高速化できるのは、メモリ内データベース/データベースタイプを使用することです。 Sqliteにはこのオプションがあります。
そして、これはあなたのためにそれを行う最良の方法のように聞こえます。
純粋なテキストファイル形式が必要ないときはいつでもSQLite（または別の適切な埋め込みデータベース）を使用するべきだと私は考えています。これはかなり大きな例外です。ピュアテキストファイル形式を必要とする、またはそれによって恩恵を受ける多くのシナリオがあります。
オーバーヘッドに関する限り、SQLiteは通常のフラグで250 kのようなものにコンパイルされます。多くのXML解析ライブラリはSQLiteよりも大きいです。 XMLを使用しても同時実行性は向上しません。 SQLiteバイナリファイル形式は、はるかに効率的な書き込みをサポートします（主に、適切にフォーマットされたXMLファイルの末尾に追加できないため）。そして、ほとんどがかなりランダムアクセスであると私が想定しているデータの読み取りでさえ、SQLiteを使用するとより高速になります。
さらに、トランザクションやインデックスなどのSQLのメリットにアクセスできます。
編集：言及するのを忘れました。 （多くのデータベースとは対照的に）SQLiteの利点の1つは、任意の列の任意の行の任意の型を許可することです。基本的に、SQLiteを使用すると、データ型に関してXMLと同じ自由度を得ることができます。これは、テキスト列に制限を設けることを心配する必要がないことも意味します。
データベースはプログラムの一部として最適です。データのクエリがビジネスロジックの一部である場合。特にデータ形式が次の場合は、XMLがファイル形式として最適です。
1、階層
2、推測できない方法で将来変更される可能性が高い
3、データはプログラムよりも長く存続します
多くの大規模なリレーショナルDB（OracleおよびSQLServer）には、データベース内にデータを格納するXMLデータ型があり、SQLステートメント内でXPathを使用してそのデータにアクセスできることに注意してください。
また、ネイティブXMLデータベースには、ドキュメントのコレクション（大体はテーブルの場合もあります）を保持する1つのバイナリファイルであるという意味でSQLiteと非常によく似ています。その場合、単一のドキュメントまたはコレクション全体に対してXPath/XQueryを実行できます。したがって、XMLデータベースを使用すると、日別のデータを個別のXMLドキュメントとしてコレクションに格納するなどのことができます。したがって、今日のデータを処理する場合は、その1つのドキュメントを使用するだけで済みます。ただし、その人のドキュメントのコレクションに関する履歴データを把握するXQueryを記述します。スリック。
私はBerkeley XMLDB（現在はOracleによってサポートされています）を使用しました。 Googleで「ネイティブXMLデータベース」を検索すると、他にもあります。この方法でデータを格納/取得することによるパフォーマンスの問題を見たことはありません。
XQueryは別の獣です（しかし、学ぶ価値は十分あります）が、現在使用しているXPathをわずかに変更するだけで使用できる場合があります。
データサイズではなく、データタイプの問題だと私は言います。データがstructuredの場合、リレーショナルデータベースを使用します。データがsemi-structuredの場合は、XMLを使用します。または、データ量が実際に大きくなりすぎる場合は、XMLデータベースを使用します。
あなたの検索がdbで行くなら。検索を容易にするためにxmlファイルをディレクトリに分割することもできますが、管理上のオーバーヘッドは簡単に非常に重くなります。また、SQLデータベースを使用した場合のパフォーマンスだけではありません...