RedisとMemcachedの比較
RedisとMemcachedの違いを簡単に比較すると、多くの場合、以下の観点が得られます.
1 Redisは単純なk/vタイプのデータだけでなくlist,set,hashなどのデータ構造の記憶も提供する.
2 Redisはデータのバックアップ、すなわちmaster-slaveモードのデータバックアップをサポートします.
3 Redisはデータの永続化をサポートし、メモリのデータをディスクに保持し、再起動時に再ロードして使用することができます.
Redisでは、すべてのデータがメモリに格納されているわけではありません.これはMemcachedと比較して最大の違いです(個人的にはそう思います).Redisはすべてのkeyの情報をキャッシュするだけで、Redisがメモリの使用量がバルブ値を超えていることを発見した場合、swapの操作がトリガーされ、Redisは「swappability=age*log(size_in_memory)」に基づいて、どのkeyに対応するvalueがディスクにswapを必要とするかを計算します.その後、これらのkeyに対応するvalueをディスクに永続化し、メモリから消去します.この特性により、Redisは、マシン自体のメモリサイズを超えるデータを保持することができる.もちろん、マシン自体のメモリはすべてのkeyを保持する必要があります.結局、これらのデータはswap操作を行わないからです.また、Redisがメモリ内のデータswapをディスクに送信すると、サービスを提供するプライマリ・スレッドとswap操作を行うサブスレッドがこのメモリの一部を共有するため、swapが必要なデータを更新すると、Redisはこの操作をブロックし、サブスレッドがswap操作を完了するまで修正することができません.
Redis固有メモリモデルを使用する場合の比較を参照してください.
Redisからデータを読み出す場合、読み出したkeyに対応するvalueがメモリに含まれていない場合、Redisはswapファイルから対応するデータをロードし、リクエスト側に戻る必要があります.ここでI/Oスレッドプールの問題があります.デフォルトでは、Redisはブロックされます.つまり、すべてのswapファイルのロードが完了してから対応します.このポリシーはクライアントの数が少なく,一括操作を行う場合に適している.しかし、Redisを大規模なWebアプリケーションに適用すると、大きな同時性を満たすことは明らかではありません.したがって、Redis実行I/Oスレッドプールのサイズを設定し、swapファイルから対応するデータをロードする必要がある読み取り要求を同時操作し、ブロック時間を短縮します.
redis、memcache、mongodb比較
以下のいくつかの次元から、redis、memcache、mongodyを比較して、レンガを撮ることを歓迎します
1、性能
いずれも高いので、パフォーマンスは私たちにとってボトルネックではないはずです.
全体的にTPSはredisとmemcacheの差が少なくmongodbより大きい
2、操作の便利性
memcacheデータ構造単一
redisは豊富で、データ操作の面で、redisはもっと良くて、少ないネットワークIO回数
mongodbは豊富なデータ表現、インデックス、最も類似した関係型データベースをサポートし、サポートされているクエリー言語は非常に豊富です.
3、メモリ容量の大きさとデータ量の大きさ
redisは2.0バージョン後に独自のVM特性を追加し、物理メモリの制限を突破した.key valueの有効期限を設定できます(memcacheのように)
memcacheは、LRUアルゴリズムを使用して最大使用可能なメモリを変更できます.
mongodbは大きいデータ量のストレージに適して、オペレーティングシステムVMに頼ってメモリの管理をして、メモリを食べるのも比較的にひどくて、サービスは他のサービスといっしょにいないでください
4、可用性(単一の問題)
単一の問題では、
redisは、クライアントに依存して分散型読み書きを実現する.プライマリ・スレーブ・レプリケーションでは、プライマリ・ノードがノードから再接続されるたびにスナップショット全体に依存し、パフォーマンスと効率の問題でインクリメンタル・レプリケーションが発生しません.
だから単点の問題は複雑です.自動shardingはサポートされていませんが、プログラムに依存して一貫したhashメカニズムを設定する必要があります.
1つの代替案は、redis自体のレプリケーションメカニズムを使用せずに、自分でアクティブなレプリケーション(複数のストレージ)を行うか、増分レプリケーションに変更するか(自分で実現する必要がある)、一貫性の問題とパフォーマンスのバランスです.
Memcache自体はデータ冗長メカニズムがなく、必要もありません.故障予防には,成熟したhashまたは環状に依存するアルゴリズムを用いて,単点故障によるジッタ問題を解決した.
mongodyはmaster-slave,replicaset(内部はpaxos選挙アルゴリズムを採用し、自動故障回復)、auto shardingメカニズムをサポートし、クライアントに対して故障移転と切り分けメカニズムを遮断した.
5、信頼性(持久化)
データの永続化とデータ・リカバリの場合、
redisサポート(スナップショット、AOF):スナップショットに依存して永続化し、aofは信頼性を向上させ、パフォーマンスに影響を与える
memcacheはサポートされておらず、通常はキャッシュとして使用され、性能を向上させる.
MongoDBは1.8バージョンからbinlog方式で持続的な信頼性をサポート
6、データ整合性(取引サポート)
Memcacheは同時シーンでcasで一貫性を保証する
redisトランザクションのサポートは弱く、トランザクション内の各操作が連続的に実行されることしか保証されません.
mongodbはトランザクションをサポートしていません
7、データ分析
mongodyにはデータ分析機能(mapreduce)が内蔵されており、その他はサポートされていません
8、シーンを適用する
redis:データ量が小さいよりパフォーマンスの高い操作と演算
memcache:ダイナミックシステムでデータベース負荷を低減し、パフォーマンスを向上させるために使用されます.キャッシュを行い、パフォーマンスを向上させる(読み書きが少なく、データ量が大きい場合はshardingを採用できる)
MongoDB:主に大量データのアクセス効率の問題を解決する
1 Redisは単純なk/vタイプのデータだけでなくlist,set,hashなどのデータ構造の記憶も提供する.
2 Redisはデータのバックアップ、すなわちmaster-slaveモードのデータバックアップをサポートします.
3 Redisはデータの永続化をサポートし、メモリのデータをディスクに保持し、再起動時に再ロードして使用することができます.
Redisでは、すべてのデータがメモリに格納されているわけではありません.これはMemcachedと比較して最大の違いです(個人的にはそう思います).Redisはすべてのkeyの情報をキャッシュするだけで、Redisがメモリの使用量がバルブ値を超えていることを発見した場合、swapの操作がトリガーされ、Redisは「swappability=age*log(size_in_memory)」に基づいて、どのkeyに対応するvalueがディスクにswapを必要とするかを計算します.その後、これらのkeyに対応するvalueをディスクに永続化し、メモリから消去します.この特性により、Redisは、マシン自体のメモリサイズを超えるデータを保持することができる.もちろん、マシン自体のメモリはすべてのkeyを保持する必要があります.結局、これらのデータはswap操作を行わないからです.また、Redisがメモリ内のデータswapをディスクに送信すると、サービスを提供するプライマリ・スレッドとswap操作を行うサブスレッドがこのメモリの一部を共有するため、swapが必要なデータを更新すると、Redisはこの操作をブロックし、サブスレッドがswap操作を完了するまで修正することができません.
Redis固有メモリモデルを使用する場合の比較を参照してください.
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on: 300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on: 1 million keys, 256 bytes values: 160.09M used
VM on: 1 million keys, values as large as you want, still: 160.09M usedRedisからデータを読み出す場合、読み出したkeyに対応するvalueがメモリに含まれていない場合、Redisはswapファイルから対応するデータをロードし、リクエスト側に戻る必要があります.ここでI/Oスレッドプールの問題があります.デフォルトでは、Redisはブロックされます.つまり、すべてのswapファイルのロードが完了してから対応します.このポリシーはクライアントの数が少なく,一括操作を行う場合に適している.しかし、Redisを大規模なWebアプリケーションに適用すると、大きな同時性を満たすことは明らかではありません.したがって、Redis実行I/Oスレッドプールのサイズを設定し、swapファイルから対応するデータをロードする必要がある読み取り要求を同時操作し、ブロック時間を短縮します.
redis、memcache、mongodb比較
以下のいくつかの次元から、redis、memcache、mongodyを比較して、レンガを撮ることを歓迎します
1、性能
いずれも高いので、パフォーマンスは私たちにとってボトルネックではないはずです.
全体的にTPSはredisとmemcacheの差が少なくmongodbより大きい
2、操作の便利性
memcacheデータ構造単一
redisは豊富で、データ操作の面で、redisはもっと良くて、少ないネットワークIO回数
mongodbは豊富なデータ表現、インデックス、最も類似した関係型データベースをサポートし、サポートされているクエリー言語は非常に豊富です.
3、メモリ容量の大きさとデータ量の大きさ
redisは2.0バージョン後に独自のVM特性を追加し、物理メモリの制限を突破した.key valueの有効期限を設定できます(memcacheのように)
memcacheは、LRUアルゴリズムを使用して最大使用可能なメモリを変更できます.
mongodbは大きいデータ量のストレージに適して、オペレーティングシステムVMに頼ってメモリの管理をして、メモリを食べるのも比較的にひどくて、サービスは他のサービスといっしょにいないでください
4、可用性(単一の問題)
単一の問題では、
redisは、クライアントに依存して分散型読み書きを実現する.プライマリ・スレーブ・レプリケーションでは、プライマリ・ノードがノードから再接続されるたびにスナップショット全体に依存し、パフォーマンスと効率の問題でインクリメンタル・レプリケーションが発生しません.
だから単点の問題は複雑です.自動shardingはサポートされていませんが、プログラムに依存して一貫したhashメカニズムを設定する必要があります.
1つの代替案は、redis自体のレプリケーションメカニズムを使用せずに、自分でアクティブなレプリケーション(複数のストレージ)を行うか、増分レプリケーションに変更するか(自分で実現する必要がある)、一貫性の問題とパフォーマンスのバランスです.
Memcache自体はデータ冗長メカニズムがなく、必要もありません.故障予防には,成熟したhashまたは環状に依存するアルゴリズムを用いて,単点故障によるジッタ問題を解決した.
mongodyはmaster-slave,replicaset(内部はpaxos選挙アルゴリズムを採用し、自動故障回復)、auto shardingメカニズムをサポートし、クライアントに対して故障移転と切り分けメカニズムを遮断した.
5、信頼性(持久化)
データの永続化とデータ・リカバリの場合、
redisサポート(スナップショット、AOF):スナップショットに依存して永続化し、aofは信頼性を向上させ、パフォーマンスに影響を与える
memcacheはサポートされておらず、通常はキャッシュとして使用され、性能を向上させる.
MongoDBは1.8バージョンからbinlog方式で持続的な信頼性をサポート
6、データ整合性(取引サポート)
Memcacheは同時シーンでcasで一貫性を保証する
redisトランザクションのサポートは弱く、トランザクション内の各操作が連続的に実行されることしか保証されません.
mongodbはトランザクションをサポートしていません
7、データ分析
mongodyにはデータ分析機能(mapreduce)が内蔵されており、その他はサポートされていません
8、シーンを適用する
redis:データ量が小さいよりパフォーマンスの高い操作と演算
memcache:ダイナミックシステムでデータベース負荷を低減し、パフォーマンスを向上させるために使用されます.キャッシュを行い、パフォーマンスを向上させる(読み書きが少なく、データ量が大きい場合はshardingを採用できる)
MongoDB:主に大量データのアクセス効率の問題を解決する