有大量 key=>value 形式的值对，如:xxxx=>aaaaaaa，值一旦建立就不会更改，数量的话后期会达到百万级别，且经常会访问到，并发不高，但要保证数据完整。用什么方案去存比较好？
有大量 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吧，这样比较简单！
