1

キー/値のキャッシュ機能を必要とするプロジェクトに取り組んでいますが、アプリケーションは、 ASP.NET Cache、memcached、AppFabricなどの業界標準のメモリキャッシュ方法をサポートしていない非常に限られた環境に存在します。

この制限のある環境で使用できる唯一のオプションは、MSSQLデータベースです。キー/値キャッシュのニーズを満たすために、単純なキー/値テーブルを作成する必要があります。ほとんどの場合、データをJSONとしてシリアル化しますが、キーに最適なデータ型が何であるかはわかりません。明らかに一意のキーである必要があり、キャッシュを取得および設定するプログラマーが読み取り可能である必要があります。また、「メモリ内」のキャッシュソリューションにアクセスできないため、パフォーマンスがすでに低下しているため、迅速に検索する必要があります。

私は主キー列をint値またはbigint値にすることに慣れています。この場合、すべてのクエリは次のようになるため、主キー（キャッシュキー）はcharまたはvarcharデータ型である必要があります。

SELECT value FROM CacheTable WHERE key = 'keyname'

md5ハッシュの使用に関する投稿も見ましたが、他の投稿では、ハッシュを信頼して一意のキーを常に生成することはできないと指摘されていました。私は基本的にデータ型に関するアドバイスを求めていますが、「key」列を主キーにするかどうか、またはintまたはbigint主キーを作成する必要があるかどうか（おそらく使用されない場合でも）。

最終的には、.NETのネイティブキャッシングと同様のキャッシングクラスを作成します。このクラスでは、次のようなデータベーステーブルからプルする静的クラスを作成できます。

CustomDatabaseCache.Set(string key, object value);
CustomDatabaseCache.Get(string key)
4

1 に答える 1

1

あなたのシナリオでは、キーネーム列にクラスター化された主キーがあるとうまくいくと思います。ただし、過度のページ分割を引き起こさない程度に十分に低い FILL FACTOR が必要ですが、ページの読み取り数を低く抑えるために十分に高い FILL FACTOR が必要なため、FILL FACTOR を試してみる価値があります。

クラスター化された IDENTITY インデックスは、クラスター化されたインデックスのページ分割を排除するという点でより適切に機能します。また、INCLUDE 句を使用して値を含めるキー名に一意のインデックスを使用できます。ただし、あなたの場合、一意のインデックスでまったく同じページ分割の問題が発生し、キー名のクラスター化されたインデックスを読み取るのにそれほど費用がかからないため、それを行う利点はわかりません。余分な列がありません。さらに、書き込み用の 2 つのインデックスでインデックス更新コストが発生します。

それが役立つことを願っています。

于 2013-02-15T14:42:52.120 に答える