2015-04-23 71 views
0

Redis排序集主要根据Score进行排序;但是,如果多个成员共享相同的分数字典(阿尔法)排序使用。所述Redis zadd文档表示该函数的复杂性是:Redis Sorted Set会员大小和性能

“O(日志(N)),其中N是在分类集合的元素数”

我必须假设这无论保持为真成员的大小/长度;然而,我有一个案例,只有4个分数导致会员在Score后按字典顺序排序。

我想为每个成员添加一个时间基准键,使次要排序基于时间,并为成员添加一些唯一性。喜欢的东西:

"time-based-key:member-string" 

我的会员字符串可以更大JavaScript对象文字像这样:

JSON.stringify({/* object literal */}) 

将有序集合zadd和其他功能的性能保持不变?

如果不是,性能会受到多大程度的影响?

回答

2

复杂性来自需要测试的元素(与新元素进行比较)以找到正确的插入点(推测使用二分搜索算法)。

它没有说明每次测试需要多长时间,因为这被认为是一个常数因素(从添加更多项目时它不会变化)。

在确定新元素应该在现有元素之前还是之后进行比较之前,需要比较的数据量将影响总时钟时间,但是对于每次比较它都会这样做。

因此,只有在比较分数时,插入的总体时钟时间才会最快,并且越深入一对字符串越深,以确定其词法顺序。然而,这并不是什么特别的大小,只是具体的微秒数乘以log(n)复杂度因子。

+0

所以为了确保我正确理解您的答案:无论成员字符串的大小如何,执行比较所花费的时间量对于每次比较都是相等的?成员字符串大小在执行插入时不会影响时间复杂度。即使排序逻辑回退到词典成员排序,时间也会随着排序集中成员的数量增加而增加。 – user3331119

+0

如果每次比较所花费的时间加倍(作为一个简单示例),执行插入所花费的时间与列表中的项目数相同,也将加倍。但它不会改变必须进行的比较次数。你不能说它会影响复杂性,因为你只是将未知数字加倍。 O(n)搜索每个项目可能需要一个小时,或者一个纳秒,所有的复杂性预测值是n个小时或纳秒。 – IMSoP

+0

因此,比较时间是每个测试的常数因子(排序集合中的成员数量),但也会因比较的复杂性而增加。因此,成员字符串大小的增加会增加每次比较的时间和总时间。这将是很好的文件,包括这种二次排序的细节,以便他们可以考虑实施商店时...... – user3331119