SDD2017 ロンドン
分散キャッシングを使用した.NETアプリケーションのスケーリング
イクバル・カーン
プレジデント＆テクノロジーエバンジェリスト
データ トランザクション ボリューム、セッション ボリューム、またはオブジェクト サイズが増加している場合は、この講演が最適です。 アプリとデータベース間の分散キャッシュを使用してアプリのパフォーマンスを向上させる方法を学びます。 この講演の内容は次のとおりです。
- .NETアプリケーションのスケーラビリティのボトルネックの概要
- 分散キャッシングの説明と、それがパフォーマンスの問題をどのように解決するか
- アプリケーションのどこで分散キャッシングを使用できますか
- 分散キャッシュのいくつかの重要な機能
- 分散キャッシュを使用した実践例
概要
みなさん、こんにちは。私の名前はイクバル・カーンです。 私はテクノロジー エバンジェリストです。 Alachisoft。 私たちはのメーカーです NCache。 どれだけの人が聞いたことがあるだろうか NCache 前？ いい、いい数字だ。 今日のトピックは、分散キャッシュを使用した .NET アプリケーションのスケーリングです。 それは問題ではありません NCacheでは、.NET アプリケーションが直面するスケーラビリティの問題全体と、この問題を解決する方法について説明します。
私はもっとインタラクティブな議論を好みます。 それでは、最後まで質問するのではなく、私の話中に質問がある場合は手を挙げてください。 アーキテクチャと実際のコードの組み合わせについて説明し、またお見せします。 NCache キャッシュがどのようなものかを示す例として。
スケーラビリティとは何ですか？
それでは、いくつかの定義を説明しましょう。 すでにご存知の方も多いと思いますが、スケーラビリティとは何でしょうか? スケーラビリティはアプリケーションのパフォーマンスではありません。 これは、ピーク負荷時のアプリケーションのパフォーマンスです。つまり、5 人のユーザーに対して超高速に実行されるアプリケーションがある場合、5,000、50,000、または 500,000 人のユーザーに対して超高速に実行されない限り、必ずしもスケーラブルであるとは限りません。 もちろん、アプリケーションが 5 ユーザーに対して高速に実行できない場合は、スケーラビリティ以外の問題が発生します。
線形スケーラビリティと非線形スケーラビリティ
線形スケーラビリティは、どちらかというと展開アーキテクチャです。 アプリケーションは、負荷分散された環境でサーバーを追加し続け、サーバーを追加するにつれてトランザクション容量が増加するように設計されていますか。 ちなみに、スケーラビリティという言葉を使用するときは、スケーラビリティのデータではなく、トランザクションのスケーラビリティを意味します。 私たちは膨大な量のデータについて話しているのではありません。 私たちはテラバイトやペタバイトのデータについて話しているのではありません。 私たちはたくさんの活動について話しています。 したがって、アプリケーションがサーバーを追加できるように設計されており、サーバーを追加するにつれて容量が直線的に増加する場合、直線的にスケーラブルになります。
そうでない場合は、大学での微積分をまだ覚えている人にとっては、対数曲線に近くなります。この曲線の問題は、増加が見られることですが、ある時点を過ぎると、サーバーを追加しても実際には何のメリットもありません。アプリケーションには解消されないボトルネックがいくつかあるため、実際にはパフォーマンスが低下します。 したがって、非線形になることは絶対に避けるべきです。
スケーラビリティが必要なアプリケーションはどれですか?
では、どのアプリケーションにスケーラビリティが必要なのでしょうか? もちろん、これらは通常サーバー アプリケーションです。 Web アプリケーション、ASP.NET、現在は ASP.NET Core また。 ウェブサービス。 繰り返しますが、WCF を通じて実行できます。 ASP.NET Web APIまたはASPで実行できます.NET Core ウェブAPI。 つまり、Web サービスは通常、最近急速に出現している分野である IoT のバックエンドです。
これらもビッグデータ処理アプリケーションです。 つまり、大量のデータがある場合、スケーラビリティのデータ部分が重要になりますが、そこでも重要なのはデータではなく、どれだけ速く処理できるかです。 したがって、ビッグ データ処理アプリケーションがある場合は、拡張する必要があります。 ビッグ データ処理アプリケーションのほとんどは、通常、.NET には含まれていません。 彼らは Java 側に重点を置いており、私は .NET アプリケーションに重点を置いています。 しかし、概念的に言えば、ビッグ データ処理アプリケーションもスケーラビリティを必要とするものです。
最後に、その他のサーバー アプリケーションです。 あなたは金融機関かもしれません、あなたは大手銀行かもしれません、何百万人もの顧客がいます、彼らから電話がかかってきたり、住所を変更したり、新しいカードを発行したり、その他何でも処理する必要があります。おそらく彼らは資金を送金したいので、あなたはそれを行う必要があります。コンプライアンスを目的として、特定の時間枠内ですべてのリクエストを処理します。 したがって、これらのバックエンド バッチ プロセスが多数実行されており、毎晩わずか数時間という非常に短い時間内で、より多くのトランザクションを処理する必要があります。 したがって、あらゆるサーバー アプリケーションに適用されます。 したがって、これらのアプリケーションのいずれかをお持ちで、拡張性が必要な場合は、今すぐに最適な場所にいます。
スケーラビリティの問題
では、スケーラビリティの問題とは何でしょうか? まあ、アプリケーション層は問題ではありません。 私が言及したこれらのアプリケーションのほとんどでは、アプリケーション層は完全に正常に動作しているようです。 さらにサーバーを追加できます。 通常、負荷分散された環境があります。 たとえば ASP.NET アプリケーションがある場合、最上位にロード バランサーがあり、ロード バランサーがトラフィックを送信するサーバーのグループがあり、より多くのトラフィックが必要な場合は処理する必要があります。ユーザーを増やすには、サーバーを追加するだけです。 とてもシンプルです。
しかし問題は、データベースがリレーショナル データであるかメインフレーム データであるかにかかわらず、ボトルネックになることです。 また、リレーショナルとは、特定の 2 つのデータベースを意味するものではありません。 SQL サーバー、Oracle、MySQL、DbXNUMX などのいずれかである可能性があります。 すべてのリレーショナル データベースには、拡張できないという固有の弱点があります。 まさにそれが理由です NoSQL 運動が始まり、実際に .NET スペース上には と呼ばれる製品さえあります。 NosDB これはオープンソースです NoSQL database しかし NoSQL database必ずしも答えが得られるわけではありません。 つまり、スケーラビリティの問題は確実に解決されます。 技術的に言えば、 NoSQL database スケーラビリティのボトルネックは発生しません。 しかし、問題は、技術的理由とビジネス上の理由が重なって、すべてのデータをリレーショナル メインフレームまたは従来のメインフレームの外に移動できないことです。 NoSQL.
だから、 NoSQL これは、いわゆる新しいデータの一部です。 従来のビジネス データは、さまざまな理由から依然としてリレーショナル データベースに存在しています。 つまり、リレーショナル データベースを使用しながらこの問題を解決する必要があるということです。 私の写真からリレーショナル データベースを削除するだけだとは言えません。 実際、当社のお客様でさえ、完全に NoSQL。 データの一部を次の場所に移動します NoSQL。 MongoDB のような大企業であっても、そこに移行する人々と同じストーリーがあります。 NoSQL database データの一部を～に移動する NoSQL そして、従来のデータは依然としてリレーショナル データベースに保存されています。
分散キャッシュの導入 (NCache)
したがって、図にあるリレーショナル データベースの問題を解決する必要があります。 分散キャッシュ 実際、同じ利点が得られることがよくあります NoSQL database。 それは実際、よく考えてみると、 NoSQL インメモリキーバリューストア。 それで、調べたことがあるなら、 NoSQL databaseJSON ドキュメント データベース、キー値ストア、グラフ データベース、その他のタイプがあります。 それで、キーバリューストアは... 分散キャッシュの唯一のことは、永続化を行わず、すべてメモリ内にあることです。 それはキーバリューストアです。 また、複数のサーバーに分散されるため、同じ利点が得られ、さらにサーバーを追加できるため拡張可能です。 したがって、これをアプリケーション層として考えてください。 ここにアプリケーション層があり、通常はこのどこかにロード バランサーがあります。 そして、この層にサーバーを追加すると、間にキャッシュ層を置かない限り、データベースにますます負荷がかかることになります。
キャッシュ層はアプリケーション層と同じように拡張できます。 ボックスをどんどん追加していくだけなので、ボトルネックはありません。 データは複数のサーバーに分散されます。 ちなみに、これらは低コストのサーバーです。 これらはハイエンドのデータベース タイプのサーバーではありません。 実際、当社の顧客は… 一般的な構成は、約 16 GB の RAM、約 8 コアのボックスで、一般的な Web サーバー ボックスと同様ですが、メモリが追加されているだけです。 16 ギガ、16 ～ 32 ギガ、32 ギガを超えることはお勧めしません。実際、64 ギガがお客様に推奨する最大値にほぼ相当します。 さらにサーバーを追加するとします。 何故ですか？ メモリを増やしすぎると、.NET にはガベージ コレクションと呼ばれるものが存在するためです。 また、ガベージ コレクションには多くの処理能力が必要です。 つまり、メモリが増えれば増えるほど、より多くのガベージ コレクションを実行する必要があり、CPU の速度も向上する必要があります。その結果、キャッシュはますますデータベースに近づかず、全体的に高価になっていきます。 したがって、ハイエンド サーバーを数台使用するよりも、より多くのサーバーを使用する方が良いでしょう。
したがって、分散キャッシュは基本的にサーバーのクラスターを形成します。 これは通常、TCP ベースのクラスターであり、クラスター内のすべてのサーバーがお互いを認識し、リソースを XNUMX つの論理容量にプールすることを意味します。 クラスターを使用すると、容量を増やす必要があるときにクラスターに別のサーバーを追加するだけで済みます。 または、容量を減らす必要がある場合は、サーバーを削除します。 また、このキャッシュ層がある場合、データを保持する必要がないため、それはインメモリ ストアになります。 常設の店舗ではありません。 永続ストアは依然としてデータベースであり、メモリ内ストアであるため、データ レプリケーションも提供する必要があります。
この全体像における目標は、基本的に約 80% の確率でキャッシュに移動することです。 つまり、想像していただければ、80% の確率でキャッシュにアクセスすると、データベースは完全にストレスフリーになります。 スケーラビリティをかなり高めることができます。
質問: アプリケーションはまだデータベースとあまりやり取りする必要はありませんか?
実際にはそうではありません。 したがって、それはデータ次第です。 ただし、ほとんどのアプリケーション データは、数秒ごとに変化しない参照データまたはトランザクション データのいずれかのカテゴリに分類されます。 おそらく数分ごとに変わります。 したがって、そのすべてのデータに対して、書き込みよりも読み取りの方がはるかに多くなります。 したがって、最初の読み取りはデータベースに送信され、次のような機能もあります NCache には、キャッシュにデータをプリロードできる機能があります。 したがって、キャッシュに必要と思われるすべてのデータを入れてウォームアップすると、トラフィックやデータベースがヒットしなくなります。 ただし、それはデータ次第です。 たとえば、他の種類のデータがある場合、そのデータにセッションを保存すると、読み取りごとに XNUMX 回の書き込みが行われるとします。 したがって、状況に応じて詳細を説明しますが、それは良い質問です。
そうならない理由は、キャッシュがデータをロードしてキャッシュ内に保持するためです。 したがって、キャッシュとデータベース間のトラフィックは非常にまれです。 繰り返しますが、80% の時間で読み取りが完了し、キャッシュにデータが保存されます。 したがって、キャッシュすると、一定期間キャッシュされることになり、その期間中、キャッシュは毎回データベースに送信されるわけではありません。 ただし、アプリケーションは毎回キャッシュにアクセスします。 したがって、大量のトラフィックがあるにもかかわらず、すべてがキャッシュに送られ、突然データベースが非常に軽くなります。
実際には、各ボックスにパーティションがあり、異なるデータが保存されており、信頼性のためにある程度の冗長性も組み込まれていますが、これについてはさらに詳しく説明します。
したがって、この図 (図 1) は、今日の高スケーラビリティ環境では、分散キャッシュが事実上のベスト プラクティスのようなものであることを納得してもらうことを目的としています。 したがって、アプリケーションを設計する場合は、キャッシュを念頭に置いてください。 どのキャッシュでも構いません。 それは別の議論です。 最初の議論は、分散キャッシュを使用するようにアプリケーションを設計する必要があるということです。 そうすれば、ビジネスでアプリケーションの実行が必要になったときに、アプリケーションが停止することはないと確信できます。
そして、事前に計画を立てないと、拡張できないという本当にマイナス面は、ビジネスが非常にうまくいっているときにこの問題が発生するということです。 あなたが航空会社で、今週末にどこかの休暇スポットでプロモーションを実施したところ、何百万人もの新規ユーザーがフライト検索をしたり、チケットを購入したりするために Web サイトにアクセスしていると想像してください。 Web サイトのパフォーマンスがクリックごとに XNUMX 分ごとに低下し始めたら、顧客を失うことになります。 さらに状況が悪化して、データベースが停止したためにアプリケーションがクラッシュし始めた場合、多くのビジネスを失うことになります。 したがって、事前に計画を立てる必要があります。 今日はそのような問題に直面していませんが、繰り返しますが、これはパフォーマンスに関するものではありません。
多くの人は、パフォーマンスが向上するためキャッシュを使用すると考えています。 パフォーマンスは向上しますが、最近のデータベースはかなり高速です。 ユーザーが XNUMX 人だけの場合。 データベースが遅いという不満を言う人は聞いたことがありません。 したがって、問題はパフォーマンスではありません。 問題はスケーラビリティです。データベース サーバーが XNUMX つしかなく、アプリケーション層にさらにサーバーを追加すると、突然データベースがボトルネックになるからです。
質問: キャッシュ クラスターには VM または物理ボックスを使用する必要がありますか?
とても良い質問です。 それについて話そうと思ったのですが忘れてしまいました、質問してもらえて良かったです。 したがって、これらは物理的なボックスである可能性があります。 物理的なボックスを所有しているお客様はまだいらっしゃいますが、VM に移行するお客様が増えており、今ではコンテナが新しいトレンドとなっています。 したがって、少なくとも VM が必要になります。 したがって、すべてのキャッシュ サーバーは VM です。 したがって、少なくとも 16 つのキャッシュ サーバー VM が必要になります。 先ほども言いましたが、それぞれ32〜XNUMXギガです。 もちろん、同じ物理ボックス上に両方の VMS を配置する必要はありません。 なぜなら、その高可用性の利点が失われるからです。 なぜなら、そのボックスがクラッシュすると、両方の VMS がなくなってしまうからです。
もう一つ質問です。 では、物理データはメモリに保存されるのでしょうか?
思い出に。 まさに、まさに。 すべてメモリ内ストレージです。 そして、これは一時的な保存であるため、数分、数時間、数日、数週間保存しますが、永久的に保存するわけではありません。 永続的なストアは依然としてデータベースです。 それが何であれ。 それは、先ほども言ったように、レガシー メインフレームである可能性があります。リレーショナルである可能性もあります。 NoSQL.
でもで NoSQL database、分散キャッシュを使用する必要があります。 なぜなら NoSQL 分散キャッシュほど高速ではありませんが、私たちが知っている両方の製品を持っているためです。 ベンチマークを実施します。 それでも10倍速いです。
私はよく知らない NoSQL database, そこで私は、なぜリレーショナル データベースよりもパフォーマンスが優れているのか疑問に思ったのです。
複数のサーバーに分散するため、より拡張性が高くなります。 したがって、分散キャッシュに 5、10、15、20 のサーバーを含めることができるのと同じように、 NoSQL database。 SQL 用に 20 台のサーバーを使用することはできません。 アクティブ/パッシブまたはアクティブ/アクティブの場合は、おそらく 2 つを持つことができますが、それだけです。 ご存知のように、実際にはスケールすることはできません。 したがって、これはスケーラビリティ上の理由によるものです。
つまり、それは VM であるか、現在ではコンテナーが管理にますます普及しており、これはオンプレミスまたはクラウドのいずれかの環境にある可能性があります。
分散キャッシュの一般的な使用法
したがって、この図 (図-1) を見て、キャッシュを使用する必要があることがわかっていただければ幸いです。 それで、これで納得したとしましょう。 次に来る質問は、どうやって使用するかということです。 どこで使うんですか？ したがって、キャッシュを使用する一般的な場所は XNUMX つあります。
アプリのデータキャッシュ
XNUMX つ目は、これまで話してきたアプリケーション データであり、まさにこの図でした。 ここでデータをキャッシュするので、データベースにアクセスする必要がなくなります。 唯一留意すべきことは、 アプリケーションデータのキャッシュ つまり、データは 10 つの場所に存在することになります。 15 つはキャッシュ、もう XNUMX つはデータベースです。 データが XNUMX つの場所に存在する場合、何が問題となるでしょうか? 同期。 したがって、これは非常に大きな問題であるため、ほとんどの人は読み取り専用データ以外の目的でキャッシュを使用することを恐れています。 一般の人に尋ねると、キャッシュの使用を考えたことはありますか、またはキャッシュを実行していますか? 場合によっては、これらのハッシュ テーブルやメモリ ストアにハッシュ テーブルを構築し、読み取り専用データのみを配置することがあります。 アプリケーション全体、または非常に快適な時間枠内で決して変更されないデータ。 そうですね、読み取り専用データまたは参照データはデータ全体の XNUMX ～ XNUMX % にすぎません。 したがって、確かに多くのメリットが得られますが、本当のメリットはすべてのデータをキャッシュできるかどうかです。 つまり、本当に対処できる必要があるということです…
優れた分散キャッシュは同期を処理する必要があります。 したがって、キャッシュが常に最新であることを保証する必要があります。 そのため、キャッシュから読み取っているものはすべてそのデータの最新コピーであるというキャッシュ内の確信が得られます。
また、自信がない場合は、読み取り専用データに制限されるため、キャッシュの価値が最小限に抑えられるか減少します。
ASP.NET固有のキャッシュ
さて、２つ目のメリットは、 ASP.NET 固有のキャッシュ。 ASPには参加しない.NET Core 今回はそれについて簡単に触れておきます。 ただし、ASP.NET キャッシュでは、これを行う場所が XNUMX か所あり、現在は少なくとも XNUMX か所です。 MVC フレームワークを使用している場合はビュー ステートはありませんが、すべての ASP.NET アプリケーションにはセッションがあり、セッションはどこかに保存する必要があります。 既定では、これらはメモリ内 (インプロセス)、つまり ASP.NET アプリケーションまたは SQL サーバーのワーカー プロセス内に保存されます。 状態サーバーはクラウドでは利用できず、オンプレミスのみであり、それらすべてに問題があります。 スケーラビリティに問題があるものもあります。 実際には、どれもスケーラビリティの問題を抱えています。 一部にはパフォーマンスの問題もあります。 SQL データベースと同様に、パフォーマンスの問題もあります。
したがって、分散キャッシュの非常に優れた使用例は、それらのセッションをキャッシュに置くことです。 ご存知のとおり、これらのセッションは保存されます。SQL に保存すると、BLOB として保存されます。 また、リレーショナル データベースは BLOB ストレージ用に設計されていません。 しかし、 NoSQL またはキー値ストアの場合、値は BLOB です。 したがって、分散キャッシュに非常にうまく適合します。 もちろん、問題も解決する必要があります。災害復旧や負荷分散、地理的負荷分散のために複数のデータベースや複数のデータセンターを利用する人が増えています。 したがって、その問題も解決する必要があります。
ビュー ステートは ASP.NET には存在しませんが、以前の場合は ASP.NET 5 だと思います。ASP.NET 4 を使用している場合は、ビュー ステートまたは MVC 以前のビュー ステートは存在していました。 これは、当時ずっと開発されてきた ASP.NET アプリケーションの大部分に今でも存在しています。
ビュー ステートが何なのか知らない人のために説明すると、ビュー ステートは、Web サーバーによってブラウザに送信され、ポストバックが発生したときにのみ戻ってくる暗号化された文字列です。 したがって、この文字列は数百キロバイトになる可能性があり、ブラウザに送信され、ブラウザに保存されてから戻ってきます。 これに、アプリケーションが処理しなければならない数百万のトランザクションを掛けると、XNUMX つの問題があります。XNUMX つは、安価な帯域幅ではない大量の帯域幅を消費すること、帯域幅の料金を支払わなければならないことです。 次に、重いペイロードが移動するため、応答時間が遅くなります。 したがって、それをサーバーにキャッシュし、小さなキーを送信するだけで、次回戻ってきたときにビューステートがキャッシュからフェッチされてページに提供されるという理想的なケースです。 繰り返しますが、ビューステートは MVC フレームワークを使用していない場合にのみ問題となり、ASP には存在しません。.NET Core ASPだから.NET Core MVCです。
ASP.NET 出力キャッシュも ASP の一部です.NET framework、ASP にはありません.NET Core ここでページ出力の大部分がキャッシュされます。 では、次のリクエストでページが変更されない場合、なぜ再度リクエストを実行するのでしょうか? そのため、ASP.NET はページをキャッシュするため、次回同じパラメーター、同じすべてを含むリクエストが来たときに、最後の実行の出力がページに提供されます。
そのため、そのフレームワークはすでに存在しており、そのフレームワークに分散キャッシュを使用するのは本当に良いことです。そうすれば、マルチサーバー環境では、フレームワークがキャッシュされるとすぐにすべてのサーバーで利用できるようになります。 ASP.NET Core キャッシュ用のセッションのみがあり、ビューステートや出力キャッシュはありません。 ただし、応答キャッシュと呼ばれるものもあります。 それで、ASP.NET Core 現在では、コンテンツのキャッシュがサーバーの外部で行われる Web アプリケーション全体である程度標準化されています。 したがって、これもキャッシュの候補となります。 それで、ASP.NET Core これは応答キャッシュ ミドルウェアの概念です。 したがって、使用できる組み込みミドルウェアがあり、サードパーティのミドルウェアを実行することもできます。 好き NCache すぐに提供する予定です。
とにかく、ASP.NET キャッシュに関しては、このデータをもうキャッシュに保存しないということを念頭に置くことが重要です。 したがって、データが 5,000 か所に存在するアプリケーション データとは異なり、現在ではデータは XNUMX か所にのみ存在し、それがキャッシュであり、メモリ内キャッシュです。 では、インメモリ ストアが唯一のストアである場合、何が問題になる可能性があるでしょうか? はい。 つまり、その箱が落ちたら大変だということです。 なぜなら、記憶は揮発性だからです。 それは持続していません。 したがって、これに対処する方法は、もちろんレプリケーションを行うことです。 そのデータを複数のサーバーに置くこと。 しかし、ここでも XNUMX つのまったく異なる問題を解決する必要があります。 優れた分散キャッシュは、インテリジェントなレプリケーションを実行する必要があります。 たとえば、ASP.NET セッションを自信を持って保存する場合です。 そうでなければ何が起こるでしょうか？ 話は戻りますが、航空会社です。 私はちょうどそのウェブサイトに行ったところです。 XNUMXドル分のチケットを買うつもりです。 フライト検索をすべて行い、あらゆる種類の組み合わせを実行し、これから…支払い情報を入力して送信しようとしているのに、突然、スタートアップ ページなどに戻ってきました。セッションが終了したためです。失った。 なぜなら、送信を押すと Web サーバーに移動し、その Web サーバーが存在せず、クラッシュしてセッションが失われたからです。 したがって、決して良い写真ではありません。
イベントを通じた実行時データの共有
XNUMX 番目の使用例は、 ランタイムデータ共有 イベントを通じて。 これは多くの人が気づいていないことですが、分散キャッシュは環境内に導入すると、非常に強力なプラットフォームとなり、複数のアプリケーション間でデータを共有することがますます普及しています。 Pub / Sub モデルまたはその他のイベント駆動型のデータ共有。
たとえば、データを共有する必要があるアプリケーションが複数ある場合があります。 XNUMX つのアプリケーションが何かを生成し、それをキャッシュに置き、いくつかのイベントを起動すると、そのイベントのサブスクライバーが存在します。 したがって、他のアプリケーション インスタンスや他のアプリケーションが存在し、多くの場合、アプリケーション内で何らかのワークフローが発生します。 最初に何かが行われ、次にそれに基づいて別の何かが行われます。 そして、その場合、これらのイベントのサブスクライバーが存在します。 それらのアプリケーションには通知が送信されます。
今この写真を思い出してください（図1） ここ。 これをアプリケーションとデータベース間のキャッシュとは見なさないでください。 これをメッセージ バスのようなものと考えてください。これらのアプリケーションはすべてメッセージ バスに接続されています。 このサーバーの XNUMX つのアプリケーションはデータをキャッシュに置き、イベントを発生させます。 これらのサーバーの一部にある他のアプリケーションは通知を受け取る可能性があり、すぐにデータを消費します。 非常に強力な方法です。
メッセージキューを使用する人もいます。 多くの場合、メッセージ キューには明確な目的があります。 分散キャッシュはそれらを完全に置き換えるものではなく、ケースのサブセットです。 すべてのデータ共有が同じデータセンター内にある場合、あまり分散された環境ではなく、トラフィックの多い環境になります。 メッセージ キューは、分散キャッシュとは異なり、スケーラブルではありません。 なぜなら、メッセージキューにはこのようなクラスターが存在しないからです。 これ以上追加することはできません。 したがって、何百万ものトランザクションが発生し、その一部にメッセージ情報も含まれている場合、メッセージ キューはその負荷を処理できませんが、キャッシュは処理できます。
したがって、実行時のデータ共有は非常に強力な方法なので、それについて触れていきます。 繰り返しになりますが、実行時データ共有では、データは通常キャッシュ内にのみ存在します。 ただし、データベースには別の形式が存在する可能性があります。 なぜなら、それはデータベースから読み取られ、他の形式で変換され、共有のためにキャッシュに置かれたからです。
したがって、一部の機能はすべてのキャッシュに共通です。 一部はただ NCache .NET 側以外のすべて NCache .NET 側の は .NET 独自の機能ではありません。 なぜなら、Java 側とすべての Java キャッシュで同じ機能が見られるからです。 つまり、Java は .NET よりも長い間サーバー側テクノロジとして使われてきたため、Java ははるかに先進的、またははるかに成熟した市場となります。 ご覧のとおり、Java 側です。 .NET 側では、すべてではなく、一部のキャッシュに表示されます。 例えば、 AppFabric、無かったと思います。 Redis 全部ではなく一部が含まれています。 NCache Java キャッシュのような本格的なものがあります。
以上が XNUMX つのユースケースです。 それぞれについて詳しく説明する前に、これに関して何か質問はありますか?
実践的なデモ
これらについて説明する前に、まずキャッシュがどのようなものかを説明しましょう。 もちろん使うつもりです NCache 例として挙げていますが、目的は、キャッシュが実際にどのようなものかを感じてもらうことです。 たとえば、Azure には 1 つの VM があります。 彼らは走っています。 Demo2 と Demon2 は私のキャッシュ サーバー VM です。 そこで、XNUMX ノードのキャッシュ クラスターを作成します。
デモクライアントは私のアプリケーションサーバーです。 つまり、キャッシュ クライアント VM です。
クラスター化キャッシュの作成
ここではデモ クライアント VM にログインしています。 先に進み、クラスター化キャッシュを作成します。 の場合には NCache, というツールを使います。 NCache マネージャー、これはグラフィカル ツールです。 ここに来て、まずキャッシュがまだ存在していないことを確認させてください。 わかりました、そうではありません。わかりました。ここに来て、新しいクラスター化キャッシュを作成すると言います。
の場合 NCache すべてのキャッシュには名前が付けられます。 したがって、私のキャッシュは次のように呼ばれます デモキャッシュ。 すべてデフォルトのままにしておきます。 この詳細については説明しません。 そのままにしておきます…重要な部分だけについて話します。
最初に選択するのは、いわゆる トポロジのキャッシュ NCache ここで、パーティション分割について質問した人がいます。 データは本当に分散しているのか、それともすべてのサーバーに同じデータが存在するのか。 したがって、パーティション レプリカは、次のようなトポロジです。 NCache あなたにあげる。
たとえば、ここからはすぐに飛んで、そのトポロジーが何であるかについて簡単に説明します。 つまり、パーティション レプリカ トポロジです。つまり、これはパーティション化されたトポロジであり、これがパーティション レプリカです。
パーティショニングでは、すべてのサーバーにデータの 1n 分の XNUMX が含まれます。 それで、もしあなたが持っているなら、たとえば、 NCache、クラスター化キャッシュを構築すると、500 個のバケットが作成されます。 したがって、XNUMX つのサーバー クラスターがある場合、各サーバーは XNUMX になります。XNUMX つのサーバーがある場合、各サーバーは XNUMX/XNUMX になります。
したがって、これらのバケットは本質的にはハッシュ テーブル バケットと同じです。 すべてのバケットにはキー値の範囲が割り当てられます。 したがって、キーをハッシュ値に変換するハッシュ マップ関数があり、キーに基づいて分類されるバケットに分類されます。 したがって、パーティション化されたレプリカには、各サーバー上に XNUMX つのパーティションがあります。 たとえば、あなたがここに来るとしたら。 ここに XNUMX つのサーバー クラスターがあるとします。そのため、XNUMX つのパーティションとすべてのパーティションにバックアップまたはレプリカが別のサーバーにあるとします。
の場合 NCache レプリカはアクティブではありません。 受動的です。 したがって、パーティションのみがレプリカと通信します。 アプリケーションはパーティションと通信します。 したがって、すべてのキャッシュ クライアント、すべてのアプリケーション サーバーがすべてのキャッシュ サーバーに接続しているとします。 接続すると、すべてのクラスターのメンバーシップ情報が取得されます。 分布マップはそのバケット マップです。 それでは、各バケットがどこにあるかを示すバケット マップを取得します。 それに基づいて、項目番号 2 を追加する必要がある場合は、サーバー 2 に移動する必要があることがわかります。なぜなら、そこには項目番号 3 のキーがあるはずのパーティション XNUMX が存在するからです。そのサーバーでそれができるのです。
そして、サーバーがダウンした場合、たとえばパーティション 3 がダウンすると、レプリカ 3 がすぐにアクティブになります。 これでパーティションになります。 レプリカからパーティションに変換されます。 なぜなら、分からないから、続けたいからです。 キャッシュは実行する必要があり、アプリケーションは続行する必要があります。 高可用性ですね。 そして、このパーティション XNUMX は、サーバーが XNUMX つしかないことに気づき、これら XNUMX つのパーティションに自分自身をマージして、ある種の存在を消し去る必要があります。 したがって、他の XNUMX つのパーティションに自分自身をマージし、それが完了すると、パーティション XNUMX のレプリカがここに作成されます。
もう一度、そのトポロジが何を意味するのか概要を説明します。これは、サーバーを追加するにつれてより多くのストレージを確保するために分散がどのように行われるかです。また、これは、すべてのデータが XNUMX つのサーバーに存在するようにレプリケーションが行われる方法でもあります。 。 したがって、サーバーがダウンしてもデータが失われることはありません。
繰り返しになりますが、高可用性の理論では、XNUMX つのサーバーが同時にダウンすることはないとされています。 XNUMX 台のサーバーが同時にダウンする可能性は、XNUMX 台のサーバーがダウンする場合に比べて天文学的に低くなります。 もちろん、先ほども述べたように、XNUMX つのサーバーが同じ電源に接続されている場合、その電源がダウンすると、すべてが冗長化されていると想定されます。 そうすれば、XNUMX つのことが同時に失敗することはなくなります。 したがって、XNUMX 枚あれば十分です。
戻りましょう。 つまり、それがパーティションのレプリカでした。 次に、非同期レプリケーションを選択します。
したがって、XNUMX つのモードがあります。 ほとんどの分散キャッシュは、結果整合性と呼ばれるこれを実行します。 つまり、分散のため、すぐに同期を行う必要がある場合、すべてが遅くなります。 しかし、余裕のあるほとんどのデータはキューに入れられ、非同期更新されます。 したがって、ここでは非同期がデフォルトとして使用されます。
デモ クライアントを選択するか、デモ 1 が最初のサーバーになります。 2 番目のサーバーとしてデモ XNUMX を選択します。
ここに来ます。デフォルトをそのまま使用します。
各サーバーが使用するメモリの量を指定します。
もちろん、あなたの場合はさらに多くなります。 したがって、各ボックスに 16 GB のメモリがある場合、一部をパーティションに割り当て、一部をレプリカに割り当てる必要があるとします。 したがって、オペレーティング システムやその他のプロセス用に 2 ～ 3 ギガを残しておく必要があり、約 13 ギガが残っているとします。 つまり、7.5 または 6.5 ギガで、パーティションに XNUMX つ、レプリカに XNUMX つになります。 また、そのサイズを指定するのは、キャッシュがこれを超えて消費しないようにするためです。 これはメモリ内ストアであるため、メモリは常に制限されており、そのボックス上で他のアプリケーションが実行されている可能性があるためです。 したがって、キャッシュが使用するメモリ量と、キャッシュがそのメモリを使用した後のメモリ量を制限したいとします。
それでは、次のページになります。 そのメモリをすべて使い果たしたとしましょう。 つまり、キャッシュがいっぱいになりました。 したがって、起こり得ることは XNUMX つだけです。 XNUMX つ目は、古いデータまたはその他のデータの一部を削除するか、XNUMX つ目は新しい挿入を拒否することです。 したがって、この XNUMX つを選択する必要があります。 もちろん、キャパシティ プランニングを行う必要があります。データ、つまりアプリケーション データの場合は、いつでもデータベースからリロードできるため、削除しても問題ありません。 セッションを削除するのは問題ありません。 したがって、これらのセッションが決して排除されない方法でキャパシティ プランニングを行う必要があります。 これで、セッション用のメモリを常に確保できる十分なメモリ、RAM、および十分なサーバーが確保されました。 また、テーマを削除するのではなく、セッションを期限切れにしたいと考えています。 エビクトとは、セッションの有効期限がまだ切れていないがメモリが残っていないため、強制的にエビクトすることを意味します。 次の場合の有効期限 NCache これは、セッションが非アクティブな状態がたとえば 20 分間のみ有効であると指定したことを意味します。 その後、セッションはクリーンアップされます。 つまり、期限切れです。 したがって、有効期限は問題ありませんが、エビクションはセッションに対して行うべきではなく、アプリケーション データに対して行っても問題ありません。
それで、次の場合にどうするか NCache、セッションのキャッシュを作成し、アプリケーション データのキャッシュを作成します。 つまり、このようにして XNUMX つを分離します。 したがって、このキャッシュを作成したとしましょう。 つまり、XNUMX ノード キャッシュです。 先に進み、デモクライアントである私のボックスであるクライアントノードを追加し、キャッシュを開始するだけです。
ストレスのシミュレーションとキャッシュ統計の監視
ご覧のとおり、非常に簡単です。 これは一種の Explorer スタイルのインターフェイスです。 XNUMX か所からマルチサーバー キャッシュを作成し、管理し、監視することができます。それが完了すると、何が起こるかというと、これが完了すると、いくつかの PerfMon カウンターが表示され、次のようになります。付属のストレス テスト ツールと呼ばれるこのツールを実行します NCacheこれにより、アプリケーションの使用状況を非常に迅速にシミュレートできます。
それで、先ほどそれを実行し始めたとしましょう… つまり、サーバーごとに約 500 ～ 800 のトランザクションが実行されています。 つまり、約 2 倍、つまり負荷になります。 負荷を増やしたい。 そこで、ストレス テスト ツールをもう XNUMX つ追加したいと思います。 ほぼ全員が自分の環境でキャッシュがどのように機能するかを確認したいと考えているため、当社の顧客はこれを頻繁に使用しています。 ご存知のとおり、私たちはすべてのベンチマークを公開しており、すべてのものを持っていますが、彼らはそれを自分たちの環境で確認したいと考えています。 したがって、プログラミングやアプリケーションを使用する代わりに、非常に迅速にシミュレーションを行うことができます。 それで、それらを XNUMX つ実行したところ、負荷が増加したとします。 したがって、これら XNUMX つのサーバーが最大になるまで、これらをさらに追加し続けることができます。 そこでスケーラビリティが重要になります。
これら XNUMX つのサーバーは現在、非常に高速に実行されています。 しかし、負荷を増やすと、ある時点から負荷が最大になり、これがデータベースに起こることです。 唯一の違いは、ここに来て別のノードを追加できることです。 つまり、XNUMX 番目の VM がある場合は、ここに来てそれを追加すると、すぐに負荷が分散されます。そして、最初に示した図がこの図です。 XNUMX つのサーバーが限界に達したため、XNUMX つ目のサーバーを追加したいと考えています。 したがって、別の VM を取得して追加するだけで、XNUMX つのサーバーになり、 NCache すべてを自動的に再調整します。パーティションを再分割します。 redisバケットマップをトリビュートします。 つまり、実行時に XNUMX 番目のサーバーが追加されます。 そのため、突然容量の問題が発生しなくなります。
はい、それで、あなたがすることは、 NCache サーバーソフトウェア、これらすべての VM 上で。 クラウドの場合、通常、インスタンスを作成する事前構成された VM イメージがあるため、新しい VM を起動するだけです。 NCache ソフトウェアが実行されている場合は、それをこのクラスターに追加するだけです。
しかし、ここでも重要な点は、一度最大状態に達すると追い詰められるデータベースとは異なるということです。 職業はなんですか？ そうですね、もっと高いものを買いたいです。 それでは、別のボックスを購入し、このボックスを降ろさなければなりません。それは悪夢です。 ここでは、別のボックスを追加するだけです。
使い方 NCache ASP.NETセッションを使用した場合
ということで、今度はそっちに行ってみます。 これで、キャッシュがどのようなものかを理解できました。 さて、次のことがわかります…の場合 NCache、すべてのキャッシュに名前が付けられます。 したがって、キャッシュの名前がわかっていれば、そのキャッシュに接続するだけです。 では、セッションのキャッシュにどのように接続するのでしょうか? それが一番簡単です。 繰り返しになりますが、ほとんどのお客様が最初に行うことは、 NCache 彼らはそれをセッションに使用します。 なぜ？ プログラミングが必要ないからです。 セッションの場合に確認する必要がある唯一のことは、セッションに入れるオブジェクトがすべてシリアル化可能であることです。 すでにセッションを SQL に保存している場合は、それをすでに確認しています。 セッションを In-Proc モードで保存している場合は、それが保証されていない可能性があります。 つまり、それがあなたがしなければならない唯一のテストです。 しかし、その後は非常に簡単です。
ここではほんの小さなサンプルをお見せします。 たとえば、ここにはセッション ストア プロバイダー サンプルと呼ばれるサンプルがあります。 つまり、ASP.NET アプリケーションがあります。 web.config に移動します。 私がこのアプリケーション サーバー ボックス上にいると仮定してください。 ここでその写真を見たら。 実際のところ、ここに戻りましょう。 ここにキャッシュ サーバーがありますが、私のアプリケーションはこのボックス上で実行されています。 それで、このボックス上に XNUMX つのサーバー クラスターを作成し、これにクライアントを追加しました。 さて、そのクライアントで何が起こったかというと、次のような場合です。 NCache、おっと、ここではありません。 さて、その場合は NCache 実際には、config フォルダー内に client.ncconf が作成されるため、エントリーが作成されます。 したがって、アプリケーションはどのサーバーに接続するかを知ることができます。
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<ncache-server connection-retries="3" retry-connection-delay="0" retry-interval="1" command-retries="3" command-retry-interval="0.1" client-request-timeout="90" connection-timeout="5" port="9800" local-server-ip="10.2.0.5" enable-keep-alive="False" keep-alive-interval="0"/>
<cache id="demoCache" client-cache-id="clientCache" client-cache-syncmode="optimistic" skip-client-cache-if-unavailable="True" reconnect-client-cache-interval="10" default-readthru-provider="" default-writethru-provider="" load-balance="False" enable-client-logs="False" log-level="error">
<server name="10.2.0.5"/>
<server name="10.2.0.6"/>
</cache>
</configuration>繰り返しますが、これらは単なる初期サーバーのリストです。 それは最終的なリストではありません。 なぜ？ なぜなら、高可用性環境の場合、実行時に 0.8 番目のサーバーを追加したらどうなるでしょうか? それはこのリストにはありませんよね？ つまり、それがドット XNUMX (.XNUMX) だったとします。 したがって、これは初期のリストにすぎません。 アプリケーションはそれらのいずれかを認識すると、それに接続します。 接続すると、アプリケーションは最初にクラスター メンバーシップ情報を受け取ります。また、そのクラスター メンバーシップが変更され、別のサーバーが追加されるたびに、更新されたクラスター メンバーシップがクライアントに送信され、すべてがメモリ内に保持されます。 それはすべてアプリケーションから隠されています。 それはすべて管理されています NCache クライアント部分ですが、それがアプリケーションがキャッシュに接続する方法を知る方法です。
したがって、セッションの場合は、ここに来るだけです。 したがって、セッションでは、最初にアセンブリを追加する必要があります。
...
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
<compilers>
<compiler language="c#" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".cs" compilerOptions="/d:DEBUG;TRACE" />
</compilers>
<assemblies>
<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.6.0.0, Culture=neutral, PublicKeyToken=CFF5926ED6A53769" /></assemblies>
</compilation>
...の場合 NCache あなたはただ…このアセンブリは セッション状態プロバイダー インターフェイス それはASPの一部です.NET framework そしてそうすることで NCache サードパーティのカスタムストレージになります。 したがって、これは単なるコピーアンドペーストであり、その後、セッション状態タグが実際に変更されます。 したがって、ここで行うことは、モードがカスタムであることを確認することです。
...
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20">
<providers>
<add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="WebF1" cacheName="democache" writeExceptionsToEventLog="false" enableLogs="false" />
</providers>
</sessionState>
...つまり、モードには、In-Proc、状態サーバー、SQL、そしてカスタムがあります。 つまり、XNUMX つのモードがあります。 したがって、モードがカスタムの場合は、タイムアウトが希望するセッション タイムアウトであることも確認してから、プロバイダーの詳細をコピーする必要があります。 つまり、次の場合、 NCache それはこの行であり、変更する必要があるのはキャッシュ名だけです。 たとえば、ここではキャッシュ名はすでに変更されています。 あなたがその変化を起こす、それだけです。 そして、その変更を加えるとすぐに、ASP.NET はワーカー プロセスを再起動し、すべてのセッションが XNUMX つのオブジェクトとしてキャッシュに保存され、パフォーマンスが大幅に向上することがすぐにわかります。 なぜなら、今は SQL に保存していないからです。
したがって、次のような分散キャッシュの恩恵を最も早く受けられる方法は次のとおりです。 NCache それは単にセッションのために置くことです。 なぜなら、アプリケーション データ キャッシュ用のオブジェクトにはさらに多くの作業があるからです。 もちろん、あなたはあれをあれにしたいと考えています。それが私がこれから説明することですが、最初の使用例は ASP.NET 仕様です。
これに関して何か質問はありますか？ たとえば、当社の一部のハイエンド顧客は、アプリケーション層に約 50 ～ 100 台のサーバーを所有していることがわかりました。 そのために、通常は 1 対 5 の比率を維持するとします。 したがって、サーバー 100 台の構成の場合、キャッシュ サーバーは 20 台になります。 50 を超えると、非常に少数です。負荷分散された環境で 50 を超えるサーバーを配置するには、実際には大量のトラフィックが必要です。 ほとんどの顧客は 4 ～ 12 台のサーバーを使用しています。 また、先ほども述べたように、アプリケーションの性質に応じて 4 対 1 または 5 対 1 の比率にすることをお勧めします。 場合によっては 5 対 1 を超えることもありますが、これは平均的な使用例のようなものです。 したがって、5 対 1 でアプリケーション層に 12 台のサーバーがある場合、XNUMX 台のサーバー キャッシュ層が存在します。 そうですね、それほど多くのつながりはありません。
理論的にはそうです。 サーバーをさらに追加し続けると、多くの冗長性が生じます。 しかし、私たちが話しているユースケースでは、それは当てはまりません。 ビッグ データの処理には 50 台または 100 台のサーバーが使用される可能性がありますが、その場合にはクライアントは存在せず、ビッグ データの処理はサーバーのみで行われます。 なぜなら、すべてがサーバー自体上で実行されているからです。 ただし、Web アプリケーションまたは Web サービス アプリケーションの場合は、いわゆる e コマース、つまりオンライン ビジネス モデルです。 つまり、それはかなりのことです。 ほとんどの場合、サーバーの数は 20 未満であり、20 を超えるサーバーを持っている顧客はごく一部であり、50 を超えるサーバーは非常に少数であると想定できると思います。
はい、確かに。 たとえば、私がここに来るとしたら、私はただ…もしここに来るとしたら。 私は使用していません NuGetパッケージ ここだけど、ここに来て NuGet に行って、ここで言うこともできます NCacheたとえば、次の結果が得られます。 NCache SDK、 NCache エンタープライズおよびプロフェッショナル向けのセッション サービス、オープンソース、NHibernate もあります。 つまり、NuGet が大量にあります。 したがって、典型的な…セッションには、このセッション NuGet パッケージを含めるだけです。 アプリケーション データのキャッシュについては、SDK を含めるだけで、これには必要なものがすべて含まれます。
アプリデータキャッシングの概要（API）
そう、 アプリケーションデータのキャッシュ プログラムする必要があるものです。 つまり、キャッシュはデータベースとして認識されます。 キャッシュに接続します。 の場合には NCache このメソッドは キャッシュの初期化.
キャッシュ接続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");他のキャッシュには他のメソッドがある可能性があり、次の場合に備えてキャッシュ名があります。 NCache 先ほど説明したように、これによりキャッシュ ハンドルが得られます。
それでは、アプリケーションに入ってみましょう。 繰り返しになりますが、… これは単純なコンソール アプリケーションです。 NuGet パッケージを含めていた場合、これはすべて自動的に行われます。 いくつか参考にしてください NCache アセンブリ。 したがって、参照する必要があるアセンブリは XNUMX つだけです。 NCache。ランタイム & NCache。ウェブ. NCache。ウェブ 次の場合の実際のパブリック API です。 NCache。 次に、アプリケーションに名前空間を含めます。 それで、あなたは NCache。ランタイム & NCache.Web.キャッシング 名前空間として。
次に、アプリケーションの開始時に、たとえば App.config からキャッシュ名を取得し、キャッシュを初期化してキャッシュ ハンドルを取得します。 ここで、アプリケーション内のあらゆる場所で使用する必要があるキャッシュ ハンドルを示します。
次に、そのキャッシュ ハンドルを見てみましょう。 それで、あなたはできます キャッシュ.追加、キーを指定します。 キーは先ほども述べたように、通常は文字列です。 オブジェクトは実際のオブジェクトです。 それは任意の .NET オブジェクトです。 NCache 実際にシリアル化してクラスターに送信します。 つまり、これらすべてはクライアント側、つまりアプリケーション サーバーで行われます。
// Alachisoft (R) NCache Sample Code.
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Sample.Data;
using Alachisoft.NCache.Web.Caching;
using System;
using System.Configuration;
namespace Alachisoft.NCache.Samples
{
/// <summary>
/// Class that provides the functionality of the sample
/// </summary>
public class BasicOperations
{
private static ICache _cache;
/// <summary>
/// Executing this method will perform all the operations of the sample
/// </summary>
public static void Run()
{
// Initialize cache
InitializeCache();
// Create a simple customer object
Customer customer = CreateNewCustomer();
string key = GetKey(customer);
// Adding item synchronously
AddObjectToCache(key, customer);
// Get the object from cache
customer = GetObjectFromCache(key);
// Modify the object and update in cache
UpdateObjectInCache(key, customer);
// Remove the existing object from cache
RemoveObjectFromCache(key);
// Dispose the cache once done
_cache.Dispose();
}
/// <summary>
/// This method initializes the cache
/// </summary>
private static void InitializeCache()
{
string cache = ConfigurationManager.AppSettings["CacheID"];
if (String.IsNullOrEmpty(cache))
{
Console.WriteLine("The CacheID cannot be null or empty.");
return;
}
// Initialize an instance of the cache to begin performing operations:
_cache = NCache.Web.Caching.NCache.InitializeCache(cache);
// Print output on console
Console.WriteLine(string.Format("\nCache '{0}' is initialized.", cache));
}
/// <summary>
/// This method adds object in the cache using synchronous api
/// </summary>
/// <param name="key"> String key to be added in cache </param>
/// <param name="customer"> Instance of Customer that will be added to cache </param>
private static void AddObjectToCache(string key, Customer customer)
{
TimeSpan expirationInterval = new TimeSpan(0, 1, 0);
Expiration expiration = new Expiration(ExpirationType.Absolute);
expiration.ExpireAfter = expirationInterval;
//Populating cache item
CacheItem item = new CacheItem(customer);
item.Expiration = expiration;
// Adding cacheitem to cache with an absolute expiration of 1 minute
_cache.Add(key, item);
// Print output on console
Console.WriteLine("\nObject is added to cache.");
}そして、それを実行したら、次のこともできます。 _cache.Get そして同じオブジェクトを返します。 API の観点から見ると、次のようになります。 キャッシュ.Get、Get、Contains、Add、Insert、Remove XNUMX つすべてに非同期バージョンがあります。これは基本的に、アプリケーションがキャッシュの更新を待たず、制御がすぐに戻ることを意味します。 ただし、キーは通常文字列です。 だいたいこんな感じのものです。 タイプ名があります。 の場合には NCache 場合によります。 と呼ばれるこの機能を使用した場合は、 クライアントキャッシュ。 それで、私はそれに飛び込むつもりです。
クライアントキャッシュ（キャッシュの近く）
したがって、デフォルトでは、次のことを行うたびに次のように仮定します。 キャッシュ.取得, 実際にはキャッシュ層に行きます。 しかし、ほとんどの人が気づいていない興味深い点があります。それは、ASP.NET キャッシュ オブジェクトなどのインプロセス キャッシュを使用していて、次のようなものに移行することにした場合です。 NCache それはパフォーマンスとスケーラビリティを向上させると述べたからです。 これは一種のスケーラビリティの向上ですが、突然パフォーマンスが実際に低下することになります。多くのお客様から電話があり、「プラグインしてからアプリケーションの速度が実際に遅くなった」と言われます。 NCache。 それで、なぜそれが本当に必要なのでしょうか。 それは本当によくないことです、それはご存知のとおりです。 したがって、インプロセス キャッシュを実行する場合、シリアル化はなく、アプリケーションとキャッシュの間のプロセス間通信は、同じボックス上であろうと別のボックス上であろうと、通常は行われないことを説明する必要があります。別箱ですね。 つまり、オブジェクトがオブジェクト形式でヒープ上に保持されると、超高速になります。 行ってリファレンスを取得するだけです。 あのパフォーマンスに匹敵するものはありません。 ただし、分散キャッシュに移行する理由は、その In-Proc モデルには多くの制限があるためです。 拡張することはできません。 データをどんどん追加することはできません。これは XNUMX つのプロセスのみであり、複数のプロセスがある場合、複製は同期されません。 他にも多くの問題があるため、分散キャッシュに移行することになりますが、その利点は失われます。 そこで、私たちがやったのは、クライアント キャッシュと呼ばれるものを思いついたということです。これは、Java 側ではニア キャッシュと呼ばれ、.NET 側ではニア キャッシュと呼ばれるようになり、それを持っているのはキャッシュだけです。
これが実際に行うことは、アプリケーション内に In-Proc ローカル キャッシュを作成することです。 したがって、そのオブジェクトはオブジェクト形式でヒープ上に保持されます。 したがって、スタンドアロンの In-Proc キャッシュ内で慣れているのと同じパフォーマンスが得られます。 唯一の違いは、このキャッシュがクラスター化されたキャッシュの一部であることを認識していることです。 したがって、ローカル コピーに保持されているものはすべて、キャッシュ層へのリンクを持っています。 これは、キャッシュ層に、このオブジェクトを持っているので、誰かがそのオブジェクトを変更したら通知してください、と伝えています。 したがって、もしあれば、このクライアントが別のクライアントに項目番号を持っていて、もちろんその項目番号 XNUMX もこのキャッシュ層にあるとします。 別のクライアントが来て、その項目番号 XNUMX を更新します。 キャッシュ層は、これらのクライアント キャッシュに項目番号 XNUMX があることを認識しているため、イベントを通じてそれを通知します。 の場合には NCache かなり早いイベントです。 これらは .NET イベントではなく、ソケット レベルの通信です。 したがって、クライアント キャッシュはすぐにそれ自体を更新します。 したがって、おそらくミリ秒の遅延について話しています。
そうすることで、得られる情報はすべて、またはほとんどの場合、正確であるという自信を得ることができます。 技術的には、古いコピーである可能性は低いですが。 の場合には NCacheそれがあまりにも心配な場合は、何かをフェッチするたびに、いわゆる悲観的同期モードを使用できます。 NCache キャッシュ層を内部的にチェックして、最新のコピーがあるかどうかを確認します。 そうでない場合は、クライアント キャッシュのデータから取得します。そうでない場合は、キャッシュ層から取得します。 ただし、ほとんどの場合、その必要はありません。 ほとんどの場合、それだけのチャンスを賭けても大丈夫です。 これにより、インプロセス キャッシュのパフォーマンスが向上します。 しかし、繰り返しになりますが、アプリケーションはそのすべてが起こっていることを知りません。
の場合 NCache アプリケーションは知っています。 アプリケーションは、キャッシュ層と通信しているだけだと考えます。 通信しているキャッシュは XNUMX つだけです。 それは私のキャッシュなどと呼ばれます。 これはデモ キャッシュであり、デモ キャッシュには、次のような場合に構成を通じてクライアント キャッシュを接続できます。 NCache。 これに関して何か質問はありますか？
JCache (JSR 107) API
つまり、これが典型的なキャッシュの様子です。 このプログラミングを行うのは非常に簡単です。 Java 側で今何が起こっているのか。繰り返しになりますが、この点では Java のほうがはるかに進んでいることを私は賞賛し続けています。 これらには、JCache と呼ばれる完全な標準 API があります。 つまり、JCache API は非常に優れた機能です。これには、私が今説明した、またはこれから説明するすべての機能が含まれています。 したがって、JCache は、業界との互換性を保つためにすべての Java キャッシュを実装する必要がある標準です。
IDistributedCache API
.NET 側にはまだそのようなものはありません。 最近までプラグインできなかった ASP.NET キャッシュ オブジェクトがあります。 したがって、ASP.NET キャッシュにプログラムする場合はプラグインできません NCache その代わりに。 したがって、サードパーティのキャッシュを接続することはできません。 それは単なるスタンドアロンのキャッシュです。 .NET 4.0 では、.NET キャッシュが開始されましたが、実際には取得されませんでした。 現在ASP中.NET core 彼らは持っています i分散キャッシュ インターフェース。 これも、入力メソッドを取得するだけの非常に基本的なものです。
したがって、標準 API の問題は、優れたキャッシュが提供するすべての機能を利用できないことです。 本当に基本的な取得入力に限定されています。 ただし、繰り返しになりますが、ほとんどのお客様はとにかくキャッシュ層をカプセル化します。 つまり、たとえ彼らがすべてを作っていたとしても、 NCache 呼び出しの場合、アプリケーション全体は公開されません。 とにかく、API は次のようになります。
アプリのデータキャッシュ機能
ここで、重要な機能をいくつか見てみましょう。 したがって、ほとんどの場合は…先に進んでください。 単純な質問です。 挿入と追加に違いはありますか? はい、insert は追加または更新を意味します。 データがすでに存在する場合は更新し、存在しない場合は追加します。 データがすでに存在する場合、追加は失敗します。 そして、これもまた、私たちがこだわってきた ASP.NET キャッシュ API です。なぜなら、当時の標準にできるだけ近づきたいからです。 いいえ、そうではありません。 つまり、保管してあります。 ASP.NET キャッシュ オブジェクトはなくなりました。前述したように、現在は ASP にあるためです。.NET Core はもうありません。ASP.NET にはまだありますが、ASP.NET Core 違います。
絶対有効期限
したがって、最初に念頭に置く必要があるのは、先ほど説明したキャッシュを最新の状態に保つことです。 一番のテクニックは有効期限です。 有効期限は次のようになります。これに戻りましょう。 それで、それを言ってみましょう、私は…これが見えますか？ これが見えますか？ OK。 キーと値、または何らかのオブジェクトがあるとします。 これをキャッシュに追加したいので、有効期限を 1 分に指定します。 したがって、これはと呼ばれます 絶対有効期限.
public static void AddObjectToCache(string key, Customer customer)
{
DateTime expirationInterval = new DateTime();
expirationInterval.AddMinutes(1);
//Adding item with an absolute expiration of 1 minute
_cache.Add(key, customer, expirationInterval, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
Console.WriteLine("\nObject is added to cache");
}絶対有効期限とは、1 分が経過すると、何があっても期限切れになることを意味します。 これは、キャッシュに対して、これを XNUMX 分以上キャッシュするのは本当に不安だ、と言っていることを意味します。 なぜなら、私はこれを XNUMX 分間キャッシュに保持しても安全であると経験に基づいた推測をしているからです。
スライド式有効期限
一方、有効期限のスライドにはまったく異なる目的があります。 セッションなどをクリーンアップするためのものです。 これは、同期やキャッシュを最新の状態に保つこととは何の関係もありません。 つまり、絶対表現はほぼすべてのキャッシュに備わっているものです。 実はASPでも.NET Core IDistributed Cache Interface には絶対式があります。
キャッシュをデータベースと同期する
しかし、キャッシュを作成したり、キャッシュを最新の状態に保つ唯一の方法が式であることの何が問題なのでしょうか? このデータは変更されないと推測しているということです。 そうなったらどうなるでしょうか？ データを変更する他のアプリケーションやスクリプトが存在する場合はどうなるでしょうか。どの企業でも、通常はデータの更新元が複数の場所にあります。 したがって、データがどのくらいの頻度で更新されるかを予測できない場合、式は出発点にすぎません。 次の段階、つまりキャッシュとデータベースの同期に進む必要があります。 つまり、基本的に、次のような場合にキャッシュをデータベースと同期する必要があります。 NCache ADO.NET .NET の一部である SQL 依存関係と呼ばれるこの機能を使用します。
SQL の依存関係とは、本質的にはどのようなものなのかを説明しましょう。 つまり、SQL 依存関係の場合は、同じ cache.Add を実行します。 キーを取得し、値を取得する代わりに、実際のオブジェクトを配置する独自の構造であるキャッシュ項目を取得します。これで、SQL 依存関係、SQL サーバー依存関係と呼ばれるものを指定します。基本的に SQL ステートメントを作成するこの変数です。
private static void AddProductToCacheWithDependency(Product product)
{
// Any change to the resultset of the query will cause cache to invalidate the dependent data
string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.Id);
// Let's create SQL depdenency
CacheDependency sqlServerDependency = new SqlCacheDependency(_connectionString, queryText);
CacheItem cacheItem = new CacheItem(product);
cacheItem.Dependency = sqlServerDependency;
// Inserting Loaded product into cache with key: [item:1]
string cacheKey = GenerateCacheKey(product);
_cache.Add(cacheKey, cacheItem);
}このコードは、ここのクライアント ボックスで実行されています。
キャッシュサーバーと通信します。 これは、ADO.NET SQL 依存関係機能を使用してデータベースに接続するようにキャッシュ サーバーに指示します。 つまり、実際にはデータベースへの接続文字列が得られます。 したがって、アプリケーションはキャッシュに、このキャッシュされた項目のデータベースはこれです、データベース内の対応するデータを表す SQL ステートメントはこれです、と伝えます。
Entity Framework/Entity Framework コアの統合
良い質問。 Entity Framework の実装の場合、これを内部に実装しました。 Entity Framework でもキャッシュを使用する方法が 6 つあります。 EF Core の場合、新しいアーキテクチャではサードパーティのキャッシュをプラグインできるようになりましたが、EFXNUMX まではキャッシュをプラグインする方法がありませんでした。 したがって、とにかくこれらの API 呼び出しを行う必要があります。 したがって、エンティティのコレクションが返され、それらをキャッシュするときに SQL 依存関係を指定できるとします。 私の言っている意味が分かりましたか？
の場合 NCache あなたは言っています NCache これが私のSQLステートメントです。 NCache ADO .NET を使用してデータベースに接続し、ADO.NET SQL 依存関係機能を使用してそのデータセットを監視します。 それで、 NCache は SQL サーバーに、このデータセットが変更された場合は通知してくださいと指示しています。 その後、SQL サーバーはデータベース通知を次の宛先に送信します。 NCache なぜなら NCache データベースのクライアントではない場合、 NCache これで、このデータがデータベース内で変更されたことがわかりました。 つまり、EF があったとしても、それをバイパスしているようなもので、今では NCache このデータが変更されたことを知っています NCache には XNUMX つのオプションがあります。 XNUMX つは、そのアイテムをキャッシュから削除することができ、削除すると、次に誰かがそのアイテムを必要とするときに、キャッシュ内でそのアイテムが見つからなくなるため、データベースからアイテムを取得する必要があります。 つまり、ある意味では新鮮なものにするか、 NCache データベース自体からそのデータをリロードできますが、リードスルーと呼ばれる別の機能を使用しない限りそれは不可能です。これについては後で説明します。
したがって、SQL の依存関係により、基本的に、データがいつ変更されるかを予測できない場合は、単に通知することが保証されます。 NCache またはキャッシュを使用してデータベースを監視してください。
SQL の依存関係には、結合を含めることができないという制限があります。 つまり、単一のテーブルの問題です。 他にも監視できる方法があります。 たとえば、次の場合 NCache という機能があります カスタム依存関係、これがあなたのコードです。 NCache コードを呼び出して、データ ソースを監視してデータが変更されているかどうかを確認してくださいと指示します。 つまり、投票のようなものです。 それで、 NCache カスタム依存関係をポーリングするため、複雑な構造になる可能性があります。
ええ、その通りです。 実際、SQL 依存関係を実行すると、キャッシュはデータベースとそれほど頻繁に通信しません。なぜなら、それはイベントがあるため、データベースが通信を開始することだけだからです。 これはイベント駆動型のアーキテクチャです。 したがって、データベースはデータが変更されるたびにイベントを送信します。
実際、SQL サーバーには、データ セットを監視し、クライアントにデータベース通知を送信するこの機能があります。 それで、 NCache データベースクライアントになります。
したがって、XNUMX つのオプションは、そのアイテムをキャッシュから削除することでした。 もう XNUMX つは、単にリロードすることです。 さて、リロードとは、 NCache そのデータを取得する方法を知る方法が必要です。つまり、リードスルーと呼ばれる機能があり、コードを作成してキャッシュ サーバー (キャッシュ クラスター) に登録します。 そのコードがどのようなものかを簡単に説明します。
リードスルーキャッシュ
いいえ、実際には単なるカスタム コードです。 したがって、そのコード内で ORM 呼び出しを行うこともできます。 つまり、コードは次のようになります。 つまり、ここに IReadThruProvider インターフェイスがあります。
...
// Perform tasks like allocating resources or acquiring connections
public void Init(IDictionary parameters, string cacheId)
{
object connString = parameters["connstring"];
sqlDatasource = new SqlDatasource();
sqlDatasource.Connect(connString == null ? "" : connString.ToString());
}
// Perform tasks associated with freeing, releasing, or resetting resources.
public void Dispose()
{
sqlDatasource.DisConnect();
}
// Responsible for loading an object from the external data source.
public ProviderCacheItem LoadFromSource (string key)
{
ProviderCacheItem cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
cacheItem.ResyncOptions.ResyncOnExpiration = true;
// Resync provider name will be picked from default provider.
return cacheItem;
}
...つまり、IReadThruProvider インターフェイスがあります。 それにはXNUMXつの方法があります。 キャッシュの開始時にのみ呼び出される Init があります。 したがって、データソースに接続する必要があります。 最後にdisposeがあり、loadがあります。 したがって、ロードするとキーが与えられ、キャッシュ項目を返す必要があります。
したがって、コードはすでにデータ ソースに接続されているため、そのキーに基づいてコードはどこへ行くべきかを知る必要があります。 つまり、ORM を使用するかどうか、EF 呼び出しを行うか、NHibernate 呼び出しを行うか、ADO.NET 呼び出しを行うか、これがすべてのコードであり、それをロードします。たとえば、データベースからそのオブジェクトをロードすると、それを入力すると、有効期限やその他の必要なメタデータを入力して、それを返します NCache. NCache その後、それをアプリケーションに返す前にキャッシュします。
では、読み合わせの全体的な目的について…この読み合わせそのものについてお話したいと思います。 リードスルーは、キャッシュがデータベースからデータをロードできるようにする方法です。 つまり、実際には永続化コードの一部をキャッシュ層に移動していることになります。 また、複数のアプリケーションでキャッシュを共有したい場合は、リードスルー、ライトスルーのメカニズムがあれば最適です。 統合することで、アプリケーションを作成することになり、コードが少し減ります。 したがって、より多くの永続化コードがキャッシュ層に送られるため、コードが少なくなります。 それは XNUMX つの利点です。 ご存知のとおり、カプセル化と統合です。
リードスルーの XNUMX 番目の利点は、先ほどリロードについて説明したことです。 したがって、リロードは XNUMX つの場合に発生します。 XNUMX つはデータベース同期中、もう XNUMX つは有効期限切れ中です。 また、非常にトラフィックの多いアプリケーションを使用しており、たとえば、変更されるある種のルックアップ テーブルや価格テーブルがあり、そこに何千ものリクエストが送信される場合など、有効期限が切れるケースもよくあります。リロード機能を使用すると、データの有効期限が切れると、何千ものリクエストがデータベースに送信されます。 そして、それらはすべて同じオブジェクトをキャッシュにロードします。 結局のところ、これはデータベースへの大量のトラフィックに過ぎません。 これに数千のアイテムを掛けると、データベースに大量の不要なトラフィックが発生する可能性があります。
実際、私たちの顧客の XNUMX 人は、米国の花きビジネスに携わる非常にハイエンドの電子商取引顧客であり、その問題を抱えていました。 そこで、リロード機能を突然実装したところ、アイテムがキャッシュから削除されなくなるため、問題全体が解消されました。 したがって、古いコピーはある時点まで保持され、新しいコピーがその上に更新されます。 したがって、アプリケーションがデータベースにアクセスする必要はありません。 つまり、探索中でも新しいコピーが更新されるだけだからです。 たくさんあります… 以上が、この同期と組み合わせることができる既読スルーの XNUMX つの利点です。
ライトスルーキャッシュ
もう XNUMX つの側面はライトスルーです。これは、書き込み用であることを除き、リードスルーと同じように機能します。書き込みは追加、挿入、削除、または削除のいずれかで行うことができます。 繰り返しますが、Init があるのと同じように、Dispose があり、今では データソースへの書き込み。 そこには操作が何であるかが示されており、データも含まれているため、データベースを更新することができます。 したがって、ライトスルーとは、キャッシュを更新し、キャッシュがデータベースを更新することを意味します。
では、ライトスルーの利点は何でしょうか? まあ、利点のXNUMXつは既読スルーと同じです。 すべての永続性を統合します。 XNUMX 番目の利点は、後書きです。 なぜなら、データベースの更新はそれほど高速ではないため、データベースの更新が成功すると信頼できる場合は、キャッシュを更新するだけで、キャッシュによってデータベースが非同期的に更新されるようになります。 もちろん、何かが失敗した場合は通知を受け取ることができますが、先に進んで他の作業を行うことができるため、アプリケーションの更新パフォーマンスも向上します。 したがって、データベースの更新はすべてキューに入れられるため、完了するまで待つ必要がなくなりました。 これが後書き部分です。 そして、ライトビハインドキューは再び複数のサーバーに複製されます。 したがって、いずれかのサーバーがダウンしても、操作は失われません。 NCache.
しかし、それはあなたのコードです。 つまり NCache あなたのものを呼び出します。 つまり、これはすべてあなたのコードです。 それで、 NCache 電話がかかってくると、書き込みの意味や読み取りの意味がわかります。
したがって、リードスルー、ライトスルーは、有効期限および同期と組み合わせることができるもう XNUMX つの非常に強力な機能です。 したがって、キャッシュが常に最新の状態に保たれていることを確認してから、リードスルーとライトスルーを使用していることを確認する必要があります。 これを開始すると、大量のデータをキャッシュできるようになります。 そして今、そのキャッシュはデータベースのように見え始めています。 つまり、キーだけでは十分ではありません。 検索ができる必要があります。 よりインテリジェントな方法で情報を取得できる必要があります。 したがって、ここでキャッシュに対して SQL タイプのクエリを実行できるはずです。 たとえば、顧客のドット City がロンドンに等しい、選択された顧客のようなものです。 その基準に一致するすべての顧客オブジェクトのコレクションが返されます。 そして、キャッシュは、たとえば都市属性に基づいてそれらのオブジェクトにインデックスを付けます。 つまり、このようにして検索できるようになります。
したがって、これができない場合、アプリケーションはより複雑になります。なぜなら、キーでしか検索できず、データベースを使用して他の多くのことを実行することに慣れているためです。キャッシュを使って行います。
キャッシュには結合はありませんが、グループ化は可能です。 そして、そのような目的は、データを取得し、それをグループ化し、そのグループに基づいて、これらのグループ、サブグループ、タグ、名前タグに属するすべてのものを私に提供することができるという目的に役立ちます。 したがって、物事を論理的にグループ化するために実行できることは他にもあり、キャッシュしているデータ自体は結合を通じて取得できます。 ただ、キャッシュは検索ベース エンジンではありません。 したがって、結合データがある場合は、それをグループ化するだけです。
キャッシュの依存関係
今回はあまりにも多くのことを取り上げることができないため、もう一度特集があります。 それで、という機能があります キャッシュの依存関係 ちなみに、これは ASP.NET キャッシュ オブジェクトから取得されます。 NCache も実装されており、これにより… この項目がこの項目に依存することをキャッシュに伝えます。 このアイテムが更新または削除されると、このアイテムは自動的に削除されます。 したがって、これらの関係を作成することで、XNUMX 対多の関係を構築できます。たとえば、XNUMX つの側がなければ多の側が存在できない XNUMX 対多の関係があるとします。 それが顧客と注文だとしましょう。 したがって、顧客を削除する場合は、注文も削除する必要があります。 したがって、キャッシュにそれを処理させることができます。 同様に、オブジェクトのコレクションをキャッシュする場合、コレクション全体を XNUMX つのオブジェクトとしてキャッシュすることも、コレクションを個別に分割することもできます。 それらを分割する場合は、キャッシュの依存関係を実行する必要があります。 したがって、いずれかのオブジェクトが削除されると、そのコレクションは無効になります。
はい、それが私が話したいテーマです。私たちのウェブサイトに来てください。 早速お見せしましょう。 それで、それについては全体の話があります。 私が思うに、それは キャッシュ内のリレーショナル データの処理。 つまり、これは XNUMX 対多、XNUMX 対 XNUMX、多対多のすべてを対象とし、今話したすべてのコレクションを対象とします。 行ってそれを見てください。 時間がないので手短に終わらせていただきます。
そこで、私はキャッシュを使用する必要がある理由と、それをどのように使用し、キャッシュによるメリットを最大化するかについて主張してみました。 スキップします ランタイムデータ共有 部分的には、十分にカバーできたと思います。 当社の Web サイトにアクセスして、詳細を読むことができます。 クライアント キャッシュ、パーティショニングによる高可用性、その他すべてについて説明しました。
分散キャッシュの WAN レプリケーション
データセンターも複数あります。 データベースが複数のデータセンターを処理できることが期待されているのに、なぜキャッシュを使用しないのでしょう。 それで、もう一度、 NCache はこの機能を提供します。 Java 側にはこれを行うキャッシュがあります。 .NET側 NCache 唯一のものです。 したがって、アクティブ/パッシブまたはアクティブ/アクティブのデータセンターを使用でき、キャッシュが同期されます。 繰り返しになりますが、パフォーマンスが低下するだけなので、WAN にまたがるクラスターを構成することはできません。 XNUMX つのデータセンターがある場合、それらは同じ場所にない可能性があるため、WAN 経由で非同期レプリケーションまたは同期を実行する必要があります。
私たちの一人 お客さま ライアンエアーはここの大手航空会社で、ダブリン、ロンドンとフランクフルトにデータセンターがあります。 したがって、同期できることを確認する必要があります。 の場合には NCache 私たちも持っています WANレプリケーション。 セッションを XNUMX つのデータセンターから別のデータセンターに移動できるマルチ データセンター セッションの概念もあります。 しかし、とにかく、キャッシュは複数のデータセンターをサポートできる必要があります。 ですから、それについては必ず調べてください。
NCache vs Redis
.NET 関係者のほとんどは知っています。 Redis. NCache、申し訳ありませんが、Microsoft はこれらを Azure の選択肢として選択しました。 Redis Linux のバックグラウンドを持っています。 Microsoft がそれらを選んだ主な理由は、複数の言語を使用したかったからだと思います。 それで、 Redis 多くの言語をカバーしています。 NCache かなり .NET に重点を置いています。 Java APIもありますが、 NCache それ自体は .NET に重点を置いています。 この XNUMX つについて簡単に概要を説明したいと思います。これが何を意味するのかを理解してから、私たちの Web サイトにアクセスしてください。実際には、本格的な機能のようなものがあります。 比較。 ここで機能の比較を行うことができます。 そして、これをダウンロードすることもできます。 それで、これを見てください。 これは彼らのドキュメントと私たちのドキュメントに基づいています。 つまり、それは…これにはスピンがありません。
NCache もオープンソースですので、 Redis。 の場合 NCache あなたは…を持っています。私たちのウェブサイトにアクセスすれば、 ダウンロード Enterprise Edition またはオープンソースのいずれか、または GitHub にアクセスすることもできます。 NCache? ここで GitHubの そして、あなたは見ることができます NCache ここも。
したがって、このエンタープライズ版は完全にサポートされています。 の場合には Redis マイクロソフトが移植した Redis Linux から Windows へ。 したがって、Microsoft が Azure のポートを使用しているのではないかと思われるかもしれませんが、実際はそうではありません。 したがって、彼らが所有する港には多くの問題があります。 多くの顧客からこの件について苦情が寄せられています。
したがって、使用する場合 Redis Azure では Linux バージョンが使用されており、安定しているため問題はありませんが、先ほど説明したすべての機能が失われます。 オンプレミスでのサポートをご希望の場合は、 NCache オープンソースはすべて無料で、エンタープライズはサポート料金よりも多くの機能を利用できるものになります。 オンプレミスで使用したい場合は、 Redis、唯一の選択肢は、次の Linux バージョンを使用することです。 Redis 研究室。 彼らは今、これをdockerにも持っています。 したがって、技術的には Windows でも実行できますが、それでも Linux 環境で実行できます。 Windows のオンプレミスは Microsoft のものですが、前述したように不安定でサポートがありません。
アズールで Redis キャッシュサービスモデルを提供します。 NCache VM モデルを提供します。 VM モデルを使用すると、より詳細な制御が可能になります。 リードスルー、ライトスルー、キャッシュローダー、データベース同期など、先ほど説明したすべてのことをすべて制御でき、存在するのはクライアント API だけです。
以上が XNUMX つの概要です。 なんとなく言及したかったのです。 基本的、 NCache .NET 空間で最も古いキャッシュです。 たくさんのお客様にご利用いただいております NCache。 また、その多くは英国にあります。 ご存知のとおり、英国は当社の XNUMX 番目に大きな市場であり、.NET アプリケーションをお持ちの場合は、スタック全体を .NET にすることを望んでいます。 NCache .NET スタックを提供します。 Redis 違います。
この話を終える前に何か質問はありますか? しかし、そうすると自分自身でパーティション分割を暴露してしまうことになります。 なぜなら、リレーショナル データベースでは、データがどちらか一方に存在するようにアプリケーションをプログラムする必要があるからです。 つまり、No SQL の全体的なコンセプトは、すべてがキーに基づいているため、シャーディングを自動的に実行するということです。 リレーショナルではさらに複雑さが増し、これまでのところ、スケーラビリティの問題に対処できるリレーショナル データベースはありません。 彼らは懸命に努力し、パフォーマンスを大幅に向上させました。 インメモリオプションがたくさんあるので、インメモリデータベースもあり、インメモリテーブルなどをたくさん実行します。 したがって、パフォーマンスはかなり向上しましたが、ここではパフォーマンスが問題ではありません。 ご存知のとおり、問題はスケーラビリティです。 あなたはその負荷に対処できますか、そして今のところ彼らはそれができません。
したがって、インデックスを作成する理由は、これらの属性に基づいて検索できるようにするためです。 したがって、SQL ステートメントを実行して、インデックス付けされたオブジェクトの属性を検索できます。
したがって、インデックスを作成しない限り、検索を実行することはできません。 そこで、検索してみると NCache この属性にはインデックスが作成されていないという例外がスローされます。 つまり、より苦しい意味で、そうです。 ただし、私たちがお客様に伝えているのは、検索しようとするものが何であれ、インデックスを作成する必要があるということです。 また、すべてが SQL であるデータベースとは異なり、ここではすべてが SQL を通過しません。 繰り返しますが、API だけを介して多くの処理を実行し、一部の処理は SQL を介して実行されます。
キャッシュ名のことですか？ キーには型情報が含まれている必要があり、特定の情報に基づいて、たとえば、それが個々のオブジェクト、型、主キー値または主キー属性名、そして値のいずれかである必要があるという規則があります。一般的なことですが、コレクション全体を保存している場合、たとえば、顧客の他のすべての注文を保存していて、顧客に基づいてそれを取得したい場合は、キーは顧客、顧客 ID、私の注文などになります。そうですよね。 したがって、キーはデータの取得方法に基づいて意味のあるものでなければなりません。
はい、それらはすべてあなたが選択できるオプションです。 私のリレーショナル データの処理に関するビデオをご覧いただければ、これらすべてのオプションを確認できます。 そして、やはりキャッシュですが、データベース内に多対多の関係があるとします。 アプリケーションレベルでは多対多はありません。 アプリケーションでは、こちら側またはこちら側からアプローチします。 常に XNUMX 対多です。 そうすると、突然視点が変わったりするんです。
データベース全体をメモリ内に再作成しようとしているわけではありません。 分散キャッシュを使用する利点を要約していただけますか? スケーラビリティだとおっしゃいましたね。 他にもありますか？ 最も重要な利点は拡張性だと思います。 XNUMX 番目の利点はパフォーマンスであり、ユース ケース、つまり ASP.NET 固有のユース ケース、セッションに関しても大きな利点があります。 なぜなら、分散キャッシュの代替手段はすべて非常に遅いか、スケーラブルではないからです。 したがって、In-Proc を実行すると、スケーラブルではなくなります。 なぜなら、毎回同じプロセスを踏まなければならないからです。
私もこれを録画していますが、SDD Conf も同様だと思います。 この講演は YouTube で公開します。ブースに来てスキャンしていただければ、講演へのリンクを電子メールでお送りします。その後、これを同僚と共有することができます。 皆様、ご辛抱いただきありがとうございました。