redisはどのようにO(1)キールックアップの時間を要求しますか？
質問があります-インデックス内のキーと値のペアのルックアップ-たとえばcassandraまたはpostgres-は通常O（logn）付近にあります
ソース： https://github.com/tinkerpop/blueprints/wiki/Graph-Indices 。
Redisのドキュメントには、実行時の複雑さはO（1）であると記載されています。
ソース： http://redis.io/commands/gethttp://redis.io/commands/hget
また、複数のキーの値を取得するのは線形のみですO(m)ここで、mは取得されたキーの数です http://redis.io/commands/hmget
どうしてそれは可能ですか？
Redisはインメモリストアです。したがって、メモリストレージに適合したデータ構造を使用できます（高速ランダムアクセスが可能になります）。
ディクショナリを実装するには（メインディクショナリだけでなく、ハッシュオブジェクトとセットオブジェクトにも使用され、zsetオブジェクトのスキップリストと組み合わせて）、Redisは 個別のチェーンハッシュテーブル を使用します。アクセスの複雑さはO（ 1 + n/k）ここで、nはアイテムの数、kはバケットの数です。
Redisは、実際にはn/kが低く保たれるように、アイテムの数に応じてバケットの数が増えることを確認します。この再ハッシュアクティビティは、バックグラウンドで段階的に実行されます。アイテムの数が多い場合、複雑さはO(1)（償却済み）に近くなります。
他のストア（たとえばCassandra）は、パフォーマンス上の理由からランダムI/Oの数を最小限に抑えながらデータをディスクに保存するように設計されています。ハッシュテーブルは、データの局所性を強制しないため、このための適切なデータ構造ではありません（バッファーキャッシュのメリットはあまりありません）。したがって、ディスクベースのストアは通常、O（log n）の複雑さを持つBツリーバリアント（ほとんどのRDBMS）またはログ構造化マージ（LSM）ツリーバリアント（Cassandra）を使用します。
そうです、Redisは多くの操作にO(1)を提供しますが、制約があります。すべてのデータがメモリに収まる必要があります。ここには魔法はありません。