为什么SSDB不支持index?

第一菜鸟 发布于 2013/10/27 02:52
阅读 1K+
收藏 1

    公司使用Redis来作为游戏的服务器(PHP开发),读写性能非常的好,但是由于是K/V类型的数据库,如果不想根据Key去查询,而是通过某个条件去查询的话,Redis可以通过建立索引来实现,效果也挺不错的;

    现在看了LevelDB(https://code.google.com/p/leveldb/),可以支持上亿数据量的处理,但是却不支持Index,不明白是为什么?难道是因为数据处理比较快而不需要使用Index?可是它与Redis比较读写速度的话反倒没有什么优势,如果是大数据的话如何更快地进行查询?

加载中
0
i
ideawu

引用来自“第一菜鸟”的答案

引用来自“ideawu”的答案

Hi, 你说的 Index 是指什么呢? Redis 同样没有"索引"的概念, 所有的数据都是通过 key(kv, hash, zset) 来获取的.

SSDB 的性能非常高, 大部分情况下是 Redis 性能的一半, 但存储的数据量却超过 Redis 上百倍.

嗯是的,Redis会受限于内存大小,而LevelDB却不会存在这个问题;

其实这个问题标准确来说是 levelDB没有索引(官方文档有提到),但是Redis是有索引这个概念的,通过对一些关键字段建立索引,可以很快速的通过非key字段查询,我们的手游服务器使用的就是Redis数据库的,key就是玩家ID,然后里面存储一坨这个玩家的所有数据,要想使用其他字段去查询就得建立索引实现,索引的名称都是 _index_之类的。

可能是levelDB和Redis的应用场景不太一样吧,Redis适用于数据量不会很大,但又要求高性能的情况;而LevelDB解决的是海量数据操作,还要进行排序的处理,如果有太多复杂操作反而会处理效率问题,不过这仅仅是本人的猜测而已

Redis打破了我对关系型数据库的固有思想,昨晚看了LevelDB和HyperDex的介绍,顿时觉得技术宅称霸世界,不过平时仅仅接触过俩三万条的Redis,对这LevelDB和HyperDex没有具体的使用过,只能自己搭一个玩玩了

好吧, 这也是某种意义上的"索引"...

另外, SSDB 支持 Redis 一样的操作. 你原来用 Redis, 改为 SSDB 之后, 代码可以几乎不做改动就直接使用. 如果你使用 SSDB, 也可以建立和 Redis 一样的"索引", 提高性能, 排序和复杂操作不会有问题.

0
i
ideawu

Hi, 你说的 Index 是指什么呢? Redis 同样没有"索引"的概念, 所有的数据都是通过 key(kv, hash, zset) 来获取的.

SSDB 的性能非常高, 大部分情况下是 Redis 性能的一半, 但存储的数据量却超过 Redis 上百倍.

0
第一菜鸟
第一菜鸟

引用来自“ideawu”的答案

Hi, 你说的 Index 是指什么呢? Redis 同样没有"索引"的概念, 所有的数据都是通过 key(kv, hash, zset) 来获取的.

SSDB 的性能非常高, 大部分情况下是 Redis 性能的一半, 但存储的数据量却超过 Redis 上百倍.

嗯是的,Redis会受限于内存大小,而LevelDB却不会存在这个问题;

其实这个问题标准确来说是 levelDB没有索引(官方文档有提到),但是Redis是有索引这个概念的,通过对一些关键字段建立索引,可以很快速的通过非key字段查询,我们的手游服务器使用的就是Redis数据库的,key就是玩家ID,然后里面存储一坨这个玩家的所有数据,要想使用其他字段去查询就得建立索引实现,索引的名称都是 _index_之类的。

可能是levelDB和Redis的应用场景不太一样吧,Redis适用于数据量不会很大,但又要求高性能的情况;而LevelDB解决的是海量数据操作,还要进行排序的处理,如果有太多复杂操作反而会处理效率问题,不过这仅仅是本人的猜测而已

Redis打破了我对关系型数据库的固有思想,昨晚看了LevelDB和HyperDex的介绍,顿时觉得技术宅称霸世界,不过平时仅仅接触过俩三万条的Redis,对这LevelDB和HyperDex没有具体的使用过,只能自己搭一个玩玩了

i
ideawu
你可以介绍一下你们的业务? 例如这样: 保存用户信息 redis.set(uid, user_info_str) 获取排行榜: redis.zRangeByScore(xxx_index_, 0, 10) ...
返回顶部
顶部