Live 360 オーランド 2016 でのトーク
分散キャッシングを使用した.NETアプリケーションのスケーリング
イクバル・カーン
プレジデント＆テクノロジーエバンジェリスト
.NETアプリケーションでは、トランザクションの負荷が増大するため、データベースまたはストレージのボトルネックが発生する可能性があります。 ボトルネックを取り除き、分散キャッシングを使用して.NETアプリケーションをスケーリングする方法を学びます。 この講演の内容は次のとおりです。
- .NETアプリケーションのスケーラビリティのボトルネックの概要
- 分散キャッシングの説明と、それがパフォーマンスの問題をどのように解決するか
- アプリケーションのどこで分散キャッシングを使用できますか
- 分散キャッシュのいくつかの重要な機能
- 分散キャッシュを使用した実践例
スケーラビリティとは
それでは、いくつかの定義から始めましょう。 これについてはほとんどの人がすでに知っていると思いますが、完全を期すために説明します。 最初の定義はスケーラビリティです。 では、スケーラビリティとは何でしょうか? スケーラビリティとパフォーマンスを混同することがよくあります。 アプリケーションごとのパフォーマンスは非常に高速な応答時間ですが、それは 50,000 ユーザーのみの場合であり、XNUMX ユーザーから XNUMX または XNUMX ユーザーまで変化しても、そのパフォーマンスが良好なままであれば、アプリケーションはスケーラブルであると言えます。 それが私たちが達成しようとしていることの要点です。
どのようなアプリケーションを使用していても、XNUMX 人のユーザーまたは非常に低いトランザクション負荷で得たパフォーマンスと同じパフォーマンスを達成できれば、高いトランザクション負荷でも同じパフォーマンスを達成できれば、そのアプリケーションはスケーラブルであると言えます。 XNUMX 人のユーザーで良好なパフォーマンスが得られない場合は、別の問題が考えられます。
線形スケーラビリティ
線形スケーラビリティはインフラストラクチャの定義に近いもので、アプリケーション サーバーやデータベース サーバーなどを追加することで、デプロイメントにサーバーを追加できるようにアプリケーションが設計されている場合、トランザクション キャパシティを線形に増加できるかどうかを示します。そうすれば、直線的にスケーラブルなアプリケーション アーキテクチャが得られます。
ただし、それができない場合、サーバーを追加しても何の価値も追加されない場合は、根本的に問題があり、アプリケーションを直線的に拡張することができません。 ここでの目標は、もちろん、直線的に拡張できるようにすることです。
非線形スケーラビリティ
非線形とは、サーバーを追加すると増加が見られるが、その後のある時点で増加が見られなくなる場合です。実際、サーバーを追加しても、アプリケーションとデプロイメントのアーキテクチャにボトルネックがあるため、パフォーマンスが低下します。あなたにはそれを克服することができません。
スケーラビリティが必要なアプリケーションはどれですか?
これらは通常、Web アプリケーションです。
つまり、これらは、.NET 担当者、Web サービス、非常に強力な新興領域であるモノのインターネットのバックエンド、およびビッグ データ処理のための ASP.NET です。 ビッグデータ処理は Java 側でより一般的です。 .NET 側でそれを行う人は多くありませんが、ビッグ データ処理もまた別の分野です。 また、他のサーバー アプリケーション、これはバッチ処理アプリケーションである可能性があります。 あなたは金融サービス会社かもしれません。何百万もの顧客がいて、彼らは電話をかけてきて住所を変更したり、ある口座から別の口座に資金を送金したりするかもしれません。ある特定のコンプライアンス要件があるため、深夜までにそれを完了する必要があります。これらの処理を完了するために、バックエンド、ワークフロー、ある意味でいくつかのバッチ処理が発生します。 したがって、一定数のトランザクションを実行するために時間の制約を受けるその他のサーバー アプリケーションには、スケーラビリティが必要です。
スケーラビリティの問題
では、スケーラビリティの問題はどこにあるのでしょうか? 線形および非線形のスケーラビリティについて説明しました。 したがって、スケーラビリティの問題は、アプリケーション層が非常に良好な線形方法でスケーリングすることです。 Web アプリケーションまたは Web サービス、アプリケーション層がある場合は、サーバーを追加するだけで問題ありません。 ボトルネックとなるのはデータストレージです。 データ ストレージという言葉は、リレーショナル データベースとメインフレームのレガシー データを意味します。 そういう意味じゃないよ NoSQL database. NoSQL databaseは素晴らしいです。 また、 NoSQL 呼ばれる製品 NosDB しかし、SQL データベースがないことが常に答えになるわけではありません。 より多くのデータを移動できるのであれば、それらは答えになります。 NoSQL database よりスケーラビリティの高いソリューションが得られます。 ただし、問題は、すべてのデータを次の場所に移動できないことです。 NoSQL。 技術的な理由とビジネス上の理由から、リレーショナルに保持する必要があるデータがたくさんあります。
したがって、リレーショナル データベースは今後も存続します。 この問題に関しては、彼らはどこにも行きません。 したがって、この現実を回避するか、リレーショナル データベースを使用することになるという現実に対処し、それでもこの問題を解決する必要があります。 そして、この問題を解決しなければならない理由は、スケーラビリティが必要な前述のアプリケーションがすべて存在するためです。
分散キャッシュの展開
そしてもちろん、その答えは、アプリケーション層とデータベース層の間に分散キャッシュを接続することです。
したがって、分散キャッシュは本質的に非常に強力でありながら、非常にシンプルな概念です。 XNUMX つ以上の低コスト サーバーがあり、それらがクラスター化されており、そのクラスターはすべてのサーバーのメモリと CPU リソースを XNUMX つの論理容量にまとめてプールします。 ボトルネックとスケーラビリティは XNUMX つの領域にあります。 XNUMX つはメモリ、XNUMX 番目は CPU、XNUMX 番目はネットワーク カードです。
たとえば、ここにデータベース サーバーが 20 台あり、ハードウェア強度の観点から 10 台のデータベース サーバーで対応できるアプリケーション層ボックスが 8 個ある場合、メモリや CPU をさらに追加できますが、それには限界があります。 したがって、答えは、それほどハイエンドではないサーバーをさらに多く持つことができるようにすることですが、実際には、定義上、サーバーはハイエンドであるべきではありません。 そして、過去 16 年以上にわたってこれを行ってきた中で最も一般的な構成は、同等のデュアル CPU クアッドコア タイプです。 したがって、8 コア ボックスと XNUMX コア ボックスは、実際にはキャッシュ サーバーとしてはかなりハイエンドな構成であるとします。 XNUMXコアがほとんど一般的です。
メモリはもちろん、大量のメモリが必要です。メモリは安価なので、それほど大きな要素ではありません。 大量のメモリが必要です。なぜなら、キャッシュはインメモリ ストアであるため、すべてをメモリに保存します。一般的な構成では、各キャッシュ サーバーに約 16 ～ 32 GB のメモリが必要であり、キャッシュ サーバーが少なくとも 2 つ必要です。冗長化の目的で。 したがって、このアーキテクチャを採用することで、アプリケーション層にサーバーを追加することができる状況になります。 キャッシュ層に比例してサーバーを追加します。 したがって、通常は 4 対 1 または 5 対 1 の比率が最も現実的であると考えられます。 場合によっては、5 対 1 をはるかに超えることもできます。つまり、5 つのアプリケーション サーバーと 1 つのキャッシュ サーバーを意味しますが、サーバーの数に制限はありません。 サーバーは 2 台、4、10、20、30 台使用できますが、ここで 20 台のサーバーを使用するには、おそらくロード バランサー環境に XNUMX 台のサーバーが必要です。
したがって、ある段階では、これは、オンライン ビジネス シナリオにおける Web または電子商取引で見てきたアプリケーションのほぼハイエンドになります。 したがって、ここにサーバーを追加することで、これがボトルネックではなくなります。 したがって、分散キャッシュは実際にベスト プラクティスになりつつあります。 必要に応じて拡張性がある場合。 なぜなら、独自の目的のために存在するデータベースがあるだけでなく、すべてのアプリケーション データに対して永続的なデータ ストアの永続性が必要であるだけでなく、アプリケーション アーキテクチャの一部である非常に高速でスケーラブルなインフラストラクチャも備えているからです。 したがって、プログラミングするときは、もはやデータベース用にプログラミングするだけではありません。 キャッシュによって、ピーク負荷下でもアプリケーションの速度が低下しないことが保証されるため、常にキャッシュのことを考えています。 たとえデータベースが同じように拡張できるように設計されていなかったとしてもです。 ということで、これが典型的な写真です。
トラフィックの約 80% がトラップされるか、キャッシュに行く時間の 80%、データベースに行く時間の 20%、そしてそれらの 20% はほとんどが更新であり、もちろん一部の読み取りです。データをキャッシュに入れる必要がありますが、キャッシュに事前にデータを取り込むこともでき、それを行う方法は他にもたくさんあります。 ただし、データベース層のトラフィックを大幅に削減することで、パフォーマンスとスケーラビリティを実現できます。
つまり、これは分散キャッシュを使用する場合に当てはまります。 それをアプリケーション アーキテクチャの一部として保持しなければならない理由。
一般的な使用例
さて、分散キャッシュの使用についてある程度の主張をしました。次の質問は、分散キャッシュをどのように使用するかです。 どこで使いますか? 分散キャッシュはどのような用途に使用する必要がありますか?
アプリケーションデータのキャッシュ
最も一般的な用途は、アプリケーション データのキャッシュです。 ここは、先ほど話したように、データベース内にあるデータが何であれ、それをキャッシュする場所です。 そのため、データベースにアクセスする必要はありません。 留意すべき点は、アプリケーション データ キャッシュの使用例では、データが XNUMX つの場所に存在するということです。この点については後続のスライドで詳しく説明します。 XNUMX つは常に存在する必要があるデータベース内にあり、XNUMX つ目はキャッシュです。 では、データが XNUMX つの場所に存在する場合、最初に思い浮かぶ問題は何でしょうか? 同期中！ うん。
したがって、そのような状況に対応できないキャッシュでは、読み取り専用データ、つまり変更されることがないとわかっているデータをキャッシュする必要があります。 実際、キャッシュについて話すとき、ほとんどの人は、なぜ読み取り専用データにキャッシュが必要なのかという考えを思いつきます。 顧客やアカウント、そして 30 秒ごとに変化するデータをキャッシュしたくありません。 しかし、調査によると、キャッシュの最大の用途はトランザクション データであり、一度キャッシュすると、そのアクティビティや使用の移動時間枠が何であれ、おそらく次の XNUMX ～ XNUMX 分以内にキャッシュが必要になるでしょう。 そのとき、同じデータが再び必要になり、それをキャッシュから取得できれば、データベースへのアクセスが減り、アプリケーション内で発生する何百万ものトランザクションを掛け合わせると、かなり大幅な効果が得られます。 したがって、優れたキャッシュはこの問題を非常に効果的に処理する必要があるということを念頭に置いて、今後の作業を進めてください。
ASP.NET固有のキャッシュ
XNUMX 番目の使用例は、ASP.NET アプリケーションがある場合、大量の一時データが存在することです。 一時的とは一時的なことを意味し、キャッシュに入れることができ、このデータは実際にはデータベースに属さないことを意味します。 たとえば、データベースは永続的に存在します。 常設店舗です。 それがあなたのマスターレコードです。 それで、 セッション状態おそらく、ユーザーがログインしてから 20 分後までの間だけ保持する必要があるでしょう。 では、なぜデータベースに保存しておくのでしょうか? データベースはそれほど高速ではありません。 リレーショナル データベースは BLOB を保存するように設計されておらず、通常、セッションは BLOB として保存されます。 したがって、セッションをデータベースに保存すると、パフォーマンスに大きな影響が生じます。 したがって、セッション状態は、ASP.NET が分散キャッシュに入れる非常に良い使用例です。
また、MVC フレームワークを使用していない場合は、ビュー ステートも存在します。これは、ポストバックでブラウザに戻るという XNUMX つの目的だけで Web サーバーからブラウザに流れる非常に重いデータです。 つまり、彼らが言うように、それはかなり長い旅です。 したがって、それをサーバー側に保持し、小さなキーを送信するだけであれば、はるかに便利になります。 つまり、これはキャッシュの非常に優れた使用例です。
XNUMX 番目の使用例はページ出力です。多くのページの出力は毎回変わりません。 では、変化しないのであれば、なぜページを実行する必要があるのでしょうか。ページを実行すると、CPU、メモリ、その他すべてのリソースが消費されるからです。 前回の実行からの出力を取得して表示してみてはいかがでしょうか。 そのため、Microsoft または ASP.NET には、分散キャッシュをプラグインできる出力キャッシュ フレームワークがあります。 したがって、この使用例、つまり ASP.NET でのこれら XNUMX つの使用例では、問題の性質が完全に変わりました。 キャッシュとデータベースの間の同期はなくなりました。 なぜ？ データベースがないからです。 キャッシュとはデータベースのことです。
問題の本質は、キャッシュがメモリ内にあるということです。 そうすることですべてのパフォーマンスが得られます。 では、データをメモリに保存していて、それが唯一のストアである場合、最大の懸念事項は何でしょうか? 失くしてしまうかも知れませんよ！ そのボックスが再起動したらどうなるでしょうか? Windows はワーカー プロセスを再起動またはリサイクルすることが知られています。 つまり、Linux ボックスを再起動する必要があるとしても、あなたのボックスが再起動したらどうなるでしょうか? そのデータを失う準備はできていますか? あなたが航空会社で、その顧客が送信ボタンを押した最後のページで、ハワイ行きの家族旅行の航空券を 5,000 ドル分持っていて、突然「すみません、最初からやり直しです!」と表示されたらどうでしょうか。 彼らはあらゆる種類のフライト調査を行って時刻を確認し、Google のフライトも実行してどれが一致するかなどを確認したので、良い経験ではありませんでした。
ビジネスとしては、顧客やショッピング カートを失いたくありません。 したがって、その答えは分散キャッシュです。 信頼性が確保できる場合、データが決して失われないことが保証される場合、レプリケーションが確実に行われる場合にのみ、セッションまたはすべての一時データを保持する必要があります。 したがって、優れた分散キャッシュは、複数のサーバー間でデータのレプリケーションを実行します。 レプリケーションは実際には時間の無駄であり、今話した不測の事態のためだけに行うのは余分なことです。 したがって、レプリケーションのマイナス面は、パフォーマンスに影響を与えることです。 したがって、キャッシュがインテリジェントに実行せず、多くのキャッシュが実行しない場合、レプリケーションをオンにするとパフォーマンスが低下することになります。
イベントを通じた実行時データの共有
したがって、これら XNUMX つの点に留意してください。XNUMX 番目の使用例は、分散キャッシュが実際に環境内にインフラストラクチャを導入すると、非常に強力なイベント駆動型のデータ共有プラットフォームになるということをほとんどの人が実際には知りません。 したがって、ワークフロー内でデータを共有する必要がある複数のアプリケーションがある場合があります。 パブリッシュ/サブスクライブのタイプがあり、メッセージ バス、エンタープライズ サービス バス、またはメッセージ キューを使用する可能性があります。 分散キャッシュは、そのための非常に強力なプラットフォームです。 すでに社内に導入されているため、他のアプリケーションが共有のみを目的として設計されているのに対し、パフォーマンスを重視して設計されているため、実際には他のオプションよりも高速でスケーラブルです。
したがって、イベント駆動型のパブリッシュ/サブスクライブ型は、複数のアプリケーション間で共有されます。 XNUMX つのアプリケーションがデータを生成し、それをキャッシュに置き、イベントを発生させます。 そのイベントに関心を示している他のアプリケーションがあるため、利用可能なときにこのデータを使用したいと考えています。 したがって、彼らはイベントを受信し、再び XNUMX つのアプリケーションがここに存在する可能性があり、これは、すべてのユーザーが利用できる非常に強力なスケーラブルなイベント エンジンになります。
これが XNUMX 番目の使用例です。 イベントの場合でも、実行時のデータ共有機能やユースケースでは、ほとんどのデータは一時的なものです。 これは永続データから派生しており、おそらくその永続データから再作成することもできますが、それを行うには多大な作業が必要であり、その性質上一時データを使用するため、そのデータは通常この一時データにあります。 通常はそうではなく、データベースに保存する必要はありません。 ただ消費するだけでいいのです。 つまり、やはりキャッシュが唯一のストアとなるため、セッションや他のものと同様に、信頼性が必要になるという問題も同じです。つまり、これらは分散キャッシュを使用する XNUMX つの一般的な方法です。
これら XNUMX つの使用例の良い点は、ASP がそのためにプログラミングを必要としないことです。.NET framework サードパーティのプロバイダーを接続できるようになります。 たとえば、セッションの場合、Web 設定にアクセスし、もちろん ASP にアクセスするだけの簡単なサンプルを XNUMX つだけ簡単に紹介します。.NET core、そのパラダイムは少し変わりますが、考え方は同じです。
ASP.NETセッションキャッシュの構成
したがって、Web.config にアクセスすると、これは単純な ASP.NET アプリケーションであることがわかります。 Web.config に移動し、まず、次の場合に使用するキャッシュのアセンブリを追加する必要があります。 NCacheでアセンブリを追加するだけです。 NCache セッション ストア プロバイダーを使用する場合は、コピー＆ペーストするだけで済みます。次に、実際に行う必要があるのは、ここで変更を行うことです。
したがって、Web の設定にはセッション状態タグがあり、モードがカスタムであり、タイムアウトがどのようなタイムアウトになるかを確認する必要があります。 そして、次の場合には、 NCache次に、実際にはこの行を追加するだけで、他にも指定できるパラメータがたくさんありますが、ここでは説明しませんが、そのうちの XNUMX つはキャッシュの名前だけです。 の場合には NCache、すべてのキャッシュには名前が付いており、実際にそのデモもお見せしますが、 したがって、キャッシュの名前を指定するだけです。 キャッシュはすでに作成されています。 これは、どのキャッシュに接続するかを示す接続文字列のようなものです。複数のキャッシュ (セッション用に XNUMX つ、アプリケーション データ用に XNUMX つ、そしてすべて用) がある可能性があるためです。 つまり、その変更を加えて健全性テストを行い、アプリケーションの一般的なユースケースをすべて確認すると、アプリケーションは突然セッションを保存できるようになります。 分散キャッシュのような NCache。 したがって、利益を得る最も簡単な方法と最大の利益は、実際にセッションです。
したがって、次のような分散キャッシュでセッション状態を使用するために必要なことはこれだけです NCache またはその他の場合も同様であり、ビューステート出力キャッシュについても同様です。 それはすべて構成ベースの変更です。 それぞれについて立ち入るつもりはありません。 これを例として示したかっただけです。
アプリのデータキャッシュ
それでは、分散キャッシュの中心部に移りましょう。中心部と言うのは、そこにほとんどの時間が費やされるからです。 分散キャッシュを組み込むことを選択した場合、ほとんどの時間をアプリケーション データのキャッシュに費やすことになります。 では、典型的な API はどのようなものでしょうか?
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");ASP.NETキャッシュオブジェクトをご存知の方は、 NCache できる限りそれに近いものを模倣しようとしますが、スーパーセットであるため、さらに多くのものがあります。 すべてのキャッシュには独自の API があります。 これはなんと NCache APIはこんな感じ。 キャッシュに接続します。それは名前付きキャッシュです。 キャッシュ ハンドルを取得し、そのキャッシュ ハンドルを周囲とアプリケーション内で保持し、Cache.Get を実行するだけです。 Get、Contains、Add、Insert、Remove のほか、Add Async、Insert Async もあります。 「挿入」とは、存在しない場合は追加し、すでに存在する場合は更新することを意味します。 これは、ASP.NET キャッシュ オブジェクトで使用される用語と同じであるため、私たちもそれを使用しました。 また、Async メソッドは基本的に、その操作が完了するまで待つ必要がないことを意味します。 実際には、コールバックを指定できる XNUMX 番目のパラメータがあります。 したがって、何か問題が発生した場合、またはすべてがうまくいったとほぼ想定できる場合にコールバックが呼び出されます。
キャッシュを最新に保つ
そこで、ここに来たとき、アプリケーション データのキャッシュについて話しましたが、最大の懸念は、キャッシュを最新の状態に保つ必要があるということです。 したがって、優れた分散キャッシュではそれが可能である必要があります。そうでないと、読み取り専用データをキャッシュすることになります。 いずれにしても、読み取り専用データはデータの約 10 ～ 15% です。 では、キャッシュすべき内容の 10 ～ 15% しかキャッシュしていない場合、このキャッシュから実際にどのようにメリットを得ることができるのでしょうか? つまり、あなたがやりたいのは、すべてのデータ、実質的にすべてのデータをキャッシュすることですが、キャッシュしてもまったく意味がないと言えるデータはごくわずかです。 ただし、ほぼすべてのデータ。 データの一部は短期間キャッシュされます。 したがって、そのデータをキャッシュすると、これはすべてアプリケーション データになります。最も困難なキャッシュは、キャッシュが最新であることを保証するためのさまざまな方法であり、最も重要なのは有効期限です。
時間ベースの有効期限の使用
有効期限は絶対的な有効期限と、スライド式の有効期限があります。 どちらも有効期限ですが、この 2 つは意味が大きく異なります。 絶対有効期限は、キャッシュを最新の状態に保つために行うべきことです。これは、この顧客オブジェクトをキャッシュに保存していると推測しているためです。 XNUMX分でキャッシュするのが安全だと思います。 あなたはただ推測に基づいて推測しているだけです、それは経験に基づいた推測ですが、それは推測です。 XNUMX 分以内にデータベース内のデータを誰も変更しないことを望みますが、変更した場合、キャッシュはデータベースと不整合になります。 一方、有効期限のスライドは、キャッシュの同期を維持することとは何の関係もありません。 これは、エビクションまたはキャッシュの自動クリーンアップに関係しています。
つまり、セッションとは、誰もログインしていないときに、非アクティブ状態が 20 分間続いた後にセッションを削除するということです。 それで、あなたは大掃除のようなことをしています。 キャッシュをクリーンアップしてください、私のためにクリーンアップしてくださいと言っているのです。 これらすべてを追跡する必要はありません。 それをキャッシュに置き、誰も触っていない場合でもキャッシュに保持する時間を指定し、その後クリーンアップします。 したがって、絶対有効期限とスライド有効期限では、永続的な目標とは大きく異なります。 したがって、スライド式有効期限は、一時データのセッションに使用します。 絶対有効期限。永続的なデータに使用します。
私が使いたいもう XNUMX つの用語は、参照データとトランザクション データです。 参照データは、それほど頻繁には変更されませんが、変更されるデータであり、読み取り専用ではありません。 それは、価格が毎日、毎週、または何かで変わる可能性がある製品テーブルですが、顧客オブジェクト、活動オブジェクト、または注文オブジェクトほど頻繁ではありません。 したがって、キャッシュしたいのはトランザクション データです。 もちろん、参照データをキャッシュしたいのは当然ですが、トランザクション データもすべてのデータを取得する場所になります。 したがって、有効期限がキャッシュを最新の状態に保つのに十分でない場合は、より多くの機能が必要になります。
データベースの依存関係の使用
したがって、次の機能は、優れた分散キャッシュに必要な非常に強力な機能ですが、ユーザーが関与することなく、監視する必要もなく、キャッシュをデータベースと同期できる必要があることです。 したがって、このオブジェクトをキャッシュしていることをキャッシュに伝えることができるはずです。 これは、データベース内のこのデータ セットに関連しています。 したがって、データベース内のこのデータセットを監視してください。 変更があるかどうかを確認してください。XNUMX つまたは XNUMX つのことを行ってください。この項目をキャッシュから削除するか、削除すると、次回アプリケーションがその項目を必要とするときに、その項目がキャッシュ内で見つからなくなることを意味します。 キャッシュで見つからない場合はどうなりますか? データベースから取得します。 つまり、新しいコピーを取得するか、新しいコピーを自動的にリロードするようなものです。 新しいコピーを自動的にリロードするには、後で説明するリードスルーと呼ばれる別の機能が必要です。
それで、話は戻りますが、 データベースの同期 は非常に強力な機能です。 これにより、キャッシュが常に最新の状態に保たれるため、安心感が得られます。 どのようなデータをキャッシュするかについて心配する必要がなく、キャッシュをデータベースと同期するさまざまな方法があること。 最も一般的なのは SQL 依存関係で、実際には ADO.NET または SQL サーバーの機能です。 NCache 使用します。
たとえば、実際に本来のコードを示します。 それでは、早速ですが、コードがどのようなものかを簡単に説明します。 それはどこへ行ったの？ したがって、.NET アプリケーションがある場合、これが次のようになっているとします。 NCacheもちろん、次の XNUMX つを参照します。 NCache ライブラリ。 NCache。ランタイムと NCache。ウェブ。 したがって、繰り返しになりますが、ASP.NET キャッシュ オブジェクトの名前空間にできるだけ近い名前を付けるようにしました。 NCache。ウェブ。 私たちが 2005 年に登場したとき、ASP.NET キャッシュ オブジェクトが唯一のキャッシュであったため、私たちはこの分野で最も古い存在であり、人々が理解しやすいようにこの名前を選択したのです。 したがって、アプリケーション内にいくつかのコードを含めることになります。 NCache 名前空間。 次に、キャッシュに接続し、キャッシュ ハンドルを取得します。これでキャッシュ ハンドルが得られるので、オブジェクトを作成し、Cache.Add を実行するとします。 したがって、Cache.Add はキーを受け取ります。 キーは実際には文字列であるため、これに従っていることに注意してください。 これは命名規則に従っていませんが、通常は Customer:CustomerID: その顧客の ID であるため、Cache.Add を実行してから実行します。この場合は XNUMX 分間の絶対有効期限を指定しています。 言っているように、有効期限のスライドやその他すべてのことは行わないでください。 したがって、これは、キャッシュがどのようなものであるかを少し知るためのものです。
非常に使いやすく、非常にシンプルな API で、ADO.NET やその他のプログラミングを行うよりもはるかに簡単です。
キャッシュとはどのようなものですか?実際に、実際にキャッシュがどのようなものかを、実際のキャッシュを使って説明しましょう。 したがって、これらの VM と Azure があります。 デモ 1 と 2 が XNUMX つあります。 これらは私が使用する XNUMX つのキャッシュ サーバーです。 これらはキャッシュ VM であり、アプリケーション サーバーを使用します。 これをデモクライアントと呼ぶことにします。 したがって、私のアプリケーションはデモクライアントで実行することになります。 わかった！ ということで、これにリモートデスクトップを入れてみました。 場合に備えてそうします NCache という名前のツールを実行します NCache マネージャーさん、実はここにあるんです。 そして、私は先に進んで作成します。 その名前のキャッシュがすでに存在しないことを簡単に確認させてください。 わかった！ そこで、新しいキャッシュを作成してみます。 このキャッシュをデモキャッシュと呼びます。 他のすべてをデフォルトとして使用します。 キャッシング トポロジを選択します。 詳細には立ち入りませんが、このキャッシュ トポロジはパーティショニングとレプリケーションの両方を同時に実行します。 したがって、このトポロジを実行すると、キャッシュは次のようになります。
つまり、これらはキャッシュ サーバーです。 つまり、データの一部、この 1 2 3 4 がデータ要素です。 したがって、一部のデータはパーティション 1 にあり、一部のデータはパーティション 2 にあり、すべてのパーティションが別のサーバーにバックアップされます。 つまり、ここに 3 つのサーバーがあるとします。
パーティション 1、2、3 があり、サーバー 2 にはパーティション 1 のレプリカがあり、サーバー 3 にはパーティション 2 のレプリカがあり、サーバー 1 にはパーティション 3 のレプリカがあるとします。つまり、キャッシュは実際にはサーバーです。 実際には、クラスター内にある複数のサーバーです。 彼らはお互いのことを知っているので、すぐにこの話に戻りましょう。 そこで、パーティション レプリカ トポロジを選択したとします。 最初のキャッシュ サーバーとしてデモ 1 を選択します。 なぜこんなに遅いのでしょうか? デモ 2 を 7802 番目のキャッシュ サーバーとして使用します。 おそらくインターネットが遅いのが原因だと思います。 わからない。 これで、XNUMX ノードのキャッシュ クラスターが完成しました。 つまり、デモ XNUMX と XNUMX はお互いのことを知っています。 それで、彼らはこのポートで互いに通信するつもりです。 ポート XNUMX を変更できます。 なぜこんなに遅いのでしょうか? 確実に。
わかった！ そこで、次にキャッシュに必要なメモリ量を指定します。 つまり、ギガ数は 13 ギガですが、先ほども言ったように、おそらく 15 ギガ程度になるでしょう。 次に、最も最近使用されていないエビクション ポリシーを指定します。 5% を保存します...申し訳ありませんが、キャッシュの XNUMX% を削除します。 本当に遅いです、何が起こっているのかわかりません。 このボックス全体が遅い、クリックですら遅い、CPU ですら遅い、そう！ そのように見える。 そうですよ！
わかった！ したがって、基本的には、論理的にキャッシュと呼ばれるサーバーのクラスターがあり、それらはデモ キャッシュによってのみ認識されます。 あなたのボックス、たとえばアプリケーションサーバーボックス上で NCache ここに設置されています。 そのキャッシュ名とそれを表すサーバーのリストを含む構成ファイルが作成されます。 したがって、これは単なる出発点ですが、クラスター全体が単なるキャッシュ名であることがわかり、それに接続すると、クライアント API がこの図にあるすべてのキャッシュ サーバーに接続します。 パーティション レプリカの場合、すべてのクライアントがすべてのサーバーと通信するため、データが存在する場所、つまりパーティション化部分に直接アクセスできます。
先に進み、デモ クライアントであるクライアントを追加します。 先に進み、キャッシュ アシスタントをクリックします。クリックするまでに時間がかかりますが、キャッシュを開始すると言います。 つまり、両方のボックスでキャッシュが開始されると言うだけです。 NCache は Windows ベースのキャッシュであるため、優れた Windows ベースの製品が持つ使いやすい機能をすべて備えています。 したがって、これらすべてを一元的な場所から実行でき、スクリプトを通じて実行することもできます。
データベースの同期 - デモそれでは、データベースの同期がどのようなものかを説明しましょう。 たとえば、これも同じタイプのアプリケーションで、キャッシュがあり、キャッシュにデータを追加しようとすると、Cache.Add here を実行しているとします。これは次のとおりです。もちろん NCache コードでは、SQL キャッシュの依存関係を指定します。 NCache クラスですが、バックエンドでは SQL サーバーの SQL 依存関係クラスにマップされます。 そして、それに SQL 文字列を渡します。 NCache データベースに接続すると、キャッシュ サーバーがデータベースのクライアントになります。 たとえば、アプリケーションがここにある場合、たとえばコードがここで実行されている場合、この呼び出しを発行したところです。 おっと、ごめんなさい！ この広告のキャッシュ呼び出しを発行し、この SQL キャッシュ依存関係を渡しました。 クライアントはこれらすべてをキャッシュ サーバーに送信します。
したがって、キャッシュ サーバーは XNUMX つまたは複数です。 また、ここでも接続文字列を指定しているため、キャッシュ サーバーはデータベースへの接続を開きます。 そして、この接続強度はもちろんプールです。 それで。 同じ接続文字列を複数回指定すると、バックエンドに接続プールが存在します。 したがって、別のキャッシュがデータベースのクライアントになりました。 データベースを監視して、データベースが NCache あなたが私に監視を依頼したこのデータが変更されたことをサーバーに伝え、 NCache その時点でサーバーは、その項目をキャッシュから削除するかデータベースから再ロードするかを決定できます。 そして、それをリロードするには、実際にリードスルー機能を実行する必要があります。
わかった！ それが一つの方法です。 本当に強力です。 イベント駆動型です。 変更が発生するとすぐにデータベースがキャッシュに通知し、キャッシュは直ちにアクションを実行します。 ただし、SQL キャッシュの依存関係を実行するたびに、そのデータ セットを監視するために SQL サーバー内にデータ構造を作成する必要があるため、このデータベース サーバー側にオーバーヘッドが発生します。 これらが 1 万個もあれば、SQL サーバーがクラッシュすることは保証できます。 繰り返しになりますが、ここではスケーラビリティについて話しているので、非常に大きな数字の観点から考える必要があります。 したがって、これらが何千、何万あっても問題ありません。 しかし、それらが数十万または数百万ある場合は、別の戦略がより良い戦略になります。
データベースの依存関係もう XNUMX つの戦略は DB 依存関係と呼ばれるもので、これは私たち独自のものです。 NCache これはポーリングベースの依存関係である機能です。 これをどこに実装しましたか。 特別なテーブルがあり、そのテーブル内の対応する行のフラグを更新できるようにトリガーを変更するようお願いします。その後、キャッシュから DB 依存関係を実行するたびに、キャッシュはそのテーブルにエントリを作成し、15 回のフェッチでエントリを作成します。 、フラグが true の場合、更新が行われた場合、キャッシュは何千もの行をフェッチできます。 つまり、これは私たち独自の追跡方法のようなものです。 ポーリングベースなので、即時ではありません。 デフォルトでは約 1 秒の遅延ですが、再構成できます。 あまり頻繁に引っ張るのも望ましくありません。 これがもう XNUMX つですが、そこにも制限があります。そのテーブルに true と false のフラグを持つ XNUMX 万行がある場合、インデックスはかなり大きく見えますよね。 true と false のインデックスがあり、これらはツリーの XNUMX つのノードです。 したがって、DB 依存関係は SQL 依存関係よりも効率的ですが、リアルタイム性ほどではなく、それでも制限があります。
CLR手順XNUMX つ目は CLR プロシージャで、実際にデータベース内のトリガーから CLR プロシージャを呼び出すことができるため、項目が追加、更新、または削除されるたびにプロシージャを呼び出すことができます。 このプロシージャは、キャッシュに対して非同期呼び出しを行います。 このアイテムをキャッシュに追加または更新するか、キャッシュから削除してくださいと表示されます。 非同期が重要な理由は、トランザクション、つまりデータベース トランザクションを遅延させたくないからです。 そうしないとタイムアウトが発生します。 したがって、非同期呼び出しはすぐに戻り、少なくともデータベース トランザクションをコミットしてキャッシュを更新できます。 したがって、キャッシュとデータベースの同期は重要な機能です。
キャッシュを非リレーショナルと同期する
非リレーショナルの場合、またはメインフレーム、レガシー、またはその他のデータ ソースがある場合、クラウド データ ソースがある場合、Web メソッド呼び出しを行って、そのデータが存在するかどうかを確認する場合も同じことが必要です。更新されているかどうか、そして NCache このカスタム依存関係機能を使用して、コードを監視できるようにします。 NCache、短い間隔ごとにコードを呼び出し、データ ソースを監視して、データが変更されたかどうかを確認し、変更された場合は通知します。 NCache & NCache 同じ方法で削除するか、再度リロードします。
リレーショナルデータの取り扱い
したがって、キャッシュを最新の状態に保つことが重要です。 それができないキャッシュがあると、メリットを享受する能力が制限されます。 リレーショナル データの処理については省略しますが、そうではありません。すぐに言っておきますが、XNUMX 対多の関係、XNUMX 対 XNUMX の関係があります。 したがって、キャッシュ内に XNUMX つのアイテムがあり、キャッシュ内にも多数のアイテムがある場合、論理的にキャッシュ内の XNUMX つのアイテムを削除すると、多数のアイテムも削除される必要があります。なぜなら、それをデータベースから削除した場合はどうでしょうか。 したがって、キャッシュはこれらすべてを追跡できる必要があります。 アプリケーションでそれを行うこともできますが、キャッシュに対して多くの簿記を行うことになるため、アプリケーションのクレジットが複雑になるだけです。 これは、アプリケーションの仕事ではないデータベース同期やデータ整合性コードをアプリケーション内に組み込んでいるようなものです。 データベースに対してはそんなことはしません。 データベースがそれを行うので、キャッシュもそれを行う必要があります。
リードスルーとライトスルー
したがって、リードスルー、ライトスルーは、キャッシュに備えるべきもう XNUMX つの非常に強力な機能です。 繰り返しになりますが、リードスルーのコンセプトは基本的に非常にシンプルです。
次の場合にインターフェースを実装します。 NCache ここで、リードスルー プロバイダーと呼ばれるインターフェイスを実装します。 見えますか？
はい、それには XNUMX つの方法があります。 データ ソースに接続できるように、キャッシュの開始時に呼び出される Init があります。 キャッシュが停止すると破棄が行われ、クリーンアップを行うことができ、ほとんどの場合、このロードをソースから呼び出すことになります。 したがって、キーが渡されます。 キーは、データ ソース内のどの項目を取得して返すかを知るための鍵です。 NCache プロバイダーのキャッシュ項目。 また、有効期限を指定したり、有効期限が切れたときに再同期したり、ここであらゆる種類のフラグを指定して、それを NCache. NCache それをキャッシュします。
では、リードスルーはどのように機能するのでしょうか? 私たちがどのように機能するかというと、アプリケーションは常にキャッシュを要求します。 Cache.Get と表示されます。 キャッシュにデータがない場合は、データがないと言うのではなく、データベースからデータを取得します。 したがって、アプリケーションは突然非常にシンプルになります。 永続化コードの多くは、アプリケーションから取り出したばかりです。 したがって、リードスルーの利点の XNUMX つは、コードを簡素化し、すべてをキャッシュ層にカプセル化できることです。 キャッシュ層には永続層がますます増えています。 すべてのコードをリードスルーで実行できるわけではありませんが、多くのコードはリードスルーで実行できます。
期限切れ時にリロード
リードスルーの XNUMX 番目の利点は、先ほど説明したリロード機能です。 ここで、電子商取引アプリケーションがあり、価格が変更され、価格が変更されるたびにそれらのアイテムをキャッシュから削除して再ロードする必要がある場合を想像してください。しかし、非常に大量のトラフィックが発生するため、アイテムが削除されている間、多くのクライアント リクエストがヒットすることになります。データベース。 最初のものはそれをフェッチしてキャッシュに入れますが、それまでの間、キャッシュに突然大量の不必要なトラフィックが発生し、それが継続的に発生すると、データベースは不必要なヒットを大量に取得することになります。期限切れになったらリロードすれば回避できたはずです。 では、有効期限をリロードするとどうなるでしょうか? 有効期限が切れてもアイテムは削除されません。 再ロードするだけなので、有効期限が切れると、キャッシュはリードスルーを呼び出してデータソースから取得し、更新するだけです。 したがって、更新操作のみが行われます。 削除および追加操作がないため、データまたは項目は常にキャッシュ内にあります。 それで、突然キャッシュができるようになりました。 自身で処理することができ、データを再ロードする必要があるときはいつでも自身を再ロードできます。
ライトスルー
つまり、これは非常に強力な読み取り機能です。 したがって、それを有効期限と組み合わせると、データベースの同期も行うことができます。 データベースの同期が発生した場合、なぜそれを削除するのでしょうか? リロードするだけです。 もう XNUMX つの機能はライトスルーで、書き込みを行う点を除いてリードスルーと同じように機能します。 もう XNUMX つ機能があり、一括書き込みも実行できます。 そして、一括書き込みが行われる理由については、後ほど説明します。 つまり、Init があるのと同じように、dispose があり、今度はデータ ソースへの書き込みが行われます。 書き込みは追加または挿入のみを意味するものではありません。 また、削除することもできるため、書き込みには追加、更新、または削除のいずれかの操作タイプが含まれます。 そして、それはキャッシュ操作の内容によって異なります。 そして、それを一括で行うこともできます。 したがって、ライトスルーには、コードを簡素化するという点でリードスルーと同じ利点がありますが、さらにもう XNUMX つの利点があります。 したがって、リードスルーにはリロードの利点があり、ライトスルーには後書きできる利点があります。
後書き
そして、ライトビハインドは非常に強力な機能です。 なぜ？ データベースの更新がボトルネックになっているためです。 繰り返しますが、データベースは、共存しなければならない必要悪です。 これなしでは生きていけませんが、アプリケーションであらゆる種類のボトルネックを引き起こしています。 したがって、依存性が低いほど、アプリケーションはより優れたものになります。 それなしでは生きていけないという事実は、それでもそれを持たなければなりません。 では、後書きは何をするのでしょうか? キャッシュを超高速で更新すると、データベースより少なくとも XNUMX 倍、それ以上の速度でキャッシュがデータベースの更新を処理します。 つまり、非同期ライトスルー、つまりライトビハインドが発生します。 したがって、キャッシュを更新し、戻ってきて作業を続行すると、キャッシュが移動してデータベースが更新されます。
もちろん、キャッシュが解決しなければならない問題はたくさんあります。 キャッシュでデータベースを更新する必要があると言うとすぐに、キャッシュ サーバーがクラッシュしたらどうなるでしょうか? その行列はどうなるのでしょうか？ したがって、次の場合には、 NCache、キュー自体は複数のサーバーにレプリケートされ、いずれかのサーバーがダウンしてもキューは失われません。 その後、再試行もあります。 更新が失敗した場合は、再試行できます。 一括更新もできます。 したがって、一括更新できるものがたくさんあります。 したがって、さらに最適化することができます。 したがって、ライトスルーとリードスルーは非常に強力な機能です。 それはサーバーサイドコードと呼ばれます。 これはキャッシュ クラスター上に存在するコードです。 これはここに存在し、そのコードをサーバー上に保持することでアプリが簡素化されます。 したがって、プッシュするコードが増えるほど、アプリケーションはよりシンプルになります。
データのグループ化
わかった！ これで、キャッシュを使用する必要があると確信したとします。 さまざまなユースケースがあり、大量のデータを確実にキャッシュできるようになりました。 これで、キャッシュがデータベースのように見えるようになりました。 キャッシュには数百万のアイテムが存在することになります。 では、キャッシュ内に何百万ものアイテムがある場合、キーに基づいて読み取るだけでよいのでしょうか? いいえ！ キーに基づいてキャッシュから項目を読み取る唯一の方法がある場合、アプリケーションは、何かを実行できるかどうかに比べて非常に困難になります。この検索条件に基づいてすべてを教えてください。
したがって、検索とグループ化は、キャッシュの非常に強力なニーズ、または非常に重要なニーズになります。 繰り返しになりますが、目的は、メリットが何かを理解していただくことです。 メリットは、より多くのデータをキャッシュできることです。 キャッシュするデータが増えるほど、より多くのデータを表示したり、より多くのデータベース タイプの機能が必要になります。 それらの機能の XNUMX つは、メタデータを実行できることです。 データベースでは、さまざまな属性にインデックスを付けることができます。 ここでは、タグ、名前付きタグ、および実際にオブジェクトをキャッシュするときに実行できます。 NCache インデックスを作成することもできます。 したがって、オブジェクトにインデックスを付けることができます。 都市で検索するのでインデックスを作成する必要があるため、顧客が都市属性でインデックスを作成できるとします。 インデックスが作成されていない場合、検索は非常に困難になります。 オーランドの顧客を知るために、すべてのオブジェクトを検査するために最初に何百万ものアイテムを逆シリアル化する必要があることを想像してください。 良い写真ではありませんし、美しい光景でもありません。
したがって、コーディングの観点から見ると、サブグループ化タグと名前タグを再度グループ化するのは非常に簡単です。 早速、これをお見せしていきます。 録音の観点から見ると非常に使いやすいです。 大量のアイテムを追加し、それにタグを割り当てた後、申し訳ありませんでした。 グループとサブグループ、グループ サブグループ、そしてグループ データを取得すると言ったり、SQL 検索を実行して、グループ名がエレクトロニクスである製品オブジェクトをすべて教えてと言ったりすることもできます。 したがって、タグとタグのグループ化とサブグループ化もまた、 AppFabric ちなみに提供されています AppFabric XNUMX月で販売中止となります。 まだ時間がありますので、スピードアップしていきます。
データの検索
繰り返しになりますが、データの検索は、SQL に基づいてデータを検索できるようにしたいデータのグループ化に関連しているので、私は… オブジェクト クエリ言語とはどこにあるのでしょうか? そこにそれがある。 基本的に、大量のデータを取得して SQL ステートメントを発行し、複数の属性を指定してパラメータを渡すことができ、次のような場合にレコード セットを取得できます。 NCache ただし、SQL サーバーと同様に、完全な SQL のサブセットです。 結合は行いませんが、結合の代わりにグループ化とタグ付けを行うことができ、これにより複数のオブジェクトをグループ化することができます。
つまり、LINQの場合は、 NCache LINQ プロバイダーを実装しているので、Iqueryable インターフェイスです。 あなたはそのコレクションを取りに行きます NCache 次に、他のオブジェクト コレクションに対して行うのと同じように LINQ クエリを実行すると、これらのオブジェクトのコレクション、つまり製品オブジェクトが返されます。 したがって、検索に関して LINQ が本当に快適である場合は、LINQ を使用して検索してください。 このクエリを発行すると、同じクエリがすべてのサーバーに送信され、結果が取得されてマージされて表示されるクラスターに移動します。 したがって、ここでは非常に単純に見えますが、舞台裏では多くの作業が行われている可能性があります。 NCache.
つまり、SQL と LINQ があります。 バルク機能もあり、前述したようにインデックス作成も可能です。
ランタイムデータ共有
非常に簡単に説明します。キーベースのイベント、キャッシュ レベルのイベント、パブリッシュ サブ イベント、継続的なクエリがあります。
継続的クエリは、キャッシュ上にあることを除けば、SQL 依存関係機能に似た機能です。 キャッシュにデータセットの監視を依頼しているのです。 つまり、SQL 依存関係を使用して、SQL サーバーにこのデータ セットを監視するように依頼し、このデータ セットが変更された場合は通知してくださいと指示したのと同じです。 さて、あなたは尋ねています NCache「お願いします。これが私の SQL ステートメントです。Customer.City が New York に等しい顧客を選択してください。この条件に一致する顧客がキャッシュに追加、更新、または削除された場合は、通知してください。それは上の任意の場所である可能性があります。」と言いました。ネットワーク、キャッシュ クラスター上の任意の場所、そして他のクライアントになる可能性があります。 通知が届きます。 したがって、これらのタイプの機能を搭載することで、ポーリングする代わりに、キャッシュに何が起こっているかを突然監視して通知を受け取ることができます。つまり、キャッシュが非常に強力なランタイム データ共有プラットフォームになると私は言いました。
高可用性
わかった！ これも省略させていただきます。 つまり、使用するキャッシュは動的である必要があります。 高可用性を提供する必要があります。 NCache、ピアツーピアアーキテクチャを採用しています。
クライアントキャッシュ
ぜひ知っておいていただきたい機能が XNUMX つあります。 クライアントキャッシュ。 これをニアキャッシュと呼ぶ人もいます。
これは実際には、アプリケーション サーバー ボックスにローカルに存在するキャッシュです。 スタンドアロンではない点を除けば、スタンドアロン キャッシュに似ています。 したがって、InProc であることもあります。 これはアプリケーションプロセス内にある可能性があり、実際にオブジェクトヒープ上にあるものをフェッチしていることを意味します。 ヒープにはオブジェクト形式のデータが含まれています。 そのパフォーマンスに勝るものはありませんよね？ キャッシュ ローカル ボックス OutProc にデータを取得するのではなく、ヒープからそのデータを取得できる場合、プロセス間を移動する場合は IPC を通過する必要があり、シリアル化、逆シリアル化を実行する必要があり、ネットワークを経由する場合はさらに複雑になります。データベースにアクセスすると、比較的高価です。
したがって、これはアプリケーション プロセス内のローカル キャッシュ、またはボックス上のローカル キャッシュです。 ただし、同期は維持されます。 クライアント キャッシュに対して特別な API プログラミングを行う必要はありません。 次の場合には、キャッシュを呼び出すだけです。 NCache、構成変更にプラグインするだけで呼び出しをインターセプトし、取得したもののコピーをローカルに保持します。 したがって、次回取得するときに、ローカル キャッシュから自動的に取得されます。 パフォーマンスが大幅に向上します。 これは唯一のことです NCache .NET側にあります。 Java 側では、クライアント キャッシュを備えた他の製品がありますが、.NET ではこれだけだと述べています。 これは、キャッシュの上にキャッシュがあるようなもので、スタンドアロンの InProc キャッシュから分散キャッシュに移行すると、多くの人が不満を言う理由です。実際にパフォーマンスが低下し、アプリケーションが遅くなり、分散キャッシュは問題があると思っていました。パフォーマンスが向上するはずですが、私たちは、スケーラビリティが向上するはずだと彼らに言いました。 ローカルの InProc キャッシュに一致するものはありません。誰も一致できません。 つまり、これは私たちが発明して何かをできるものではありません。 複数のプロセスをまたぐことになるので、相応のコストがかかります。
したがって、この課題を克服できる 16 つの方法は、クライアント キャッシュを使用することです。 したがって、クライアント キャッシュもサブセットです。 通常、各キャッシュ サーバーには 32 ～ XNUMX GB があります。 したがって、XNUMX ～ XNUMX 台のサーバーがある場合、潜在的に約 XNUMX ギガを超えるキャッシュ データが存在し、クライアント キャッシュはそれぞれ最大 XNUMX ギガ、おそらく XNUMX ギガ、おそらく XNUMX ギガまたは XNUMX ギガで、ワーカー プロセスの数によって異なります。もつ。 ワーカー プロセスが XNUMX つしかない場合は、XNUMX ギガにします。 ハイエンド顧客の多くが Web 層にワーカー プロセスを XNUMX つ持っている場合、クライアント キャッシュだけで XNUMX の XNUMX 倍にする必要はありません。 したがって、プロセス キャッシュから XNUMX GB を確保するのは良いことかもしれませんが、それでもキャッシュ層に行くよりは優れています。 まだ高速であるか、XNUMX ギガバイトまたは XNUMX ギガバイト未満の InProc キャッシュを使用することもできます。 これで、コピーが XNUMX つありますが、それらも同期されています。 したがって、キャッシュから値を取得する場合は、間違いなくクライアント キャッシュの使用を検討する必要があります。
さて、私の目標は、キャッシュ機能を販売することではなく、優れたキャッシュには何が必要か、そしてこれらの機能の多くは Java 側で見つかることを伝えることです。 Java は、キャッシュ側でははるかに成熟した市場です。 彼らは分散キャッシュの代わりにインメモリ データ グリッドという言葉を使用していますが、どのような機能が表示されていても同じです。 NCache、それらの多くは Java 側でも見られますが、.NET 側でも見られます。 NCache 唯一のものです。
WANレプリケーション
もう XNUMX つの特徴は、複数のデータ センターがある場合、データベースを複製する必要があるのに、なぜキャッシュを複製しないのかということです。 何をする？ キャッシュ全体を再構築しますか? ショッピングカートについてはどうですか？ セッションについてはどうですか？ したがって、複数のデータセンターが現実になり、クラウドによってユーザー側の労力が不要になるため、それがさらに簡単になります。 リージョン XNUMX とリージョン XNUMX と言えば、データ センターが XNUMX つありますよね? しかし、根本的な問題は解決しません。つまり、WAN レプリケーションをサポートしない分散キャッシュを使用すると、行き詰まってしまいます。 キャッシュがレプリケートされなければ、アクティブ/アクティブ、さらにはアクティブ/パッシブのマルチ データ センター ソリューションを構築することはできないため、非常に重要な機能です。
NCache もちろんこれがあります。 すでにハンズオンデモを提供しました。 NCache は市場で最も古い .NET キャッシュです。 当社は 2005 年に設立されました。
NCache vs Redis
それでは、早速行っていきます NCache 対 Redis、非常に非常に高いレベル、そしてそれは、 Redis 多くの人が私たちに「あなたと比べてどうですか？」と尋ねてきます。 Redis Microsoft が Azure にそれらを選択したためです。
Redis、素晴らしい製品です。 超高速です。 これは主に Linux 側から来ます。 多くの機能はありません。 機能では勝てません。 これは、それが Linux 側からのものであり、Microsoft が AWS 市場を獲得したかったため、.NET ソリューションを採用できなかったという事実で勝っているだけです。 彼らはマルチプラットフォームを採用する必要がありました。 つまり、彼らの Linux バージョンは非常に安定しており、非常に優れていますが、Microsoft 自体が行った Windows への移植は一種の孤立した移植です。 Microsoft 自身はこれを使用していません。 Azure で使用している場合 Redisの Windows ポートを使用していません。 Redis, Linux バージョンを使用しています。 したがって、Azure を使用しておらず、Windows ポートを使用する場合は、 Redis、気をつけてください。 つまり誰も所有していないのです。 Redis 研究室の Web サイトにアクセスしても、Windows のダウンロードはありません。 つまり、彼らは Linux のダウンロードしか持っていないのです。 Redis。 Microsoft は、自分たちでも言いましたが、コミットメントの使用に関しては、口を出してお金を出しませんでした。
そう、 NCache これが唯一の実行可能なオプションであり、オープンソースなので、お金がない場合は、無料のオープンソース バージョンを使用してください。 プロジェクトが重要であり、エンタープライズ機能であるサポートやその他の機能が必要な場合。 企業 NCache オープンソースの上に構築されています。 それは別のもののようなものではありません。 オープンソースは孤立したものではありません。 つまり、私たちがそれを所有し、維持し、その上に企業が構築されているということです。 したがって、オープンソースは安定している必要がありますが、サポートやより多くの機能が必要な場合は、Enterprise Edition を購入してください。
私たちはネイティブの .NET です。 C-sharp で開発し、Windows Server 2012 r2 認定を取得しています。 次もすぐに手に入れる予定です。 つまり、Microsoft に関する限り、私たちは先頭に立っていないということになります。 私たちはほぼ .NET そのものです。 当社には Java クライアントがありますが、Java を購入する顧客によるほぼすべての Java の使用は、 NCache .NET 用であり、社内にあるため Java からも使用しています。 したがって、私たちの生存の糧はすべて .NET 上にあります。 したがって、私たちは常に最新かつ最高であり、最初で最も簡単であるつもりです。