游戏服务器存储数据库选型
数据库选择历程
我们的项目一直使用 MySQL作为数据库。无论是从 C++的服务器，还是到
Golang服务器。当年搞服务器时，看大部分人都是用 SQL(MySQL/SQLServer)，
而 Mongo感觉像邪教一样，再加上服务器还是 Linux比较正统，所以果断选了
MySQL。
刚开始感觉，游戏服务器的数据存储其实应该是蛮神圣的过程。那么多的数
据， 需要按照 MySQL一样分表，分字段存储，为了查询，还要乖乖的学一下
SQL的语法。
就这么折腾了几年，在云 DB的蒙蔽下，一直认为 MySQL就是做游戏服务
器存储的专业技术。分布式和存储压力一定交给云 DB来做。直到真正试了下
NoSQL在游戏服务器开发里的思路。
用了 Golang，才发现同步写逻辑是多么的优雅。
用了 NoSQL系列的数据库，才意识到: 游戏服务器的数据存储和游戏服务
器的存盘两个概念差异其实蛮大的。
MySQL中，背包其实跟角色完全没有关系，只是通过 1个角色 id映射过去，
人为的割裂了数据的关联性。还硬生生的整出个概念叫结构化查询让你学。
NoSQL中，只是把数据库当成是存储点，每个角色的数据是完整的一块。
里面怎么存随你便。每个角色通过 id来查询，其他都没有了。
于是乎，游戏开发变得异常简单。MySQL角色进门查询 4~5次才能搞定要
的数据。而 NoSQL一口气全查出来，存盘也无需增量，直接存盘就可以了。
所以现在觉得，NoSQL的思路对于游戏服务器存储来说简直是完美的！
NoSQL数据库方案对比
NoSQL下实现方案很多，游戏常用的就这么 3家: mongo， redis，
memcached
下面说下优缺点
mongo
磁盘映射内存数据库
value为 document类型，基于 BSON的 value序列化
应用场景:
适合多写少读，例如日志和备份
redis
内存数据库
单核
value限制 512M
多种 value类型，游戏用途使用私有的序列化协议(例如 protobuf)
支持落地(bgsave)
用户: 新浪，淘宝，Flickr，Github
应用场景: 适合读写都很高，数据处理复杂等
memcached
内存数据库
多核
value限制 1M
不支持落地(持久化)
用户: LiveJournal、hatena、Facebook、Vox
应用场景: 动态系统中的缓冲，适合多读少写
个人评价
memcached 适合网页缓冲，游戏里很少有使用。目前只有腾讯云支持云
memcached。
redis非常适合游戏的内存数据库，但是落地策略会比较复杂，需要具体分
析，可以参考后面的链接看下云风怎么处理这个问题。
mongo数据库在早期还是非常不错的 NoSQL的数据库。工具比较方便，可
视化。但是随着近年来游戏的并发度越来越高， 所以为了一次到位，很多人还
是选择了 redis。
游戏服务器存储数据库选型
