3

私は、答えがおそらく私の専門外であるという難問に直面していることに気づきました。誰かが助けてくれることを願っています。

テーブル (およびリンクされた) データをフェッチするための最適化された効率的なクエリがありますが、その実際の内容は重要ではありません。ただし、読み取るたびに、そのデータを処理して JSON 形式でデータを表示する必要があります。数百行に数十万行が関連付けられる典型的な例を話しているので、これには時間がかかります。マルチスレッドと強力な CPU (i7 3960X) を使用すると、この処理は 100% CPU で約 400ms - 800ms です。私が知っていることはあまりありませんが、そもそもなぜ毎回処理するのですか?

この特定の例では、私がこれまでに読んだことはすべてそうしていないことを示していますが (私が理解しているように)、計算された JSON を VARCHAR(MAX) 列に格納して高速に読み取ることを検討しています。

なんで？データは 1 回の書き込み (変更) ごとに 100 回以上読み取られます。これらの数値を考えると、最適化された検索のために JSON を保存し、奇妙な機会に関連付けを再計算して更新する方がはるかに優れているように思えます。変更の書き込みにかかる時間はおそらく 10 ～ 20 ミリ秒増加しますが、読み取りは大幅に改善されます。

これについてのご意見をお待ちしております。

4

1 に答える 1

3

はい、パフォーマンス上の理由から冗長な情報を保存することは非常に一般的です。最初のステップは、オーバーヘッドを測定することです-そして、あなたはすでにそれを行っているように思えます（ただし、どのjsonシリアライザーを使用していますか?他のものを試しましたか?)

しかし、基本的には、状況がそれを正当化する場合、はい、それは問題ありません。例を挙げると、stackoverflow にも同様のシナリオがあります。入力したマークダウンは、html に処理するのに比較的コストがかかります。すべての読み取りでこれを行うことができますが、書き込みよりも読み取りの方が非常に多いため、 write でマークダウンをクックし、ソースのマークダウンと同様に html を保存します。ほとんどの「表示」コード。

ただし、json シリアライゼーションは少し単純であり、多くのメタプログラミングの最適化がほとんどのシリアライザーによって実行されるため、これが json で一般的な問題になることはまれです。したがって、このルートに進む前に別のシリアライザーを試すことをお勧めします。

また、レンダリングされた json は、TDS の元のソース データよりも多くのネットワーク帯域幅を必要とする可能性があることに注意してください。そのため、db サーバーとアプリケーション サーバー間のデータ転送が増加する可能性があります。考慮すべきもう1つのこと。

于 2013-05-29T10:41:31.443 に答える