問題タブ [distributed-caching]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
caching - MemCachedの最大ブロックサイズを変更することの意味
最大キャッシュブロックサイズが100MBの場合、MemCachedを実行することのデメリットは何ですか?
10MBまたは1MBのページを使用する場合とは大幅に異なる動作をしますか?逆に、100kなどの小さなページでMemCachedを実行するのはなぜですか?
MemCachedが最大サイズ100MBを使用するように設定されている場合、実際のサイズに関係なく、すべてのメモリユニットに実際に100MBが割り当てられますか?
java - Hazelcast では、1 つの大きなマップと複数の小さなマップのどちらが優れていますか?
複数のサーバーへのリクエストをレート制限できるレート リミッター システムを作成したいと考えています。このために、すべてのサーバーがこれらのカウンターをチェックおよび更新できるように、カウンター (IP アドレスごとに 1 つのカウンター) を作成したいと考えています。
私の質問: 最善のアプローチは何ですか。1 つのマップを作成し、クライアントの IP アドレスをキーとして使用し、その IP のカウンターは Java オブジェクトになります。そのオブジェクトはマップ エントリの値になります。
また
各 IP アドレスのマップを作成し、カウンター名をキーとして使用し、カウンター値をエントリの値 (int) として使用します。
私の最優先事項はスピードです。カウンター オブジェクトの取得とインクリメントは、非常に高速に行う必要があります。
それで何が一番いいの?多数の小さな地図か、1 つの大きな地図か?
誰かがこれで私を助けてくれることを願っています。
よろしく、
マールテン
hibernate - 休止状態を使用したキャッシュ
2 つのアプリケーションがあります。1 つ目は、参照データをプロビジョニングする Web アプリケーションです。2 つ目は、参照データが使用される ESB ベースのアプリケーションです。参照データは変更されますが、それほど頻繁ではありません。参照データをキャッシュする必要がありました。 Webアプリケーション(私は所有者ではありません)は休止状態を使用しました。しかし、私の ESB ベースのアプリケーションはそうではありませんでした。EHCache のみを使用しました。ESB アプリケーションに反映する必要がある独立した Web アプリケーションによって参照データが変更された場合。メッセージ キューを使用して実装しました。つまり、参照データが変更された場合、Web アプリケーションはメッセージ キューにメッセージを送信します。ESB アプリケーションはそのメッセージをリッスンしてクリアします。これは機能しますが、時間がかかります。Hibernate を使用して状況を改善するにはどうすればよいですか?
よろしく、 Subhendu
java - EhCache、JPA 2.0 L2 キャッシュ、キャッシング戦略
こんにちは、みんな、
私は L2 キャッシングの世界に慣れていないので、気楽にやってください :)。いくつかの質問を聞きたいんです:
1) EhCache と JPA 2.0 L2 キャッシュの違いは何ですか?
私の理解では、EhCache は分散されています (スタンドアロンにすることもできます) が、JPA 2.0 L2 キャッシュは分散されていません (JVM ごと)。
2) キャッシング戦略
キャッシング 101 戦略を共有してください。コレクションをキャッシュする方法 (問題とヒント)? キャッシュ プール内のオブジェクトを検索する方法 (キャッシュしていることがわかっている場合)。
3) キャッシングとストアド プロシージャ
データベースがその上で 2 つの異なるアプリケーションをサポートしているとします。一方のアプリケーションがストアド プロシージャを介してデータを更新し、もう一方の (キャッシュ) がデータを読み取る場合、更新の問題をどのように解決しますか? 読者にとっては、更新がないかのようです。
特定の大きな Web サイトがすべてをキャッシュしているという話を聞きました。これは、キャッシュ ライブラリと JPA / ORM の両方の上に独自のデータ アクセス レイヤーを記述することを意味するのでしょうか?
PS: ゴールデン ルールは、早い段階でキャッシュを回避するか、できればハードウェアの機能を向上させることであることを理解しています。学習目的でこの質問をしています。また、特定のシナリオを求めているわけではありませんが、一般的なルール、一般的なシナリオ、最小公倍数のほうが多く、全員の問題を解決する必要はありません。
ありがとう!
caching - Varnishでドーナツキャッシングを行うことは可能ですか?
私は ASP.NET 開発者で、オープン ソース スタックでキャッシュがどのように行われるかについてもう少し学びたいと思っています。ASP.NET MVC でできるように、Varnish でドーナツ キャッシュを実行できるかどうか疑問に思っていました。
ASP.NET MVC の例がローカル キャッシュであるのに対し、Varnish は分散キャッシュ システムであることは認識していますが、Varnish でそのような動作を実装することは可能ですか?
performance - キャッシュ更新戦略の推奨
私たちのサイトは最近、いくつかの小さなサイトに分割され、その後、異なる IDC に分散されます。
これらのサイトの 1 つはユーザー認証およびその他のユーザー関連サービスを提供し、他のサイトは Web サービスを介してアクセスします。
リモートでデータを取得するすべてのサイトで、ユーザー情報が必要になるたびにリモートに移動する必要がないように、ローカル キャッシュを作成します。
データの整合性を確保するために、どのキャッシュ更新戦略を推奨しますか?
caching - AppFabric キャッシュを使用したクエリのページング、一覧表示、およびグループ化
AppFabric キャッシュに関するドキュメントをたくさん読みましたが、そのほとんどは単純なシナリオをカバーしています。たとえば、都市リスト データやショッピング カード データをキャッシュに追加します。しかし、製品カタログ データをキャッシュに追加する必要があります。
私は4つのテーブルを持っています:
Product (100 万行)、ProductProperty (2,500 万行)、Property (100 行)、PropertyOption (300 行)
- Product および ProductProperty テーブルのいくつかのフィルターを使用してクエリを実行し、ページ化された検索結果を表示します。
- 検索結果セットに対して基準セットを作成しています。例 (4 アイテムの新製品、34 アイテムの電話、26 アイテムの書籍など)
- IsNew、CategoryId、PriceType などの列を使用して Product テーブルをグループ化するため
のクエリを実行し、PropertyId および PropertyOptionId 列を使用して ProductProperty テーブルをグループ化する別のクエリを実行して、どのプロパティにアイテムがいくつあるかを取得します。
したがって、検索結果を表示するには、検索結果に対して1つのクエリを作成し、基準リストを作成するために2つのクエリを作成します(カウント付き)
検索結果のクエリに 0.7 秒、2 つのグループ化クエリに合計 1.5 秒かかりました。負荷テストを実行すると、1 秒あたり 7 リクエストに達し、%10 が IIS によってドロップされました。これは、db が応答を返すことができなかったためです。
これが、製品とプロパティのレコードをキャッシュしたい理由です。
以下の項目に従う場合 (AppFabric 内);
- 名前付きキャッシュを作成する
- 製品カタログ データのリージョンを作成します (100 万行のテーブルと 2,500 万行のプロパティ テーブル)。
- データのクエリとグループ化のためのタグ付けアイテム。
いくつかのタグを使用してクエリを実行し、結果の 1 ページ目または 2 ページ目を取得できますか? いくつかのタグを使用してクエリを実行し、いくつかのグループ化結果の数を取得できますか? (フィルターオプションをカウントで表示) そして、3 台のサーバーが必要ですか? appfabric サーバーが 1 つだけのソリューションを提供できますか (もちろん、リスクは承知しています)。これらのシナリオについて説明している記事やドキュメントをご存知ですか?
ありがとう。
ノート:
いくつかの追加テスト: 約 30.000 項目をキャッシュに追加しました。そのサイズは 900 MB です。getObjectsInRegion メソッドを実行すると、約 2 分かかりました。「IList> dataList = this.DataCache.GetObjectsInRegion(region).ToList();」問題は IList への変換です。IEnumerable を使用すると、非常に迅速に動作します。しかし、自分のタイプに変換せずにページングまたはグループ化の結果を取得するにはどうすればよいですか?
別のテスト:
30.000 個の商品アイテムでグループ化カウントを取得しようとしましたが、グループ化の結果を取得するのに 4 秒かかりました。たとえば、GetObjectByTag("IsNew").Count() などの約 50 のクエリがあります。
azure - 分散システムとクラウドコンピューティングについての良い本をお勧めしますか?
私はMicrosoftAzureについて学んでいます。私にとっては目新しいものではありませんが、データベースシャーディング、非正規化、nosql、コンテンツ配信ネットワーク、分散キャッシュ( memcacheのように)、非同期処理、分割システム、負荷分散など...など...
テクニックよりもアプローチについての本を探しています。
問題は、AzureStorageの使用方法やAzureCDNの使用方法について多くのことを読むことができるということですが、正しいアプローチがないと、期待したほど良い結果が得られません。
前もって感謝します。
java - TerracottaサーバーがHibernateでEHCacheのバックエンドとして使用される場合、何をしますか?
私のDALはで実装されており、分散機能(スケーラビリティとHA用)を備えた第2レベルのキャッシュとしてHibernate
使用したいと考えています。私の質問でのみ分散キャッシング
を提供するように見えるのは、サーバーインスタンスの役割は何ですか?データも保持していますか?パーティション化されたキャッシュパーツ間の分散を調整するだけですか?私の混乱は主に、サーバーがデータを保持しているというTSAに関するこの説明
に由来しますが、私のシナリオでは、キャッシュとサーバーが一種のマージされていると思います。私は正しいですか?
サーバーがデータを保持している場合、ボトルネックをデータベースからサーバーに移動するべきではないのはなぜですか? EHCache
EHCache
Terracotta
Terracotta
Terracotta
Terracotta
更新: Affeの回答は、重要な部分である私の質問の2番目の部分に答えましたが、誰かが最初の部分を探しに来た場合に備えて、TCサーバーはメモリ内のEHCacheが保持するすべてのデータを保持する必要があると言います。分散キャッシュ(複製されない)が必要な場合は、L2(TCサーバー)がすべてのオブジェクト自体も保持する必要があります。
よろしくお願いします、
イッタイ
java - Ehcache - RMI を使用したレプリケートされたキャッシング
ehcache を使用してみましたが、うまくいきました。そして、ehcache RMI を使用して分散キャッシュを実装しようとしています。URL に記載されている手順に従いました: http://ehcache.org/documentation/distributed_caching_with_rmi.html?cf03800515=21D4D871!NTAxODEzNDE0OmNvcnByYWRpdXNzc286vsRypkVtSPb7t3MnL22gFQ==#
しかし、分散キャッシュが機能していることはわかりませんでした...
ポート番号を指定し、2 台のマシンでスタンドアロンの Java コードを使用しています。まず、データを「deviceCache1」に入れる友人のマシンでメイン プログラムを実行し、メイン プログラムでそのキャッシュにアクセスしようとします。しかし、2台のマシン間で接続が発生していません。
ばかげているように聞こえるかもしれませんが、キャッシングに関して知っておく必要があることはほとんどありません。誰かが私の疑問を明確にして助けてください。私の質問は次のとおりです。 1. 両方のマシンの ehcache.xml でどのポート ID を指定する必要がありますか? 2. rmi ポートを使用するには、Windows サービスを有効にする必要がありますか? 3. 2 台のマシンを接続するために他のコードを追加する必要はありますか?
至急助けてください。ありがとう