图片来源：https://blog.engineyard.com/2013/maintaining-cross-platform-functionality-and-scalability
在《排行榜是怎么算出来的？》一文里，我们把服务器想象成了一面很大的墙，墙上有很多抽屉。当你在某一局游戏里玩了567分后，游戏会把你的名字和分数一起，寄送给服务器。服务器收到之后，会打开一个空抽屉，把567这个数据放进去，并在抽屉上贴一个标签，上面写下你的名字。
这篇文章我们继续讨论一下这个抽屉具体是怎么回事，以便尽早摆脱这个比喻。
想象一下你走进FBI的档案室，这时候你看到了一个满是抽屉的柜子，每个柜子上贴着一个通缉犯的ID，你打开一个贴着“通缉犯_007”标签的抽屉，在里面发现了一张表格，这张表格是这位通缉犯的简历：
昵称：Jack爱放盐，
性别：男，
籍贯：德克萨斯州，
政治面貌：清白，
追捕原因：走私、贩卖咸豆腐脑
这张简历里，排在左边的昵称、性别、籍贯叫做键（Key），排在右边的Jack爱放盐、男、德克萨斯州这些叫做这个键所对应的值（Value）。这张由许多键值对构成的简历叫做一个文档（Document）。每份文档都贴着一个标签（例如“通缉犯_007”），以便索引，每个柜子像是一个数据集（Collection），而整个档案室就像是一个面向文档的数据库。
回到《水果忍者》这个例子，假设我们还要记录游戏者获得某个分数的时间，参考刚才FBI档案室的做法，服务器在收到游戏者寄送来的数据包时，需要记录如下一个文档：
昵称：Jack爱放盐，
最高分数：567，
获得时间：2014年5月4日
现在我们可以找一个叫做“排行榜”的柜子，把这个文档存在它的某个空抽屉里，并把这位游戏者的ID（例如“游戏者_001”）作为标签贴在抽屉的外边。除了“排行榜”这个数据集合以外，我们还需要其它的数据集，或许我们会有一个“玩家信息”的柜子，柜子的每个抽屉里都放着玩家的个人信息：
昵称：Jack爱放盐，
国家：美国，
签名档：咸还是甜，这是一个问题，
使用设备：iPhone7
所以，整个游戏的数据就是这么存储的：数据库里有很多个数据集，每个数据集里有很多个文档，而一个文档就是以某种格式（比如上面的键值对格式）来封装、组织数据的这么一个东西。
当然，这种面向文档的数据库并非存储数据的唯一方式，我们还有更传统的关系型数据库，还有基于节点和边的网络型数据库等等，我们甚至可以用自己定义的格式，把数据存储在各种文件里；这些数据有可能是保存在你的iPhone上（单机游戏），也可能是保存在某台服务器上（多人游戏）；但不管以何种方式存在哪里，这些数据都是对游戏世界的一种描述，是对游戏状态的一种持久化。
透过这些数据，我们可以看到它们所描述的世界，数据越多，关于这个世界的信息就越详细。当数据多到一定程度后，我们就拥有了一个传说中的“大数据”。这些数据是如此之庞杂，以至于其中许多变量之间的相关关系是无法一眼看出来的。这个时候，我们需要把这些有价值的相关关系挖掘出来。
等等，什么是相关关系，为什么我需要把相关关系挖出来？挖出来后能吃吗？
先说说什么是相关关系。数学上的定义太枯燥，所以请各位再次容忍一下我的不严谨。设想你在刚才的FBI数据库里取出了很多文档，并逐个观察每个文档里一个叫做“地域”的键和另一个叫做“豆腐脑喜好”的键，假设你发现“地域”值为“北方”的文档，“豆腐脑喜好”的值都是“咸”，而“地域”为“南方”的，“豆腐脑喜好”的值都是“甜”，那么我们就说这两个变量是有相关关系的，下次再看到一个文档地域为南，我们就能猜测它的豆腐脑喜好为甜。再比如游戏角色的级别越高，杀伤力也越高；一条微博的转发量越多，被阅读次数也多；一个物体受力越大，加速度就越大，等等。
尽管相关关系并不意味着因果关系，但它可以让你去猜测变量之间可能存在的因果关系，此外，对相关关系本身的理解也有助于我们对周围的世界获得更加准确的判断，但这一切都有个前提，就是你的数据库是没问题的。
遗憾的是，我们常常有意无意地在自己的数据库里做着数据挖掘：知乎用户太装逼，豆瓣用户小清新，处女室友太纠结，天蝎前任复仇心。地图炮这个群攻型的拉仇恨主动技，正是以此为理论基础的。如果你把我们的世界想象成一款游戏，那么每个人所掌握的数据都只是服务器上所有数据的一部分而已，由此得出的结论，难免有失偏颇。
网友评论