又是那个词
当人们说“社交数据不是关系型数据”时，并不是他们说的意思。他们的意思是下面两个方面： 1.“从概念上说，社交数据是一个比表集合更大的图谱。”
这绝对是正确的。但是很少有概念自然的提及模式化表是标准化的。我们用结构化表示是因为它行之有效，这样做可以减少冗余，而且我们可以解决它变慢的问题。 2.“当在非标准化的单文档结构中查询所有社交数据时是很快的。”
这也是绝对正确的。当你的社交数据是按照关系型存储时，你为特定用户取出活动流将要在许多表中查询，并且当表越大速达越慢。然而，我们可以用简单的方式来解决这个问题。那就是缓存。
在牛津早些年的数据库会议中，我曾做过一个这样的报告，我强烈推荐你看看Neha Narula谈论有关缓存的报告。无论如何，缓存让标准化数据存储变得复杂，但行之有效。我也曾看过缓存非标准化的活动流为一个文档结构，比如说MongoDB，它会让检索数据变得更快。但存在缓存失效的问题。
“在计算机学科中有两个头疼的问题：缓存失效和命名” Phil Karlton 他提出缓存失效的问题是很难解决的。Phil Karlton写过SSL版本3、X11和OpenGL，所以他对计算机了解的还是很多的。 缓存失效作为一个服务
那什么是缓存失效，为什么解决它很难？
众所周知，缓存失效就是缓存数据过期，它需要更新或是替换了。这里有个在网络应用中经常见的例子。我们有个后台存储器，典型的是PostgreSQL或MySQL，前台有一个缓存层，典型的结构是Memcached或Redis.请求读取用户的活动流时直接从缓存拿数据显然要比从数据库拿快的多。
典型的缓存和后台存储安装 应用的写操作更加复杂。让我们说说两个粉丝都写了一个消息的情况。首先发生的就是(第一部分)这些消息被复制和存储。一旦这些动作完成，后台将进入下一段工作(第二部分)将这些消息放入所有粉丝的活动流缓存中。
这种模式是很常见的。Twitter将近期活动用户的活动流都放入内存缓存中，当有粉丝发送消息时也将这些消息添加到缓存中。甚至是很小应用使用这样的活动流时也是这么做的(看看：7个表联合查询)。 回到我们的例子。当作者修改现存的帖子（post）时，更新过程在本质上与创建是一样的，唯一不同的是它不是增加到缓存，而是更新一个已经存在的条目。
如果步骤2的后台作业中途失败会怎样呢？机器重启了，网络线缆插头被拔掉了，应用重启了。在我们的工作中，不稳定是唯一不变的变量。当那些事情发生的时候，你将会被缓存中的非法数据整崩溃。一些帖子的拷贝是旧的标题，而另一些拷贝却是新的标题。这是一个严重的问题，但是对于缓存而言，经常会有这种毁灭式的情况。 
经常的一种情况 >_< 你完全可以从缓存中删除整个活动流记录，并从持久化的后台存储中重新生成它。这或许很慢，但至少这是可能的。
如果没有后台存储又会怎样呢？如果你跳过了步骤1呢？如果你仅仅只有缓存呢？ |
