使用 MongoDB 持久化文档数据

有一些数据的最佳表现形式是文档（document）。也就是说，不要把这些数据分散到多个表、节点或实体中，将这些信息收集到一个非规范化（也就是文档）的结构中会更有意义。尽管两个或两个以上的文档有可能会彼此产生关联，但是通常来讲，文档是独立的实体。能够按照这种方式优化并处理文档的数据库，我们称之为文档数据库。

例如，假设我们要编写一个应用程序来获取大学生的成绩单，可能需要根据学生的名字来查询其成绩单，或者根据一些通用的属性来查询成绩单。但是，每个学生是相互独立的，任意的两个成绩单之间没有必要相互关联。尽管我们能够使用关系型数据库模式来获取成绩单数据（也许你曾经这样做过），但文档型数据库可能才是更好的方案。

文档数据库不适用的场景

文档数据库不是通用的数据库，它们所擅长解决的是一个很小的问题集。
有些数据具有明显的关联关系，文档型数据库并没有针对存储这样的数据进行优化。例如，社交网络表现了应用中不同的用户之间是如何建立关联的，这种情况就不适合放到文档型数据库中。

使用 Neo4j 操作图数据

文档型数据库会将数据存储到粗粒度的文档中，而图数据库会将数据存储到多个细粒度的节点中，这些节点之间通过关系建立关联。因为数据的结构是图，所以可以遍历关联关系以查找数据中你所关心的内容，这在其他数据库中是很难甚至无法实现的。

例如，社交网络图谱，在社交网络中，公司、员工、技能的信息，这些都是节点，它们之间的关系和朋友之间的关系都是边，在这里面图数据库可以做一些非常复杂的公司之间关系的查询。比如说公司到员工、员工到其他公司，从中找类似的公司、相似的公司，都可以在这个系统内完成。

使用 Redis 操作 key-value 数据

Redis 是一种特殊类型的数据库，它被称之为 key-value 存储。顾名思义，key-value 存储保存的是键值对。实际上，key-value 存储与哈希 Map 有很大的相似性。可以不太夸张地说，它们就是持久化的哈希 Map。
当你思考这一点的时候，可能会意识到，对于哈希 Map 或者 key-value 存储来说，其实并没有太多的操作。我们可以将某个 value 存储到特定的 key 上，并且能够根据特定 key，获取 value。差不多也就是这样了。