为社交游戏选择正确的数据库

1.概述

对于社交游戏（游戏与社交网络高度结合）来说，在设计之初，就应该考虑到未来用户的飞速增长，有时可能在一夜之间就步入百万级了。比如之前很火爆的“围住神经猫”，借助微信朋友圈的传播，在3天内就破了一亿次点击并拥有了500多万的独立用户，类似的例子还有很多。要更好的解决这样的数据增长，同时还要保证游戏的可玩性和稳定性，社交游戏的开发者来说会在游戏开发的每一层上遇到不小的挑战。为了能有效地运行这样的在线操作，一个坚实高效的后台系统是必须的。其中，选择一个对的数据库，是建立一个高效后台的步。

社交游戏是一个需要人气的产品，每个游戏开发者都想要能在短时间内获得大量用户的青睐，并且能一直牢牢抓住这些用户。为此，不仅游戏开发之初需要具备创新的内容以及更好的用户体验，为了抓住用户，游戏还需要在运营的过程中，不断的吸收反馈做出改变，同时也需要不断添加新的内容、新的功能来吸引用户继续玩下去。因此，数据库的选择就更为重要了，否则后台系统将没办法跟上游戏快速改变和增减的这一种特性。

举个例子，之前某游戏公司发布了一款游戏名为“The Simpson’s: Trapped Out”的游戏，因为基于的动漫辛普森一家，所以游戏在发布初期就取得了很快的发展和传播，很快就登上了App Store下载量的第二位，然而，在登上第二名的四天之后，这款游戏就很快的掉出了榜单并且很快就从人们视野中消失了。该公司没有公布相关的解释，但是据众多的该游戏玩家反映，游戏在快速增长之后，游戏体验迅速下降，不仅载入缓慢，甚至还出现了资料信息错误的情况。很显然，这就是没有使用正确的数据库架构的后果。

那么，哪一种数据库是适合的呢？事实上，NoSQL数据库就能完美的适应社交游戏的需要，如今，已经有许多的移动游戏厂商和社交游戏厂商选择了NoSQL数据库作为它们的后台系统的底层数据库。下来我就将介绍一下NoSQL数据库的特性以及其如何能完美的适应社交游戏的需求。

2.大用户量+快速增长 vs. 水平扩展

社交游戏中，游戏与社交网络的紧密结合，使得游戏团队不仅需要处理庞大的用户基群，还需要处理由社交网络的传播效应带来的大量新用户，很可能每天就会增长几十甚至上百万。如果作为一个个独立的单机游戏来处理，那就十分简单了，可是因为是基于社交网络，一旦用户之间出现联系，因为社交网络的好友关系比普通游戏的用户更密切，所以当两个用户建立联系之后，他们的朋友圈子很有可能存在更多的交集和互动的可能，这样需要处理的业务量随着用户的增长将会呈指数性的增长。也正因为如此，扩展性对于应对大量快速的用户和数据增长是至关重要的。对于社交游戏，数据库的扩展性需要具备以下的特性：

快速、规模化的水平扩展性：针对上述的场景，首先需要的是数据库需要具备大规模水平扩展性。随着数据量的爆发增长，社交游戏对于容量和处理器的需求也会大幅增加，这时，水平扩展的规模就标志了这款游戏所能容纳的多的用户数量。而NoSQL中近乎无限的水平增长就正好突破了所谓容量的上限，让数据库容量不再成为一个限制。

扩展的快速：速度对于社交游戏的数据扩展至关重要。若扩展性不够快速，在游戏环境和用户场景不断增加和变化的情况之下，就不能跟上产品发展变化的步伐，成为拖累产品的一个短板。NoSQL数据库对于快速灵活同样表现出色，其可以根据需要对数据库进行扩展，同时分布式架构以及众多的服务机制也提供了简化和高效了扩展的操作。

高效的自动分区：当数据节点负载过大时，就需要进行扩展，而扩展之后并不是单纯把新的数据存入新节点，而是需要在节点之间对负载进行均衡，这就需要数据库的自动分区（auto-sharding）功能了。高效的自动分区不仅能在需要时快速的将数据库进行分区操作，同时在分区操作的过程中还要确保数据的安全。

扩展性是数据库应对快速、大量的数据量变化的好方式，NoSQL优异的扩展性恰好完美的适应了这样的应用场景。

3.游戏响应 vs. 数据库性能表现

作为一类基于网络的游戏，社交游戏和其他的网络游戏一样，需要有的游戏响应。如果玩家不能够快速准确的完成一个游戏操作，比如，玩家在游戏中购买了道具，希望能利用道具来帮助自己取得战斗的胜利，可是购买的道具直到战斗结束都还没有更新到可用道具列表当中。这对玩家的积极性和体验都是极差的，很可能就因为这些不流畅的表现而一票否决了游戏的所有其他优点。

文档型和K-V型的NoSQL数据库通常都能很好的表现出高性能，他们都将相关的数据存放于同一个文档存储于内存或磁盘中，这样再调用的时候就能比需要链接不同表的RDBMS快速许多。但是NoSQL之间也是不同的，游戏所需要的是能稳定的提供小于毫秒（ms）级别的延迟性的数据库，这里的稳定是指所有的数据库操作，无论读、写还是扩展分区等都应该保证响应的快速。

