行キャッシュは、単一の列への最初のアクセスで行全体を RAM にロードします。新しい列の更新と挿入により、行キャッシュが更新されます。これは、ライト スルーと見なすことができます。
行をキャッシュするのに十分なRAMがあると仮定すると、キャッシュされた行の更新/挿入とは関係なく、読み取りアクセスが常にRAMから提供されると確信できますか?
行キャッシュは、単一の列への最初のアクセスで行全体を RAM にロードします。新しい列の更新と挿入により、行キャッシュが更新されます。これは、ライト スルーと見なすことができます。
行をキャッシュするのに十分なRAMがあると仮定すると、キャッシュされた行の更新/挿入とは関係なく、読み取りアクセスが常にRAMから提供されると確信できますか?
簡単な答え: はい。行キャッシュを使用すると、ミリ秒ではなくマイクロ秒になります。
より長い答え: 技術的には、最初の読み取りの後のみ、既存のエントリがない限り、書き込みはキャッシュに追加されません。Cassandra は定期的なキャッシュの保存をサポートしているため、次回の再起動時に事前にウォームアップできます。
はい。ただし、パフォーマンスが5%程度しか向上せず、95%の場合は決してオンにしないでください。
playOrmプロジェクトでは、インデックステーブルから行をキャッシュするだけで、クラスター全体に分散するとすべてのクエリが高速化されるため、パフォーマンスが40%程度、さらには100%向上するのではないかと考えています。S-SQL(Scalable SQL)を使用したパーティション内の1,000,000行のクエリは、すでに60ミリ秒に達しています。これにより、playOrmがネストされた先読みループ結合を追加すると、古いDBMSネストブロックよりも高速になる可能性があります。ループ結合。