問題タブ [database-caching]

Web では、ASP.Net のキャッシュについて多くの質問が寄せられていますが、スマート クライアント アプリケーションとそのデータベースのキャッシュ オプションについてはあまり議論されていません。

.Net フレームワーク上のスマート クライアント アプリケーションで使用できるデータ キャッシュ オプションとは何ですか?また、それらをどのように使用していますか?

編集

Enterprise Framework については後述しましたが、どう思いますか?

コンテンツの一部をMySQLデータベースに依存するアプリケーションに取り組んでいます。場合によっては、アプリケーションはインターネット接続（UMTS）が制限された環境で実行され、特に待ち時間が長くなります。

アプリケーションのユーザーはログインでき、アプリケーションのユーザーインターフェイスのコンテンツのほとんどはMySQLデータベースから取得されます。ユーザーがログインした後の遅延を防ぐために、クライアント側でできるだけ多くのデータベースコンテンツをキャッシュしたいと思います。新しいコンテンツは、関連する変更が行われた場合にのみデータベースから取得する必要があります。この問題に取り組む一般的な方法はありますか？この問題の固溶体を説明している文献はありますか？

小さな更新：現在、特定のユースケースのソリューションとしてCouchDBを検討しています。主な理由は次のとおりです。

これにより、ユーザーとサーバーは、切断中に同じ共有データにアクセスして更新し、後でそれらの変更を双方向に複製することができます。

（from：http ://couchdb.apache.org/docs/overview.html ）

これまでのところ、それは本当に有望に見えます。

mysqlに特定のクエリを強制的にキャッシュする方法はありますか（たとえば5分間）、そのクエリを実行すると、基になるデータベースが変更された場合でも常に同じ結果が返されますか？

私は出会い系サイトを運営していますが、「最新の一致」を表示するページがあり、データベースにヒットしすぎています。

前もって感謝します。

codeigniter と mysql を使用してサイトを構築しました。うまく機能しますが、データベースのキャッシュをオンにしたいです。各selectステートメントを手動でキャッシュするのではなく、グローバルに行うだけだと考えました。データベース構成ファイルで、'cache_on' = TRUE に設定し、'cachedir' = "http://www.mydomain.com/application/cache/dbcache"

キャッシュディレクトリ全体を書き込み可能に設定したので、すべてが正しく設定されていると思います。いくつかのページを読み込んだ後、キャッシュ ディレクトリをもう一度確認しましたが、まだ空です。これは、何もキャッシュされていないことを意味すると思います。何か不足していますか？エラーは発生せず、すべての select ステートメントが結果を表示しています。何が間違っているのですか / キャッシングが機能しているかどうかを確認するにはどうすればよいですか?

ありがとう！

私はC++/ Qtでプロジェクトを作成しており、QtSQL（http://doc.qt.nokia.com/latest/qtsql.html ）でサポートされている任意のタイプのSQLデータベースに接続できます。これには、ローカルサーバーと外部サーバーが含まれます。

ただし、問題のデータベースが外部にある場合、クエリの速度が問題になり始めます（UIが遅いなど）。理由：データベースに格納されているすべてのオブジェクトは遅延読み込みされるため、属性が必要になるたびにクエリが発行されます。これらのオブジェクトのうち平均して約20個が画面に表示され、それぞれに約5個の属性が表示されます。これは、表示するすべての画面で約100個のクエリが実行されることを意味します。クエリはデータベースサーバー自体で非常に高速に実行されますが、ネットワーク上で実行される実際のクエリのオーバーヘッドはかなりのものです（画面全体で数秒で測定）。

私はこの問題を解決するためのいくつかの方法を考えてきましたが、最も重要なアプローチは（私によれば）次のようです：

1. クエリを減らす
2. クエリを高速化

タックル（1）

