在redis中列出替代方案

Question

Redis.io

从时间复杂性的角度来看，Redis列表的主要特性是支持固定时间插入和删除靠近头和尾的元素，即使插入了数百万项。访问元素的速度非常快，接近列表的极限，但如果您尝试访问一个非常大的列表的中间，则会很慢，因为它是一个O(N)操作。

当数据太高且写入量小于读取时，LIST的替代方案是什么？

Answer 1

在进行测试之前，我肯定会对此进行基准测试，但如果您确实遇到了访问列表中间项的性能问题，那么有几个替代方案确实取决于您的用例。

1. 不要列出那么大的列表，把那些不再重要的东西变老/修剪掉。
2. 会对列表中的热门部分进行记忆。如果一个特定的分页范围被请求的频率比其他的要高得多，那么就创建它自己的列表。检查它是否已经存在，并且它没有在分页范围内创建列表的一个子集。
3. Bucket将您的列表从一开始到“可管理的大小”(对于可管理的定义是什么)。如果列表纯粹是加性的(没有从列表中删除)，则可以使用项的模数索引作为键的一部分，以便将列表存储在较小的桶中。例: key = "your_key_name_“+ index % 100000