有大量 key=>value 形式的值对,如:xxxx=>aaaaaaa,值一旦建立就不会更改,数量的话后期会达到百万级别,且经常会访问到,并发不高,但要保证数据完整。用什么方案去存比较好?
其实把问题再问得完整一点自然就有答案了
被访问的方式,除了“经常会访问到,并发不高”之外,访问的形式是单key查询还是查多条?数据是否有序?是否有类似“搜索key前缀为foo”的需求?有“列出10个key”的需求?有“列出全部key”的需求?访问是随机key的还是集中在部分热点key值?冷热key值的比例大概怎样?目前并发不高,是否需要考虑后期并发增加以后的方案?
数据完整,是否需要备份?key增加的频率如何?新增加的key是否立刻需要能访问?
key和value的长度分别是多少?百万条1K是一条内存条,可百万条1M就是一块磁盘了
一般而言,条件不是特别极端的话,选单redis&备份,单mysql&备份,或是mysql+redis都行,各有长短,看你想要什么和你手里有什么资源来找平衡点了
PS:别忘了mysql还分ssd上的mysql和机械磁盘上的mysql,也是各有优劣的
redis 比较方便 一般放内存里 也可以放硬盘
并发不高,数据库,百万级别单表够了;并发高的话,前面加一层memcached
从你的需求上面主要针对两个点:值一旦建立就不会更改,以及保证数据完整。
数据库是跑不掉的,目前在保证数据完整性方面数据库是首选,同时也是最通用最值得信赖的。而针对数量的话后期会达到百万级别,且经常会访问到,并发不高这三个点可以考虑使用内存数据库提供访问效率,如redis,数据结构使用普通的k-v结构即可。
memcached
根据key哈希到不同的文件中, 根据访问量来决定要不要加一层内存cache
用mysql存储,然后前面加redis做缓存。
只是Key-Value的话,可以不用放数据库.找一些kv型的nosql就可以用.有持久化的话,可以考虑redis,或者SSDB之类的.Nosql上可以很容易做基于key的分片来解决你的数据容量和访问量的问题.
直接用apc吧,这样比较简单!