• 属性の実際のフェッチを遅らせる（トランザクションを開始する）方法を見つけることができ、プログラマーがendTransaction（）を書き込むと、データベースはすべてを一度にフェッチしようとします（SQL UNIONまたはループを使用...） 。これはおそらく怠惰なオブジェクトの動作方法にかなりの変更を加える必要がありますが、人々がそれがまともな解決策であるとコメントした場合、私はそれがエレガントに解決できると思います。このソリューションがすべてを十分に高速化する場合、複雑なキャッシュスキームは必要ないかもしれず、多くの頭痛の種を節約します
• 要求されたすべてのオブジェクトに対して1つのクエリですべてをフェッチすることで属性データをプリロードして、効果的に遅延をなくすことができます。もちろん、その場合、私は古いデータについて心配する必要があります。少なくとも1つのクエリを外部データベースに送信せずに古いデータを検出するにはどうすればよいですか？（注：すべての属性チェックで失効したデータをチェックするクエリを送信すると、データが実際に失効していることが判明した場合に、最良の場合は0倍のパフォーマンスが向上し、最悪の場合は2倍のパフォーマンスが低下します）

タックル（2）

たとえば、データベースのローカル同期コピーを実行し続けることで、クエリを高速化できます。ただし、クライアントマシンで、たとえばサーバー上のデータベースタイプとまったく同じデータベースタイプを実行する可能性はあまりありません。したがって、ローカルコピーはたとえばSQLiteデータベースになります。これは、db-vendor固有のソリューションを使用できなかったことも意味します。ここでの私のオプションは何ですか？このような状況で人々にとって何がうまくいったのでしょうか？

心配事

私の主な心配事は次のとおりです。

• 古いデータ：古いデータを持つユーザーには可能と思われるアクションを禁止するような方法でデータベースを変更する、考えられるクエリはたくさんあります。
• 保守性：この新しいレイヤーでどの程度緩く結合できますか？私の内部の怠惰なオブジェクトシステムとすべてのオブジェクトと可能なクエリについてすべてを知る必要がなければ、明らかに望ましいでしょう。

最後の質問

クエリを作成するコストを最小限に抑えるための良い方法は何でしょうか？良い意味は、次のような組み合わせのようなものです。保守可能で、実装が簡単で、アプリケーション固有ではありません。いずれか2つを選ぶことになった場合は、そうしてください。人々が彼らの経験とそれを解決するために何をしたかについて話してもらいたいです。

ご覧のとおり、私はいくつかの問題とそれを処理する方法を考えましたが、賢明なアプローチを構成するものについては途方に暮れています。プログラムの多くのレイヤーにかなりの作業と集中的な変更が必要になる可能性があるため（できればできるだけ少ない）、この問題について最終決定を下す前に、ここですべての専門家に質問することを考えました。非常に単純な解決策を見落としている可能性もあります。その場合は、それへのポインタをいただければ幸いです。

関連するすべてのサーバー側の調整が行われたと仮定します（例：MySQLキャッシュ、可能な限り最高のインデックス、...）

*注：同様の問題を抱えているユーザーの質問を確認しましたが、私の質問を完全には満たすことができませんでした：私のユースケースのレプリケーションスキームに関する提案？ローカルデータベースキャッシュのベストプラクティスは？例えば）

回答を提供するために追加情報が必要な場合は、お知らせください。質問を適切に更新します。スペル/文法の誤りについてお詫びします。英語は私の母国語ではありません。

「怠惰」についての注意

私のコードがどのように見えるかの小さな例（もちろん簡略化されています）：

負荷分散サーバーでMicrosoftEnterpriseLibraryキャッシングを使用できますか？私の場合、2つの負荷分散サーバーにWebサービスがあり、データベースキャッシュの「backingStores」を次のような構成で使用しています。

そして、server1からキー " _testorderstatus3 "を使用してキャッシュを設定し、server2から取得しようとすると、Null値が返されます!!!

また、server1から同じキーで値を設定し、server2から再度設定して、DBを確認したところ、以下のように2回設定されていることがわかりました。