此外，网络游戏通常都有数十万计的玩家同时在线进行操作，这对于后台系统和数据库的并发性也就相当的高了。处理并发操作一直是数据库性能提升的一个重要瓶颈，其中锁的机制就是限制并发性的一个重要因素。形如MongoDB这样粗糙的锁机制，在面对高并发高负载的情况下，非常容易出现延迟甚至宕机。为了保证高并发，NoSQL还需要对于锁机制进行精心的设计，比如尽量避免锁操作或者建立更完善高效的锁机制。

数据库的性能表现直接影响了玩家的游戏体验，所以选对高性能高并发的数据库是游戏后台系统开发的首要任务。

4.免费玩 vs. 低花费

通常，基于社交网络的游戏都是免费的，但是游戏的运营却不是免费的，而通常只有小部分的玩家会花钱在这些游戏上。这样，游戏开发和运营的成本就成为重要的考量因素了。因此，他们需要一款能满足扩展性和高性能的数据库，却又不能花费太多在购买和后期的维护上。而同时，你还得想到游戏获得成功之后的快速发展，届时后台的需求将会不一样，如果不在一开始做好数据库的规划，那么临阵磨枪将对整个产品造成坏的影响。

为此，现在许多的社交游戏都选择了NoSQL数据库，不仅因为NoSQL具备了上述的扩展性和高性能，还因为NoSQL数据库基本都进行了开源，社区版的使用都是免费的，再配合上亚马逊AWS之类的云平台，可以将游戏的后台花费降到小。除此之外，NoSQL对于游戏快速发展后也能得心应手，也就是上述的可扩展和高性能表现。有了这样的可以很好适应社交游戏开发和发展的所有阶段的NoSQL数据库，为什么不选择它？

5.快速变化的游戏环境 vs. 灵活的数据模型

社交游戏市场竞争非常激烈，玩家的数量就是游戏是否成功的标准。玩家的选择面非常多，现有的游戏种类已经非常繁多，同时还不断有各种新游戏加入到竞争当中。在这样的一个快速发展、充满竞争的环境下，游戏需要能快速的迭代也要不断的改进已有的部分。特别是游戏进入发展期之后，快速迭代对于维持新鲜度、吸引玩家和扩展新玩家都有着重要意义，游戏开发人员也不能容忍过长的设计周期和发布周期。

文档型NoSQL数据库正好提供了灵活的数据模型，使得开发者能快速的修改内容，JSON文件作为存储格式，不仅支持多样的平台和架构，JSON这样的无模式数据模型也是非常灵活和易于修改的。如果要增加新的数据类型，只需要将这些数据放入何时的JSON文档当中就可以。这样一来，就不需要DBA来设计操作模式、数据转移和重新对接应用程序了。在数据层，文档型的NoSQL相比K-V和列式的NoSQL还能更好地支持复杂的索引和查询操作。

灵活的数据类型作为NoSQL的一大特点，正好符合社交游戏对于快速变化的游戏环境的需求。

6.全球化游戏 vs. 数据库实时在线

社交游戏和现在的其他游戏一样，是面向全球的 24x7x365在线的。如果游戏因为维护或者故障需要暂停服务一段时间，对于玩家是非常失望和不开心的，这也会让游戏厂商损失一大笔钱。理想的情况，就是能做到持久的在线不需要暂停，无论是软硬件更新或者是服务器故障。

“分区组”这一机制就很好的解决了这一问题，一个分区组中，数据节点有三个，主数据节点可以读写信息，之后通过异步复制将数据备份到两个只读的从节点中。不仅数据通过备份大大提高了安全性和可用性，主-从节点的设计还可以实现“读写分离”，写操作在主节点进行，其他后台读操作可以调用从节点的数据而无需暂停写操作，这样不仅提高了并发性，也避免了读写操作之间出现的冲突。

此外，NoSQL数据库还能：简便的增删节点，不影响其他的集群和节点；完善的数据备份和恢复机制，保证数据安全；SequoiaDB等NoSQL还加入了事务功能，更好支持应用。

7.结论

如果你在思考用什么样的数据库来构造社交游戏的后台，那么这款数据库需要具有扩展性、稳定性、高性能以及灵活的数据模型。答案已经显而易见了，就是文档型的NoSQL数据库。SequoiaDB 巨杉数据库,作为一款领先的文档型NoSQL数据库，它领先业内的高性能、近乎无限的水平扩展能力、的稳定性和安全性以及多样的开发语言、平台架构支持，让其成为了社交游戏和移动游戏开发的佳选择！

------------------------------------------------

MDCC 2014 大会将于2014年11月1日-11月2日，在北京新云南皇冠假日酒店举行。作为本次MDCC大会的合作伙伴之一，SequoiaDB(巨杉数据库)诚邀各位共赴展会现场，并希望大家能到我们的展位（展场3层T20）与我们做更进一步的交流！

SequoiaDB 官网：

www.sequoiadb.com

SequoiaDB 免费社区版下载试用 ：

www.sequoiadb.com/index.php?p=downserver

SequoiaDB官方微信号：SequoiaDB_BigData