我了解的差别有：
自带的数据结构：不用和缓存服务器建立通信，效率可能会更高？
NoSQL：集群环境下，业务服务器的缓存数据不能共享，存在资源浪费。而NoSQL的数据可以共享给业务服务器。
不知道还有没有其他差别，主要是发现现在的项目中部署了多台服务器，但是每台服务器的缓存数据都是一样的，而且请求是不走数据库的，有个定时任务会去同步数据库中的数据到缓存中。如果仅仅为了提高系统的QPS，是否应该使用NoSQL去做缓存?
认证0级讲师
「どちらが良いですか?」と尋ねると、答えは通常「必ずしもそうではありません」です。これは白か黒かで決まる世界ではなく、ほとんどの場合、状況によって異なります。 キャッシュ用のデータ構造が組み込まれた軽量アプリケーションは、ネットワークを経由しない通信方法が、間違いなく比較的効率的で、プログラムにとって使いやすいものとなる可能性があります。ただし、組み込みデータ構造のほとんどはスレッドセーフではないため、必要に応じてスレッド同期のために自分自身をロックする必要があります。スレッド同期のトピックはこのトピックの範囲外ですが、多くの人がロックできないか過剰なロックを使用するため、パフォーマンスが低下します。本当に高い同時実行性の環境では、短期間でもパフォーマンスが低下すると、サーバー上に大量のリクエストが蓄積して処理できなくなり、アプリケーションがクラッシュする可能性があります。 アプリケーションがある程度の規模に達したら、サーバー側で解決されたロックの問題に加えて、前述したようにキャッシュを共有できないという問題も解決できる分散キャッシュの使用を検討する必要があります。問題 (キャッシュが多すぎて 1 つのサーバーに収容できない場合はどうすればよいですか?)。同じ条件下では、内部キャッシュから分散キャッシュに移行しても応答時間は短縮されず、ほとんどの場合、応答時間はある程度延長されます (ネットワーク送信およびシリアル化および逆シリアル化プロセス)。しかし、その代わりに、より重要なのは、水平方向のスケーラビリティをもたらし、ヒープ サーバーを通じてより多くのリクエストを処理できるようになります。 水平方向の拡張は、ほとんどの分散データベースが解決する必要がある重要な問題です。 もちろん、NoSQL の導入により必然的に複雑さも増し、開発に余分な作業負荷が追加されます。ただし、NoSQL データベースは、高可用性やキャッシュされたデータの一貫性など、追加の利点ももたらします。 これを言うと混乱してしまいますが、私が言いたいのは、キャッシュに NoSQL を導入することは、あなたが思っているほど素晴らしいことではないかもしれないということです。あなたがしなければならないことは、それがもたらす利点が自分のアプリケーションシナリオで望むものであるかどうか、それらの利点を享受しながら、それがもたらす悪影響を許容できるかどうかを評価し、それからそれを使用するかどうかを決定することです。
これはデータのサイズによって異なりますが、少量の場合は、組み込みのデータ構造を使用するのが最も安価で効率的なオプションです。 データ量が大きい場合は、既製の noSql サービスを使用する必要があります。自分で作成したコンポーネントに重大なバグがあるとは限りません。実績のあるソフトウェアが最適な選択であるとは限りません。さらに、これらのソフトウェアはいずれも大容量データに必要な機能を備えています。
は良くありません。ehcache
データ構造キャッシュを使用するのはデータ量が少ない場合だけです。結局、データ量が多い場合は NoSQL のみを使用します。
HBase の設計を参照できます。 HBase 物理ストレージは、HDFS の MapFile 形式に基づいています (新しいバージョンでは HFile 自体が実装されていますが、原理は基本的に同じです)。 MapFile は読み取り専用のキーと値のファイルであり、一度書き込んだ後は変更できません。さらに、MapFile では、書き込み時にファイル内のすべてのキーがソートされている必要があります。この場合、HBase はまずデータを MemStore に保存し、MeMStore が一定量のデータを保存した後、そのデータを HDFS (MapFile または HFile) に永続的に書き込みます。 つまり、キャッシュはメモリ内データ構造と NoSQL 永続化メカニズムを使用して実装できます。 2 つの方法は相互に補い合います
実装が簡単かどうかはわかりません。多数のオブジェクトを直接 JVM に配置すると、プログラムを開始したときに髪の毛が真っ白になってしまいます。起動するたびに一度初期化してロードしてください！悲惨です
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
「どちらが良いですか?」と尋ねると、答えは通常「必ずしもそうではありません」です。これは白か黒かで決まる世界ではなく、ほとんどの場合、状況によって異なります。
キャッシュ用のデータ構造が組み込まれた軽量アプリケーションは、ネットワークを経由しない通信方法が、間違いなく比較的効率的で、プログラムにとって使いやすいものとなる可能性があります。ただし、組み込みデータ構造のほとんどはスレッドセーフではないため、必要に応じてスレッド同期のために自分自身をロックする必要があります。スレッド同期のトピックはこのトピックの範囲外ですが、多くの人がロックできないか過剰なロックを使用するため、パフォーマンスが低下します。本当に高い同時実行性の環境では、短期間でもパフォーマンスが低下すると、サーバー上に大量のリクエストが蓄積して処理できなくなり、アプリケーションがクラッシュする可能性があります。
アプリケーションがある程度の規模に達したら、サーバー側で解決されたロックの問題に加えて、前述したようにキャッシュを共有できないという問題も解決できる分散キャッシュの使用を検討する必要があります。問題 (キャッシュが多すぎて 1 つのサーバーに収容できない場合はどうすればよいですか?)。同じ条件下では、内部キャッシュから分散キャッシュに移行しても応答時間は短縮されず、ほとんどの場合、応答時間はある程度延長されます (ネットワーク送信およびシリアル化および逆シリアル化プロセス)。しかし、その代わりに、より重要なのは、水平方向のスケーラビリティをもたらし、ヒープ サーバーを通じてより多くのリクエストを処理できるようになります。 水平方向の拡張は、ほとんどの分散データベースが解決する必要がある重要な問題です。
もちろん、NoSQL の導入により必然的に複雑さも増し、開発に余分な作業負荷が追加されます。ただし、NoSQL データベースは、高可用性やキャッシュされたデータの一貫性など、追加の利点ももたらします。
これを言うと混乱してしまいますが、私が言いたいのは、キャッシュに NoSQL を導入することは、あなたが思っているほど素晴らしいことではないかもしれないということです。あなたがしなければならないことは、それがもたらす利点が自分のアプリケーションシナリオで望むものであるかどうか、それらの利点を享受しながら、それがもたらす悪影響を許容できるかどうかを評価し、それからそれを使用するかどうかを決定することです。
これはデータのサイズによって異なりますが、少量の場合は、組み込みのデータ構造を使用するのが最も安価で効率的なオプションです。
データ量が大きい場合は、既製の noSql サービスを使用する必要があります。自分で作成したコンポーネントに重大なバグがあるとは限りません。実績のあるソフトウェアが最適な選択であるとは限りません。さらに、これらのソフトウェアはいずれも大容量データに必要な機能を備えています。
は良くありません。ehcache
などのキャッシュ フレームワークを使用することをお勧めします。データ構造キャッシュを使用するのはデータ量が少ない場合だけです。結局、データ量が多い場合は NoSQL のみを使用します。
HBase の設計を参照できます。
HBase 物理ストレージは、HDFS の MapFile 形式に基づいています (新しいバージョンでは HFile 自体が実装されていますが、原理は基本的に同じです)。 MapFile は読み取り専用のキーと値のファイルであり、一度書き込んだ後は変更できません。さらに、MapFile では、書き込み時にファイル内のすべてのキーがソートされている必要があります。この場合、HBase はまずデータを MemStore に保存し、MeMStore が一定量のデータを保存した後、そのデータを HDFS (MapFile または HFile) に永続的に書き込みます。
つまり、キャッシュはメモリ内データ構造と NoSQL 永続化メカニズムを使用して実装できます。 2 つの方法は相互に補い合います
実装が簡単かどうかはわかりません。多数のオブジェクトを直接 JVM に配置すると、プログラムを開始したときに髪の毛が真っ白になってしまいます。起動するたびに一度初期化してロードしてください！悲惨です