それについて何か考えはありますか？両方のサーバーを設定して取得する必要があります。

ありがとうございました

Glassfish でメッセージ駆動型 Bean を実行しています。毎秒数百のメッセージを受信します。メッセージを受信した後、JDBC データベースの値を読み取って処理する必要があります。

ただし、データベースの値は 1 日に 1 回以下しか更新されません。そのため、ほとんどの場合、MDB が読み取る内容は一貫しています。では、パフォーマンスを向上させるためにコンテンツをメモリにキャッシュする良い方法はありますか?

更新: MDB 用に Glassfish でメモリ内データベース JDBC 接続プールを構成することは可能ですか?

私はまだ Codeigniter フレームワークに慣れていません。今日、データベース キャッシングhttp://codeigniter.com/user_guide/database/caching.htmlと Web ページ キャッシングhttp://codeigniter.com/user_guide/general/caching.htmlについて読みました。

ページビューが既にキャッシュされている場合、データベースのキャッシュが大きな意味を持つかどうか、少し混乱しています。そのため、ページがキャッシュにある場合でも、データベースには移動しません。

次のシナリオで見られる唯一のポイント: db から 30 の結果をロードする場合、php を使用して結果をシャッフルし、配列 10 の結果からプルします。次回ページキャッシュが削除されたとき、db からの 30 件の結果がまだキャッシュに残っていますが、今回はそれらの 30 件の結果をシャッフルした後に異なる結果が得られます。

ページ キャッシュも使用する場合にデータベース キャッシュを使用すると何らかの利点が得られる場合、他にシナリオはありますか?

シナリオの説明から始めましょう。SQL Server 2008 を使用する MVC 3 アプリケーションがあります。ページの 1 つで、データベースから返され、ログインしたユーザーごとに一意である製品のリストを表示します。製品のリストを返すために使用される SQL クエリ (実際には VIEW) は非常に高価です。

• これは、現段階では変更できない非常に複雑なビジネス要件に基づいています。
• データベース スキーマは、他のアプリケーションで使用されているため、変更または再設計することはできません。
• 50,000 個の製品と 5,000 人のユーザーがいます (各ユーザーは 1 個から 50,000 個の製品にアクセスできます)。

ログインしたユーザーの製品ページを表示するには、次を使用します。

上記のクエリは、最大 50 行 (最大ページ サイズ) を返します。WHERE 句は、行数を最大 50k (ユーザーがアクセスできる製品) に制限します。ページの読み込みに約 5 ～ 7 秒かかります。これは、上記の SQL クエリを SQL で実行するのにかかる時間とまったく同じです。 問題:

ユーザーは製品ページに移動し、ページングを使用して結果を再ソートし、詳細ページに移動してからリストに戻る可能性が非常に高くなります。そして、結果を表示するのに 5 ～ 7 秒かかるたびに。

これは受け入れがたいことですが、同時に、ビジネス チームは、商品ページが最初に読み込まれるときに 5 ～ 7 秒かかることを認めています。したがって、 CACHINGについて考えました。

選択できるオプションが 2 つあります。少なくとも私にとって最も「明白な」オプションは、.Net キャッシュ (メモリ内/プロセス内) を使用することです。(現時点では、プロバイダー/ホスティング パートナーの技術的な制約により、分散キャッシュは許可されていないことに注意してください)。

しかし、私はこれにあまり満足していません。コードが新しいアイテムを挿入している間に.Netがキャッシュアイテムを絶えず削除してスペースを解放するなど、サーバーに他の問題を引き起こす可能性がある(50人または100人のユーザーが同時にログインしている場合)メモリ内に多くの製品が残る可能性があります。

2番目のオプション:

