操作，这正式Key-Value的使用场景。如确实有SQL要求并且数据量适中、性能要求不高的数据，可以使用CDB解决。
第二部分：云存储——数据层解决方案
看过应用开发过程中存储层方案变迁后，回到项目起始阶段，如果在应用开始设计时就考虑使用云存储来解决数据层的问题是非常明智的。一来可以快速开发，使开发者更加聚焦于应用逻辑开发和产品运营；二来减少数据层后期扩容、运维成本，减少故障概率。我们再从各个纬度来全面看下数据层是否使用云存储的优劣。
| |
自行设计和解决数据层问题 |
使用Cmem、CDB等云存储方案 |
| 开发门槛 |
熟悉LAMP架构和业界知名开源软件如Memcached、Mysql即可 |
Cmem兼容MemCached协议 CDB兼容Mysql协议 无门槛 |
| 研发效率 |
需投入专业人员进行数据层的设计和开发工作 |
无需关注数据层具体实现，通过云存储解决数据层性能、容量、安全及可用性问题，资源可投入到应用开发 |
| 运维质量 |
1、数据层开发要求高，设计时的疏忽可能带来运维中的重大数据灾难； 2、经常的重构和各类数据运维操作带来额外风险； 3、业务极速增长带来资源的压力，经常会导致系统过载 |
1、成熟可靠的存储层方案，保障数据安全和可用性； 2、全面的监控告警、自动容错机制； 3、云端资源池共享，支持业务的极速成长 |
| 运营成本 |
1、以实际设备投入来计算，即便只用了1/10的资源； 2、需提前准备资源来应对可能的业务突发； 3、业务开发人员兼顾数据层优化，性能提升有限 |
1、以实际使用资源来核算； 2、云存储资源的复用，资源单位成本小于直接使用物理资源； 3、专业数据层研发团队，从应用到硬件的极致优化 |
表1
可见，无论从性能、效率、质量、成本各个方面来看，对于第三方开发者来说，云存储都是更优的选择，不过这里还是有些研发模式的转变的。这一部分将就如何在云存储下进行数据层的设计进行一些分享。
我们分析了App常用的数据类型、场景和访问情况，有一些基于Key-Value的App数据设计参考方案供参考。目前对于各类应用来说，所用到的主要数据类型大致有以下几种：
| |
数据类型 |
示例 |
数据量 |
读取量 |
修改量 |
| 1 |
用户资料 |
昵称、等级、金钱、经验 |
中 |
多 |
多 |
| 2 |
背包数据 |
农场游戏的田地、果实等 |
大 |
多 |
多 |
| 3 |
Feeds |
“小明摘了我的菜” “小白帮我捉了虫” |
大 |
少 |
中 |
| 4 |
留言信息 |
好友留言、系统消息 |
小 |
少 |
少 |
| 5 |
购买物品 |
用户装饰、游戏道具 |
小 |
少 |
少 |
| 6 |
成果归档 |
某用户升级到30级 |
大 |
少 |
少 |
| 7 |
其他 |
好友排名、游戏排名 |
中 |
多 |
少 |
表2
除了第7点的排序工作外，通常应用对各类数据的在线访问都是以Key的形式来访问Value，并不会用到SQL功能。比如用户经验值成长了，我们根据用户id取出用户资料，修改经验值并设置回去就行了。特别是前几类高访问量的数据，非常适合Cmem的高性能存储场景。同时，将不同类型的数据分开存放在不同的数据表中是有好处的，同类数据的局部化可以方便Cmem根据不同模型进行更好的优化。
那么有没有场景是涉及到多条记录操作的，答案是有。比如农场游戏中A摘了好友B的萝卜，A的数量要增加，B的要减少，就涉及到多个记录的修改了。这个时候在分布式场景中如果要使用事务是极其不理智的，即便能实现（没有分库分表），在实际使用的性能消耗也非常高，基本上不可承受。其实上是有折衷的方案的，比如先增加A的数量，再减少B的数量，这时出现问题的概率非常小，而且出现了也不会影响游戏效果和用户体验，但换来的却是系统扩展性和性能的大幅提升。在实际使用中，有的应用自己简单实现了一个非常轻量的transaction模块，效果也非常好。
针对表2中的各类数据类型，我们给出了建议使用场景，这里主要是根据访问密度和数据量2个纬度来衡量（Cmem具备更高的性能和扩展性，CDB提供SQL支持），下表中“访问密度高”表示>500iops/GB，“数据量高”表示>150GB。
| 访问密度 |
数据量 |
推荐云存储方案方案 |
示例数据 |
| 高 |
高 |
Cmem |
背包数据 Feeds |
| 高 |
低 |
Cmem |
用户资料 |
| 低 |
高 |
Cmem（数据量有持续增长的需求） |
成果归档 |
| CDB（数据量相对固定且有SQL的需求） |
好友排名、用户排名 |
| 低 |
低 |
CDB |
购买物品 留言消息 |
表3
根据上述一些原则，结合实际的应用策划，如果在早期能合理的进行数据层的规划，那么就可以避免在后期遭受巨大的数据层运营挑战。那么，Cmem和CDB能解决所有的数据层问题吗，显然它们不是万能的，不过它们能解决我们目前在线上业务中最棘手的在线数据访问的根本问题。解决了这个，其他问题都好办了。如果还有什么疑问，请访问yun.tencent.com，那里有更多的信息和解答。
第三部分：应用云存储的一些遗留问题
1、事务操作
应尽量通过业务逻辑来避免事务，在Social Game开发中使用事务是极其不明智的行为，当然支付类操作除外，不过这个不属于游戏数据的在线访问，腾讯云平台也提供了相应的解决方案；
2、统计分析
提供数据导入到DB的功能，但DB分析能力终归是有限的，计划日后提供类似MapReduce原理的分析工具；
3、游戏运营
比如需要对金钱<100的用户统一送2000金币，如果碰到这类问题，分析系统+操作工具应该是个不错的选择，直接去数据库修改太危险了，不是吗？
4、用户排名，搭建额外的排名系统，效率更高
设计个专用的排名系统把，逻辑实现即可，既高效又不影响在线数据的访问。