ここでの主な問題は、ユーザー x 製品 x アクセス ビューを生成するのに非常にコストがかかることです。そのため、フラット テーブル (つまり、データベース内のすべての製品 x ユーザーのキャッシュ) を作成できると考えました。このテーブルは、まさにビューの結果です。ただし、新しい製品が追加されたり、ユーザー権限が変更されたりすると、結果はいつでも変更される可能性があります。そのため、テーブルを常に更新する必要があり (数秒かかる場合があります)、これが少し複雑になり始めました。

同様に、ある種のキャッシュ プロバイダーを実装し、ユーザーからの要求に応じて、元の SQL クエリを実行し、ビューから製品を選択し (5 ～ 7 秒、1 回のみ許容)、その結果をフラットに保存します。 SQL では ProductUserAccessCache と呼ばれるテーブル。次のリクエストでは、このキャッシュされたテーブルから値を取得します (その特定のユーザーに対して結果がキャッシュされたことを簡単に識別できるため)。SQL での計算を行わない高速クエリを使用します。製品が追加されるか権限が変更されるたびに、キャッシュされたテーブルが切り捨てられ、新しいリクエストがあったときに、リクエストされたユーザーのテーブルが再作成されます。私にはそれほど複雑ではないように思えますが、基本的にここで行っていることは、新しいキャッシュ「プロバイダー」を作成することです。

• この種の問題を経験した人はいますか?
• .Net Caching (in proc) を使用したほうがよいでしょうか?
• 助言がありますか？

MySQL サーバーは、特定のタイプのクエリで常にロックアップして応答を停止し、最終的に (数分間応答しないと) エラー「 MySQL server has gone away 」であきらめ、次の一連のクエリで再びハングアップするようです。そしてまた。dbAサーバーは、マスターから主に INSERT ステートメントに 1 秒あたり約 5 ～ 10 行でレプリケートするスレーブとして設定されます。PHP ベースのアプリケーションがサーバー上で実行されており、5 ～ 10 秒ごとに新しく複製されたデータを読み取り、それを処理して (INSERT ON DUPLICATE KEY UPDATE) 結果を別のデータベースに保存します。dbB. すべてのテーブルは MyISAM エンジンを使用します。Web アプリケーションは、後処理されたデータをユーザーに表示します。基本的には、関連する処理手順は、1 秒あたりの解像度の時系列データを 1 分あたり、1 時間あたり、および 1 日あたりの解像度に圧縮することです。

MySQL がロックしたときに SHOW PROCESSLIST コマンドを実行すると、次のクエリが表示されます。

「時間」列は、ある種のクエリ待機タイムアウトに達するまで同期的に刻み続け、その後「MySQL サーバーが消えました」というエラーが発生します。5 ～ 10 秒後に新しいデータを再び処理する時間になると、同じロックアップが発生します。クエリ #1 はレプリケーション プロセスです。クエリ #2 は、後処理されたデータの更新です。クエリ #3 は、新しくレプリケートされたデータを処理のためにストリーミング (バッファリングなし) しています。おそらくそれが最初にタイムアウトしたため、最終的に「 MySQLサーバーが消えました」というエラーを生成するのはクエリ＃3です。

ある種のデッドロックのように見えますが、その理由はわかりません。あるデータベースで SELECT と INSERT を同時に実行すると、別のデータベースでの INSERT ON DUPLICATE KEY UPDATE によるクエリ キャッシュの更新でデッド ロックが発生するようです。レプリケーションまたはクエリ キャッシュをオフにすると、ロックアップは発生しません。プラットフォーム: Debian 7、MySQL 5.5.31、PHP 5.4.4 - すべての標準パッケージ。ほぼ同じアプリケーションが現在Debian 6、MySQL 5.1.66、PHP 5.3.3で正常に動作していることは注目に値するかもしれませんが、後処理されたデータが INSERT ON ではなく個別の INSERT および UPDATE クエリを使用して保存されるという点のみが異なります。重複キーの更新。

MySQL 構成 (Debian 6 および 7 マシンの両方):

このロックアップが発生する理由についてのヒントをいただければ幸いです。